EIP-7702の委任とは？EOAスマートアカウントを解説

EIP-7702のデリゲーションでは、外部所有アカウント（EOA）が、アドレスを変更したり秘密鍵を手放したりすることなく、実行ロジックを別のコントラクトに委任できます。コードフィールドには0xef0100とデリゲートアドレスが設定され、その後の呼び出しでは、残高、ノンス、ストレージが引き続きそのアカウントに属したまま、EOA自身のコンテキスト内でそのコードが実行されます。

本稿は、セルフカストディウォレットとEVMのアカウントモデルをすでに理解している読者を対象としています。Ethereumには長年にわたり、秘密鍵で管理されるEOAと、コードを含むコントラクトアカウントという2種類のアカウントが存在してきました。カスタム検証ロジックを持てるのは後者だけであり、そのためには新しいアドレスが必要でした。EIP-7702はPectraアップグレードで導入され、新しいアカウントを開設する代わりに、すでに使用中のアドレスへコードを書き込むことでカスタム検証を可能にしました。

認可タプルは6つのフィールドで構成され、デリゲーション指定子は3バイトのプレフィックスと20バイトのアドレスからなる23バイトです。書き込み経路、新機能の制限、ERC-4337との役割分担、デリゲートを信頼できるかどうかによって、その署名後にアカウントが維持できる制御の範囲が決まります。

要点

• EIP-7702のデリゲーションでは、アドレス、秘密鍵、残高、ノンスをそのまま維持し、コードフィールドのみをデリゲートコントラクトに向けます。

• タイプ0x04トランザクションは認可タプルを通じてデリゲーションを書き込みます。署名対象メッセージには手数料フィールドが含まれず、送信者は所有者である必要がありません。

• デリゲーションに有効期限はありません。取り消しによってコードは消去されますが、ストレージ、トークン承認、Permit署名は消去されません。

• デリゲートにreceive()またはfallback()がない場合、通常のETH送金はリバートします。また、tx.originはアカウントにコードがないことを意味しなくなります。

• ERC-4337は独立したアカウントシステムを構築する一方、EIP-7702は既存のEOAにコードを追加するため、両者は併用できます。

EIP-7702のデリゲーションは外部所有アカウントをどのように変えるのか？

Ethereumには、秘密鍵で管理される外部所有アカウントと、コードを含むコントラクトアカウントの2種類のアカウントがあります。

EIP-7702で変わるのはアカウントの識別情報ではなくコードフィールドです。EOAはアドレスを変更せずに、一時的にコントラクトコードを参照できるためです。アドレス、秘密鍵、残高、ノンスは従来どおり維持されます。違いは、アドレスが別のデプロイ済みコントラクトから取得した実行可能コードを持つようになる点です。

このフィールドには、0xef0100のプレフィックスと20バイトのアドレスからなる23バイトのデリゲーション指定子が保持されます。呼び出しがそのEOAを対象とすると、EVMは指定子を読み取り、デリゲートのコードを読み込みます。そのため、秘密鍵による制御を維持しつつ、送信者、残高、ストレージがすべてEOAとして読み取られるスマートアカウントのように振る舞えます。

デリゲートは自身の状態を参照できません。実行ロジックは対象コントラクトから読み込まれますが、ストレージと送信者コンテキストはEOAのまま維持され、EOAがこれまで使用していなかったストレージにも同じロジックに従って書き込みが行われます。

署名は引き続き元の秘密鍵から生成されるため、アカウントがマルチシグになるわけではありません。この設計は、アカウント種別の変更ではなく、ネイティブ型を含むアカウント抽象化に向けた一歩です。

タイプ0x04と認可タプル：デリゲーションがコントラクトコードに到達する仕組み

書き込みには、新しいトランザクションタイプである0x04が必要です。その本文には認可リストが含まれます。各タプルはアカウント保有者によって署名されますが、トランザクション自体は任意のアドレスが送信・支払いできます。認可は、アカウントがどのコードの実行を許可するかを指定します。

タプルは [chain_id, address, nonce, y_parity, r, s] であり、署名対象メッセージはkeccak(0x05 || rlp([chain_id, address, nonce]))です。EIP-7702仕様では、認可署名を通常のトランザクション署名と区別するために0x05プレフィックスを使用しており、このメッセージにはガスまたは手数料フィールドが含まれません。

