アカウント抽象化（AA）は、イーサリアムエコシステムの長期的な探求における重要な方向性であり、外部アカウント（EOA）とコントラクトアカウント間の境界を打ち破り、ウォレットのプログラミング性、セキュリティ、アップグレード性を高めることを目指しています。最も主流のAA実装ソリューションであるEIP-4337は、EntryPointベースの多くのスマートコントラクトウォレット（Safe、Stacks、Argentなど）で広く利用されています。しかし、 EIP-4337は独立したトランザクションプールとエントリーコントラクトメカニズムを導入しているため、オンチェーンネイティブ性、運用の複雑さ、エコシステムの互換性という点で依然として一定の制限があります。
アカウント抽象化の利用ハードルをさらに下げ、ネイティブサポートを強化するため、Vitalikは2024年にEIP-7702を提案し、Pectraのアップグレードにこの提案を組み込みました。EIP -7702の中核となるアイデアは、独自のEOAがトランザクション開始時に指定アドレスのコントラクトコード（contract_code）を実行し、このコードを用いてトランザクションの実行ロジックを定義できるようにすることです。
EIP-7702は、「トランザクションレベルのコードインジェクション」という新しいメカニズムを導入します。これにより、ユーザーアカウントは事前にデプロイされたコントラクトコードに依存するのではなく、各トランザクションで実行ロジックを動的に指定できるようになります。これは、静的コードに基づく従来の権限モデルを打ち破り、柔軟性を高める一方で、新たなセキュリティ上の課題も生み出します。isContractやextcodehashといった判定ロジックに依存するコントラクトが無効になる可能性があり、呼び出し元が純粋なEOAであると想定している一部のシステムもバイパスされる可能性があります。監査担当者は、インジェクションされたコード自体のセキュリティを検証するだけでなく、動的なコンテキストにおける他のコントラクトシステムへの潜在的な影響を評価する必要があります。
この記事では、Beosin セキュリティ チームがEIP-7702 の設計原則と主な機能に焦点を当て、それに基づいて構築された AA ウォレットが監査中に直面する可能性のあるセキュリティ リスクを体系的に整理し、実用的な観点から監査プロセスと提案を提示して、セキュリティ研究者がこの新しいパラダイムの下での技術的な課題にうまく対処できるようにします。
1. EIP-7702の紹介
1. EIP-7702 技術概要
EIP-7702では、新しいトランザクションタイプ0x 04（SetCode）が導入され、EOAはこのトランザクションを通じてコントラクトコードの実行を承認できるようになります。トランザクション構造は以下のとおりです。
rlp([チェーンID, nonce, ガスあたりの最大優先度手数料, ガスあたりの最大手数料, ガス制限,
宛先、値、データ、アクセスリスト、承認リスト、署名yパリティ、署名r、署名s])
authorization_list には複数の認可リストが含まれており、非トランザクションイニシエーターの認可動作も含めることができます。内部構造は次のとおりです。
authorization_list = [[chain_id, address, nonce, y_parity, r, s]]
このうち、chain_idはユーザーの認可が有効なチェーンを示し、その値は実行チェーンのチェーンIDと等しいか0でなければなりません。chain_idが0の場合、EIP-7702をサポートするすべてのEVMチェーンに対して認可が有効であることを意味しますが、前提として他のパラメータ（nonceなど）が一致している必要があります。addressは、ユーザーが認可する対象のコントラクトアドレスを示します。
承認が完了すると、システムは承認ユーザーのコードフィールドを0x ef 0100 || addressに変更します。ここで、addressは承認されたコントラクトアドレスです。承認をキャンセルしたい場合は、SetCodeトランザクションを開始してaddressを0 addressに設定してください。
2. EIP 7702の利点
（1）柔軟性とカスタマイズ性
抽象アカウントは、アカウントロジックをスマートコントラクトに記述することで、ニーズに合わせて機能を柔軟にカスタマイズできます。例えば、ユーザーはマルチ署名、ソーシャルリカバリ、リミット制御などを設定でき、個人や企業の様々なシナリオのニーズに対応できます。この設計により、アカウントの機能拡張性が大幅に向上し、従来の外部アカウント（EOA）の限界を打破します。
（２）セキュリティの強化
抽象アカウントは、多要素認証、取引制限、ソーシャルリカバリなど、多層的なセキュリティメカニズムを提供します。ユーザーが秘密鍵を紛失した場合でも、信頼できる連絡先や多要素認証を通じてアカウントを復元できるため、従来のアカウントにおける秘密鍵の紛失による資産の永久的な損失を回避できます。同時に、制限制御などの機能により、多額の資金が悪意を持って盗難されるのを防ぐこともできます。
（3）ガスの最適化
抽象アカウントは柔軟なガス抽象化メカニズムをサポートしており、ユーザーは第三者を介してガスを支払ったり、他のトークンを直接使用して取引手数料を支払ったりすることができます。このメカニズムは、ユーザーの運用コストを削減するだけでなく、特に初心者ユーザーや複雑な多段階取引シナリオにおいて、ブロックチェーンの利用プロセスをさらに簡素化します。
（4）Web3の普及促進
抽象アカウントは、ユーザーエクスペリエンスとセキュリティを最適化することで、ブロックチェーンの複雑さをユーザーから隠蔽し、Web2に近い便利な操作を提供します。この設計により、一般ユーザーの学習コストが削減され、より多くの人々が障壁なくWeb3アプリケーションに参加できるようになり、分散型技術の普及が促進されます。
2. EIP-7702実践におけるセキュリティリスクの分析
EIP-7702 はイーサリアム エコシステムに新たな推進力を与え、その適用シナリオを拡大しましたが、必然的にいくつかの新たなセキュリティ リスクももたらしました。
1. 認可リプレイ攻撃
EIP-7702モデルでは、ユーザーが認可のchain_idフィールドを0に設定すると、その認可は複数のチェーンで有効であることを意味します。この「クロスチェーンユニバーサル認可」設計は、一部のシナリオにおいて柔軟性を向上させますが、同時に明らかなセキュリティリスクも生じます。
異なるチェーン上の同一アドレスのアカウントIDが同じであっても、その基盤となるコントラクトの実装は全く異なる可能性があることに注意することが重要です。つまり、攻撃者は悪意のあるバージョンのコントラクトを別のチェーンにデプロイし、チェーン上の同一アドレスの承認動作を利用して予期しない操作を実行し、ユーザー資産にリスクをもたらす可能性があります。
したがって、ウォレット サービス プロバイダーまたはフロントエンドのインタラクティブ プラットフォームでは、ユーザーがこのような認証操作を実行するときに、ユーザー認証で宣言された chainId が現在接続されているネットワークと一致しているかどうかを明確に検証する必要があります。ユーザーが chainId を 0 に設定したことが検出された場合は、認証がすべての EVM 互換チェーンに有効になり、悪意のあるコントラクトによって悪用される可能性があることをユーザーに思い出させるために、明確なリスク警告を与える必要があります。
さらに、サービスプロバイダーは、誤操作やフィッシング攻撃のリスクを軽減するために、UI レイヤーでデフォルトで chainId 0 による認証を制限するか禁止するかも評価する必要があります。
2. 契約の互換性の問題
（1）コントラクトコールバックの互換性
既存のERC-721、ERC-777、ERC 1155などのトークンコントラクトは、コントラクトアドレスへの資金送金時に、標準のコールバックインターフェース（onERC 721 Received、tokensReceivedなど）を呼び出して送金操作を完了します。受信アドレスが対応するインターフェースを実装していない場合、送金は失敗するか、資産がロックされる可能性があります。
EIP-7702では、「set_code」操作を通じてユーザーアドレスにコントラクトコードを割り当てることができ、これによりコントラクトアカウントが作成されます。この時点で、
ユーザーアドレスは契約とみなされます。
契約が必要なコールバック インターフェイスを実装していない場合、トークンの転送は失敗します。
ユーザーは知らないうちに主流のトークンを受け取ることができない可能性があります。
したがって、開発者は、ユーザーによって委任されたターゲット コントラクトが関連するコールバック インターフェイスを実装し、主流のトークンとの互換性を確保する必要があります。
（2）「tx.origin」検証失敗
従来のコントラクトでは、「tx.origin」はトランザクションがユーザーによって直接開始されたかどうかを判断するためによく使用され、コントラクト呼び出しなどのセキュリティ制御を防止するために使用されます。
しかし、EIP-7702 のシナリオでは次のようになります。
ユーザーは認可トランザクションに署名します。このトランザクションは実際にはリレーヤーまたはバンドラによってブロードキャストされます。トランザクションが実行されると、「tx.origin」はユーザーアドレスではなく、リレーヤーアドレスになります。
「msg.sender」は、ユーザー ID を表すウォレット コントラクトです。
したがって、 「tx.origin == msg.sender」に基づく権限検証は、正当なユーザー操作を拒否することになり、信頼性を失ってしまいます。同様に、「tx.origin == user」といったコントラクト呼び出しの制限も機能しません。セキュリティ判断の基準として「tx.origin」を放棄し、代わりに署名検証や認可メカニズムを使用することが推奨されます。
（3）「isContract」の誤判断
多くのコントラクトでは、コントラクト アカウントがエアドロップやスナップアップなどの特定の操作に参加するのを防ぐために、「isContract(address)」（アドレス コードの長さをチェック）を使用します。
require(!isContract(msg.sender), 契約は許可されていません)
EIP-7702メカニズムでは、「set_code」トランザクションを通じてユーザーアドレスをコントラクトアカウントに変更することができ、「isContract」がtrueを返します。コントラクトは正当なユーザーをコントラクトアカウントと誤認し、操作への参加を拒否します。その結果、ユーザーは特定のサービスを利用できなくなり、ユーザーエクスペリエンスに支障をきたします。
コントラクトウォレットの普及に伴い、 「isContract」に頼って人間であるかどうかを判断する設計はもはや安全ではなくなりました。署名検証など、より正確なユーザー識別方法の使用が推奨されます。
3. フィッシング攻撃
EIP-7702委任メカニズムの実装後、ユーザーアカウントの資産は委任されたスマートコントラクトによって完全に管理されるようになります。ユーザーが悪意のあるコントラクトを承認すると、攻撃者はそれを利用してアカウント資産を完全に制御し、資金を迅速に送金または盗難する可能性があり、非常に高いセキュリティリスクをもたらします。
したがって、ウォレットサービスプロバイダーは、EIP-7702タイプのトランザクション解析およびリスク識別メカニズムをできるだけ早くサポートすることが重要です。ユーザーが委任トランザクションに署名する際、フロントエンドは対象の契約アドレスを明確かつ目立つように表示し、契約元や展開情報などの補助情報を組み合わせることで、ユーザーが潜在的なフィッシングや不正行為を識別できるようにし、誤署名のリスクを軽減する必要があります。さらに、ウォレットサービスは、契約コードのオープンソースステータスチェック、権限モデル分析、潜在的な危険操作の識別など、対象の契約に対する自動セキュリティ分析機能を統合し、ユーザーが承認前により安全な判断を下せるように支援する必要があります。
特に重要なのは、 EIP-7702で導入された委任署名形式が、既存のEIP-191およびEIP-712署名標準と互換性がないことです。この署名は、ウォレットの署名警告や対話型プロンプトを容易に回避できるため、ユーザーが騙されて悪意のある操作に署名してしまうリスクがさらに高まります。したがって、ウォレット実装にこの署名構造の認識および処理メカニズムを導入することは、ユーザーのセキュリティを確保するための重要な鍵となります。
4. ウォレット契約リスク
（1）ウォレット契約の権限管理
多くのEIP-7702ウォレットコントラクトは、ロジックのアップグレードをサポートするためにプロキシアーキテクチャ（または組み込みの管理権限）を使用しています。しかし、これは権限管理のリスクを高めます。アップグレード権限が厳密に制限されていない場合、攻撃者は実装コントラクトを置き換えて悪意のあるコードを挿入し、ユーザーアカウントの改ざんや資金の盗難につながる可能性があります。
安全のヒント:
アップグレード権限を制御するには、マルチ署名、多要素認証、またはタイムロックメカニズムを使用します。
コードと権限の変更は、厳格な監査とセキュリティ検証を受ける必要があります。
アップグレード プロセスはオープンかつ透明であり、ユーザーの知る権利と参加する権利が確保されます。
（２）ストレージ競合リスクとデータ分離
ウォレットのコントラクトバージョンや異なるウォレットサービスプロバイダーが、同じストレージスロットを再利用する場合があります。ユーザーがウォレットサービスプロバイダーを変更したり、ウォレットロジックをアップグレードしたりした場合、ストレージスロットの再利用は状態変数の競合、データの上書き、読み取り異常などの問題を引き起こします。これにより、ウォレットの正常な機能が損なわれるだけでなく、資金の損失や権限異常が発生する可能性があります。
安全のヒント:
専用のストレージ分離ソリューション (EIP-1967 標準など) を使用するか、一意の名前空間を利用してストレージ スロットを管理します。
契約をアップグレードするときは、変数の重複を避けるために、ストレージ レイアウトに互換性があることを確認してください。
アップグレードプロセス中にストレージ状態の合理性を厳密にテストします。
（3）ウォレット内のナンス管理
ウォレットコントラクトは通常、ユーザー操作の実行順序を保証し、リプレイ攻撃を防ぐために、内部的にナンスを設定し、それを自身で管理します。ナンスが不適切に使用されると、ユーザー操作が正常に実行されなくなります。
安全のヒント:
nonce は、等価性 (または増分) を厳密にチェックする必要があり、スキップすることはできません。
関数は nonce を直接変更することは禁止されています。nonce はユーザー操作が実行された場合にのみ同期的に更新されます。
nonce デッドロックを回避するために、nonce 異常に対するフォールト トレランスと回復メカニズムを設計します。
(4) 関数呼び出し元の権限チェック
セキュリティを確保するため、ウォレットコントラクトは、キー関数の呼び出し元がウォレットの所有者アカウントであることを保証する必要があります。一般的な方法としては、以下の2つがあります。
オフチェーン署名認証
ユーザーは秘密鍵を用いて一連の操作に署名し、ウォレットコントラクトはチェーン上で署名が正当であるか、期限切れであるか、対応するノンスを満たしているかを検証します。この方法は、EIP-7702で提唱されているリレートランザクションモード（ユーザーオフライン署名＋リレーエージェントトランザクション）に適しています。
呼び出し制約 (msg.sender == address(this))
ユーザー操作関数はコントラクト自体によってのみトリガーされます。これは本質的に、外部イニシエーターがアカウント自身であることを保証するコールパス制御メカニズムです。これは実際には、呼び出し元が元のEOAであることを要求するのと同等です。なぜなら、この時点でのコントラクトアドレスはEOAアドレスだからです。
3. 展望：EIP-7702と将来のAAウォレット標準
EIP-7702の導入は、従来のアカウントモデルの革新であるだけでなく、アカウント抽象化エコシステムへの大きな後押しでもあります。これにより、ユーザーがコントラクトコードをロードできるようになったことで、将来のウォレット設計とコントラクトシステムの探求の余地が広がり、セキュリティ監査基準に対する新たな要件も提示されます。
1. EIP-4337との共進化：デュアルモード互換性に向けて
EIP-7702とEIP-4337は設計目標が異なりますが、前者はアカウントコードの読み込みメカニズムを再構築し、後者は完全なトランザクションエントリとパッケージングエコシステムを構築します。しかし、両者は矛盾するものではなく、非常に補完的です。
● EIP-4337は、「ユニバーサルトランザクションチャネル」と「抽象アカウント実行インターフェース」を提供します。
● EIP-7702 により、ユーザーアカウントはアドレスを変更せずに契約ロジック機能を動的に付与できます。
したがって、ウォレットは将来的に「デュアルモード サポート アーキテクチャ」を採用する可能性があります。つまり、EIP-4337 をサポートしていないチェーンでは EIP-7702 を軽量な代替手段として使用し、オフチェーン パッケージングとマルチユーザー集約を必要とするシナリオでは EIP-4337 の完全なプロトコル スタックに引き続き依存することになります。
このデュアルモードのメカニズムにより、ウォレットはカーネル層でより柔軟なアカウント権限モデル、ダウングレードメカニズム、ロールバックソリューションをサポートできるようになります。
2. MPCやZKなどの新しいウォレットロジックのサポートとインスピレーション
EIP-7702 が提唱するアカウント契約メカニズムは、MPC ウォレット、ZK ウォレット、モジュラー ウォレットなど、現在人気の新しいアーキテクチャと自然に統合できる可能性があります。
● MPCモードでは、署名動作は単一の秘密鍵に依存するのではなく、複数の当事者による協調的な意思決定に依存します。EIP -7702とMPCの融合によって生成された署名は、動的に読み込まれるコントラクトロジックを制御できるため、より柔軟な実行戦略を実現します。
● ZKウォレットは、秘密鍵情報を公開することなく、ゼロ知識証明を通じてユーザーの身元または権限を検証します。EIP -7702と組み合わせることで、ZKウォレットは検証完了後に特定のロジックコントラクトを一時的に挿入することができ、プライバシー計算後のパーソナライズされた動作展開を実現します。例えば、特定のプライバシー条件が満たされた場合にのみ、特定のロジックを自動的に実行するなどです。
● モジュラーウォレットはEIP-7702 を使用してアカウントロジックを複数のモジュールに分割し、必要に応じて動的にロードすることができます。
そのため、EIP-7702 は、上記の高度なウォレットに、よりネイティブな「実行コンテナ」を提供します。ユーザー アドレスを変更せずにさまざまな契約ロジックを挿入できるため、従来の契約展開プロセスにおけるアドレス依存性の問題を回避し、事前展開の必要性を排除して、アカウント動作の柔軟性と組み合わせ機能を大幅に向上させます。
3. 契約開発者と監査人への影響
EIP-7702は、開発パラダイムに大きな変化をもたらします。契約開発者は、発信者を従来のEOAまたは固定の契約アカウントとして扱うのではなく、新しいメカニズムに適応する必要があります。つまり、発信者のIDは、トランザクションプロセス中にEOAと契約ステータス間で動的に切り替えることができ、アカウントの動作ロジックは静的に固定されるのではなく、需要に応じて柔軟に変更できるようになります。そのため、開発者と監査担当者には以下の要件が求められます。
より厳格な発信者検証および権限判断ロジックを導入しました。
呼び出しパスが動的コントラクト ロジックの影響を受けるかどうかを確認します。
msg.sender.code.length == 0、isContract() などの動作に依存する潜在的な脆弱性を特定します。
静的呼び出しやデリゲート呼び出しの境界制御など、契約ロジックの「コンテキスト依存性」を明確にします。
ツールチェーン レベルでの setCode シナリオのシミュレーションと復元分析をサポートします。
言い換えれば、コード セキュリティはもはや単なる「展開前の問題」ではなく、「呼び出しやトランザクション中に検証する必要がある動的なプロセス」になっています。
IV. 結論
EIP-7702は、アカウント抽象化（AA）のための軽量でネイティブかつ柔軟な実装を導入し、一般的なEOAが単一のトランザクションでコントラクトロジックを伝達・実行できるようにします。このメカニズムは、アカウントの動作に関する従来の静的な仮定を打ち破ります。開発者は、アカウントアドレスのコードステータスのみに頼って動作モデルを判定することはもはや不可能であり、呼び出し元のIDと権限の境界に関する理解を再構築する必要があります。
これに続くのは、セキュリティ分析におけるパラダイムシフトです。監査の焦点はもはや「特定のアドレスに権限があるかどうか」に限定されず、「トランザクションに含まれるコントラクトロジックが現在のコンテキストで何ができるか」へと移行します。各トランザクションは独立した動作定義を持つことができるため、アカウントの機能は強化され、セキュリティ監査の要件もより厳しくなります。
