【ITニュース解説】8 Field Techniques for Smart Contract Auditing — Forged by Refuting My Own Findings

スマートコントラクトは、ブロックチェーン上で自動的に実行されるプログラムであり、一度展開されるとその動作を変更することが非常に難しくなる。そのため、開発段階でのセキュリティ監査は、予期せぬ脆弱性やバグによって重大な金銭的損失や機能不全を引き起こすことを防ぐ上で極めて重要となる。セキュリティ監査を行う際には、単にコードの表面的な構造を追うだけでなく、より深く、多角的な視点からコントラクトの安全性を検証する実践的なテクニックが存在する。

まず一つ目のテクニックは、プログラムの機能を読み始める前に、そのコントラクトが構築する「経済モデル」を再構築することだ。オークションや貸し借り、エスクローのような仕組みを持つコントラクトでは、誰が誰にいつ、どのような権利に対して支払うのか、というお金や価値の流れをまず明確に理解することが重要である。攻撃者は多くの場合、この基本的な経済モデルの隙間を突いて、無料で利益を得ようとする。この経済モデルを先に理解することで、コードのどの部分が重要で、どのような状態の変化が攻撃の糸口になり得るのかを効率的に見つけ出す手助けとなる。

次に、過去の監査で修正された箇所の「パッチの痕跡」を追うことが有効な方法である。コードのコメントなどに残された以前の修正IDは、これまでのレビューアがどこに注目し、どの部分を重点的に精査したかの地図となる。修正IDが多く密集している部分は、すでに安全性が確認されている可能性が高い。しかし、修正IDが少なく、かつ外部のコントラクトとのやり取りが多い部分は、これまでの監査で見落とされている可能性があり、新たな脆弱性が隠れている「狩り場」となり得る。

三つ目のテクニックは、コード内にある「もし〇〇なら処理を中止する」といった条件チェックが、実際に「どのような損失の範囲」をブロックしているのかを具体的に問うことである。例えば、「持ち分がゼロなら処理を中止する」というチェックは、利用者が資産を完全に失うような特定の攻撃は防ぐかもしれない。しかし、部分的な損失を引き起こす攻撃には対応できない場合がある。見かけ上の保護が、実は限定的なケースしかカバーしていない「見せかけの保護」であることが多く、それが本当に防ぐべき全ての損失を防いでいるのかを厳密に問い直す必要がある。

四つ目は、数値計算における「丸め処理」で発生する小数点以下の「端数（dust）」が最終的に誰に渡るのかを追跡することである。割り算などの計算で生じるわずかな端数は、切り捨てられる際に特定の利用者やシステム、あるいは最悪の場合、攻撃者の利益となる可能性がある。この端数がファンドの元々のソースに戻るなら安全だが、プロトコル（コントラクト自体）の利益となるなら注意が必要な設計とみなされ、攻撃者の手に入るなら明白なバグである。この端数の行方を明確にすることで、潜在的な収奪や不公平を特定できる。

五つ目のテクニックは、スマートコントラクト内で常に正しい状態を保つべき「不変条件」を追跡することだ。例えば、「預かり金の残高は常に予約されている最低額以上であるべき」といったルールが不変条件にあたる。この不変条件が最初に設定される場所、そしてその後、誰がその値を変更し、誰がその条件を再計算するのかを特定する。一度設定された不変条件が、その後のどんな変更操作によっても自動的に守られるような設計になっている場合、多くのセキュリティ上の懸念が解消され、コントラクトの堅牢性を確認できる。

六つ目は、外部のコントラクトを呼び出す可能性のある「コールバックポイント」を全て列挙し、それぞれでセキュリティ原則が守られているかを確認することである。スマートコントラクトが外部のコントラクトとやり取りする場所は、思っているよりも数が少ないことが多い。それらを一つ残らず洗い出し、各ポイントで「Checks-Effects-Interactions (CEI)」というセキュリティパターン（まず条件を確認し、内部の状態を変更してから、外部のコントラクトを呼び出す）が守られているかを検証する。これにより、外部呼び出し中に同じコントラクトを再呼び出しして不正な操作を行う「再入攻撃」のリスクを網羅的に評価できる。

七つ目のテクニックは、ある処理が失敗した場合に、何らかの資源が消費されてしまう「失敗時消費設計」の場合に、攻撃者が意図的に失敗を引き起こせるかを問うことである。例えば、一度きりの使用が許されるトークンが、何らかの理由で処理が失敗しても消費されてしまう設計があったとする。このとき、もし攻撃者が故意に失敗を引き起こすことで、他者の貴重な資源を無駄に消費させることができるならば、それはDoS攻撃（サービス妨害攻撃）や嫌がらせ攻撃の脆弱性となる。失敗の原因が外部環境（例えば、古い情報データや時間の経過）によるものであれば問題ないが、攻撃者が任意に失敗を誘発できる場合は危険である。

そして最後の八つ目のテクニックは、発見した脆弱性の仮説を、最小単位（例えば、イーサリアムの通貨単位である「wei」のような極小単位）レベルまで「厳密な数値で計算して検証する」ことだ。抽象的な「教科書的な攻撃パターン」が、実際のコントラクトの特定の条件や実装（例えば、特定の預金プロファイルや既存の他のチェック）では成立しないことが多々ある。例として、トークンのインフレーション攻撃の仮説があったとしても、そのコントラクトが採用している償還ロジックや預金条件によっては、仮説通りの損失が発生しない場合がある。厳密な数値計算による裏付けがなければ、どんなに巧妙に見える攻撃仮説も机上の空論に過ぎず、信頼性の高い監査報告にはならない。

これらのテクニックは、コードを単に読み解くだけでなく、その背後にある経済原理、過去の教訓、数学的な厳密性、そして外部との相互作用に深く目を向けることで、より効果的に脆弱性を特定し、あるいは自身の発見が誤りであることを証明するために役立つ。厳密な検証と、自己の発見を客観的に反証する姿勢が、高品質なスマートコントラクト監査には不可欠である。