1回の署名で財布のコードを書き換える：イーサリアムEIP-7702の功罪

1. 旧来のウォレットに新たな技術を授けたアップグレード

2025年5月7日10時05分11秒UTC（エポック364032）、Pectraがメインネットで有効化されEIP-7702が稼働した。Vitalik Buterin、Sam Wilson、Ansgar Dietrichs、lightclientは2024年5月7日にこのコア仕様を作成した。目的は「EOAに永続的にコードを設定する新しいトランザクションタイプ」の追加である。通常の鍵管理アカウントが、アドレスを変えずスマートコントラクト機能を得た。^[1][2][6]

コード設定トランザクションはタイプ0x04と、[chain_id, address, nonce, y_parity, r, s]形式の認可タプルを使う。有効なタプルごとに0xef0100と委任先を結合した指標（0xef0100 || address）がアカウントコードへ書かれる。以後のコード実行は委任先のバイトコードを読み込む。秘密鍵は残るが、実行時には指定コントラクトとして振る舞う。^[1]

この設計は原子的バッチ処理、ガススポンサー、パスキー等の代替認証、支出制限、アドレスを変えない復元を可能にした。イーサリアム財団は、委任がデフォルトでチェーン限定かつナンス拘束で、所有者が置換・解除できると説明する。再利用や固定化の危険を減らす安全策である。^[2]

2. 偶発的ではなく設計通りの永続性

認可リストはトランザクション実行前、送信者のナンス増加直後に処理される。後続処理が失敗またはリバートしても、委任インジケータはロールバックされない。委任は別の認可で置換するか、ゼロアドレスで消去するまで残る。セッション終了で消える権限ではなく、永続するアカウントソフトウェアである。^[1][3]

仕様書は、認可コードがアカウントへ「無制限にアクセス」するため、ウォレットの厳格な監査が必要だと警告する。一般利用者が任意のバイトコードを検証するのは難しい。秘密鍵で通常EOAへ戻せても、悪意あるコードの有効中に実行された取引までは取り消せない。^[1][3]

不適切に実装された委任先は、悪意ある攻撃者に署名者のEOAに対するほぼ完全な制御を許してしまう可能性がある。^[1]

— EIP-7702仕様書、セキュリティの考慮事項

3. 認可フィッシングという新たな攻撃面

独立系セキュリティ組織Security Allianceは、EIP-7702認可検証ガイダンスで主な脅威を挙げている。ウォレットの「アップグレード」を装い、悪意あるコントラクトへのSetCode委任に署名させるフィッシングサイトや詐欺である。ユーザーが攻撃者のコードを指す認可に署名すれば、攻撃者がアカウントを制御して資産を流出させ得ると同ガイダンスは警告する。シードフレーズを盗まず、有効な同意署名を欺瞞的な画面で得ることが武器になり得る。^[5]

これは認可フィッシングの構造を変える。従来の多くの承認・取引型詐欺は、被害者に有害な送金やトークン承認を署名させることに重点を置く。EIP-7702では、有効な認可タプルが0x04トランザクションで処理されると、後続の実行が失敗しても永続的なコードポインタが残る。2025年12月のプレプリントはこの持続的な状態変更を質的に新しいフィッシングと位置づけた。永続性は仕様上の事実だが、攻撃分類は著者らのプレプリント上の主張である。^[1][4]

影響は複数チェーンへ広がり得る。認可は通常チェーンIDに拘束されるが、chain_id=0なら全EVMネットワークで有効となる。Security Allianceは、同じアドレスへ悪意あるコードを置いた他チェーンで署名が再利用される恐れを警告する。公式指針が委任先を明確に表示するよう求める理由である。^[3][5]

4. プレプリント論文と検証の境界

2025年12月13日、マカオ都市大学のMinfeng QiとTianqing Zhu、CSIRO Data61のQin WangとShiping Chen、ウーロンゴン大学のRuiqiang Liらの研究チームは、プレプリント論文「EIP-7702 Phishing Attack」をarXiv（2512.12174v1 [cs.CR]）に公開した。著者らは要旨においてその中心的主張を簡潔に述べている。^[4]

我々はこの設計が質的に全く新しいクラスのフィッシング攻撃を可能にすることを示す^[4]

— Minfeng Qiら、EIP-7702フィッシング攻撃（arXivプレプリント 2512.12174v1）

論文の実験とオンチェーン測定は査読前の著者主張である。本記事は被害総額や普及統計を確定事実として扱わない。ただし核心的な警告は先にあった。2024年5月のEIP-7702は、生の認可署名インターフェースを利用者へ提供してはならないと明記していた。^[1][4]

5. インターフェースが築く防衛境界線

エコシステムの防衛策は役割分担である。ethereum.orgのガイダンスは、ウォレットが特定の委任先コントラクトをホワイトリスト化する前提を示し、dAppにはEIP-7702認可を直接要求せず、ERC-5792（wallet_sendCalls）等の標準ウォレットインターフェースを使うよう求める。ハードウェアウォレットについても、任意の委任を公開せず、信頼できる委任先リストを使うべきだとしている。これらはプロトコルが強制する保証ではなく、インターフェース上の制約と推奨である。^[3]

Security Allianceはウォレット固有の正規フローと審査済みコントラクトだけを使うよう促す。ゼロアドレス（0x0000000000000000000000000000000000000000）への委任で通常EOAへ戻せる。安全は利用者のコード分析でなくインターフェース規律に依存する。仕様書は「このインターフェースを安全に提供する方法は存在しない」と断言する。^[1][5]

この分業こそがEIP-7702の真の遺産である。既存アカウントにスマートアカウントの恩恵をもたらした一方で、1回の署名でコードが書き換わる以上、セキュリティの焦点は事後警戒からインターフェースの厳格な統制へと移行した。アップグレードの設計者たちは、学術的な警告が出る1年以上前から仕様書の中にこの防衛義務を書き込んでいたのである。^[1][2][4]

アプリケーションはユーザーに認可署名を提案できると期待してはならず、したがってそのようなインターフェースを提供しないことがウォレットの義務である。^[1]

— EIP-7702仕様書、アプリケーションおよびウォレットとの相互作用