署名するのはコードが参照すべきアドレスであり、特定のトランザクションではありません。そのため、一部のシステムでは認可とインテントを組み合わせます。アカウントはオフラインで一度署名し、スポンサーがガス代を負担することもできます。

ノード検証は6つのステップで実行されます。ノンスとの紐付けにより、認可は一致するノンスで一度だけ使用できます。

認可リストは、アクセスリストがトランザクション形式を拡張するのと同様に、トランザクション本文に含まれます。チェーンIDは0またはローカルチェーンと一致する必要があります（0はすべてのチェーンで有効であることを意味します）。ノンスは2^64-1未満である必要があります。ecrecoverが署名を検証し、アカウントコードは空であるか、すでにデリゲート済みでなければなりません。ノンスは現在の値と一致する必要があり、コードはノンスがインクリメントされたうえで0xef0100 || addressとして書き込まれます。

取り消しは、アドレスをゼロに設定して同じ経路で行います。これにより、基盤となるEOAの状態を恒久的に変更せず、コードハッシュを消去します。

どのアカウントプロパティが変わらないのか？

4つのプロパティは従来どおり維持され、移動するのはコードとストレージのみです。コードは0xから指定子に変わり、未使用のストレージスロットに書き込みが開始され、それらの値は取り消し後も存続します。仕様では、残高、ノンス、呼び出し元識別に関する3つのオンチェーン不変条件が成立しなくなることも個別に示されています。これらはリスクセクションで扱います。

1. アドレス：変更されないため、履歴、トークン承認、ネームレコードは引き続き同じアドレスを指します。

2. 秘密鍵：変更されず、通常のトランザクションだけでなく、デリゲーションを上書きまたは取り消す新たな認可にも署名します。

3. 残高：デリゲーションでは資産を移動しないため変更されず、アカウントは引き続き資産を直接保有します。

4. ノンス：認可によって1つ消費されるため増加を続け、同一署名のリプレイを防ぎます。

デリゲート済みアカウントは通常どおりETHを受け取れるのか？

デフォルトでは受け取れません。アカウントがコードを持つようになると、通常のETH送金はコード実行経路に入ります。デリゲートがreceive()もfallback()も実装していない場合、送金はリバートし、資金は送信者に返されます。

この問題は、取引所からの出金、給与支払い、エアドロップなど、一般的な支払いフローで発生する可能性があります。ウォレットソフトウェアは通常、デリゲートが原因であることではなく、失敗のみを表示します。署名前に対象がreceive関数を実装していることを確認するか、calldataを含む呼び出しを通じて入金を受けるようにしてください。また、ウォレットソフトウェアはその原因をユーザーにより明確に示すべきです。

図1．EIP-7702の書き込み経路：EOAが認可タプルに署名し、タイプ0x04トランザクションがコードを0xef0100とデリゲートアドレスに設定し、その後の呼び出しではEOAのコンテキストでそのコードが実行されます。

デリゲート済みアカウントでできること：バッチ処理、ガススポンサーシップ、リカバリー

デリゲーションにより、EOAはトランザクションへの署名しかできないアカウントから、日常的なユーザー向けにはスマートアカウントのように振る舞うアカウントへと変わります。主な利点は、バッチ処理、ガススポンサーシップ、ルールベースのリカバリーにあります。

最も具体的な利点はバッチ処理です。承認とスワップを1つのトランザクションで実行できます。スポンサーは、適切なタイミングで複数のステップをバックグラウンドで完了させることで、オンボーディングやバッチ処理を円滑にすることもできます。これにより、1回の署名で一度に決済され、途中で承認が未使用のまま残りません。

ガススポンサーシップは、署名と送信者を分離することで実現します。第三者が支払いを行うため、アカウントは事前にETHを保有する必要がありません。ERC-4337のpaymasterを使用すれば、アプリケーションがコストを負担できます。つまり、一部のアプリはガス代を負担したり、バックグラウンドで処理することでオンボーディングを円滑にしたりできます。ただし、開発者は、ユーザーが単に別の機能を求めている場面でデリゲーションを促すことは避けるべきです。

リカバリーとセッションキーは、たとえばパスキー、ガーディアンセット、または単一鍵の代わりとなる支出制限などを用いて、デリゲート自身が署名を検証することに依存します。デリゲートは、送金や署名者の利用に関するポリシー的な機能も適用できます。

