イーサリアム Pectra アップグレード：EIP-7702 実用ガイド

Cobo Global

2025-02-26 18:28:50

コレクション

本文では、EIP-7702の実装を深く分析し、それがもたらす可能性のある機会とリスクを示し、さまざまなユーザーや業界関係者に参考を提供します。

共有する

WeChatでQRコードをスキャン

著者：Cobo Global

イーサリアムのメインネットに迫る Pectra アップグレードは大規模な更新であり、複数のイーサリアム改善提案（Ethereum Improvement Proposals, EIPs）を一度に導入します。その中で EIP-7702 はイーサリアムの外部アカウント（Externally Owned Account, EOA）に対する大規模な改造を実現し、この提案は EOA と契約アカウント（Contract Account, CA）の境界を曖昧にし、新たな能力を提供することで、一般ユーザー、さまざまなインフラ提供者、開発者に重大な影響を与えます。

最近、Pectra はテストネットでの完了を迎え、まもなくメインネットに導入される見込みです。本記事では EIP-7702 の実装を深く分析し、そのもたらす可能性のある機会とリスクを示し、さまざまなユーザーや業界関係者に参考を提供します。

EIP-7702 概要

EIP-7702 の実際のタイトルは EIP-7702: Set EOA account code 副題 Add a new tx type that permanently sets the code for an EOA です。これはこの提案の核心要素を概括しています：EOA に契約コードを設定できる取引タイプを提供します。

具体的には、この提案は SETCODETX_TYPE (0x04) の取引タイプを導入し、そのデータ構造は以下の通りです：

rlp([chainid, nonce, maxpriorityfeepergas, maxfeepergas, gaslimit, destination, value, data, accesslist, authorizationlist, signatureyparity, signaturer, signature_s])

authorizationlist = [[chainid, address, nonce, y_parity, r, s], …]

一般的な 0x02 取引タイプと比較して、主な変更点は authorizationlist フィールドが追加されたことです。authorizationlist の各要素は、アドレス代理の承認を示します。その中で：

chain_id は承認が有効なチェーン ID で、リプレイ防止に使用されます。
nonce は承認者アドレスの nonce で、通常の取引の nonce と一致し、リプレイ防止にも使用されます。
address はアドレス代理時に指定された代理先です。
y_parity, r, s は署名データで、ecrecover を通じて authority アドレス、すなわち承認を発起した EOA アドレスを取得できます。

各取引には、上記の承認を複数含めることができます。また、上記の承認は独立した署名を持ち、取引本体の署名とは異なるため、アドレス承認行為のガス代支払いを実現できます。ウォレットサービスプロバイダーやアプリ開発者は、authority のガス代を支払うことで EOA の承認を実現でき、authority 自身のアドレスにガスを保持する必要はありません。

取引がブロックチェーンに追加されると、authority アドレスの code フィールドは代理アドレスの委任識別子（Delegation Designation, DD）に設定されます。DD の形式は以下の通りです：

0xef0100 || address

ここで 0xef0100 は固定プレフィックスで、address は代理の対象アドレスです。ここでの詳細として、EIP-3541 に基づき、ユーザーは通常の契約デプロイ手段（to が空の取引、create/create2 命令）を通じて 0xef で始まる契約コードをデプロイすることはできません。したがって、上記の委任は EOA のみが発起でき、0x04 取引を通じて完了します。

委任が完了すると、authority に対するすべての契約呼び出しは、address 上の code を code として使用し、同時に authority 自身のストレージを使用します。使用体験は ERC-1167 プロキシ契約に非常に似ています。

まとめ：EIP-7702 は EOA が元々の取引発起能力を保持しつつ、同時にプロキシ契約の効果を持つことを可能にします。ユーザーは SETCODETX_TYPE (0x04) 取引を通じてプロキシの実装契約を設定、変更、削除できます。

EIP-7702 に関するその他の技術的詳細は提案の原文を参照してください。

EIP-7702 がもたらす影響と機会

EIP-7702 は重要な変化であり、ブロックチェーン業界のさまざまな参加者に重大な影響を与え、多くの新しい機会を提供します。

契約ウォレットサービスプロバイダー

提案自体のタイトルと実装メカニズムからわかるように、EIP-7702 はアカウント抽象（Account Abstraction, AA）に関する上位の能力（ガス抽象、nonce 抽象、署名抽象など）を特に提供するものではなく、EOA をプロキシ契約に変換するための基本的な能力を提供します。したがって、この提案は現行のさまざまな契約ウォレットインフラ（Safe、ERC-4337 など）と衝突することはありません。むしろ、EIP-7702 は既存の契約ウォレットとほぼシームレスに統合できます。ユーザーの EOA を Safe ウォレットや ERC-4337 ウォレットに変換し、契約が提供するマルチシグ、ガス代支払い、一括取引、パスキー署名などの機能を統合します。契約ウォレットプロバイダーが EIP-7702 を迅速かつスムーズに統合できれば、ユーザー層を効果的に拡大し、ユーザー体験を向上させることができます。

