イーサリアム Pectra アップグレード：EIP-7702 がもたらす変革と課題

イントロダクション

イーサリアムは、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 と同じ意味に従います。このフィールドはリスト型で、複数の承認エントリを含むことができ、各承認エントリには次のように記載されます。

• chain_id はこの委任が有効なチェーンを示します
• addressは委託の対象アドレスを示します
• 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 は最初に取引を事前チェックし、その際に 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もスマートコントラクトとして使用できるようになるため、一部の取引所はスマートコントラクトの入金が一般化する状況に直面する可能性があります。

取引所は、traceを通じて各充電取引の状態を確認し、スマートコントラクトの偽充電リスクを防ぐべきです。

アカウント変換

EIP-7702 の委託が実施された後、ユーザーのアカウントタイプは EOA と SC の間で自由に変換できるようになり、アカウントは取引を開始することも呼び出されることもできます。これは、アカウントが自分自身を呼び出し、外部呼び出しを行うとき、その msg.sender も tx.origin になることを意味し、EOA のみがプロジェクトに参加するという安全な仮定を破ることになります。

コントラクト開発者にとって、tx.originが常にEOAであると仮定することはもはや通用しません。同様に、msg.sender == tx.originによるチェックで再入攻撃を防ぐことも無効になります。

開発者は開発過程で、将来の参加者がすべてスマートコントラクトである可能性を考慮すべきである。

コントラクトの互換性

現在のERC-721、ERC-777トークンは、コントラクトに対して転送を行う際にHook機能を持っています。これは、受取人がトークンを正常に受け取るために、対応するコールバック関数を実装する必要があることを意味します。

開発者にとって、ユーザーが委託したターゲットコントラクトは、主流トークンと互換性を確保するために、適切なコールバック関数を実装する必要があります。

フィッシングチェック

EIP-7702の委任を実施した後、ユーザーアカウント内の資産はスマートコントラクトによって管理される可能性があり、ユーザーがアカウントを悪意のあるコントラクトに委任すると、攻撃者が資金を盗むことが非常に簡単になります。

ウォレットサービスプロバイダーにとって、できるだけ早くEIP-7702タイプの取引をサポートすることが特に重要であり、ユーザーが委任署名を行う際には、ユーザーに委任の対象契約を強調して表示し、ユーザーがフィッシング攻撃のリスクにさらされる可能性を軽減する必要があります。

さらに、アカウントの委託先契約に対するより深い自動分析（オープンソースのチェック、権限のチェックなど）を行うことで、ユーザーがこのようなリスクを回避するのに役立ちます。

まとめ

この記事では、イーサリアムの間近に迫ったPectraアップグレードにおけるEIP-7702提案について探討します。EIP-7702は新しい取引タイプを導入することにより、EOAにプログラム可能性とコンビナビリティを持たせ、EOAとコントラクトアカウントの境界を曖昧にします。現在、実戦で検証されたEIP-7702タイプのスマートコントラクト標準が存在しないため、実際のアプリケーションにおいて、ユーザー、ウォレットサービスプロバイダー、開発者、取引所などの異なるエコシステム参加者は多くの課題と機会に直面しています。この記事で述べられるベストプラクティスの内容はすべての潜在的リスクをカバーするものではありませんが、実際の操作において参考にする価値があります。