文:ベオシン アカウント抽象化(AA)は、イーサリアムエコシステムにおける長期的な探求の重要な方向性であり、外部アカウント(EOA)と契約アカウントの間の境界を打ち破り、ウォレットのプログラム性、セキュリティ、アップグレード性を強化することを目的としています。 EIP-4337は、最も主流のAA実装ソリューションとして、多くの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は新しい取引タイプ0x04（SetCode）を導入しました。これにより、EOAはこの取引を通じて実行する必要のあるコントラクトコードを承認できます。取引構造は以下の通りです： authorization\_listには複数の承認リストが含まれ、取引の発起者以外の承認行為も含むことができます。内部構造は次のとおりです。 ここで、chain\_id はユーザーの承認が有効になるチェーンを示し、その値は実行チェーンのチェーンIDと等しいか、0である必要があります。chain\_id が0の場合、承認はすべてのEIP-7702をサポートするEVMチェーンに対して有効になりますが、その前提として他のパラメータ（nonceなど）が一致する必要があります。address はユーザーが承認したターゲットコントラクトのアドレスを示します。認証が完了すると、システムは認証されたユーザーのコードフィールドを 0xef0100 || address は、承認されたコントラクト・アドレスです。 認証を解除する場合は、アドレスを 0 に設定して SetCode トランザクションを開始するだけです。2. EIP7702の利点(1) 柔軟性とカスタマイズ 抽象的なアカウントは、スマートコントラクトにアカウントロジックを書き込むことで、ニーズに応じて機能を柔軟にカスタマイズできます。 たとえば、ユーザーは、マルチシグ、ソーシャルリカバリ、およびクォータ制御を設定して、さまざまなシナリオで個人や企業のニーズを満たすことができます。 この設計により、アカウントの機能スケーラビリティが大幅に向上し、従来の外部アカウント (EOA) の制限が打ち破られます。(2) セキュリティを強化する 抽象アカウントは、複数のセキュリティ保障メカニズムを提供しています。これには、多重認証、取引限度額、ソーシャルリカバリーなどが含まれます。ユーザーが秘密鍵を失った場合でも、信頼できる連絡先や多重検証を通じてアカウントを復元できるため、従来のアカウントが秘密鍵の喪失により資産を永久に失うことを防ぎます。また、限度額制御機能などは、大量の資金が悪意のある盗難に遭うのを防ぐことができます。(3) ガス最適化 Abstractアカウントは、ユーザーが第三者を通じてガスの代金を支払ったり、他のトークンを直接使用して取引手数料を支払ったりできる柔軟なガス抽象化メカニズムをサポートしています。 このメカニズムは、ユーザーの運用コストを削減するだけでなく、ブロックチェーンの使用プロセスをさらに簡素化するため、初心者ユーザーや複雑なマルチステップトランザクションシナリオに特に適しています。(4) Web3の普及を推進する 体験と安全性を最適化することにより、抽象アカウントはブロックチェーンの複雑さをユーザーの目に見えないところに隠し、Web2に近い便利な操作を提供します。このデザインは一般ユーザーの学習コストを低減させ、より多くの人々がWeb3アプリケーションに障壁なく参加できるようにし、分散型技術の普及を促進しています。二、EIP-7702 実践におけるセキュリティリスクの解析EIP-7702はEthereumエコシステムに新しい活力を注ぎ、豊富なアプリケーションシーンを拡大しましたが、その一方で、いくつかの新しいセキュリティリスクも避けられません。1. 権限のあるリプレイ攻撃 EIP-7702モデルでは、ユーザーが承認のchain\_idフィールドを0に設定した場合、その承認は複数のチェーンで有効であることを示します。この「クロスチェーン汎用承認」の設計は、特定のシナリオで柔軟性を向上させる一方で、明らかなセキュリティリスクももたらします。特に注意が必要なのは、同じアドレスが異なるチェーン上で同じアカウント識別子を持っていても、その背後のコントラクト実装は完全に異なる可能性があるということです。これは、攻撃者が別のチェーン上に悪意のあるバージョンのコントラクトをデプロイし、チェーン上の同じアドレスの権限行使を利用して予期しない操作を実行し、ユーザーの資産にリスクをもたらす可能性があることを意味します。したがって、ウォレットサービスプロバイダーやフロントエンドインタラクションプラットフォームにとって、ユーザーがこのような承認操作を行う際には、ユーザーの承認に記載されたchainIdと現在接続されているネットワークが一致しているかどうかを明確に確認する必要があります。ユーザーがchainIdを0に設定した場合は、すべてのEVM互換チェーンでこの承認が有効になり、悪意のある契約に悪用される可能性があることを警告する明確なリスク警告を提供する必要があります。さらに、サービス提供者は、誤操作やフィッシング攻撃のリスクを軽減するために、UI層でchainIdが0の承認をデフォルトで制限または禁止するかどうかを評価する必要があります。2. コントラクトの互換性の問題(1) 契約コールバックの互換性現在、ERC-721、ERC-777、ERC1155などのトークンコントラクトは、コントラクトアドレスに送金する際に、標準コールバックインターフェース（onERC721Received、tokensReceivedなど）を呼び出して送金操作を完了させます。受取アドレスが対応するインターフェースを実装していない場合、送金は失敗し、資産がロックされる可能性があります。EIP-7702では、ユーザーアドレスは「set\_code」操作によって契約コードが割り当てられ、契約アカウントに変わることができます。この時： ユーザーアドレスは契約と見なされます；その契約が必要なコールバックインターフェースを実装していない場合、トークンの転送が失敗します。ユーザーは、知らずに主流のトークンを受け取れない可能性があります。したがって、開発者はユーザーが委託したターゲットコントラクトが関連するコールバックインターフェースを実装していることを確認し、主流トークンとの互換性を確保する必要があります。 (2) "tx.origin" の検証が失敗する従来のコントラクトでは、「tx.origin」は取引がユーザーによって直接発起されたかどうかを判断するために使用され、コントラクト呼び出しなどのセキュリティ制御に役立ちます。しかし、EIP-7702のシナリオでは： ユーザーは取引を承認し、実際にはリレーサーやバンドラーによってブロードキャストされます。取引が実行されるとき、「tx.origin」はリレーサーのアドレスであり、ユーザーのアドレスではありません。「msg.sender」はユーザーの身分を示すウォレット契約です。 したがって、「tx.origin == msg.sender」に基づく権限検証は、正当なユーザーの操作を拒否し、信頼性を失うことになります。同様に、「tx.origin == user」のような制限で契約呼び出しを行うことも無効になります。「tx.origin」を安全判断の根拠として使用するのはやめ、署名検証または承認メカニズムを使用することをお勧めします。 「isContract」の誤判断(3)。多くの契約は「isContract (address)」（アドレスコードの長さを確認する）を通じて、契約アカウントがエアドロップや購入などの特定の操作に参加するのを防ぎます。 EIP-7702 メカニズムの下で、ユーザーアドレスは「set\_code」トランザクションを通じてコントラクトアカウントに変わることができ、「isContract」は true を返します。このため、コントラクトは合法的なユーザーを誤ってコントラクトアカウントと判断し、操作への参加を拒否することになり、ユーザーは特定のサービスを利用できず、体験が妨げられることになります。契約ウォレットが普及するにつれて、「isContract」を使って「人間のユーザーかどうか」を判断する設計はもはや安全ではなく、署名検証などのより正確なユーザー識別方法を採用することをお勧めします。3. フィッシング攻撃EIP-7702の委任メカニズムの実装後、ユーザーのアカウント内の資産は、委任されたスマートコントラクトによって完全に制御されます。 ユーザーが悪意のあるコントラクトを承認すると、攻撃者はアカウント資産を完全に制御できるようになり、その結果、資金の迅速な送金や盗難が発生する可能性があり、これは非常にリスクが高いです。したがって、ウォレットサービスプロバイダーは、EIP-7702トランザクションの解決とリスク識別メカニズムをできるだけ早くサポートすることが重要です。 ユーザーが委託取引に署名するとき、フロントエンドはターゲット契約アドレスを明確かつ目立つように表示し、契約ソースやデプロイメント情報などのサポート情報を組み合わせて、ユーザーが潜在的なフィッシングや不正行為を特定できるようにすることで、誤署名のリスクを減らす必要があります。 さらに、ウォレットサービスには、契約コードのオープンソースステータスチェック、許可モデル分析、潜在的に危険な操作の特定など、対象契約の自動セキュリティ分析機能を統合して、ユーザーが承認前により安全な判断を下せるようにする必要があります。特に、EIP-7702 では、既存の EIP-191 および EIP-712 署名標準と互換性のない委任署名形式が導入されています。 その署名は、ウォレットの元の署名警告と対話プロンプトを簡単にバイパスできるため、ユーザーがだまされて悪意のある操作に署名するリスクがさらに高まります。 したがって、ウォレット実装における署名構造の識別および処理メカニズムの導入は、ユーザーのセキュリティを確保するための重要なリンクになります。 4. ウォレット契約リスク(1) ウォレット契約権限管理多くのEIP-7702ウォレット契約は、プロキシアーキテクチャ(または内蔵管理権限)を採用して、ロジックのアップグレードをサポートしています。しかし、これにより権限管理リスクが高まります。アップグレード権限が厳しく制限されていない場合、攻撃者は実装契約を置き換え、悪意のあるコードを注入する可能性があり、ユーザーのアカウントが改ざんされるか、資金が盗まれる危険があります。安全に関するアドバイス： マルチシグネチャ、マルチファクター認証、またはタイムロックメカニズムを使用してアップグレード権限を制御します。コードと権限の変更は厳格な監査とセキュリティ検証を経なければならない。公開透明なアップグレードプロセスで、ユーザーの知る権利と参加権を保証します。 (2) ストレージ競合リスクおよびデータ隔離ウォレットのコントラクトバージョンまたは異なるウォレットプロバイダーは、同じストレージスロットを再利用できます。 ユーザーがウォレットサービスプロバイダーを変更したり、ウォレットロジックをアップグレードしたりすると、ストレージスロットの再利用により状態変数が競合し、データの上書きや例外の読み取りなどの問題が発生します。 これは、ウォレットの正常な機能を妨害するだけでなく、資金の損失や異常な許可につながる可能性があります。安全に関する提案： 専用のストレージ隔離ソリューション（例えばEIP-1967標準）を使用するか、ユニークなネームスペースを利用してストレージスロットを管理します。アップグレード契約時は、ストレージレイアウトの互換性を確保し、変数の重複を避けてください。ストレージの状態の妥当性を厳密にテストするアップグレードプロセス。 (3) ウォレット内部の nonce 管理ウォレットコントラクトは通常、内部で nonce を設定し、自己管理を行って、ユーザー操作の実行順序を確保し、リプレイ攻撃を防ぎます。nonce が適切に使用されない場合、ユーザー操作が正常に実行されなくなります。安全に関する提案： nonceは強制的に等価（または増加）でなければならず、スキップすることはできません。関数がnonceを直接変更することは禁止されています。ユーザー操作が実行される時にのみnonceが同期更新されます。nonceの異常状況に対してフォールトトレランスと復旧メカニズムを設計し、nonceのデッドロックを回避する。 (4) 関数呼び出し者の権限チェック安全を確保するために、ウォレット契約は重要な関数の呼び出し者がウォレットの所有者アカウントであることを確認する必要があります。一般的な2つの方法には、次のものが含まれます： オフチェーン署名の権限付与 ユーザーはプライベートキーを使用して一連の操作に署名し、ウォレットコントラクトはチェーン上で署名が有効かどうか、有効期限が切れていないか、対応するnonceを満たしているかを検証します。この方法はEIP-7702が提唱するリレートランザクションモデル（ユーザーのオフライン署名 + リレーターによるトランザクションの送信）に適しています。 呼び出し制約 (msg.sender == address (this)) ユーザー操作関数は、契約自身によってのみ呼び出されることを許可します。これは本質的に呼び出しパス制御メカニズムであり、外部の発起者がそのアカウント自体であることを保証します。これは、呼び出し者が元のEOAであることを要求することと実質的に等価であり、この時の契約アドレスはEOAアドレスになります。 三、展望：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ウォレットは検証が完了した後に特定のロジックコントラクトを一時的に注入できるようになり、プライバシー計算後の個別の行動展開を実現します。たとえば、特定のプライバシー条件を満たした場合にのみ、特定のロジックを自動的に実行することができます。モジュラーウォレット（Modular Wallets）は、EIP-7702を利用してアカウントロジックを複数のモジュールに分解し、必要に応じて動的にロードできます。 したがって、EIP-7702は上記の高度なウォレットに対して、よりネイティブな「実行コンテナ」を提供します：ユーザーアドレスはそのままで、異なる契約ロジックを注入でき、従来の契約デプロイメントプロセスにおけるアドレス依存の問題を回避し、事前にデプロイする必要もなく、アカウントの行動の柔軟性と組み合わせ能力が大幅に向上します。3. 契約開発者および監査人への影響EIP-7702は、開発パラダイムに大きな変化をもたらします。 契約開発者は、もはや単に発信者を従来のEOAまたは固定契約アカウントとして扱うのではなく、新しいメカニズムに適応する必要があります:呼び出し元のIDは、トランザクション中にEOAと契約ステータスの間で動的に切り替えることができ、アカウントの動作ロジックはもはや静的に固まらず、需要に応じて柔軟に変更することができます。 これには、開発者と監査人が次のことを行う必要があります。 より厳格なcaller検証と権限判断ロジックを導入する；動的契約ロジックの影響を受けているかどうか、呼び出しパスを確認する；msg.sender.code.length == 0、isContract ()などの動作に依存する潜在的な脆弱性を特定します。契約ロジックの「コンテキスト依存」を明確にする。例えば、静的呼び出しやdeleGatecallの境界制御；ツールチェーンレベルでsetCodeシナリオのシミュレーションと復元分析をサポートします。 言い換えれば、コードの安全性はもはや「デプロイ前の問題」ではなく、「呼び出し時や取引時にも検証が必要な動的プロセス」となった。四、まとめEIP-7702 では、より軽量でネイティブで柔軟な Account Abstraction (AA) の実装が導入されており、通常の EOA でコントラクト ロジックを伝送し、1 つのトランザクションで実行できます。 このメカニズムは、アカウントの動作に関する従来の静的な仮定を破り、開発者はもはやアカウントアドレスのコード状態に依存してその動作モデルを判断するのではなく、呼び出し元のIDと権限の境界の理解を再構築する必要があります。 それに伴い、セキュリティ分析のパラダイムシフトがもたらされます。 監査の焦点は、もはや「アドレスに権限があるかどうか」に限定されず、「トランザクションで運ばれるコントラクトロジックが現在のコンテキストで何ができるか」に移ります。 各トランザクションには、動作の独立した定義がある場合があり、これにより、アカウントにより多くの機能が提供され、セキュリティ監査に対するより高い要件が提唱されます。
Beosin: EIP-7702 と次世代 AA ウォレットのセキュリティ監査分析
文:ベオシン
アカウント抽象化(AA)は、イーサリアムエコシステムにおける長期的な探求の重要な方向性であり、外部アカウント(EOA)と契約アカウントの間の境界を打ち破り、ウォレットのプログラム性、セキュリティ、アップグレード性を強化することを目的としています。 EIP-4337は、最も主流のAA実装ソリューションとして、多くの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 ウォレットが監査において直面する可能性のあるセキュリティリスクを体系的に整理し、実戦的な視点を組み合わせて監査プロセスと提案を提示し、この新しいパラダイムにおける技術的課題に対処するためにセキュリティ研究者を支援します。
EIP-7702の紹介
EIP-7702 技術概要
EIP-7702は新しい取引タイプ0x04（SetCode）を導入しました。これにより、EOAはこの取引を通じて実行する必要のあるコントラクトコードを承認できます。取引構造は以下の通りです：
authorization_listには複数の承認リストが含まれ、取引の発起者以外の承認行為も含むことができます。内部構造は次のとおりです。
ここで、chain_id はユーザーの承認が有効になるチェーンを示し、その値は実行チェーンのチェーンIDと等しいか、0である必要があります。chain_id が0の場合、承認はすべてのEIP-7702をサポートするEVMチェーンに対して有効になりますが、その前提として他のパラメータ（nonceなど）が一致する必要があります。address はユーザーが承認したターゲットコントラクトのアドレスを示します。
認証が完了すると、システムは認証されたユーザーのコードフィールドを 0xef0100 || address は、承認されたコントラクト・アドレスです。 認証を解除する場合は、アドレスを 0 に設定して SetCode トランザクションを開始するだけです。
(1) 柔軟性とカスタマイズ
抽象的なアカウントは、スマートコントラクトにアカウントロジックを書き込むことで、ニーズに応じて機能を柔軟にカスタマイズできます。 たとえば、ユーザーは、マルチシグ、ソーシャルリカバリ、およびクォータ制御を設定して、さまざまなシナリオで個人や企業のニーズを満たすことができます。 この設計により、アカウントの機能スケーラビリティが大幅に向上し、従来の外部アカウント (EOA) の制限が打ち破られます。
(2) セキュリティを強化する
抽象アカウントは、複数のセキュリティ保障メカニズムを提供しています。これには、多重認証、取引限度額、ソーシャルリカバリーなどが含まれます。ユーザーが秘密鍵を失った場合でも、信頼できる連絡先や多重検証を通じてアカウントを復元できるため、従来のアカウントが秘密鍵の喪失により資産を永久に失うことを防ぎます。また、限度額制御機能などは、大量の資金が悪意のある盗難に遭うのを防ぐことができます。
(3) ガス最適化
Abstractアカウントは、ユーザーが第三者を通じてガスの代金を支払ったり、他のトークンを直接使用して取引手数料を支払ったりできる柔軟なガス抽象化メカニズムをサポートしています。 このメカニズムは、ユーザーの運用コストを削減するだけでなく、ブロックチェーンの使用プロセスをさらに簡素化するため、初心者ユーザーや複雑なマルチステップトランザクションシナリオに特に適しています。
(4) Web3の普及を推進する
体験と安全性を最適化することにより、抽象アカウントはブロックチェーンの複雑さをユーザーの目に見えないところに隠し、Web2に近い便利な操作を提供します。このデザインは一般ユーザーの学習コストを低減させ、より多くの人々がWeb3アプリケーションに障壁なく参加できるようにし、分散型技術の普及を促進しています。
二、EIP-7702 実践におけるセキュリティリスクの解析
EIP-7702はEthereumエコシステムに新しい活力を注ぎ、豊富なアプリケーションシーンを拡大しましたが、その一方で、いくつかの新しいセキュリティリスクも避けられません。
EIP-7702モデルでは、ユーザーが承認のchain_idフィールドを0に設定した場合、その承認は複数のチェーンで有効であることを示します。この「クロスチェーン汎用承認」の設計は、特定のシナリオで柔軟性を向上させる一方で、明らかなセキュリティリスクももたらします。
特に注意が必要なのは、同じアドレスが異なるチェーン上で同じアカウント識別子を持っていても、その背後のコントラクト実装は完全に異なる可能性があるということです。これは、攻撃者が別のチェーン上に悪意のあるバージョンのコントラクトをデプロイし、チェーン上の同じアドレスの権限行使を利用して予期しない操作を実行し、ユーザーの資産にリスクをもたらす可能性があることを意味します。
したがって、ウォレットサービスプロバイダーやフロントエンドインタラクションプラットフォームにとって、ユーザーがこのような承認操作を行う際には、ユーザーの承認に記載されたchainIdと現在接続されているネットワークが一致しているかどうかを明確に確認する必要があります。ユーザーがchainIdを0に設定した場合は、すべてのEVM互換チェーンでこの承認が有効になり、悪意のある契約に悪用される可能性があることを警告する明確なリスク警告を提供する必要があります。
さらに、サービス提供者は、誤操作やフィッシング攻撃のリスクを軽減するために、UI層でchainIdが0の承認をデフォルトで制限または禁止するかどうかを評価する必要があります。
(1) 契約コールバックの互換性
現在、ERC-721、ERC-777、ERC1155などのトークンコントラクトは、コントラクトアドレスに送金する際に、標準コールバックインターフェース（onERC721Received、tokensReceivedなど）を呼び出して送金操作を完了させます。受取アドレスが対応するインターフェースを実装していない場合、送金は失敗し、資産がロックされる可能性があります。
EIP-7702では、ユーザーアドレスは「set_code」操作によって契約コードが割り当てられ、契約アカウントに変わることができます。この時：
ユーザーアドレスは契約と見なされます；
その契約が必要なコールバックインターフェースを実装していない場合、トークンの転送が失敗します。
ユーザーは、知らずに主流のトークンを受け取れない可能性があります。
したがって、開発者はユーザーが委託したターゲットコントラクトが関連するコールバックインターフェースを実装していることを確認し、主流トークンとの互換性を確保する必要があります。
(2) "tx.origin" の検証が失敗する
従来のコントラクトでは、「tx.origin」は取引がユーザーによって直接発起されたかどうかを判断するために使用され、コントラクト呼び出しなどのセキュリティ制御に役立ちます。 しかし、EIP-7702のシナリオでは：
ユーザーは取引を承認し、実際にはリレーサーやバンドラーによってブロードキャストされます。取引が実行されるとき、「tx.origin」はリレーサーのアドレスであり、ユーザーのアドレスではありません。
「msg.sender」はユーザーの身分を示すウォレット契約です。
したがって、「tx.origin == msg.sender」に基づく権限検証は、正当なユーザーの操作を拒否し、信頼性を失うことになります。同様に、「tx.origin == user」のような制限で契約呼び出しを行うことも無効になります。「tx.origin」を安全判断の根拠として使用するのはやめ、署名検証または承認メカニズムを使用することをお勧めします。
「isContract」の誤判断(3)。
多くの契約は「isContract (address)」（アドレスコードの長さを確認する）を通じて、契約アカウントがエアドロップや購入などの特定の操作に参加するのを防ぎます。
EIP-7702 メカニズムの下で、ユーザーアドレスは「set_code」トランザクションを通じてコントラクトアカウントに変わることができ、「isContract」は true を返します。このため、コントラクトは合法的なユーザーを誤ってコントラクトアカウントと判断し、操作への参加を拒否することになり、ユーザーは特定のサービスを利用できず、体験が妨げられることになります。 契約ウォレットが普及するにつれて、「isContract」を使って「人間のユーザーかどうか」を判断する設計はもはや安全ではなく、署名検証などのより正確なユーザー識別方法を採用することをお勧めします。
EIP-7702の委任メカニズムの実装後、ユーザーのアカウント内の資産は、委任されたスマートコントラクトによって完全に制御されます。 ユーザーが悪意のあるコントラクトを承認すると、攻撃者はアカウント資産を完全に制御できるようになり、その結果、資金の迅速な送金や盗難が発生する可能性があり、これは非常にリスクが高いです。
したがって、ウォレットサービスプロバイダーは、EIP-7702トランザクションの解決とリスク識別メカニズムをできるだけ早くサポートすることが重要です。 ユーザーが委託取引に署名するとき、フロントエンドはターゲット契約アドレスを明確かつ目立つように表示し、契約ソースやデプロイメント情報などのサポート情報を組み合わせて、ユーザーが潜在的なフィッシングや不正行為を特定できるようにすることで、誤署名のリスクを減らす必要があります。 さらに、ウォレットサービスには、契約コードのオープンソースステータスチェック、許可モデル分析、潜在的に危険な操作の特定など、対象契約の自動セキュリティ分析機能を統合して、ユーザーが承認前により安全な判断を下せるようにする必要があります。
特に、EIP-7702 では、既存の EIP-191 および EIP-712 署名標準と互換性のない委任署名形式が導入されています。 その署名は、ウォレットの元の署名警告と対話プロンプトを簡単にバイパスできるため、ユーザーがだまされて悪意のある操作に署名するリスクがさらに高まります。 したがって、ウォレット実装における署名構造の識別および処理メカニズムの導入は、ユーザーのセキュリティを確保するための重要なリンクになります。
(1) ウォレット契約権限管理
多くのEIP-7702ウォレット契約は、プロキシアーキテクチャ(または内蔵管理権限)を採用して、ロジックのアップグレードをサポートしています。しかし、これにより権限管理リスクが高まります。アップグレード権限が厳しく制限されていない場合、攻撃者は実装契約を置き換え、悪意のあるコードを注入する可能性があり、ユーザーのアカウントが改ざんされるか、資金が盗まれる危険があります。
安全に関するアドバイス：
マルチシグネチャ、マルチファクター認証、またはタイムロックメカニズムを使用してアップグレード権限を制御します。
コードと権限の変更は厳格な監査とセキュリティ検証を経なければならない。
公開透明なアップグレードプロセスで、ユーザーの知る権利と参加権を保証します。
(2) ストレージ競合リスクおよびデータ隔離
ウォレットのコントラクトバージョンまたは異なるウォレットプロバイダーは、同じストレージスロットを再利用できます。 ユーザーがウォレットサービスプロバイダーを変更したり、ウォレットロジックをアップグレードしたりすると、ストレージスロットの再利用により状態変数が競合し、データの上書きや例外の読み取りなどの問題が発生します。 これは、ウォレットの正常な機能を妨害するだけでなく、資金の損失や異常な許可につながる可能性があります。
安全に関する提案：
専用のストレージ隔離ソリューション（例えばEIP-1967標準）を使用するか、ユニークなネームスペースを利用してストレージスロットを管理します。
アップグレード契約時は、ストレージレイアウトの互換性を確保し、変数の重複を避けてください。
ストレージの状態の妥当性を厳密にテストするアップグレードプロセス。
(3) ウォレット内部の nonce 管理
ウォレットコントラクトは通常、内部で nonce を設定し、自己管理を行って、ユーザー操作の実行順序を確保し、リプレイ攻撃を防ぎます。nonce が適切に使用されない場合、ユーザー操作が正常に実行されなくなります。
安全に関する提案：
nonceは強制的に等価（または増加）でなければならず、スキップすることはできません。
関数がnonceを直接変更することは禁止されています。ユーザー操作が実行される時にのみnonceが同期更新されます。
nonceの異常状況に対してフォールトトレランスと復旧メカニズムを設計し、nonceのデッドロックを回避する。
(4) 関数呼び出し者の権限チェック
安全を確保するために、ウォレット契約は重要な関数の呼び出し者がウォレットの所有者アカウントであることを確認する必要があります。一般的な2つの方法には、次のものが含まれます：
オフチェーン署名の権限付与
ユーザーはプライベートキーを使用して一連の操作に署名し、ウォレットコントラクトはチェーン上で署名が有効かどうか、有効期限が切れていないか、対応するnonceを満たしているかを検証します。この方法はEIP-7702が提唱するリレートランザクションモデル（ユーザーのオフライン署名 + リレーターによるトランザクションの送信）に適しています。
呼び出し制約 (msg.sender == address (this))
ユーザー操作関数は、契約自身によってのみ呼び出されることを許可します。これは本質的に呼び出しパス制御メカニズムであり、外部の発起者がそのアカウント自体であることを保証します。これは、呼び出し者が元のEOAであることを要求することと実質的に等価であり、この時の契約アドレスはEOAアドレスになります。
三、展望：EIP-7702 と未来の AA ウォレット標準
EIP-7702の提案は、従来のアカウントモデルの革新であるだけでなく、アカウント抽象化エコシステムの大幅な推進でもあります。 それによって導入された契約コードをロードするユーザーの能力は、将来のウォレット設計と契約システムのための探索のための広いスペースをもたらし、また、セキュリティ監査基準のための新しい要件を提唱します。
EIP-7702とEIP-4337は設計上の目標が異なりますが、前者はアカウントのコードロードメカニズムを再構築し、後者は完全なトランザクション入口とパッキングエコシステムを構築しています。しかし、両者は対立しているわけではなく、むしろ非常に強い相補性を持っています。
EIP-4337が提供するのは「汎用取引チャネル」と「抽象アカウント実行インターフェース」です；
EIP-7702は、ユーザーアカウントがアドレスを変更することなく、動的にコントラクトの論理能力を付与できることを許可します；
したがって、将来的なウォレットは「デュアルモードサポートアーキテクチャ」を採用する可能性があります：EIP-4337をサポートしていないチェーン上ではEIP-7702を軽量代替として使用し、オフチェーンパッキングやマルチユーザーアグリゲーションが必要なシナリオでは引き続きEIP-4337の完全プロトコルスタックに依存します。
このデュアルモードメカニズムは、ウォレットがカーネルレベルでより柔軟なアカウント権限モデル、ダウングレードメカニズム、およびロールバックソリューションをサポートすることを促進します。
EIP-7702が提唱するアカウントコントラクト化メカニズムは、現在人気のMPCウォレット、ZKウォレット、モジュール式ウォレットなどの新しいアーキテクチャと自然に融合する潜在能力を持っています。
MPCモードでは、署名行為は単一の秘密鍵に依存せず、複数の当事者が協調して決定します。EIP-7702とMPCの融合によって生成された署名は、動的にロードされるコントラクトロジックを制御し、より柔軟な実行戦略を実現します。
ZKウォレットは、ユーザーのアイデンティティや承認をゼロ知識証明を通じて検証し、秘密鍵情報を露出する必要がありません。EIP-7702と組み合わせることで、ZKウォレットは検証が完了した後に特定のロジックコントラクトを一時的に注入できるようになり、プライバシー計算後の個別の行動展開を実現します。たとえば、特定のプライバシー条件を満たした場合にのみ、特定のロジックを自動的に実行することができます。
モジュラーウォレット（Modular Wallets）は、EIP-7702を利用してアカウントロジックを複数のモジュールに分解し、必要に応じて動的にロードできます。
したがって、EIP-7702は上記の高度なウォレットに対して、よりネイティブな「実行コンテナ」を提供します：ユーザーアドレスはそのままで、異なる契約ロジックを注入でき、従来の契約デプロイメントプロセスにおけるアドレス依存の問題を回避し、事前にデプロイする必要もなく、アカウントの行動の柔軟性と組み合わせ能力が大幅に向上します。
EIP-7702は、開発パラダイムに大きな変化をもたらします。 契約開発者は、もはや単に発信者を従来のEOAまたは固定契約アカウントとして扱うのではなく、新しいメカニズムに適応する必要があります:呼び出し元のIDは、トランザクション中にEOAと契約ステータスの間で動的に切り替えることができ、アカウントの動作ロジックはもはや静的に固まらず、需要に応じて柔軟に変更することができます。 これには、開発者と監査人が次のことを行う必要があります。
より厳格なcaller検証と権限判断ロジックを導入する；
動的契約ロジックの影響を受けているかどうか、呼び出しパスを確認する；
msg.sender.code.length == 0、isContract ()などの動作に依存する潜在的な脆弱性を特定します。
契約ロジックの「コンテキスト依存」を明確にする。例えば、静的呼び出しやdeleGatecallの境界制御；
ツールチェーンレベルでsetCodeシナリオのシミュレーションと復元分析をサポートします。
言い換えれば、コードの安全性はもはや「デプロイ前の問題」ではなく、「呼び出し時や取引時にも検証が必要な動的プロセス」となった。
四、まとめ
EIP-7702 では、より軽量でネイティブで柔軟な Account Abstraction (AA) の実装が導入されており、通常の EOA でコントラクト ロジックを伝送し、1 つのトランザクションで実行できます。 このメカニズムは、アカウントの動作に関する従来の静的な仮定を破り、開発者はもはやアカウントアドレスのコード状態に依存してその動作モデルを判断するのではなく、呼び出し元のIDと権限の境界の理解を再構築する必要があります。 それに伴い、セキュリティ分析のパラダイムシフトがもたらされます。 監査の焦点は、もはや「アドレスに権限があるかどうか」に限定されず、「トランザクションで運ばれるコントラクトロジックが現在のコンテキストで何ができるか」に移ります。 各トランザクションには、動作の独立した定義がある場合があり、これにより、アカウントにより多くの機能が提供され、セキュリティ監査に対するより高い要件が提唱されます。