DApp 開発者

EIP-7702 が AA ウォレットのユーザー体験を向上させるため、DApp 開発者はより広範囲に AA ウォレットを接続し、ユーザーと DApp のインタラクションをより便利で安全な体験を提供することを検討できます。たとえば、契約ウォレットの一括取引機能を利用して、複数の DeFi 操作を一度に完了させることができます。

別の方向性として、DApp はプロジェクトの特性に応じてユーザー向けにカスタムの Delegation 契約を開発し、ユーザーに専用の複雑な契約インタラクション機能を提供することも考えられます。

資産管理者

取引所や資金管理者は、通常、大量のアドレスを管理し、ユーザーの入金アドレスとして使用し、定期的に資金を集約する必要があります。従来の資金集約モデルでは EOA アドレスを入金アドレスとして使用し、集約時には入金アドレスに一定額のガスを充填し、入金アドレスから出金アドレスに転送取引を行う必要があります。この資金プロセスは大量の取引送信を伴い、プロセスが長く、高額なガス費用が必要です。過去には、機関が資金を集約することでチェーン上の取引手数料が上昇し、取引が混雑する事例もありました。

EIP-7702 の登場により、EOA アドレスをシームレスに契約ウォレットに変換できるようになり、EIP-7702 のガス代支払いメカニズムにより、ガス充填取引の存在が不要になります。また、契約ウォレットのプログラマビリティを利用して、複数の集約転送を単一の取引にパッケージ化し、取引数を減らし、ガス消費を節約できます。最終的に集約効率を向上させ、集約コストを削減します。

EIP-7702 がもたらす潜在的リスク

EIP-7702 は新しいアカウント機能をもたらす一方で、潜在的なセキュリティリスクも引き起こします。ウォレットサービスプロバイダー、契約開発者、ユーザーは警戒を怠らない必要があります。

ウォレットサービスプロバイダー

EIP-7702 は新しい取引タイプ SETCODETX_TYPE (0x04) を導入し、この取引タイプは一般ユーザーにも直接関連します。したがって、Metamask、Rabby などのソフトウェアウォレットサービスプロバイダーやさまざまなハードウェアウォレットサービスも、新しい取引タイプに適応するためにソフトウェアを更新する必要があります。

EIP-7702 の承認にはアカウント全体を乗っ取る可能性があるため、ウォレットサービスプロバイダーは UI 表示においてユーザーに十分な警告を提供し、警告レベルは Token Approve や Permit と同等、あるいはそれ以上であるべきです。

新しい取引タイプの接続やユーザーインタラクションにおいて、安全チェックが不十分である場合、ユーザーがフィッシング攻撃を受ける可能性があります。

一般ユーザー

一般ユーザーもイーサリアムの新しい取引タイプに注意を払い、さまざまなソフトウェアウォレットやハードウェアウォレットの更新に留意する必要があります。新しい特殊取引タイプを効果的に認識し、十分な注意を払うことが重要です。

この取引タイプは、Delegation の対象契約を重点的に検証する必要があり、技術的な準備が整っている場合は、契約ソースコードを監査することが望ましいです。安全リスクを引き起こさないようにするためです。一般ユーザーは、承認された契約がオープンソースであり、第三者による信頼できる監査報告書を提供しているかどうかに注意を払う必要があります。

新しい取引タイプは従来の取引タイプよりも監査が難しく、ウォレットに対する制御能力が強化されています。将来的には、この取引タイプを使用したフィッシング攻撃が発生することが予想されます。一般ユーザーは積極的に関連知識を蓄え、安全意識を高める必要があります。

契約開発者

契約開発者にとって、EIP-7702 は新しい視点を提供します。Delegation 契約に関しては、成熟した公開ライブラリコンポーネントや開発基準が存在しないため、アップグレードの初期段階では、開発者がそれぞれ独自の Delegation 契約を実装する必要があるかもしれません。開発者は十分な調査を行い、新機能によって引き起こされるセキュリティリスクを回避することを保証することをお勧めします。

Cobo セキュリティチームの分析によると、EIP-7702 における契約のセキュリティに関して注意すべき点は以下の通りです：

1. Delegation 契約の初期化のリプレイ問題

EIP-7702 はコードを設定する能力を提供するだけで、契約の初期化能力は提供しません。開発者がよく知っているプロキシメカニズムと比較すると、EIP-7702 は実装の更新能力を提供しますが、initialize 関数を呼び出す能力は提供しません。

既存のさまざまな主流契約ウォレットの例として、ERC-4337 の公式実装におけるウォレットは、initialize メソッドを提供し、initialize メソッドには権限チェックがありません。このメソッドを最初に呼び出したユーザーがウォレットの所有権を取得できます。