制約は明確です。秘密鍵を保有する者は、デリゲーションを上書きする新しい認可に常に署名できます。そのため、ここでのリカバリーはネイティブスマートアカウントより弱く、紛失した鍵に対するコストを下げるだけです。

デリゲーションに有効期限はありません。新しい認可によって上書きされるか、ゼロアドレスによって取り消されるまで有効です。そのため、この権限は長期にわたって存続し、積極的な管理が必要です。セキュリティ上は、委任されたコードがアクセスおよび制御できる範囲を確認してください。

EIP-7702のデリゲーションはERC-4337およびアカウント抽象化とどう異なるのか？

EIP-7702は既存のEOAにコードを追加する一方、ERC-4337は独立したアカウントシステムを構築します。アカウント抽象化を補完するアプローチとして、両者は相互に置き換わるのではなく併用できます。

ERC-4337は新たにデプロイされるコントラクトから始まるため、資産と承認を移動する必要があります。7702は元のアドレスから始まり、コードを追加するため、既存のアカウントは別のウォレットを先にデプロイすることなくスマートコントラクトの動作を利用でき、移行を回避できます。

両者を組み合わせると、7702アカウントはERC-4337のアカウント実装として機能し、開発者は7702でデリゲートされたアカウント上に4337互換フローを構築できます。ただし、これにより初期化の競合が再び発生します。デリゲーションの反映から初期化の完了までの間に、誰でもinitializerを呼び出して自分自身を所有者として設定できる可能性があります。

解決策は2つあります。署名を初期化引数に紐付けるinitWithSig、または初期化をEntryPointのみに制限する方法です。

デリゲートは信頼できるか？不変性を確認する方法

標準的なCREATE2 initcodeからデプロイされた不変コントラクトにのみデリゲートしてください。検証メカニズムではアップグレード経路のない対象を優先する必要があります。プロキシコントラクト、アップグレード可能なコントラクト、self-destruct経路を持つコントラクトはいずれも適切な対象ではありません。

デリゲーションはそのコードに実行権限を渡しますが、保有者には変更通知が届きません。アップグレード可能な対象では、アップグレード権限を持つ者が、それにデリゲートするすべてのアカウントに対する実行権限を持つことになります。不変の対象であれば、少なくとも攻撃対象領域を事前に固定でき、監査も可能です。認可後にデリゲートコードが変更可能である場合、セキュリティ上の露出は高まります。

不変コード、プロキシなし、再現可能なデプロイという3つの基準は、ウォレットと開発者がデリゲーションを付与する前にブロックエクスプローラーで検証すべき4つの確認事項になります。

1. 実装スロットと管理者スロットを読み取る：0x360894で始まるゼロ以外のEIP-1967スロットは、プロキシまたはアップグレード経路を示します。

2. オンチェーンのバイトコードと検証済みソースを比較し、コンストラクタ引数とデプロイ済みバイトコードが一致することを確認します。

3. selfdestructとdelegatecallを検索し、コードを消去したり実行を別の場所に転送したりする分岐がないことを確認します。

4. initcodeとsaltからCREATE2アドレスを再計算し、デプロイヤーが別のアドレスで他のコントラクトに置き換えられないことを確認します。

EIP-7702のデリゲーションにはどのようなリスクがあるのか？

リスクは3つの領域にあります。デリゲートのバグ、デリゲーションによって変化するアカウントセマンティクス、そして一度きりの署名の不可逆性です。これは機能のアップグレードであると同時にセキュリティ上のトレードオフであり、主な懸念は、認可が付与された後にアカウントを制御できるコードの範囲が広いことです。

tx.originの行は最も影響範囲が広いものです。デリゲート済みアカウントはコールスタック内でコードを実行できるため、msg.sender == tx.originは、呼び出し元にコードがないことを意味しなくなります。この比較に基づくガードは保護として機能しなくなります。nonReentrantまたは一時ストレージロックは、呼び出し元の識別情報に依存しません。

実際には、ウォレットが認可の詳細を明確に表示しない場合、ユーザーは確認する意図のなかったアクセスを承認する可能性があります。PectraドキュメントのEIP-7702ガイダンスでは、これを別項目として挙げています。

