1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@cardene(かるでね)

[ERC7902] Wallet Call APIでアカウント抽象化向けの追加設定を受け渡す仕組みを理解しよう！

1
Posted at

はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

今回は、Wallet Call APIを拡張して、アカウント抽象化向けの追加設定をdAppとウォレットのあいだで受け渡せるようにするERC7902についてまとめていきます！

以下にまとめられているものを解説しながらまとめていきます。

他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。

概要

ERC7902は、EIP5792のCapability機構を使って、アカウント抽象化で必要になる追加パラメータをdAppからウォレットへ渡すための提案です。

EIP5792については以下の記事を参考にしてください。

原文の副題は「EIP-5792 Capabilities allowing dApps and wallets to exchange all AA specific UserOp fields」です。
要するに、UserOperationを組み立てる時に必要なAA固有の値を、Wallet Call APIの拡張項目としてやり取りできるようにします。

ERC4337やERC7769は、AAをどう動かし、bundlerへどう送るかを定義しています。
ただし、それだけではdAppが「このPaymaster設定を使ってほしい」「この時間帯だけ有効にしたい」「このnonceの枝を使いたい」といった細かい要求を、ウォレットへ標準的に伝えられません。

ERC4337については以下の記事を参考にしてください。

ERC7769については以下の記事を参考にしてください。

ERC7902は、この隙間を埋める規格です。
Capabilityの識別子と入力形式を共通化しておくことで、AA対応dAppはウォレットごとの独自拡張を前提にせず、必要な追加設定だけをWallet Call APIへ渡せるようになります。

2026年5月4日時点で、ERC7902のステータスは Draft です。
まだ確定規格ではないため、今後フィールド名や運用の細部が変わる可能性があります。

ERC7902 の位置づけ

動機

既存AA規格の役割分担

AAまわりの規格は、すでにいくつかの層に分かれています。

規格 役割
ERC4337 スマートアカウントとUserOperationの基本モデルを定義します。
ERC7769 UserOperationをbundlerへ送るJSON-RPCを定義します。
EIP5792 dAppとウォレットのあいだで複数呼び出しを送るWallet Call APIを定義します。

この分担自体は自然です。
一方で、AAを理解したdAppがウォレットへ渡したい情報は、これよりもう少し細かいところにあります。

未標準化のAA入力

原文で挙げられている論点は大きく5つです。

  1. EIP7702の委譲先を指定したい
    どのEOAに、どの実装を委譲させるかをdAppが制御したい場合があります。
  2. 固定的なPaymaster設定を渡したい
    dApp側で paymaster と paymasterData を解決済みなら、その値をそのまま使ってほしい場合があります。
  3. 有効時間を絞りたい
    署名後すぐ有効にせず、ある時刻以降だけ有効にしたい、ある時刻までしか有効にしたくない、という要求があります。
  4. 半抽象化nonceの枝を指定したい
    多次元nonceを使うアカウントでは、どの枝の連番を使うかをdAppが選びたい場合があります。
  5. AA特有のガス値を上書きしたい
    開発や特定プロトコル向けの実装では、ウォレットの自動見積もりではなくdApp側の値を使いたい場合があります。

これらは、UserOperationの世界では重要な値です。
しかし、dAppとウォレットの境界でどう渡すかが標準化されていないと、ウォレットごとの独自仕様に依存することになります。

EIP5792のCapability拡張

EIP5792は、もともとWallet Call APIをCapabilityで拡張できるように設計されています。
ERC7902はその拡張点を使い、AA向けの追加項目を「どの名前で」「どの型で」渡すかをそろえます。

この構成により、AA対応dAppは wallet_getCapabilities で対応状況を問い合わせ、wallet_sendCalls に必要なCapabilityだけを載せる、という流れで実装できます。
ウォレット側も、どの追加設定を受け付けるかを機械的に表明しやすくなります。

5つのCapabilityの分類

仕様

原文の仕様は短く、主眼はCapabilityの定義です。
最初に置かれている前提は1つだけで、EIP5792文脈で行うAAの操作は、単一チェーン上で、かつアトミックに実行しなければなりません。

