Reentrancy Attack

リエントランシー攻撃とは何ですか？一般的に理解されている「ハッカーが秘密鍵を盗む」こととはどう違いますか？

リエントランシー攻撃が狙うのは秘密鍵や利用者の署名行為ではなく、スマートコントラクトのコード自体が持つ実行順序上の論理的な欠陥である。多くのコントラクトの引き出しロジックは、理論上「残高を確認し、残高を差し引き、それから資金を送金する」という順序に従うべきだが、もしコントラクトが「先に資金を送金し、その後で残高を差し引く」という順序で書かれていた場合、危険な空白期間が生じる。資産は既に送金されているのに、帳簿はまだ更新されていないのだ。攻撃者はまさにこの空白期間を利用する。悪意あるコントラクトが送金を受け取った瞬間に、直ちに同じ引き出し関数を再び呼び出す。この時点で帳簿上の残高はまだ差し引かれていないため、コントラクトは「このアカウントにはまだ引き出せる資金がある」と誤認し、再び資金を送金してしまう。そしてこのコールバックは同一の取引の中で数十回も再帰的に発生しうる。

ハッカーによる秘密鍵の盗難との本質的な違いは次の点にある。秘密鍵の盗難は利用者を騙すか鍵を直接入手することに依存するが、リエントランシー攻撃は利用者や秘密鍵に一切触れる必要がない。単純に攻撃者が悪意あるコントラクトをデプロイし、標的となるコントラクト自体のコードに存在する実行順序の脆弱性を利用して、標的コントラクトに対して攻撃を仕掛けるだけである。被害を受けるのはコントラクトが管理する資産プール全体であり、特定の利用者のウォレットではない。

なぜこの脆弱性が存在するのですか？ブロックチェーンセキュリティの歴史においてどのような特別な位置を占めていますか？

リエントランシー攻撃が存在する理由は、イーサリアムのスマートコントラクト設計における一見無害な機能に由来する。コントラクトは資金を送金すると同時に、受取側のコード（fallback関数やreceive関数などを通じて）を呼び出すことができる。この設計は本来、受取側のコントラクトが資産を受け取った後に自身のロジックを実行できるようにするためのものであり、コントラクト間のやり取りの基礎的な仕組みの一つであって、それ自体には何の問題もない。問題が生じるのは、開発者が「外部コントラクトを呼び出す」という動作が、本質的にプログラムの実行権を一時的に相手に渡すことを意味していると認識していない場合である。相手はその間に何でもできる。あなたのコントラクトに何度も呼び戻すことも含めてだ。

この脆弱性がブロックチェーンセキュリティの歴史において特別な位置を占めているのは、これがまさに2016年のThe DAO事件の攻撃原理そのものだからである。攻撃者はThe DAOのスマートコントラクトの引き出し関数にあった「先に送金し、後で残高を更新する」という順序の脆弱性を利用し、繰り返し再帰的に引き出しを行い、最終的に当時の価値で約6,000万ドル相当のイーサを盗んだ。この事件はイーサリアムコミュニティが資金を取り戻すためにハードフォークを実行するまでに至り、チェーンはイーサリアム（ETH）とイーサリアムクラシック（ETC）に分裂した。これが、リエントランシーがスマートコントラクトセキュリティ教育において最も基礎的で、必ず理解しなければならない教訓とみなされている理由でもある——それは古いからではなく、10年後の今日でも、全く同じ論理的欠陥が新しいプロトコルで繰り返し発生しているからである。

リエントランシー攻撃は実際にどのように発生し、開発者はどう防いでいるのですか？

典型的な攻撃の流れはいくつかのステップに分かれる。まず攻撃者が悪意あるコントラクトをデプロイし、標的コントラクトに少額の資金を預けて正当な引き出し資格を得る。続いて標的コントラクトの引き出し関数を呼び出す。標的コントラクトが「先に送金し、後で残高を更新する」という順序で実行される場合、資金を送金した瞬間に攻撃者のコントラクトのfallback（またはreceive）関数がトリガーされ、攻撃者はこの関数の中に「直ちに引き出し関数を再び呼び出す」というロジックをあらかじめ仕込んでおく。この時点で標的コントラクトの帳簿はまだ更新されていないため、攻撃者の残高は依然として元の金額のまま表示され、引き出しリクエストは再び承認される。このプロセスは同一の取引の中で数十回再帰的に繰り返され、コントラクトの資金プールが枯渇するかガス上限に達するまで続く。攻撃全体は発動から完了まで、多くの場合1回の取引と数秒で完了する。

開発者がこの脆弱性を防ぐための標準的な手法は「チェック・エフェクト・インタラクション（checks-effects-interactions）パターン」と呼ばれる。まず全ての条件チェック（残高が十分かどうか）を実行し、続いてコントラクトの内部状態を更新し（先に残高を差し引き、帳簿を「既に引き出し済み」に変更する）、最後に外部呼び出し（実際に資金を送金する）を実行する。「帳簿の更新」という動作を「送金」より前に配置するだけで、攻撃者がコールバックしてきた時点で帳簿は既に残高ゼロを示しているため、リエントラント（再入）の引き出しリクエストは直ちに拒否される。コードの順序そのものに加えて、開発者は一般的にリエントランシーガード（reentrancy guard）も併用する。関数の実行中にロック用のフラグを設定し、同じ関数がロック状態の間に再度呼び出されたことを検知したら、直ちに取引を中止する。これは論理層に第二の防御線を追加することに相当する。

リエントランシー攻撃は一般利用者の資産にとって何を意味しますか？リスクをどう判断すればよいですか？

リエントランシー攻撃が狙うのはプロトコルレベルの資産プールであり、個々の利用者のウォレットではない。つまり利用者は自分側の操作習慣（慎重な署名やコントラクトアドレスの確認など）によってこの種の攻撃を直接防ぐことはできない。あなたの資産が安全かどうかは完全に、あなたが資金を預けたプロトコルのコードが防御機構を正しく実装しているかどうかにかかっており、これは純粋に技術的な実装の問題であって、利用者の判断力が介入できる部分ではない。これが、リエントランシー攻撃による損失は、その協議に資金を預けたすべての利用者が被害を受けることが多く、特定の1人か2人の操作ミスによるものではない理由でもある。

一般利用者が具体的にできることには、監査を受けており、かつ監査報告書に明確にリエントランシー攻撃への対策テストが行われたと記載されているプロトコルを優先すること（監査報告書の中でreentrancyやchecks-effects-interactionsといったキーワードを検索できる）、プロトコルが業界で広く使われている標準ライブラリ（OpenZeppelinのReentrancyGuardなど、多数のプロジェクトで実戦検証済みのもの）を採用しているかに注意を払うこと、そして「監査に合格した」ことがこの種の脆弱性が起こりえないことを意味しないと理解することが含まれる。2026年初頭にも、リエントランシー二重鋳造の脆弱性によって攻撃を受けたプロトコルが存在しており、10年前から記録されているこの種の攻撃パターンが、開発上の見落としによって今なお再現されうることを証明している。資金を分散させ、単一のプロトコルに大きなポジションを集中させないことが、利用者側でこの種のリスクへの露出を実質的に低減できる唯一の方法である。