EIP-7702 安全回避ガイド：バイナンスにおける63億ドルの盗難事件から見る、新メカニズムの5つの致命的盲点

バイナンスが10月30日に約63億ドル相当の資産を盗まれ、世界中が衝撃を受けた。事後の分析によると、攻撃者は従来型の秘密鍵窃取ではなく、今年になってようやくアクティベートされたイーサリアムの新メカニズム——EIP-7702 委任認証（デリゲーション）を悪用していた。これは「新たな脆弱性」ではなく、メカニズム自体の「設計上の盲点」が、人間のセキュリティ慣性と衝突した結果である。一般ユーザーも開発者も、誰でも巻き込まれる可能性がある。本稿では、攻撃の全過程を丁寧に解説し、EIP-7702 とはそもそも何かを平易な言葉で分かりやすく説明。さらに、ユーザー・開発者それぞれ向けに、実践的な回避策を各5項目ずつ提示する。

一、バイナンス盗難事件における EIP-7702 の役割

まず事件の経緯に戻ろう。10月30日の未明、チェーン上監視者である「神魚（しんぎょ）」氏がX（旧Twitter）上で、気になる情報を公開した：バイナンスの14個のホットウォレットアドレスが、イーサリアムのPectraアップグレード後に、ある「奇妙なトランザクション」——type-4 トランザクション——に署名していたという事実だ。しかも、これらのウォレットは外部の攻撃者コントラクトに対して、有効な委任認証を保持していた。

現在、コミュニティが再構築した攻撃の全体像はおおむね以下の通りである：

1. 侵入経路：バイナンスの内部開発者または運用担当者のノートPCがフィッシング／マルウェアによって乗っ取られた；
2. 悪意あるトランザクションの挿入：攻撃者は内部署名チャネルを入手し、ホットウォレットへ type-4 トランザクションを送り込む権限を得た；
3. 一括委任：数時間のうちに、50個のホットウォレットが次々と署名し、自身のコード実行権を攻撃者が支配するコントラクトへ委任した；
4. 制御権の乗っ取り：委任が有効化されると、攻撃者はあたかも自分のコントラクトを呼び出すかのように、これらのホットウォレットを自由に操作できた——署名システムが認識するのは32バイトの「トランザクション要約」だけだが、実際には「車の鍵を他人に渡す」ような委任書に署名していたのだ。

幸い、事件が拡大した後、バイナンスのチェーン上チームが緊急で取消トランザクションを展開。現時点で約30億ドル相当の盗まれた資産が、成功裏に凍結・回収された。つまり、EIP-7702 の委任は「不可逆」ではないが、その前提は「まだ取消トランザクションに署名できる状態であること」だ。今回の事件の詳細なタイムラインについては、当サイトの過去報道をご覧ください：63億ドル盗難：バイナンスのホットウォレットが EIP-7702 委任により乗っ取られる。

なお、バイナンスは EIP-7702 を標的にした最初の機関ではない。すでに9月には、個人ユーザーが見知らぬDAppのtype-4トランザクションに署名した結果、資産を失う事例が報告されていた。しかし、バイナンス事件はこの「メカニズムレベルのセキュリティ課題」を、一気に業界の表舞台へ押し上げた。

二、EIP-7702 の核心メカニズム概観（3分で理解）

従来のイーサリアムには2種類のアカウントしか存在しない：EOA（外部所有アカウント）とコントラクトアカウントだ。EOAは銀行口座のようなもので、秘密鍵で1回署名すれば1回分の送金が可能。一方、コントラクトアカウントはブロックチェーン上にデプロイされたプログラムの論理そのものである。EIP-7702 が解決しようとした根本的な問いはこうだ：EOAが一時的に、コントラクトアカウントと同じ能力を持つことはできないか？

その答えが「委任認証（デリゲーション）」——たとえるなら、「あなたの車（EOA）を友達（対象コントラクト）に貸す」行為だ。車の名義変更ではなく、ブロックチェーン上で「鍵の管理を誰に一時的に委ねるか」を明記した委任書に署名するのである。

技術的には、EIP-7702 は以下の2つの重要な変更を導入している：

• type-4 トランザクション：「委任」を実行するための新しいトランザクションタイプ。署名者は対象アドレスへETHを送金する必要はなく、単に委任書をチェーン上に公開するだけでよい。
• 委任は明示的な取消がない限り、永久に有効である。これが最も重要であり、かつ最も見落とされやすい点だ——「自動失効」もなければ、「使い切り型」もない。