全体の前提

この制約があるのは、複数チェーンをまたぐ処理や、部分成功を前提にした処理をここで扱わないためです。
ERC7902は、Wallet Call APIの1回の呼び出しの中でAA用の追加設定を渡す規格なので、まず「同じチェーンでまとめて扱う」ことを前提にしています。

単一チェーン前提と対象外

eip7702Auth

eip7702Auth は、ウォレットにEIP7702の認可情報を作らせるためのCapabilityです。

EIP7702については以下の記事を参考にしてください。

  • 引数
{
  account: `0x${string}`;
  delegation: `0x${string}`;
}

ウォレットがこのCapabilityに対応している場合、account のEOAへ delegation のコードを設定するEIP7702互換トランザクションを生成しなければなりません。
つまり、dAppは「どのEOAを」「どのアカウント実装へ切り替えたいか」を指定でき、ウォレットはその意図に沿って認可タプルを組み立てます。

eip7702Auth の流れ

staticPaymasterConfiguration

staticPaymasterConfiguration は、ウォレット側で追加の解決処理をしなくても使える、固定的なPaymaster設定を渡すCapabilityです。

  • 引数
{
  paymaster: string;
  paymasterData: string;
  paymasterValidationGasLimit: `0x${string}`;
  paymasterPostOpGasLimit: `0x${string}`;
}

ここで重要なのは、原文が「Wallet Application to resolve any dynamic configuration」を不要にする用途だと書いている点です。
つまり、ウォレットが都度Webサービスへ問い合わせて設定を取りにいくケースではなく、dApp側が先に解決済みの固定値を渡すケースを想定しています。

動的なPaymaster解決は、この規格ではなくERC7677の守備範囲です。

固定設定と動的設定の違い

ERC7677については以下の記事を参考にしてください。

validityTimeRange

validityTimeRange は、署名後にその操作が有効となる時間帯をdAppが明示するCapabilityです。

  • 引数
{
  validAfter: `0x${string}`;
  validUntil: `0x${string}`;
}

ウォレットは、この時間範囲が妥当かを確認し、人が読める形でユーザーへ提示しなければなりません。
さらに、スマートアカウント側も、この validAfter から validUntil までの範囲を、そのままトランザクションの有効期間として反映しなければなりません。

このCapabilityは、単に表示用の補足情報ではありません。
署名確認とオンチェーン実行の両方にまたがって守られる前提です。

validityTimeRange の時間窓

multiDimensionalNonce

multiDimensionalNonce は、ERC4337で定義される半抽象化nonceの構成要素をdAppが指定するCapabilityです。

  • 引数
{
  nonceKey: `0x${string}`;
  nonceSequence: `0x${string}`;
}

原文では「semi-abstracted nonce as defined in ERC-4337」と書かれています。
つまり、単一の連番だけを渡すのではなく、「どの枝か」と「その枝の何番目か」を分けて伝える用途です。

多次元nonceをサポートするスマートアカウントでは、ウォレットは実際のオンチェーン実行時にこれらの値を使う必要があります。
これにより、dAppは用途別の枝を分けたり、並列実行に向いたnonce管理をしたりしやすくなります。

multiDimensionalNonce の枝構造

accountAbstractionGasParamsOverride

accountAbstractionGasParamsOverride は、AA特有のガス関連フィールドをdApp側で上書きするためのCapabilityです。

  • 引数
{
  preVerificationGas?: `0x${string}`;
  verificationGasLimit?: `0x${string}`;
  callGasLimit?: `0x${string}`;
  paymasterVerificationGasLimit?: `0x${string}`;
  paymasterPostOpGasLimit?: `0x${string}`;
  maxFeePerGas?: `0x${string}`;
  maxPriorityFeePerGas?: `0x${string}`;
}

原文で強調されているのは、このCapabilityがかなり低レイヤーだという点です。
特定プロトコルの特定バージョンに密結合した実装や、開発、デバッグでは有用になり得ますが、本番dAppではウォレットの高レイヤー機能に任せる方が一般的に望ましいとしています。

