Pectra 7702

概要

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

この新しいトランザクションタイプでは、認証リストが導入されます。 リスト内の各認証タプルは、次のように定義されます。

[ chain_id, address, nonce, y_parity, r, s ]

address は委任です (EOAによって使用される、すでにデプロイされたバイトコード) chain_id は、認証を特定のチェーン (またはすべてのチェーンに対して0) にロックします nonce は、認証を特定のアカウントの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.8opens in a new tabを指す4337バンドラーopens in a new tabを使用することをお勧めします。理由は次のとおりです。

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

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

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

ウォレットはEIP-7702の特定の委任コントラクトをホワイトリストに登録するため、dAppsは7702の認証を直接リクエストすることを想定すべきではありません。 代わりに、統合は標準化されたウォレットインターフェースを通じて行われるべきです:

• ERC-5792 (wallet_sendCalls): dAppsがウォレットにバッチコールの実行をリクエストできるようにし、トランザクションのバッチ処理やガスの抽象化などの機能を容易にします。

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

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

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

詳細については：

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

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

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

拡張性とモジュラーセキュリティ: アカウントの実装は、新しい機能やセキュリティの向上とともに進化できるように、拡張可能であるべきです。 アップグレード可能性はEIP-7702に本来備わっています (EOAはいつでも将来的に新しいコントラクトに委任してロジックをアップグレードできるため)。 アップグレード可能性を超えて、優れた設計はモジュール性を提供します。例えば、異なる署名スキームや支出ポリシーのためのプラグインモジュールにより、全体を再デプロイする必要がなくなります。 Alchemyのアカウントキットは好例で、デベロッパーは (ECDSA、BLSなどの異なる署名タイプのための) 検証モジュールをインストールできます。 およびカスタムロジックのための実行モジュール。 EIP-7702対応アカウントでより高い柔軟性とセキュリティを実現するために、デベロッパーは特定の実装に直接委任するのではなく、プロキシコントラクトに委任することが推奨されます。 このアプローチにより、各変更に追加のEIP-7702認証を必要とせずに、シームレスなアップグレードとモジュール性が可能になります。

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

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

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

例えば、SafeEIP7702Proxyopens 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を実装する方法に注意する必要があります。

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

レイジー

EOAは通常通り動作し続けるため、何もする必要はありません。

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

アウェア

EOAのコードをチェックして、委任が行われていることをユーザーに通知し、オプションで委任の削除をオファーします。

共通の委任

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

別のものに委任されたEOAは、標準のEOAとして処理されます。

カスタム委任

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

別のものに委任されたEOAは、標準のEOAとして処理されます。

最終更新： 2025年10月22日

popens in a new tab

wopens in a new tab

copens in a new tab

+6

貢献者を表示