承認者が承認データに署名した後、取引の発起者はそれを authorization_list フィールドに集約して署名し、RPC を通じて取引をブロードキャストします。取引がブロックに含まれて実行される前に、Proposer はまず取引を事前チェックします。この中で to アドレスに対して強制チェックを行い、この取引が契約作成取引でないことを確認します。つまり、EIP-7702 タイプの取引を送信する際、取引の to アドレスは空であってはなりません。
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
EIP-7702：イーサリアムPectraアップグレードによるEOAの重大な変革
イーサリアム Pectra アップグレード中の EIP-7702: EOA の重大な変革を実現
イントロダクション
イーサリアムはPectraアップグレードを迎えようとしており、これは重要な更新です。その中で、EIP-7702はイーサリアム外部アカウント(EOA)に対して画期的な改造を行いました。この提案はEOAと契約アカウントCAの境界を曖昧にし、EIP-4337に続く、ネイティブアカウントの抽象化に向けた重要なステップであり、イーサリアムエコシステムに新しいインタラクションモデルをもたらしました。
Pectraはテストネットでの展開を完了し、近日中にメインネットに上线する予定です。本稿では、EIP-7702の実装メカニズムを深く分析し、それがもたらす可能性のある機会と課題について探求し、さまざまな参加者に実用的な操作ガイドを提供します。
プロトコル分析
###概要
EIP-7702は新しい取引タイプを導入し、EOAがスマートコントラクトアドレスを指定してコードを設定できるようにします。これにより、EOAはスマートコントラクトのようにコードを実行できる一方で、取引を開始する能力も保持します。この特性は、EOAにプログラム可能性とコンポーザビリティを与え、ユーザーはEOA内でソーシャルリカバリー、権限管理、多署名管理、zk検証、サブスクリプション型支払い、取引スポンサーシップ、取引バッチ処理などの機能を実現できます。注目すべきは、EIP-7702がEIP-4337によって実現されたスマートコントラクトウォレットと完全に互換性があり、両者のシームレスな統合は新機能の開発と適用プロセスを大幅に簡素化することです。
EIP-7702 の具体的な実装は、取引タイプ SET_CODE_TX_TYPE (0x04) の取引を導入することであり、そのデータ構造は以下のように定義されています:
rlp([chain_id、nonce、max_priority_fee_per_gas、max_fee_per_gas、gas_limit、目的地、値、データ、access_list、authorization_list、signature_y_parity、 signature_r、signature_s])
その中でauthorization_listフィールドは次のように定義されています:
authorization_list = [[chain_id, 住所, nonce, y_parity, r, s], ...]
新しい取引構造では、authorization_list フィールドを除いて、残りは EIP-4844 と同じ意味を持ちます。このフィールドはリスト型で、リストには複数の承認エントリを含めることができ、各承認エントリには次のように記載されます:
一つの取引内の authorization_list フィールドには、複数の異なる承認アカウント(EOA) によって署名された承認項目を含めることができ、つまり取引の発起者は承認者と異なることができ、承認者に対する承認操作のガス代を支払うことが可能です。
###実装
承認者が承認データに署名する際には、まず chain_id、address、nonce を RLP エンコードする必要があります。その後、エンコードされたデータと MAGIC 数を一緒に keccak256 ハッシュ演算を行い、署名待ちのデータを得ます。最後に、承認者の秘密鍵を使用してハッシュされたデータに署名し、y_parity、r、s データを取得します。ここで、MAGIC (0x05) はドメインセパレーターとして使用され、その目的は異なるタイプの署名結果が衝突しないようにすることです。
注意が必要なのは、承認者が承認した chain_id が 0 の場合、承認者がすべての EIP-7702 をサポートする EVM 互換チェーン上での承認の再利用を許可していることを意味します（前提として nonce もちょうど一致する必要があります）。
承認者が承認データに署名した後、取引の発起者はそれを authorization_list フィールドに集約して署名し、RPC を通じて取引をブロードキャストします。取引がブロックに含まれて実行される前に、Proposer はまず取引を事前チェックします。この中で to アドレスに対して強制チェックを行い、この取引が契約作成取引でないことを確認します。つまり、EIP-7702 タイプの取引を送信する際、取引の to アドレスは空であってはなりません。
同時に、このような取引では、取引中の authorization_list フィールドに少なくとも1つの承認エントリが含まれている必要があります。もし複数の承認エントリが同じ承認者によって署名された場合、最終的に有効なのは最後の承認エントリのみです。
その後、取引実行プロセスにおいて、ノードは最初に取引の発起者の nonce 値を増加させ、次に authorization_list の各認可項目に対して applyAuthorization 操作を行います。applyAuthorization 操作では、ノードはまず認可者の nonce をチェックし、その後に認可者の nonce を増加させます。これは、取引の発起者と認可者が同一のユーザー(EOA)である場合、認可取引に署名する際に nonce の値をさらに 1 増加させる必要があることを意味します。
ノードが特定の権限エントリを適用する際、何らかのエラーが発生した場合、その権限エントリはスキップされ、取引は失敗しません。その他の権限エントリは引き続き適用され、バッチ権限シナリオにおいてDoSリスクが発生しないように確保されます。
アプリケーションの承認が完了すると、承認者のアドレスの code フィールドは 0xef0100 || address に設定されます。ここで 0xef0100 は固定の識別子で、address は委託先のアドレスです。EIP-3541 の制限により、ユーザーは一般的な方法で 0xef バイトで始まるコントラクトコードをデプロイできないため、このような識別子は SET_CODE_TX_TYPE (0x04) タイプのトランザクションによってのみデプロイ可能であることが保証されます。
権限付与が完了した後、権限付与者が権限を取り消したい場合は、委託先のターゲットアドレスを 0 アドレスに設定するだけで済みます。
EIP-7702によって導入された新しいトランザクションタイプにより、承認者(EOA)は、スマートコントラクトのようにコードを実行できるだけでなく、トランザクションを開始する能力も保持しています。EIP-4337と比較して、これはユーザーにネイティブアカウント抽象(Native AA)により近い体験を提供し、ユーザーの利用ハードルを大幅に下げました。
ベストプラクティス
EIP-7702がイーサリアムエコシステムに新しい活力を注入したにもかかわらず、新しいアプリケーションシナリオは新たなリスクをもたらすこともあります。以下は、エコシステムの参加者が実践過程で警戒すべき点です:
秘密鍵の保管
たとえEOAが委任後にスマートコントラクト内蔵のソーシャルリカバリーなどの手段を利用して、プライベートキーの喪失による資金損失問題を解決できるとしても、EOAプライベートキーの漏洩リスクを回避することはできません。明確にする必要があるのは、委任を実行した後も、EOAプライベートキーは依然としてアカウントに対して最高の制御権を持っており、プライベートキーを保持することによりアカウント内の資産を自由に処分することができるということです。ユーザーやウォレットサービスプロバイダーがEOAの委任を完了した後、ローカルに保存されているプライベートキーを完全に削除しても、プライベートキーの漏洩リスクを完全に排除することはできず、特にサプライチェーン攻撃のリスクが存在するシナリオではなおさらです。
ユーザーにとって、委任後のアカウントを使用する際、ユーザーは常にプライベートキーの保護を最優先にし、常に注意する必要があります: Not your keys, not your coins。
マルチチェーンリプレイ
ユーザーは委任の権限を署名する際に、chainIdを通じて委任が有効になるチェーンを選択できます。もちろん、ユーザーはchainIdを0に設定して委任を行うこともでき、これにより委任は複数のチェーンで再生され、有効になります。これにより、ユーザーは一度の署名で複数のチェーン上で委任を行うことができます。ただし、複数のチェーン上の同じコントラクトアドレスには、異なる実装コードが存在する可能性があることに注意が必要です。
ウォレットサービスプロバイダーは、ユーザーが委託を行う際、委託の有効チェーンが現在接続しているネットワークと一致しているかを確認し、chainIdが0の委託に伴うリスクについてユーザーに警告する必要があります。
ユーザーは、異なるチェーン上の同じコントラクトアドレスでは、そのコントラクトコードが常に同じとは限らないことに注意する必要があります。委託の目的を事前に理解しておくべきです。
初期化できません
現在主流のスマートコントラクトウォレットの多くは、プロキシモデルを採用しています。ウォレットプロキシはデプロイ時に、DELEGateCALLを通じてコントラクトの初期化関数を呼び出し、ウォレットの初期化とプロキシウォレットのデプロイを原子的な操作で達成し、先に初期化される問題を回避します。しかし、ユーザーがEIP-7702を使用して委託する際には、そのアドレスのcodeフィールドのみが更新され、委託アドレスを呼び出して初期化することはできません。これにより、EIP-7702は一般的なERC-1967プロキシコントラクトのように、コントラクトデプロイのトランザクションで初期化関数を呼び出してウォレットを初期化することができなくなります。
開発者にとって、EIP-7702を既存のEIP-4337ウォレットと組み合わせて適合させる際には、ウォレットの初期化操作で権限チェックを行うことに注意すべきです（例えば、ecrecoverを通じて署名アドレスを復元して権限チェックを行うこと）これは、ウォレットの初期化操作が先に行われてしまうリスクを避けるためです。
ストレージ管理
ユーザーが EIP-7702 の委任機能を使用する際、機能要件の変更やウォレットのアップグレードなどの理由から、異なるコントラクトアドレスに再委任する必要がある場合があります。しかし、異なるコントラクトのストレージ構造には違いがある可能性があり（例えば、異なるコントラクトの slot0 スロットが異なる種類のデータを表す場合）、再委任の際に新しいコントラクトが古いコントラクトのデータを意図せず再利用する可能性があり、その結果、アカウントのロックや資金の損失などの悪影響を引き起こす可能性があります。
ユーザーにとって、再委任の状況を慎重に扱うべきです。
開発者にとって、開発の過程では ERC-7201 が提案する Namespace Formula に従い、変数を指定された独立したストレージ位置に割り当てることで、ストレージの競合リスクを軽減する必要があります。また、ERC-7779 (draft) は EIP-7702 のために再委任の標準プロセスを提供しています。これは、ERC-7201 を使用してストレージの競合を防ぎ、再委任の前にストレージの互換性を検証し、古い委任のインターフェースを呼び出してストレージの古いデータをクリーンアップすることを含みます。
偽チャージ
ユーザーが委託を行った後、EOAはスマートコントラクトとしても使用できるため、中央集権型取引所(CEX)はスマートコントラクトの充電の一般化の状況に直面する可能性があります。
CEX は trace を通じて各入金取引の状態を確認し、スマートコントラクトの偽入金リスクを防ぐべきです。
アカウント変換
EIP-7702 の委任を実施した後、ユーザーのアカウントタイプは EOA と SC の間で自由に変換できるようになり、アカウントは取引を開始することも、呼び出されることもできます。これは、アカウントが自分自身を呼び出し、外部呼び出しを行うとき、その msg.sender も tx.origin になることを意味し、EOA のみがプロジェクトに参加するという安全な仮定を破ることになります。
コントラクト開発者にとって、tx.originが常にEOAであると仮定することはもはや機能しません。同様に、msg.sender == tx.originによるチェックで再入攻撃を防ぐことも無効になります。
開発者は開発過程において将来の参加者がすべてスマートコントラクトであると仮定すべきである。
コントラクトの互換性
現行のERC-721、ERC-777トークンは、コントラクトに対する転送時にフック機能を持っており、これは受取人がトークンを正常に受け取るために対応するコールバック関数を実装する必要があることを意味します。
開発者にとって、ユーザーが委託したターゲットコントラクトは、主流のトークンと互換性を持つことを保証するために、対応するコールバック関数を実装すべきです。
フィッシングチェック
EIP-7702の委任を実施した後、ユーザーアカウントの資産はすべてスマートコントラクトによって制御される可能性があります。ユーザーがアカウントを悪意のあるコントラクトに委任した場合、攻撃者が資金を盗むのは容易になります。
ウォレットサービスプロバイダーにとって、できるだけ早くEIP-7702タイプの取引をサポートすることが特に重要であり、ユーザーが委任署名を行う際には、ユーザーに対して委任の対象契約を強調して表示し、ユーザーがフィッシング攻撃のリスクにさらされる可能性を軽減すべきである。
さらに、アカウント委託の対象契約に対してより深い自動分析（オープンソースチェック、権限チェックなど）を行うことで、ユーザーがこのようなリスクを回避するのに役立ちます。
まとめ
EIP-7702は新しい取引タイプを導入することで、EOAにプログラム可能性とコンポーザビリティを持たせ、EOAとコントラクトアカウントの境界をあいまいにしました。現在、実戦で検証されたEIP-7702タイプのスマートコントラクト標準が存在しないため、実際のアプリケーションにおいて、ユーザー、ウォレットサービスプロバイダー、開発者、CEXなどのさまざまなエコシステム参加者は、多くの課題と機会に直面しています。本記事で述べるベストプラクティスの内容は、すべての潜在的リスクをカバーすることはできませんが、依然として各方が実際の操作において参考にして活用する価値があります。
! EOAアカウントコードの設定解除