イーサリアム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フィールドは、権限を持つアカウントが権限を付与するための署名データを署名したものです

トランザクション内の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を通じて取引をブロードキャストします。取引がブロックに含まれて実行される前に、提案者は取引を事前チェックし、その中で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タイプの取引をできるだけ早くサポートすることが特に重要であり、ユーザーが委任署名を行う際には、委任の対象コントラクトをユーザーに強調して表示し、ユーザーがフィッシング攻撃に遭うリスクを軽減する必要があります。

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

サマリー

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