ペクトラ 7702

概要

EIP-7702は、EOAにコードを追加するメカニズムを定義しています。この提案により、従来のイーサリアムのアカウントであるEOAが短期的な機能改善を享受できるようになり、アプリケーションのユーザビリティが向上します。これは、新しいトランザクション・タイプであるタイプ4を使用して、すでにデプロイされたコードへのポインタを設定することによって行われます。

この新しいトランザクション・タイプは、認可リスト（authorization list）を導入します。リスト内の各認可タプルは次のように定義されます。

[ 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自体が使用できます。7702によって可能になる高度な機能（ガス抽象化、プライバシー保護付きの引き出し）を使用したいアプリケーション開発者には、リレイヤーが必要です。さまざまなリレイヤー・アーキテクチャがありますが、少なくともエントリーポイント 0.8 (opens in a new tab)を指す4337バンドラー (opens in a new tab)を使用することをお勧めします。その理由は以下の通りです。

• リレーのための標準化されたインターフェースを提供する
• 組み込みのペイマスター・システムが含まれている
• 前方互換性を確保する
• パブリックなメンプール (opens in a new tab)を通じて検閲耐性をサポートできる
• init関数がEntryPoint (opens in a new tab)からのみ呼び出されるようにリクワイアできる

言い換えれば、アカウントから必要な有効な署名またはユーザーオペレーションを提供する限り、誰でもトランザクションのスポンサー/リレイヤーとして機能できるべきです。これにより検閲耐性が確保されます。カスタム・インフラストラクチャが不要であれば、ゲートキーパーとなるリレーによってユーザーのトランザクションが恣意的にブロックされることはありません。たとえば、メタマスクのDelegation Toolkit (opens in a new tab)は、メタマスク専用のサーバーを必要とせず、任意のチェーン上の任意のERC-4337バンドラーまたはペイマスターと明示的に連携します。

ウォレット・インターフェースを介したdappの統合:

ウォレットがEIP-7702の特定の委任コントラクトをホワイトリストに登録することを考慮すると、分散型アプリケーション (dapp) は7702の認可を直接要求することを期待すべきではありません。代わりに、標準化されたウォレット・インターフェースを通じて統合を行う必要があります。

• ERC-5792 (wallet_sendCalls): dappがウォレットにバッチ呼び出しの実行を要求できるようにし、トランザクションのバッチ処理やガス抽象化などの機能を促進します。

• ERC-6900: dappがウォレット管理のモジュールを通じて、セッション鍵やアカウント復元などのモジュール式スマート・アカウント機能を活用できるようにします。

これらのインターフェースを利用することで、dappは委任を直接管理することなく、EIP-7702によって提供されるスマート・アカウント機能にアクセスでき、さまざまなウォレット実装間での互換性とセキュリティを確保できます。

注: dappが7702の認可署名を直接要求するための標準化された方法はありません。dappは、EIP-7702の機能を活用するために、ERC-6900などの特定のウォレット・インターフェースに依存する必要があります。

詳細情報:

• ERC-5792 仕様 (opens in a new tab)
• ERC-6900 仕様 (opens in a new tab)

ベンダーロックインの回避: 上記に沿って、優れた実装はベンダーニュートラルであり、相互運用可能です。これは多くの場合、スマート・アカウントの新たな標準に準拠することを意味します。たとえば、AlchemyのModular Account (opens in a new tab)は、モジュール式スマート・アカウントのERC-6900標準を使用しており、「パーミッションレスで相互運用可能な使用」を念頭に置いて設計されています。

プライバシーの保護: オンチェーンのプライバシーは限られていますが、委任コントラクトはデータの露出とリンク可能性を最小限に抑えるよう努めるべきです。これは、ERC-20トークンでのガス支払い（ユーザーが公開のETH残高を維持する必要がなくなり、プライバシーとUXが向上します）や、ワンタイム・セッション鍵（単一の長期鍵への依存を減らします）などの機能をサポートすることで実現できます。たとえば、EIP-7702はスポンサー付きトランザクションを介したトークンでのガス支払いを可能にしており、優れた実装であれば、必要以上の情報を漏らすことなく、そのようなペイマスターを簡単に統合できます。さらに、特定の承認をオフチェーンで委任する（オンチェーンで検証される署名を使用する）ことで、ユーザーのプライマリ鍵を使用したオンチェーン・トランザクションが減り、プライバシーの向上に役立ちます。リレイヤーの使用を必要とするアカウントは、ユーザーにIPアドレスの公開を強制します。パブリックなメンプールはこれを改善します。トランザクションやユーザーオペレーションがメンプールを通じて伝播する際、それが送信元のIPから発生したものか、p2pプロトコルを介してリレーされただけなのかを区別できなくなります。

拡張性とモジュール式セキュリティ: アカウントの実装は、新機能やセキュリティの改善とともに進化できるように拡張可能であるべきです。EIP-7702では、アップグレード可能性が本質的に可能です（EOAは将来、ロジックをアップグレードするために常に新しいコントラクトにデリゲートできるため）。アップグレード可能性を超えて、優れた設計はモジュール性を可能にします。たとえば、完全に再デプロイすることなく、さまざまな署名スキームや支出ポリシー用のプラグイン・モジュールを追加できます。AlchemyのAccount Kitはその典型的な例であり、開発者は検証モジュール（ECDSA、BLSなどのさまざまな署名タイプ用）やカスタム・ロジック用の実行モジュールをインストールできます。EIP-7702対応アカウントでより高い柔軟性とセキュリティを実現するために、開発者は特定の実装に直接デリゲートするのではなく、プロキシ・コントラクトにデリゲートすることが推奨されます。このアプローチにより、変更のたびに追加のEIP-7702認可を必要とせずに、シームレスなアップグレードとモジュール性が可能になります。

プロキシ・パターンの利点:

• アップグレード可能性: プロキシを新しい実装コントラクトに向けることで、コントラクトのロジックを更新します。

• カスタム初期化ロジック: プロキシ内に初期化関数を組み込み、必要な状態変数を安全に設定します。

たとえば、SafeEIP7702Proxy (opens in a new tab)は、EIP-7702互換アカウントで委任を安全に初期化および管理するためにプロキシをどのように利用できるかを示しています。

プロキシ・パターンの欠点:

• 外部アクターへの依存: 安全でないコントラクトにアップグレードしないように、外部チームに依存する必要があります。

セキュリティに関する考慮事項

リエントランシー・ガード: EIP-7702の委任の導入により、ユーザーのアカウントは外部所有アカウント（EOA）とスマート・コントラクト（SC）の間を動的に切り替えることができます。この柔軟性により、アカウントはトランザクションを開始することも、呼び出しのターゲットになることも可能になります。その結果、アカウントが自身を呼び出し、外部呼び出しを行うシナリオでは、msg.sender が tx.origin と等しくなり、以前は tx.origin が常にEOAであることに依存していた特定のセキュリティ上の前提が損なわれます。

スマート・コントラクトの開発者にとって、tx.origin がEOAを指すと想定することはもはや安全ではありません。同様に、リエントランシー攻撃に対する保護手段として msg.sender == tx.origin を使用することは、もはや信頼できるストラテジーではありません。

今後、開発者はシステム内のすべての参加者がスマート・コントラクトである可能性があるという前提で設計する必要があります。あるいは、nonReentrant 修飾子パターンを持つリエントランシー・ガードを使用して、明示的なリエントランシー保護を実装することもできます。監査済みの修飾子（例: OpenZeppelinのリエントランシー・ガード (opens in a new tab)）に従うことをお勧めします。また、一時ストレージ変数 (opens in a new tab)を使用することもできます。

初期化のセキュリティに関する考慮事項

EIP-7702の委任コントラクトを実装すると、特に初期化プロセスに関して特有のセキュリティ上の課題が生じます。初期化関数（init）が委任プロセスとアトミックに結合されている場合、重大な脆弱性が発生します。このような場合、フロントランナーが委任署名を傍受し、変更されたパラメータで init 関数を実行して、アカウントの制御を奪う可能性があります。

このリスクは、既存のスマート・コントラクト・アカウント（SCA）の実装を、その初期化メカニズムを変更せずにEIP-7702で使用しようとする場合に特に関連します。

初期化の脆弱性を軽減するための解決策

• initWithSig の実装
  標準の init 関数を、ユーザーに初期化パラメータへの署名を要求する initWithSig 関数に置き換えます。このアプローチにより、初期化はユーザーの明示的な同意がある場合にのみ進行することが保証され、不正な初期化のリスクが軽減されます。

• ERC-4337のEntryPointの利用
  初期化関数がERC-4337のEntryPointコントラクトからのみ呼び出されるようにリクワイアします。この方法は、ERC-4337によって提供される標準化された検証および実行フレームワークを活用し、初期化プロセスに追加のセキュリティ・レイヤーを加えます。
  （参照: Safe ドキュメント (opens in a new tab)）

これらの解決策を採用することで、開発者はEIP-7702の委任コントラクトのセキュリティを強化し、初期化フェーズにおける潜在的なフロントランニング攻撃から保護することができます。

ストレージの衝突 コードをデリゲートしても、既存のストレージはクリアされません。ある委任コントラクトから別の委任コントラクトに移行する場合、前のコントラクトの残存データが残ります。新しいコントラクトが同じストレージ・スロットを利用しつつ、それらを異なる方法で解釈する場合、意図しない動作を引き起こす可能性があります。たとえば、最初の委任先がストレージ・スロットを bool として表すコントラクトであり、その後の委任先が同じスロットを uint として表すコントラクトである場合、この不一致は予測不可能な結果を招く可能性があります。

フィッシングのリスク EIP-7702の委任の実装により、ユーザーのアカウント内の資産は完全にスマート・コントラクトによって制御される可能性があります。ユーザーが気付かずに悪意のあるコントラクトにアカウントをデリゲートした場合、攻撃者は簡単に制御を奪い、資金を盗むことができます。chain_id=0 を使用する場合、委任はすべてのチェーンIDに適用されます。イミュータブルなコントラクトにのみデリゲートし（プロキシには絶対にデリゲートしないでください）、デプロイヤーが他の場所で同じアドレスに異なるものをデプロイできないように、CREATE2（標準のinitcodeを使用し、メタモルフィック・コントラクトではないもの）を使用してデプロイされたコントラクトにのみデリゲートしてください。そうしないと、委任によって他のすべてのEVMチェーンでアカウントが危険にさらされます。

ユーザーが委任の署名を行う際、フィッシングのリスクを軽減するために、委任を受けるターゲット・コントラクトが明確かつ目立つように表示されるべきです。

最小限の信頼サーフェスとセキュリティ: 柔軟性を提供する一方で、委任コントラクトはそのコア・ロジックを最小限に抑え、監査可能に保つべきです。コントラクトは事実上ユーザーのEOAの拡張であるため、いかなる欠陥も壊滅的な結果を招く可能性があります。実装は、スマート・コントラクト・セキュリティ・コミュニティのベストプラクティスに従う必要があります。たとえば、コンストラクタや初期化関数は慎重に保護されなければなりません。Alchemyが強調しているように、7702の下でプロキシ・パターンを使用する場合、保護されていない初期化関数は攻撃者にアカウントの乗っ取りを許す可能性があります。チームはオンチェーンのコードをシンプルに保つことを目指すべきです。Ambireの7702コントラクトはわずか約200行のSolidityであり、バグを減らすために意図的に複雑さを最小限に抑えています。機能豊富なロジックと、監査を容易にするシンプルさのバランスを取る必要があります。

既知の実装

EIP-7702の性質上、ウォレットがユーザーによるサードパーティ・コントラクトへのデリゲートを支援する際には注意を払うことが推奨されます。以下にリストされているのは、監査済みの既知の実装のコレクションです。

ハードウェア・ウォレットのガイドライン

ハードウェア・ウォレットは任意の委任を公開すべきではありません。ハードウェア・ウォレット分野におけるコンセンサスは、信頼できるデリゲーター・コントラクトのリストを使用することです。上記にリストされている既知の実装を許可し、その他の実装についてはケースバイケースで検討することをお勧めします。EOAをコントラクトにデリゲートするとすべての資産の制御が渡されるため、ハードウェア・ウォレットは7702の実装方法に慎重になる必要があります。

コンパニオン・アプリの統合シナリオ

レイジー（Lazy）

EOAは依然として通常通り動作するため、何もすることはありません。

注: ERC-1155 NFTなど、一部の資産は委任コードによって自動的に拒否される可能性があり、サポートはこれを認識しておく必要があります。

アウェア（Aware）

コードをチェックしてEOAに委任が設定されていることをユーザーに通知し、オプションで委任の解除を提案します。

一般的な委任（Common delegation）

ハードウェア・プロバイダーは既知の委任コントラクトをホワイトリストに登録し、ソフトウェア・コンパニオンでそのサポートを実装します。完全なERC-4337サポートを備えたコントラクトを選択することをお勧めします。

異なるコントラクトにデリゲートされたEOAは、標準のEOAとして処理されます。

カスタム委任（Custom delegation）

ハードウェア・プロバイダーは独自の委任コントラクトを実装し、それをリストに追加してソフトウェア・コンパニオンでそのサポートを実装します。完全なERC-4337サポートを備えたコントラクトを構築することをお勧めします。

異なるコントラクトにデリゲートされたEOAは、標準のEOAとして処理されます。

ページの最終更新: 2026年6月6日

p (opens in a new tab)

c (opens in a new tab)

j (opens in a new tab)

+6

コントリビューターを見る