contract SimpleAccount {
function initialize(address anOwner) public virtual initializer {
_initialize(anOwner);
}
}

Safe などの他の主流契約ウォレットも基本的に同様の問題を抱えています。過去の契約ウォレットの実装では、契約のデプロイと初期化を一つの取引にパッケージ化し、原子操作を実現することで、リプレイ問題の発生を回避してきました。

しかし、EIP-7702 のシナリオでは、承認署名が authorization_list に独立して存在し、リプレイボットはメモリプール内で承認取引を監視し、承認取引を先に送信し、同時に初期化関数を呼び出して契約ウォレットの権限を奪うことができます。もし EOA ウォレット内に一定の暗号資産が存在する場合、リプレイの過程で直接資産移転が行われ、ユーザーに資金損失をもたらす可能性があります。アップグレードが完了した初期の段階では、チェーン上で EIP-7702 に基づく初期化のリプレイ攻撃が発生することが予想されます。

調査の結果、従来のプロキシモデル下のコード実装は EIP-7702 のシナリオでは安全に初期化できないことがわかりました。開発者は既存のコードを EIP-7702 に適応させた後、ユーザーに使用を開放すべきです。ユーザーもさまざまな旧バージョンの契約に対して承認を行わないよう注意し、資金の安全を確保する必要があります。

開発者にとって、EIP-7702 に適応するためには、初期化メソッドに対する権限チェックを行うことが主な課題です。典型的な検証コードは以下のようになります：

require(msg.sender == address(this), "Only self")

または

require(ECDSA.recover(hash, signature) == address(this), "Only signed")

これにより、EOA 自身または合法的な署名を持つ者のみが初期化メソッドを呼び出せることを保証します。ガス代支払いのシナリオを考慮すると、後者の方が一般的に使用されるかもしれません。

2. Delegation 契約のストレージ構造の衝突問題

EIP-7702 のシナリオでは、EOA が頻繁に Delegation 更新を行うことになり、これはプロキシのアップグレードに相当します。各 Delegation 契約は異なるウォレットプロバイダーや DApp 開発者によって提供される可能性があり、実装が異なる場合があります。単一の開発者のシナリオでの契約アップグレードとは異なり、各バージョンの互換性を保証するのが難しいです。

異なる Delegation 契約の変数ストレージ構造は完全に異なる可能性が高く、契約間で同じストレージスロットを再利用すると、誤ったデータを読み取ったり、予期しないデータを書き込んだりして、契約機能に異常を引き起こす可能性があります。また、一度データが誤ってしまうと、修正には高い技術能力が必要であり、一般ユーザーには難しいです。

ここでは、開発者に ERC-7201 のストレージ管理モードを使用し、名前空間方式で独立したストレージ空間を使用することをお勧めします。デフォルトの 0x0 から始まるスロットを使用することは避けてください。

3. Delegation 権限管理問題

EIP-7702 はプロキシ契約に非常に似ていますが、EIP-7702 のシナリオではイーサリアムプロトコルレベルでの実装契約の管理が行われます。これは、プロキシが固定不可変のオーナーを持つことに相当します。したがって、EOA アカウントはいつでも契約を更新し、ストレージ空間内の任意のデータを変更し、任意の操作を行うことができます。

開発者はこの違いに注意し、DApp 開発時には EOA ストレージ空間のデータを信頼しないようにすべきです。特に Solana や SUI ユーザーモデルに慣れた開発者はこの問題に注意が必要です。一般ユーザーもこの問題に留意する必要があります。

たとえば、EOA をマルチシグウォレットに代理した場合、最上位の権限は依然として EOA の秘密鍵自身です。

4. 新型 EOA が従来のセキュリティ仮定を破る問題

旧バージョンの契約では、発起者が EOA であるというセキュリティ仮定が破られる可能性があります。典型的には、既存の規範では以下のようなコードを使用して呼び出し元が EOA であるかどうかを確認します。

require(msg.sender == tx.origin, "Only EOA")

さらに、EOA が契約呼び出し能力を持たないという仮定に基づいて、バッチ呼び出しの制限や再入チェックロジックが行われない場合があります。

EIP-7702 のシナリオでは、EOA と CA の境界が曖昧になり、EOA もコードを実行する能力を持ちます。上記のチェックを通過した場合でも、その EOA に ETH を転送すると、EOA プロキシ契約のフォールバックがトリガーされ、再入問題を引き起こす可能性があります。また、各取引が一度だけ呼び出せるように制限されているメソッド（たとえば、特定のトークンのマイニング配布メソッドや NFT ミントメソッドなど）も、新しいシナリオでは EOA プロキシコードを通じてバッチ呼び出しを実現し、開発者の意図しないアービトラージ攻撃を引き起こすことができます。