chain_idが0の場合、3つ目のカテゴリはさらに広がります。同じ署名が他のEVMチェーンでも有効となるため、保有者が考慮していなかったチェーンでアカウントにコードが付与される可能性があります。署名デバイスではチェーンIDが省略されることが多く、コールドウォレットでデリゲーションを有効にすることのトレードオフはここにあります。

デリゲーションを確認・取り消すには？

確認にはコードの読み取りが1回必要です。eth_getCodeが0xを返す場合はデリゲーションなし、0xef0100で始まる23バイトの場合はアカウントがデリゲート済みの外部所有アカウントであり、それ以外のバイトコードはコントラクトアカウントを意味します。

デリゲーションはチェーンレベルの状態であるため、同じアドレスでもあるチェーンではデリゲートされ、別のチェーンでは未変更である場合があります。各チェーンで個別に確認する必要があります。最後の20バイトがデリゲートであり、ウォレットまたはプラットフォームは、監査およびモニタリングのためにステータス確認や変更のログを保持しながら、これらの確認をチェーン横断で自動化できます。

簡易的な手動確認については、デリゲーションの確認と取り消しで手順を説明しています。

取り消しはウォレット内で行います。アドレスフィールドをゼロに設定した新しい認可に署名すると、ノードがコードハッシュを消去してアカウントを通常のEOAに戻します。外部dAppは一般に保有者に代わって実行できません。また、ウォレットチームが取り消しワークフローをサポートする場合でも、保有者に代わって操作するリクエストには、引き続き保有者自身の承認が必要です。

取り消しによってデリゲートコードは削除されますが、過去のスマートコントラクト承認や、アプリにすでに付与されたその他のアクセスは削除されません。OpenZeppelinのEOAデリゲーションに関する注記では、この境界が説明されています。

まとめ

EIP-7702は、1回の署名でEOAにプログラマビリティをもたらします。アドレスと鍵はそのまま維持され、コードフィールドはデリゲートを指し、実行はアカウント自身のコンテキスト内で行われます。

その代償は、変更されたセマンティクスと長期的な権限です。通常の受取送金が失敗する可能性があり、tx.originはもはやEOAを意味せず、chain_idが0の署名はチェーンをまたいで有効となり、取り消しで消去されるのはコードのみです。

よくある質問

EIP-7702は私のウォレットをマルチシグに変えるのか？

いいえ。デリゲーションが変更するのはコードフィールドのみであり、署名は引き続き元の秘密鍵から生成されます。そのため、単一の鍵保有者は独立して取引でき、新しい認可によってデリゲーションを上書きできます。複数署名を要求するデリゲートも、その鍵によって回避できます。

自分のウォレットがEIP-7702でデリゲートされているかを確認するには？

アドレスに対してeth_getCodeを呼び出してください。0xが返される場合はデリゲーションなしです。0xef0100で始まる23バイトが返される場合はデリゲート済みであり、最後の20バイトがデリゲートを示します。その他のバイトコードはコントラクトアカウントを意味します。

デリゲーションはチェーンごとに記録されるため、それぞれを確認してください。ウォレットまたは管理システムは、確認のためにこれらのチェックのログを保持する場合があります。要するに、ウォレットごとにインターフェースの詳細は異なる場合がありますが、基盤となるコード確認は同じです。

EIP-7702のデリゲーションを取り消すには？

ウォレット内でアドレスフィールドをゼロに設定した新しい認可に署名してください。検証が完了すると、ノードがコードハッシュを消去します。署名できるのはアカウント保有者のみであり、外部dAppが通常その代理で操作することはできません。

デリゲーションに有効期限はあるか？また、以前のトークン承認は取り消し後も残るか？

デリゲーションに有効期限はなく、上書きまたは取り消しが行われるまで有効です。取り消しで消去されるのはコードのみであり、ストレージ、ERC-20承認、Permit署名はそのまま残ります。

秘密鍵が漏洩していなくても、悪意あるEIP-7702認可によってアカウント資産が流出する可能性はあるか？

はい。署名は権限の移転です。攻撃者はその署名を用いて悪意あるコントラクトを指すデリゲーションを書き込み、秘密鍵に触れることなく、資産の移動を含むアカウントへの広範なアクセスを得る可能性があります。

タプル内のチェーンIDと対象アドレスを確認し、不変のコントラクトに対してのみ署名してください。ウォレットチームは、組織に代わって内部のデリゲーション関連承認を付与する前に、署名者の役割も確認すべきです。