こんにちは。BOOSTRY ソフトウェアエンジニアの久禮です。
2025年5月7日にEthereumメインネットへPectraアップグレードが適用され、その中で導入されたEIP-7702について調査しました。
Account Abstractionへ向かう潮流のなかで導入された本EIPについて、仕様と制約、そしてERC-4337との組み合わせを解説します。
なお本調査はB.O.O.S.T. Lab の活動の一環として実施しました。内容は2026年1月時点の情報に基づいており、リンク先や仕様は将来変更される可能性があります。
ERC-4337の制約とEIP-7702の概要
ERC-4337とAccount Abstractionについては以下の記事で解説しています。
Account Abstractionとは、コントラクトをEOAと同様にトップレベルのアカウントとして扱えるようにする考え方です。ERC-4337は、プロトコルレイヤーを変更せずにAccount Abstractionを実現する提案でした。
この提案はスマートウォレットの実用化を大きく前進させた一方で、設計思想として「新しいアカウントを作る」ことを前提としており、既存EOAからの移行という観点では障壁がありました。
そこで、現状のEOAから移行を必要とせずにスマートウォレット化する提案として、EIP-7702が提案されました。 EIP-7702では、EOAに対して一時的にコントラクトを委譲（= delegate）することで、そのEOAにコードを設定できます。これにより、主に以下の3点が実現できます。
- バッチ処理：同一ユーザーの複数操作を、1つのアトミックトランザクションとして実行する
- スポンサーシップ：コードを委譲されたアカウントXをアカウントYが呼び出すことで、YがXを代行してガス代を支払う
- 権限の縮小：特定の操作のみ可能とするように権限を絞る
以降でEIP-7702の詳細な仕様について見ていきます。
EIP-7702の仕様詳細
BobがAliceのガス代を代行してトランザクションを発行するという状況で流れを説明します。 このとき、BobがAliceのEOAに対してコントラクトを委譲し、そのコントラクトを呼び出すということになります。
set code transactionの作成
まずはEOAにコントラクトを委譲する流れについてです。
はじめにBobはAliceに対してコード設定の承認を得るべく署名を依頼します。依頼を受けたAliceは承認（authorization）の証明として署名を行います。
AliceはMAGIC(0x05) と RLP(chainId, 設定するcontract address, Alice EOAのnonce) を連結した値をkeccak256でハッシュ化し、それを秘密鍵で署名して y_parity, r, s を得ます。
y_parity, r, s = sign(keccak(0x05 || rlp([chain_id, address, nonce])))
続いてAliceから受け取った署名を使ってBobがset code transactionを作成します。
先ほど得たy_parity,r,sと再びchainId,contract address, Alice EOAのnonceを用いてauthorization listを以下のように作ります。
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
ここではAliceのEOAに対してのみコード委譲をしていきますが、authorization listはlistになっていることから複数のEOAに対して一度にコード委譲設定ができることが分かります。
また、EIP-2718で導入されたTransactionTypeという枠組みを用いて、7702のコード委譲トランザクションであることを明示します。具体的には SET_CODE_TX_TYPE として 0x04 を設定します。
先ほどの authorization list を含む以下の値をRLPエンコードし、それに SET_CODE_TX_TYPE の値を連結したものを署名します。署名対象には、EIP-2930で導入された access_list も含まれます。
signature_y_parity, signature_r, signature_s = sign(keccak(0x04 || RLP(chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list)))
最後に、signature_y_parity, signature_r, signature_s を先ほどのRLP末尾に付与すれば、set code transactionが完成です。
rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])
なお、authorization list作成以降の流れは、EIP-1559など他のEIP-2718準拠トランザクションの作成手順と同様です。
コードの委譲設定
続いて、コード設定トランザクションが発行されてから実際にコードが設定されるまでの流れです。
Bobが発行したset code transactionを受け付けると、コードを設定する前に署名された内容が現在のチェーン状態と整合しているか等のチェックが行われます。主なチェック項目は以下の通りです。
- chainIdが0もしくは現在のchainIdと等しいこと
- nonce が2**64 - 1より小さいこと
- authorityのcodeが空、もしくはすでに委任されていること（=委譲設定するアカウントが通常のスマートコントラクトではないこと）
- authority に含まれる nonce が実際の EOA の現在の nonce と一致すること
チェックに問題がなければ、0xef0100 || address の値をEOAのcodeに設定します。0xef0100 はdelegation indicatorで、この値がある場合「EOAにセットされたcodeの内容は、後続のaddressに該当するコントラクトのcodeを参照して実行せよ」という意味になります。
最後にEOAのnonceをインクリメントしコードの委譲が完了します。
委譲されたコードの呼び出し
EOAに委譲されたコードを呼び出す際は、コードを委譲したEOAを宛先（to）に指定してトランザクションを送るだけです。 宛先のアドレスにセットされているcodeがdelegation indicatorから始まる場合、その後ろに続く委譲先コントラクトアドレスのcodeを参照して実行されます。
上図の例だと、BobがtoにAliceのEOAを、calldataにAliceのEOAに委譲したコントラクトの関数を呼び出す引数を設定してトランザクションを作成します。この場合、トランザクションのガス代の負担者はBob、トランザクション実行者はAliceとなります。
以上がコードの委譲設定から呼び出しまでの流れです。委譲対象コントラクトの設計次第で複数トランザクションのバッチ実行や、一定時間経過後に実行不可とする一時的な権限付与も実現できます。
一連の流れについては、以下のリポジトリにサンプル実装を置いているので、ぜひご覧ください。 GitHub - BoostryJP/eip7702-example
ガス代
最後にEIP-7702で必要なガス代についてです。
EIP-2930と同様
21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count
のガス代がかかり、EIP-7702特有の値としてPER_EMPTY_ACCOUNT_COST(=25000) * authorization list lengthを加算した値がコード設定にかかるベースのガス代となります。
すでにコード委譲がされている場合には PER_AUTH_BASE_COST(=12500) 分だけrefundされます。
EIP-7702 の懸念事項と対策
ガス代の代行などUX向上に大きく寄与するEIP-7702ですが、セキュリティ上の懸念も指摘されています。例えば、昨年9月時点ではトランザクションの約半数が犯罪に使われていると報告されています。（出所：Phemexニュース） https://phemex.com/ja/news/article/wintermute-reports-48-of-eip7702-uses-tied-to-cybercrime-20223
ここではEIP-7702を用いる上で考慮すべき懸念点と対策を4つ挙げます。
初期化処理の脆弱性
EIP7702では委譲するコントラクトをEOAにセットしているのみであり、initcodeはあえて実行しない作りになっています。そのため委譲完了後に初期化を実行する必要があるのですが、初期化関数の実行でフロントランニングされるリスクがあります。
対策としては、初期化用calldataに対してEOA の秘密鍵で署名を行い、コントラクト側で ecrecover により署名者を検証するという方法が考えられます。もしくは初期化関数はERC-4337 EntryPointコントラクトからのみ呼び出されるようにするということも有効です。（後述）
chainIdが0の場合にチェーンのチェックがされない
前述の通り、chainIdが0の場合はチェーンの一致チェックが行われず、どのチェーン上でも有効になります。そのため想定していないコードが委譲されるおそれがあります。
委譲対象のチェーンとコントラクトを明確に確認したうえで承認するようにしましょう。
確認せずに署名してしまうとどんな関数でも実行可
前項と同様ですが、未確認のまま委譲を承認してしまいEOAにコードが設定されると資金流出などの被害につながる恐れがあります。 委譲される内容の確認に加え、ホワイトリストに登録されたコントラクトのみ委譲可能とするなどの対策が考えられます。
tx.origin == msg.sender による再入攻撃防止が効かなくなる
これまで単純な再入攻撃の防止として msg.sender == tx.origin をチェックしていた場合、EIP-7702を用いるとそのチェックをすり抜けてしまいます。コード委譲されたEOAが自らに対してトランザクションを発行した場合、msg.sender と tx.origin のどちらもEOAのアドレスを指すためです。
OpenZeppelin の nonReentrant など、修飾子パターンによる再入性ガードを用いることが推奨されます。
EIP-7702とERC-4337の併用
ERC-4337は、UserOperationをEntryPointコントラクトに送信し、コントラクトウォレットをコールする流れでした。一見するとERC-4337とEIP-7702は比較対象の規格に見えますが、両者を組み合わせることで、従来のEOAにスマートコントラクトウォレットの機能を付与でき、既存EOAから段階的かつ柔軟な移行が可能になります。
具体的には、ERC-4337で定義されたUserOperationに eip7702Auth パラメータを追加することで、EIP-7702のauthorizationを付与できます。Bundlerはこれらのauthorizationを集約し、SET_CODE_TX_TYPE トランザクションとして実行することで、EOAに対するコード委譲を行えます。
また通常、EntryPointコントラクトはsenderが存在しない場合、UserOperationに含まれるfactoryコントラクトでコントラクトウォレットを作成します。
一方で、UserOperationのinitcodeが 0x77020000000… の場合、factoryコントラクトは呼び出されず、コントラクトウォレットはコード委譲されたEOAとみなされ、EntryPointコントラクトが署名検証を行います。
このときUserOperationのハッシュ計算では、initcodeの先頭20byteを委譲先コントラクトアドレスに置き換えた値が用いられ、これにより署名を別の委譲先に流用することを防げます。また21byte目以降の値は初期化処理の呼び出しに用いられます。
なお、EIP-7702の認可処理にはガス代が25000かかると定義されているため、その分を preVerificationGas に上乗せしておく必要があります。
まとめ
EIP-7702ではset code transactionを用いてEOAにコントラクトを委譲することが可能になり、既存アカウントの移行不要でAccount Abstractionが実現されました。 一方でその簡便さと引き換えに安全に使用するにはいくつかセキュリティ上注意するポイントがある仕様となっています。
また、ERC-4337とは対立する規格ではなく二つの併用も可能である仕様となっています。これらを併用することにより既存のEOAアカウントを用いたままERC-4337のメリットを享受することが可能となります。今後Account Abstractionがどのように発展していくか注目です。
本記事の内容は社内勉強会資料をもとに再整理したものです。BOOSTRY では毎週、社内で技術勉強会を開催し、ブロックチェーンをはじめとする先端技術の知見をメンバー間で共有しています。この記事を通じて、BOOSTRY の技術への取り組みやブロックチェーン技術の可能性に少しでも興味を持っていただければ幸いです。今後も研究開発およびプロダクト開発を通じて、より効率的で機能性の高い、先進的な金融市場の実現に向けて取り組んでまいります。 引き続き BOOSTRY の活動にご注目ください！
ご興味のある方は、ぜひ採用情報もご覧ください！