一見便利に思えるだろう？理論上は、ガス代支払いを代行するコントラクトや、DAppへ一時的な自動化操作権限を与えることも可能になる。だが、この「永久有効」という設計思想こそが、ほぼすべてのセキュリティ事故の種をまいている。

三、5つの致命的盲点（一般ユーザーがハマりやすい）

以下に挙げる5つの盲点は、一般ユーザーが最も陥りやすいリスクである。いずれも実際の事例に基づいている。

1．委任認証は自動失効しない——使い終わっても取消しない＝鍵を永遠に他人に渡す

多くのDAppがユーザーに対し、「『delegate』ボタンを1回押せば今後の送金手数料が2割引き！」などと誘導する。ユーザーは承諾してしまい、その後忘れてしまう。すると、その委任はチェーン上にずっと残り続け、DAppの運営チームが交代したり、アドレスそのものが売却されたりしても、あなたのウォレットの鍵は依然として他人の手にある。

2．ウォレットUIは「誰に委任済みか」を表示しない

これは現時点のエコシステム全体で最も厄介な問題だ。2026年10月現在、Trust Wallet、Exodus、さらには一部のハードウェアウォレットの公式アプリを含む、ほとんどの主要ウォレットには「委任管理」ページが存在しない。あなたが17回のtype-4トランザクションに署名していても、ウォレット内ではただ「トランザクション要約」の一覧しか表示されず、「誰に鍵を渡したか」が一切分からない。
朗報は、etherscan.ioがついにUIを更新したことだ——今や自分のアドレスページを開き、「Delegations」タブを選択すれば、すべての過去の委任記録を確認できる。etherscan.ioは、現時点で最も信頼できる自己診断ツールである。

3．署名と同時に即時有効——2度目の確認は不要

DApp上で「確認」ボタンをクリックすると、ウォレットのポップアップに「ガス代：0.001 ETH」と表示され、あなたは署名する——その瞬間にチェーン上で起きているのは、「あなたのEOAが攻撃者コントラクトへ永久委任書を発行した」ことだ。2度目のポップアップも、追加の確認も一切ない。署名者が目にするのは32バイトのトランザクション要約のみであり、それが通常の送金なのか、type-4なのか、まったく区別がつかない。

4．委任はネスト（入れ子）可能——元の署名者は完全に無知のまま

AがBに委任し、BがCに委任し、CがDに委任する——理論上、無限にネスト可能だ。バイナンス事件でも、このような委任チェーンのネストが確認されている。もし既にあなたのウォレットが悪意あるコントラクトによって制御されていれば、あなたが同意しなくても、さらに他のアドレスへ制御権を下付することが可能となる。

5．委任の取消自体にも署名が必要

これが最も絶望的な点だ。攻撃者がすでにあなたの委任権を取得していれば、彼らはあなたの資産を凍結したり、ウォレットを悪意あるコントラクトモードへ変更したりできる。あなたが取消したいと思っても、その取消トランザクションにも署名が必要となる。そして、その署名チャネル自体が、ネスト委任によってすでに攻撃者に掌握されている可能性すらある。

四、一般ユーザー向け実践チェックリスト

ここまで読んだあなたが、今すぐすべきことは？以下の5ステップを順に実行せよ：

✅ ステップ1：直ちに自身のウォレット委任記録を確認せよ。
etherscan.ioを開き、自分のウォレットアドレスを入力。その後、「Delegations」タブへ切り替える。もし委任リストに見知らぬアドレスが表示されていたら、それはまさに「時限爆弾」である。

✅ ステップ2：見知らぬ委任があれば、直ちに取消せよ。
取消ツールとしては、OpenZeppelin Defender やコミュニティがメンテナンスする EIP-7702 Revoker を推奨。チェーン上での取消はガス代が通常1～5ドル程度で、操作は通常の送金と同様だ。
⚠️ 注意：すでに悪意ある委任によってウォレットが乗っ取られている場合、取消は失敗する可能性がある。その場合は、LedgerやTrezorなどのハードウェアウォレットを用いて、オフラインで取消トランザクションの署名を生成し、別の安全なPCからブロードキャストするのが、現時点で最も確実な方法である。