また、すべてのフィールドは任意です。
上書きしたい値だけを渡せます。

ウォレットは、dAppが上書き値を渡してきたことをユーザーへ警告し、それらの値を使う想定です。
さらに、設定どうしが衝突している場合、呼び出しを拒否してもよいとされています。

ガス上書きの守備範囲

補足

5つのCapabilityの役割分担

この提案の5つは、すべて「AAだから必要になる追加値」ですが、役割はかなり異なります。

Capability 解決したいこと
eip7702Auth EOAをどの実装へ委譲するかを決める。
staticPaymasterConfiguration どのPaymaster設定を使うかを固定値で渡す。
validityTimeRange いつ有効な操作かを制限する。
multiDimensionalNonce どのnonceの枝と連番を使うかを指定する。
accountAbstractionGasParamsOverride AA特有のガス値をdApp側で上書きする。

この表から分かるとおり、ERC7902は1つの大きな新機能を足す規格ではありません。
AAで必要になりやすい追加入力を、Capabilityごとに分解して整理する規格です。

ERC7902の対象外

この提案で標準化されるのは、dAppとウォレットの間で追加設定をどう渡すかです。
以下は別の層の話であり、この規格だけでは解決しません。

  1. bundlerとの低レイヤー通信
    UserOperationをbundlerへ送るRPCの詳細はERC7769の役割です。
  2. 動的なPaymaster解決
    Webサービス経由でPaymaster設定を受け取る流れはERC7677の役割です。
  3. スマートアカウント実装そのもの
    どの実装を採用するか、内部ロジックをどう書くかまでは決めません。

そのため、ERC7902はAA全体の中では「入力の受け渡し」を担う位置づけです。
低レイヤーの送信方式や、アカウント実装の正しさそのものを代替するわけではありません。

セキュリティ

eip7702Auth の危険性

原文でも This is by far the most sensitive capability in the document. と書かれています。
誤ったCapabilityへ署名した時の損害に上限がなく、悪意ある delegation を許すと account の資産を丸ごと抜かれる恐れがあるためです。

ウォレットは、受け入れる delegation 実装を厳しく制限し、広く知られた公開監査済みの実装だけを許可しなければなりません。
dAppが渡してきたアドレスを、そのまま信じて署名させる実装では不十分です。

eip7702Auth の危険箇所

staticPaymasterConfiguration の攻撃面

原文では、誤った paymaster や paymasterData が攻撃ベクトルになり得ると述べています。
例として、PaymasterコントラクトがERC20トークンの承認を保持している場合、それを悪用される余地があると書かれています。

ERC20については以下の記事を参考にしてください。

つまり、ウォレットは通常のトランザクションの calldata を確認するのと同じように、このPaymaster設定が本当にユーザー意図と一致しているかを確認しなければなりません。

ガス上書きの運用リスク

accountAbstractionGasParamsOverride は、プロトコル実装の細部を知っているdAppには便利です。
一方で、値を誤ると実行失敗や過剰な手数料負担へつながります。

原文が「production dapps rely on higher-level features of Wallet Applications instead」と書いているのは、この危険があるためです。
普段はウォレットの見積もり機構に任せ、どうしても必要な場合だけ使う方が自然です。

最後に

今回は「ERC7902」についてまとめてきました。

ERC7902は、AAそのものを新しく定義する規格ではなく、EIP5792のCapabilityを使ってAA向けの追加設定を受け渡すための規格です。
eip7702Auth、staticPaymasterConfiguration、validityTimeRange、multiDimensionalNonce、accountAbstractionGasParamsOverride の5つを共通化することで、AA対応dAppとウォレットの相互運用性を高めようとしています。

一方で、eip7702Auth や staticPaymasterConfiguration は、そのまま強い攻撃面にもなります。
特にウォレット側は、どの実装へ委譲するか、どのPaymaster設定を受け入れるかを、通常の署名確認以上に慎重に扱う必要があります。

他でも色々記事を書いているのでぜひよろしければ読んでいってください！

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?