整数オーバーフローの「墓場」から生還する：Solidity 0.8以降の現実とエンジニアの心得
現場で幾多のスマートコントラクトを監査してきたが、いまだに「SafeMathがないと不安だ」と漏らすエンジニアがいる。ハッキリ言おう。Solidity 0.8以降の世界において、旧態依然としたSafeMathの乱用は、単なるコードの冗長化であり、むしろ可読性を損なうノイズでしかない。
今日は、かつてのDeFiプロジェクトを壊滅させた「整数オーバーフロー・アンダーフロー」という亡霊を、現代のコンパイラがどう屠っているのか、そして我々エンジニアがどこに注意を払うべきなのか、実務の最前線から解説する。
—
1. 脆弱性の本質：なぜ数字は「反転」するのか
コンピュータの算術演算において、数値は有限のビット枠（例えばuint256なら256ビット）の中に押し込まれる。この境界を超えたとき、数値は「0」に巻き戻る（オーバーフロー）か、最大値に跳ね上がる（アンダーフロー）。
攻撃者はこれを利用し、例えば「残高をマイナスにしてアンダーフローさせ、極大値のトークンを手に入れる」といった荒技を平然とやってのける。かつてはこれを防ぐためにSafeMathライブラリを全関数に噛ませるのが「宗教的な作法」だったが、Solidity 0.8からは言語仕様そのものが変わった。
2. Solidity 0.8以降の革命：デフォルトで「パニック」する
Solidity 0.8.0以降、算術演算はデフォルトで「オーバーフロー／アンダーフロー発生時に例外（Panic）を投げる」仕様になった。require文でチェックを書かなくても、コンパイラが自動的にチェックコードを挿入してくれる。
しかし、ここでエンジニアが陥る罠がある。
注意すべき「盲点」
- ガス代の増加: 全ての演算でチェックが入るため、極限までガス代を削りたい超高頻度な計算ロジックではコスト要因になる。
- 意図的なオーバーフロー: 暗号学的な計算や、あえてラップアラウンド（循環）させたいアルゴリズムを書く場合、この自動チェックは「お節介」となる。
そのために用意されているのが unchecked ブロックだ。
// Solidity 0.8以降のセキュアな実装例
function transfer(uint256 amount) public {
// 通常の演算は自動でオーバーフローチェックが働く（安全）
balance -= amount;
// どうしてもガスを節約したい、かつオーバーフローしないと確証がある計算のみ
unchecked {
// ここはオーバーフローしても例外を投げない
counter++;
}
}—
3. 実務で「やってはいけない」ことと対策
後輩のコードレビューでよく見かけるのは、「外部からの入力値を検証せずに計算に回す」ことだ。Solidityが算術演算を守っても、ロジック自体が破綻していては意味がない。
攻撃者に付け入る隙を与えないための実装ガイド
もしあなたがスマートコントラクトとやり取りするWebアプリケーション（フロントエンドやバックエンド）を構築しているなら、以下の点に留意せよ。
JavaScript側での防衛（BigIntの利用）
フロントエンドでトークン数を扱う際、JavaScriptのNumber型は安全な整数範囲が 2^53 - 1 までしかない。Web3開発でこれを使うのは自殺行為だ。必ず BigInt を使うこと。
// Web3.jsやethers.jsで数値を扱う際の鉄則
const balance = BigInt("1000000000000000000"); // 18桁のweiを安全に保持
const amount = BigInt(userInput);
if (amount > balance) {
throw new Error("残高不足です");
}
// ここで初めてコントラクトへ送信するバックエンド（Python）での防衛
Pythonは整数型が任意精度だが、API経由で受け取る「文字列としての数値」には常にバリデーションをかける。
# FastAPI等での入力チェック例
from pydantic import BaseModel, validator
class TransactionRequest(BaseModel):
amount: str
@validator('amount')
def validate_uint256(cls, v):
# 負の数や過大な数値を事前に弾く
val = int(v)
if val < 0 or val > 2**256 - 1:
raise ValueError("無効な数値範囲です")
return v—
4. 最後に：セキュリティリサーチャーからの警鐘
「ツールが守ってくれる」と過信した瞬間に、脆弱性は生まれる。
1. コンパイラ設定を確認せよ: solc の設定で viaIR: true を使う場合は、最適化によって予期せぬ挙動が出る可能性がある。常に最新のマイナーバージョンを追え。
2. unchecked は「最後の手段」: どんぶり勘定で unchecked を使うな。そこは攻撃者にとっての「スイートスポット」になる。
3. 静的解析ツールをCIに組み込め: Slither や Mythril は、Solidity 0.8以降でも、人間が気づかない論理的な脆弱性を見抜く。これを通さないコードを本番環境へデプロイしてはならない。
技術は進化するが、攻撃者の執念は変わらない。安全な演算は「言語仕様」に任せ、君たちは「ビジネスロジックの脆弱性」という、より高次元な戦場にリソースを割くべきだ。
コードは嘘をつかない。だが、書いた人間の「油断」はコードの中に潜伏する。常に疑い、常に検証せよ。健闘を祈る。
コメント