✅ ステップ3：ウォレットの利用習慣を一時的に見直せ。
Trust Wallet や Exodus を使っている場合、type-4 トランザクションへの直接署名は一時的に避けることを推奨。比較的安全な組み合わせは、Ledger ハードウェアウォレット ＋ Rabby ブラウザ拡張だ——ハードウェア署名デバイスはネスト委任を自動実行しないため、少なくとも「黙って」署名させることはない。

✅ ステップ4：見知らぬDAppで「Delegate」ボタンを押さない。
「ガス代割引」「手数料無料」「自動収益化」などを理由に委任を促すDAppには、まず立ち止まれ。XやTelegramで、そのDAppの名称＋「hack」「scam」を検索し、3分間の背景調査を行うことが、数ドルのガス代を節約するよりはるかに価値がある。

✅ ステップ5：取引所ユーザーへの特別注意喚起。
バイナンスやOKXといった中心化取引所を主に利用している場合、それらはホットウォレットの委任を統一管理している。個人アカウントレベルでは追加の操作は不要だが、取引所の公式アプリを優先的に利用し、第三者のウォレットから取引所の入金アドレスへtype-4トランザクションを直接送信することは避けるべきである。

五、開発者向け実践チェックリスト

DAppやDeFiの開発者として、あなたにはより重い責任がある。以下5項目は、業界内で既に合意形成が進んでいる「最低限のセキュリティ基準」である。

1．委任認証には必ず妥当な有効期限（expiry）を設定せよ。
現時点では、すべてのウォレットが署名時に expiry を検証できるわけではないが、あなたがデプロイする委任コントラクトのロジック内には、このチェックをハードコードで組み込む必要がある。「30日後に自動失効」する委任と、「永久有効」な委任では、セキュリティ水準がまったく異なる。

2．フロントエンドUIでは、type-4トランザクションを赤色の大型ポップアップで明示せよ。
標準的な実装はこうだ：ユーザーが「Delegate」ボタンをクリックすると、フロントエンドが独立した赤色モーダルウィンドウを表示。「⚠️ あなたは今から EIP-7702 委任トランザクションに署名しようとしています——これにより、対象アドレスがあなたのウォレットのコード実行権を獲得します」と太字で明記し、ユーザーが「リスクを理解しました」と手動入力して初めて続行可能とする。

3．ユーザーが任意に入力した委任先（delegation target）は、絶対に受け入れるな。
委任先のコントラクトアドレスは、フロントエンドのコード内でハードコードし、チェーン上のデプロイ済みアドレスと照合して検証しなければならない。ユーザーにtargetを自由に記入させるということは、委任権の「住所」を丸ごと渡してしまうのと同じである。

4．EIP-7715 の「delegateWithPermissions」へ早急に移行せよ。
EIP-7715 は、EIP-7702 をベースに「権限制限（permissions）」を追加したもので、委任先がどの関数を呼び出せるか・できないかを明示的に規定できる。理論的にはこれが標準仕様となるべきだが、現時点での対応率はまだ低い。可能な限り早期に移行すること。

5．テスト環境では、OpenZeppelin の EIP-7702 対応審査スクリプトを強制実行せよ。
OpenZeppelin はすでに、EIP-7702 のセキュリティ審査を Defender のチェックリストに組み込んでいる。すべてのコントラクトデプロイ時に、委任関連のリスクを自動スキャンするスクリプトを走らせることが、コストゼロで実現できる。

六、結語

EIP-7702 は「バグのあるプロトコル」ではない。その設計目的——一般ユーザーのEOAにコントラクト同等の能力を付与する——は、正しく、かつ前向きなものだ。問題は、「永久有効」という根幹的な前提が、イーサリアムエコシステムにおいて最も脆い環節——人間のセキュリティ習慣——と衝突したことにこそある。

バイナンス事件は、EIP-7702 の普及以降、最も高額なセキュリティ教育の一コマとなったかもしれない。だが逆に考えれば、この事件は、エコシステム全体を「無自覚な委任」の甘い夢から、一撃で目覚めさせたのだ。今や etherscan には委任タブが登場し、ウォレット開発チームはセキュリティポップアップを追加し、OpenZeppelin は審査スクリプトを更新した——すべての事故は、このメカニズムを少しずつ、確実に安全なものへと変えている。

あなた個人にとって、今最も価値ある行動はただ2つだけだ：etherscan で自分の委任状況を確認すること、そしてDeFi を使う友人にこの事実を伝えること。それだけで十分である。