# イーサリアム Pectra アップグレード：EIP-7702 デプス解析とベストプラクティスガイド## イントロダクションイーサリアムは今後Pectraアップグレードを迎えます。これは重要な更新です。その中で、EIP-7702はイーサリアム外部アカウント(EOA)に対して革命的な改造を行いました。この提案はEOAと契約アカウントCAの境界を曖昧にし、ネイティブアカウント抽象化に向けた重要な一歩であり、イーサリアムエコシステムに新しいインタラクションモデルをもたらしました。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 はリスト型で、複数の承認エントリを含むことができます。各承認エントリには：- chain_id は委任された権限が有効になるチェーンを示します- アドレスは委託の対象アドレスを示します- nonce は現在の承認アカウントの nonce と一致する必要があります- y_parity、r、s は、承認されたアカウントが承認の署名データに署名するためのデータです1つのトランザクションの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 は事前チェックを行い、この取引が契約作成取引でないことを確認します。すなわち、EIP-7702 タイプの取引を送信する際には、取引の to アドレスは空であってはなりません。このような取引では、authorization_list フィールドに少なくとも1つの認可項目が含まれている必要があります。同一の認可者によって署名された複数の認可項目がある場合、最終的に有効となるのは最後の認可項目です。トランザクションが実行されると、ノードは最初にトランザクション発起者の nonce 値を増加させ、その後 authorization_list の各承認項目に対して applyAuthorization 操作を行います。applyAuthorization 操作では、ノードは最初に承認者の nonce を確認し、その後承認者の nonce を増加させます。これは、トランザクション発起者と承認者が同一のユーザー(EOA)である場合、承認トランザクションを署名する際に nonce の値は1つ増加させる必要があることを意味します。ノードアプリケーションの承認項目がある場合、エラーが発生した場合、その項目はスキップされ、取引は失敗せず、他の承認項目は引き続き適用され、バッチ承認シナリオにおけるDoSリスクを回避します。アプリケーションの承認が完了すると、承認者アドレスの code フィールドは 0xef0100 || address に設定されます。ここで 0xef0100 は固定の識別子で、address は委託先のアドレスです。EIP-3541 の制限により、このような識別子は 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タイプの取引をできるだけ早くサポートし、ユーザーが委任署名を行う際に、委任する対象契約をユーザーに強調して表示し、ユーザーがフィッシング攻撃を受けるリスクを軽減する必要があります。さらに、アカウントの委任先契約に対してより深い自動分析（オープンソース検査、権限検査など）を行うことで、ユーザーがこのようなリスクを回避するのに役立ちます。## サマリーこの記事では、イーサリアムの間もなく行われるPectraアップグレードにおけるEIP-7702提案について考察します。EIP-7702は新しい取引タイプを導入することで、EOAにプログラマビリティとコンポーザビリティを持たせ、EOAとコントラクトアカウントの境界を曖昧にします。現在、実戦で試されたEIP-7702タイプのスマートコントラクト標準が存在しないため、実際のアプリケーションでは、ユーザー、ウォレットサービスプロバイダー、開発者、CEXなど、さまざまなエコシステム参加者が多くの課題と機会に直面しています。この記事で述べるベストプラクティスの内容はすべての潜在的リスクをカバーするものではありませんが、依然として実際の操作において各方面が参考にして応用する価値があります。
イーサリアムPectraアップグレードEIP-7702デプス解析とベストプラクティス
イーサリアム Pectra アップグレード：EIP-7702 デプス解析とベストプラクティスガイド
イントロダクション
イーサリアムは今後Pectraアップグレードを迎えます。これは重要な更新です。その中で、EIP-7702はイーサリアム外部アカウント(EOA)に対して革命的な改造を行いました。この提案はEOAと契約アカウントCAの境界を曖昧にし、ネイティブアカウント抽象化に向けた重要な一歩であり、イーサリアムエコシステムに新しいインタラクションモデルをもたらしました。
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 はリスト型で、複数の承認エントリを含むことができます。各承認エントリには：
1つのトランザクションの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 は事前チェックを行い、この取引が契約作成取引でないことを確認します。すなわち、EIP-7702 タイプの取引を送信する際には、取引の to アドレスは空であってはなりません。
このような取引では、authorization_list フィールドに少なくとも1つの認可項目が含まれている必要があります。同一の認可者によって署名された複数の認可項目がある場合、最終的に有効となるのは最後の認可項目です。
トランザクションが実行されると、ノードは最初にトランザクション発起者の nonce 値を増加させ、その後 authorization_list の各承認項目に対して applyAuthorization 操作を行います。applyAuthorization 操作では、ノードは最初に承認者の nonce を確認し、その後承認者の nonce を増加させます。これは、トランザクション発起者と承認者が同一のユーザー(EOA)である場合、承認トランザクションを署名する際に nonce の値は1つ増加させる必要があることを意味します。
ノードアプリケーションの承認項目がある場合、エラーが発生した場合、その項目はスキップされ、取引は失敗せず、他の承認項目は引き続き適用され、バッチ承認シナリオにおけるDoSリスクを回避します。
アプリケーションの承認が完了すると、承認者アドレスの code フィールドは 0xef0100 || address に設定されます。ここで 0xef0100 は固定の識別子で、address は委託先のアドレスです。EIP-3541 の制限により、このような識別子は 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タイプの取引をできるだけ早くサポートし、ユーザーが委任署名を行う際に、委任する対象契約をユーザーに強調して表示し、ユーザーがフィッシング攻撃を受けるリスクを軽減する必要があります。
さらに、アカウントの委任先契約に対してより深い自動分析（オープンソース検査、権限検査など）を行うことで、ユーザーがこのようなリスクを回避するのに役立ちます。
サマリー
この記事では、イーサリアムの間もなく行われるPectraアップグレードにおけるEIP-7702提案について考察します。EIP-7702は新しい取引タイプを導入することで、EOAにプログラマビリティとコンポーザビリティを持たせ、EOAとコントラクトアカウントの境界を曖昧にします。現在、実戦で試されたEIP-7702タイプのスマートコントラクト標準が存在しないため、実際のアプリケーションでは、ユーザー、ウォレットサービスプロバイダー、開発者、CEXなど、さまざまなエコシステム参加者が多くの課題と機会に直面しています。この記事で述べるベストプラクティスの内容はすべての潜在的リスクをカバーするものではありませんが、依然として実際の操作において各方面が参考にして応用する価値があります。