--- title: ペクトラ 7702 metaTitle: Pectra EIP-7702 guidelines description: ペクトラ・リリースにおける7702の詳細を学ぶ lang: ja --- ## 概要 EIP-7702は、EOAにコードを追加するメカニズムを定義しています。この提案により、従来のイーサリアムのアカウントであるEOAが短期的な機能改善を享受できるようになり、アプリケーションのユーザビリティが向上します。これは、新しいトランザクション・タイプであるタイプ4を使用して、すでにデプロイされたコードへのポインタを設定することによって行われます。 この新しいトランザクション・タイプは、認可リストを導入します。リスト内の各認可タプルは次のように定義されます。 ``` [ chain_id, address, nonce, y_parity, r, s ] ``` **address** は委任です（EOAによって使用される、すでにデプロイされたバイトコード）。 **chain_id** は、認可を特定のチェーンにロックします（すべてのチェーンの場合は0）。 **nonce** は、認可を特定のアカウントのナンスにロックします。 (**y_parity, r, s**) は認可タプルの署名であり、認可が適用されるEOA（オーソリティとも呼ばれます）の秘密鍵による `keccak(0x05 || rlp ([chain_id ,address, nonce]))` として定義されます。 委任は、nullアドレスにデリゲートすることでリセットできます。 EOAの秘密鍵は、委任後もアカウントの完全な制御を維持します。たとえば、Safeにデリゲートしても、任意の署名ポリシーをバイパスできる単一の鍵が依然として存在するため、アカウントがマルチシグになるわけではありません。今後、開発者はシステム内のすべての参加者がスマート・コントラクトである可能性があるという前提で設計する必要があります。スマート・コントラクトの開発者にとって、`tx.origin` がEOAを指すと想定することはもはや安全ではありません。 ## ベストプラクティス **アカウント抽象化**: 委任コントラクトは、互換性を最大化するために、イーサリアムのより広範なアカウント抽象化（AA）標準に準拠する必要があります。特に、ERC-4337に準拠しているか、互換性があることが理想的です。 **パーミッションレスで検閲耐性のある設計**: イーサリアムはパーミッションレスな参加を重視しています。委任コントラクトは、単一の「信頼できる」リレイヤーやサービスをハードコードしたり、それに依存したりしてはなりません。リレイヤーがオフラインになった場合、アカウントが機能しなくなるためです。バッチ処理（例: approve+transferFrom）などの機能は、リレイヤーなしでEOA自体が使用できます。EIP-7702によって可能になる高度な機能（ガスの抽象化、プライバシーを保護する出金）を使用したいアプリケーション開発者には、リレイヤーが必要になります。さまざまなリレイヤー・アーキテクチャがありますが、少なくとも[エントリ・ポイント 0.8](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0)を指す[ERC-4337バンドラー](https://www.erc4337.io/bundlers)を使用することをお勧めします。その理由は以下の通りです。 - リレーのための標準化されたインターフェースを提供する - 組み込みのペイマスター・システムが含まれている - 前方互換性を確保する - [パブリック・メンプール](https://notes.ethereum.org/@yoav/unified-erc-4337-mempool)を通じて検閲耐性をサポートできる - init関数が[EntryPoint](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0)からのみ呼び出されるようにリクワイアできる 言い換えれば、アカウントからの必要な有効な署名またはユーザーオペレーションを提供する限り、誰でもトランザクションのスポンサー/リレイヤーとして機能できるべきです。これにより検閲耐性が確保されます。カスタム・インフラストラクチャが不要であれば、ゲートキーパーとなるリレーによってユーザーのトランザクションが恣意的にブロックされることはありません。たとえば、[メタマスクのDelegation Toolkit](https://github.com/MetaMask/delegation-framework/releases/tag/v1.3.0)は、メタマスク専用のサーバーを必要とするのではなく、任意のチェーン上の任意のERC-4337バンドラーまたはペイマスターと明示的に連携します。 **ウォレット・インターフェースを介した分散型アプリケーション (dapp) の統合**: ウォレットがEIP-7702の特定の委任コントラクトをホワイトリストに登録することを考慮すると、dappはEIP-7702の認可を直接要求することを期待すべきではありません。代わりに、標準化されたウォレット・インターフェースを通じて統合を行う必要があります。 - **ERC-5792 (`wallet_sendCalls`)**: dappがウォレットにバッチ呼び出しの実行を要求できるようにし、トランザクションのバッチ処理やガスの抽象化などの機能を促進します。 - **ERC-6900**: dappがウォレット管理のモジュールを通じて、セッション鍵やアカウント復旧などのモジュール式スマート・アカウント機能を活用できるようにします。 これらのインターフェースを利用することで、dappは委任を直接管理することなく、EIP-7702によって提供されるスマート・アカウント機能にアクセスでき、さまざまなウォレット実装間での互換性とセキュリティを確保できます。 > 注: dappがEIP-7702の認可署名を直接要求するための標準化された方法はありません。dappは、EIP-7702の機能を活用するために、ERC-6900などの特定のウォレット・インターフェースに依存する必要があります。 詳細情報: - [ERC-5792 仕様](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5792.md) - [ERC-6900 仕様](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6900.md) **ベンダーロックインの回避**: 上記と同様に、優れた実装はベンダー中立であり、相互運用可能です。これは多くの場合、スマート・アカウントの新たな標準に準拠することを意味します。たとえば、[AlchemyのModular Account](https://github.com/alchemyplatform/modular-account)は、モジュール式スマート・アカウントのERC-6900標準を使用しており、「パーミッションレスで相互運用可能な使用」を念頭に置いて設計されています。 **プライバシーの保護**: オンチェーンのプライバシーは限られていますが、委任コントラクトはデータの露出とリンク可能性を最小限に抑えるよう努めるべきです。これは、ERC-20トークンでのガス支払い（ユーザーが公開のETH残高を維持する必要がなくなり、プライバシーとUXが向上します）や、1回限りのセッション鍵（単一の長期的な鍵への依存を減らします）などの機能をサポートすることで実現できます。たとえば、EIP-7702では、スポンサー付きトランザクションを介してトークンでガスを支払うことが可能であり、優れた実装であれば、必要以上の情報を漏らすことなく、そのようなペイマスターを簡単に統合できるようになります。さらに、特定の承認をオフチェーンでデリゲートする（オンチェーンで検証される署名を使用する）ことで、ユーザーのプライマリ鍵を使用したオンチェーン・トランザクションが減り、プライバシーの保護に役立ちます。リレイヤーの使用を必要とするアカウントは、ユーザーにIPアドレスの公開を強制します。パブリック・メンプールはこれを改善します。トランザクションやユーザーオペレーションがメンプールを通じて伝播する際、それが送信元のIPから発生したものか、p2pプロトコルを介して単にリレーされたものかを区別することはできません。 **拡張性とモジュール式セキュリティ**: アカウントの実装は、新機能やセキュリティの改善に合わせて進化できるように拡張可能であるべきです。EIP-7702では、アップグレード可能性が本質的に可能です（EOAは将来、ロジックをアップグレードするために常に新しいコントラクトにデリゲートできるため）。アップグレード可能性を超えて、優れた設計はモジュール性を可能にします。たとえば、完全に再デプロイすることなく、さまざまな署名スキームや支出ポリシーのためのプラグイン・モジュールを利用できます。AlchemyのAccount Kitはその代表的な例であり、開発者は検証モジュール（ECDSA、BLSなどのさまざまな署名タイプ用）とカスタム・ロジック用の実行モジュールをインストールできます。EIP-7702対応アカウントでより高い柔軟性とセキュリティを実現するために、開発者は特定の実装に直接デリゲートするのではなく、プロキシ・コントラクトにデリゲートすることが推奨されます。このアプローチにより、変更のたびに追加のEIP-7702認可を必要とせずに、シームレスなアップグレードとモジュール性が可能になります。 プロキシ・パターンの利点: - **アップグレード可能性**: プロキシを新しい実装コントラクトに向けることで、コントラクトのロジックを更新します。 - **カスタム初期化ロジック**: プロキシ内に初期化関数を組み込み、必要な状態変数を安全に設定します。 たとえば、[SafeEIP7702Proxy](https://docs.safe.global/advanced/eip-7702/7702-safe)は、EIP-7702互換アカウントで委任を安全に初期化および管理するためにプロキシをどのように利用できるかを示しています。 プロキシ・パターンの欠点: - **外部アクターへの依存**: 安全でないコントラクトにアップグレードしないように、外部チームに依存する必要があります。 ## セキュリティに関する考慮事項 {#security-considerations} **リエントランシー・ガード**: EIP-7702の委任の導入により、ユーザーのアカウントは外部所有アカウント（EOA）とスマート・コントラクト（SC）の間を動的に切り替えることができます。この柔軟性により、アカウントはトランザクションを開始することも、呼び出しのターゲットになることも可能になります。その結果、アカウントが自身を呼び出し、外部呼び出しを行うシナリオでは、`msg.sender` が `tx.origin` と等しくなり、以前は `tx.origin` が常にEOAであることに依存していた特定のセキュリティ上の前提が損なわれます。 スマート・コントラクトの開発者にとって、`tx.origin` がEOAを指すと想定することはもはや安全ではありません。同様に、リエントランシー攻撃に対する保護手段として `msg.sender == tx.origin` を使用することは、もはや信頼できるストラテジーではありません。 今後、開発者はシステム内のすべての参加者がスマート・コントラクトである可能性があるという前提で設計する必要があります。あるいは、`nonReentrant` 修飾子パターンを持つリエントランシー・ガードを使用して、明示的なリエントランシー保護を実装することもできます。監査済みの修飾子（例: [OpenZeppelinのリエントランシー・ガード](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/ReentrancyGuard.sol)）に従うことをお勧めします。また、[一時ストレージ変数](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html)を使用することもできます。 **初期化のセキュリティに関する考慮事項** EIP-7702の委任コントラクトを実装すると、特に初期化プロセスに関して特有のセキュリティ上の課題が生じます。初期化関数（`init`）が委任プロセスとアトミックに結合されている場合、重大な脆弱性が発生します。このような場合、フロントランナーが委任署名を傍受し、変更されたパラメータで `init` 関数を実行して、アカウントの制御を奪う可能性があります。 このリスクは、既存のスマート・コントラクト・アカウント（SCA）の実装を、その初期化メカニズムを変更せずにEIP-7702で使用しようとする場合に特に関連します。 **初期化の脆弱性を軽減するための解決策** - `initWithSig` の実装 標準の `init` 関数を、ユーザーに初期化パラメータへの署名を要求する `initWithSig` 関数に置き換えます。このアプローチにより、初期化はユーザーの明示的な同意がある場合にのみ進行することが保証され、不正な初期化のリスクが軽減されます。 - ERC-4337のEntryPointの利用 初期化関数がERC-4337のEntryPointコントラクトからのみ呼び出されるようにリクワイアします。この方法は、ERC-4337によって提供される標準化された検証および実行フレームワークを活用し、初期化プロセスに追加のセキュリティ・レイヤーを加えます。 _（参照: [Safe ドキュメント](https://docs.safe.global/advanced/eip-7702/7702-safe)）_ これらの解決策を採用することで、開発者はEIP-7702の委任コントラクトのセキュリティを強化し、初期化フェーズにおける潜在的なフロントランニング攻撃から保護することができます。 **ストレージの衝突** コードをデリゲートしても、既存のストレージはクリアされません。ある委任コントラクトから別の委任コントラクトに移行する場合、前のコントラクトの残存データが残ります。新しいコントラクトが同じストレージ・スロットを利用しつつ、それらを異なる方法で解釈する場合、意図しない動作を引き起こす可能性があります。たとえば、最初の委任先がストレージ・スロットを `bool` として表すコントラクトであり、その後の委任先が同じスロットを `uint` として表すコントラクトである場合、この不一致は予測不可能な結果を招く可能性があります。 **フィッシングのリスク** EIP-7702の委任の実装により、ユーザーのアカウント内の資産は完全にスマート・コントラクトによって制御される可能性があります。ユーザーが気付かずに悪意のあるコントラクトにアカウントをデリゲートした場合、攻撃者は簡単に制御を奪い、資金を盗むことができます。`chain_id=0` を使用する場合、委任はすべてのチェーンIDに適用されます。イミュータブルなコントラクトにのみデリゲートし（プロキシには絶対にデリゲートしないでください）、デプロイヤーが他の場所で同じアドレスに異なるものをデプロイできないように、CREATE2（標準のinitcodeを使用し、メタモルフィック・コントラクトではないもの）を使用してデプロイされたコントラクトにのみデリゲートしてください。そうしないと、委任によって他のすべてのEVMチェーンでアカウントが危険にさらされます。 ユーザーが委任の署名を行う際、フィッシングのリスクを軽減するために、委任を受けるターゲット・コントラクトが明確かつ目立つように表示されるべきです。 **最小限の信頼サーフェスとセキュリティ**: 柔軟性を提供する一方で、委任コントラクトはそのコア・ロジックを最小限に抑え、監査可能に保つべきです。コントラクトは事実上ユーザーのEOAの拡張であるため、いかなる欠陥も壊滅的な結果を招く可能性があります。実装は、スマート・コントラクト・セキュリティ・コミュニティのベストプラクティスに従う必要があります。たとえば、コンストラクタや初期化関数は慎重に保護されなければなりません。Alchemyが強調しているように、7702の下でプロキシ・パターンを使用する場合、保護されていない初期化関数は攻撃者にアカウントの乗っ取りを許す可能性があります。チームはオンチェーンのコードをシンプルに保つことを目指すべきです。Ambireの7702コントラクトはわずか約200行のSolidityであり、バグを減らすために意図的に複雑さを最小限に抑えています。機能豊富なロジックと、監査を容易にするシンプルさのバランスを取る必要があります。 ### 既知の実装 EIP-7702の性質上、ウォレットがユーザーによるサードパーティのコントラクトへのデリゲートを支援する際には注意を払うことが推奨されます。以下にリストされているのは、監査済みの既知の実装のコレクションです。 | コントラクト・アドレス | ソース | 監査 | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 0x000000009B1D0aF20D8C6d0A44e162d11F9b8f00 | [Uniswap/calibur](https://github.com/Uniswap/calibur) | [監査](https://github.com/Uniswap/calibur/tree/main/audits) | | 0x69007702764179f14F51cdce752f4f775d74E139 | [alchemyplatform/modular-account](https://github.com/alchemyplatform/modular-account) | [監査](https://github.com/alchemyplatform/modular-account/tree/develop/audits) | | 0x5A7FC11397E9a8AD41BF10bf13F22B0a63f96f6d | [AmbireTech/ambire-common](https://github.com/AmbireTech/ambire-common/blob/feature/eip-7702/contracts/AmbireAccount7702.sol) | [監査](https://github.com/AmbireTech/ambire-common/tree/feature/eip-7702/audits) | | 0x63c0c19a282a1b52b07dd5a65b58948a07dae32b | [MetaMask/delegation-framework](https://github.com/MetaMask/delegation-framework) | [監査](https://github.com/MetaMask/delegation-framework/tree/main/audits) | | 0x4Cd241E8d1510e30b2076397afc7508Ae59C66c9 | [イーサリアム財団 AAチーム](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/accounts/Simple7702Account.sol) | [監査](https://github.com/eth-infinitism/account-abstraction/blob/develop/audits/SpearBit%20Account%20Abstraction%20Security%20Review%20-%20Mar%202025.pdf) | | 0x17c11FDdADac2b341F2455aFe988fec4c3ba26e3 | [Luganodes/Pectra-Batch-Contract](https://github.com/Luganodes/Pectra-Batch-Contract) | [監査](https://certificate.quantstamp.com/full/luganodes-pectra-batch-contract/23f0765f-969a-4798-9edd-188d276c4a2b/index.html) | ## ハードウェア・ウォレットのガイドライン {#hardware-wallet-guidelines} ハードウェア・ウォレットは任意の委任を公開すべきではありません。ハードウェア・ウォレット分野におけるコンセンサスは、信頼できるデリゲーター・コントラクトのリストを使用することです。上記にリストされている既知の実装を許可し、その他の実装についてはケースバイケースで検討することをお勧めします。EOAをコントラクトにデリゲートするとすべての資産の制御が渡されるため、ハードウェア・ウォレットは7702の実装方法に慎重になる必要があります。 ### コンパニオン・アプリの統合シナリオ {#integration-scenarios-for-companion-apps} #### レイジー（Lazy） {#lazy} EOAは依然として通常通り動作するため、何もすることはありません。 注: ERC-1155 NFTなど、一部の資産は委任コードによって自動的に拒否される可能性があり、サポートはこれを認識しておく必要があります。 #### アウェア（Aware） {#aware} コードをチェックしてEOAに委任が設定されていることをユーザーに通知し、オプションで委任の解除を提案します。 #### 一般的な委任 ハードウェア・プロバイダーは、既知の委任コントラクトをホワイトリストに登録し、ソフトウェア・コンパニオンでそのサポートを実装します。ERC-4337を完全にサポートするコントラクトを選択することをお勧めします。 異なるコントラクトにデリゲートされたEOAは、標準のEOAとして処理されます。 #### カスタム委任 ハードウェア・プロバイダーは独自の委任コントラクトを実装し、それをリストに追加して、ソフトウェア・コンパニオンでそのサポートを実装します。ERC-4337を完全にサポートするコントラクトを構築することをお勧めします。 異なるコントラクトにデリゲートされたEOAは、標準のEOAとして処理されます。