bundlerと UserOperation：ERC-4337 取引の仕組み

UserOperation は ERC-4337 が定義する、署名された意図オブジェクトです。スマートコントラクト・アカウントが何を実行してほしいのか、そしてそのアクションをどう検証し、どう支払うのかを記述します。通常の Ethereum 取引とは異なり、外部所有アカウントが署名するプロトコルレベルのオブジェクトではありません。その署名はアカウント・コントラクト自身によってチェックされ、ネイティブガスを自ら支払う必要もありません。bundler は、専用の代替メムプールから UserOperation を収集し、それぞれをシミュレートし、有効なものを単一の通常の Ethereum 取引にパックして、正規の EntryPoint コントラクトを呼び出すオフチェーンのアクターです。EntryPoint は、バッチ内のどの操作を実行するよりも前に、すべての操作を検証します。bundler は自身の EOA から実際のガスを立て替え、送信元アカウントまたはそのアカウントの paymaster からオンチェーンで補填を受けます。オプションの paymaster コントラクトは、その検証ステップの中で操作の費用を引き受けることに同意でき、これによって手数料はスポンサードされるか、チェーンのネイティブなガストークンの代わりに ERC-20 トークンで支払えるようになります。

ERC-4337 のおさらい

ERC-4337 は アカウント抽象化 のための Ethereum 標準です。ベースプロトコルを一切変更することなく、スマートコントラクト・アカウントに、外部所有アカウント（EOA）が常に持っていたのと同じ、アクションを開始し支払う第一級の能力を与える方法です。コンセンサス層を変更する代わりに、ERC-4337 は、最終的に通常の Ethereum 取引を通じて決済される、より高レベルのオブジェクトとオフチェーン・インフラからなる並行システムを導入します。まず基礎から知りたい場合は、アカウント抽象化とは何か の解説がその動機をカバーし、ERC-4337 とは何か が標準全体を俯瞰し、スマートアカウントと EOA の比較 が二つのアカウント種別を直接比べています。本稿ではその仕組み、すなわちシステム内を移動するオブジェクトと、それらを処理するアクターに焦点を当てます。ERC-4337 は EVM 標準であり、Ethereum および EVM 互換チェーンに適用され、Solana や TON のような非 EVM チェーンには適用されない点に留意してください。

UserOperation とは実際に何なのか

ERC-4337 の中心的なオブジェクトが UserOperation です。それは表面的には取引のように見えますが、署名された意図の表明として理解するのが適切です。すなわち、「これが私のアカウントがやってほしいことであり、これがそれを検証し支払うためのパラメータだ」というものです。UserOperation はコントラクトに calldata として渡される構造体であり、ネイティブなプロトコル・オブジェクトではありません。ベース層はその存在を一度も知りません。

UserOperation が実質的に運ぶ内容は次のとおりです。

• sender — その操作が代理するスマートコントラクト・アカウント。
• nonce — リプレイ保護。EntryPoint がキーとシーケンスからなる二部構成の値として追跡するため、アカウントは一本の厳密なキューではなく、独立した複数のノンス・レーンを走らせられます。
• callData — アカウントが実行すべき内容。一つの操作の中に複数の呼び出しをまとめたバッチであることも多くあります。
• アカウント・デプロイ用データ — オプション。いちばん最初の操作でアカウント・コントラクトをデプロイします。これにより、スマートアカウントはオンチェーンに存在するより前に、決定論的に導出された既知のアドレスへ入金を受けられます。
• ガスリミット — 検証用と実行用の別々の予算に加え、EntryPoint 自身では計量できない calldata とオーバーヘッドを bundler に補償する preVerificationGas の値。
• 手数料パラメータ — EIP-1559 に倣った最大手数料と最大優先手数料。
• paymaster データ — オプション。どのコントラクトがその操作をスポンサーするか、およびそれが必要とするコンテキスト。
• 署名 — プロトコルではなく、アカウント自身の検証関数によってチェックされます。

正確なエンコーディングは EntryPoint のバージョンによって変化してきました。v0.6 が単一の initCode と paymasterAndData のバイト列を使っていたのに対し、v0.7 はデプロイと paymaster のブロブを明示的なフィールドに分割し、複数のガス値をまとめてパックします。とはいえ概念上の中身は同じです。実際に組み込むのであれば、利用する bundler がどの EntryPoint バージョンを対象としているかを確認してください。

通常の取引との重要な違いは、誰が、何を 署名するかにあります。従来の Ethereum 取引は、固定の ECDSA 方式を用いて EOA の秘密鍵で署名されなければならず、その同じアカウントがガスを支払います。UserOperation は、送信元自身のスマートコントラクト・アカウントのロジックによって検証されます。そのロジックは、アカウントが定義するどのような署名方式、複数鍵ルール、セッションキー、承認ポリシーでも実装でき、しかもネイティブガスで自ら支払う必要がまったくありません。その柔軟性こそが要点です。プロトコルではなくアカウントが、有効なアクションとは何かを決定するのです。

それらが存在する代替メムプール

UserOperation は、まだ取引ではないため、通常の Ethereum 取引メムプールには入りません。代わりに、それらは別個の 代替メムプール（しばしば alt-mempool と呼ばれる）にブロードキャストされます。これは ERC-4337 オブジェクト専用のピアツーピア・ネットワークです。実務上は、ウォレットや dApp が bundler の RPC エンドポイントに対して eth_sendUserOperation を呼び出すことで送信します。その bundler は、受け取ったものを共有の alt-mempool へゴシップすることもあれば、自前のプライベート・プールに留めることもあります。いずれにせよ、これらのオブジェクトを消費するインフラは、ベース層のメムプールではなく、ここをリッスンします。この分離により、アカウント抽象化のトラフィックは、実際の取引にパッケージ化される瞬間まで、コンセンサスにとって重要な経路から切り離されたままになります。

bundlerの役割

bundler は、意図をオンチェーンの現実へと変換するオフチェーンのアクターです。その仕事は四つの部分から成ります。第一に、代替メムプールから UserOperation を収集します。第二に、それぞれをシミュレートして検証します。すなわち、アカウントの検証ロジックをシミュレートされたコンテキストで実行し、署名が有効であること、ノンスが正しいこと、そしてアカウントまたはそのpaymasterがコストを負担できることを確認します。第三に、一つ以上の有効な UserOperation を単一の通常の Ethereum 取引にパックします。第四に、その取引を自身の EOA からネットワークに送信し、ベース層のガスを前払いして、オンチェーンでの補填を期待します。

シミュレーションだけでは十分な防御になりません。シミュレーションから取り込みまでの間に状態が変わり得るからです。そこで ERC-4337 は、検証コードに許されることも制約します。検証フェーズの間、アカウントやpaymasterは、ブロックのタイムスタンプをはじめ、シミュレーション時とオンチェーンとで挙動を変えられるような環境値を読むことができず、ストレージへのアクセスも概ね自分自身のアカウントに紐づくスロットに限定されます。また、多数のユーザーを代理して動作するコントラクト、とりわけファクトリーとpaymasterは、ステークを預けることが期待されます。単一の不正なコントラクトが、メムプールの大きな部分を安価に一挙に無効化できないようにするためです。これらのルールが存在する理由はただ一つ、bundlerのシミュレーションを、オンチェーンで実際に起きることの信頼できる予測にするためです。

bundlerはガスを立て替え、取り込みに対する手数料を得るため、アカウント抽象化トラフィック向けの専門的なブロックビルダーのように振る舞います。そのシミュレーションと検証のステップこそが、bundlerを保護します。bundlerは、自らを補填しないような操作をバンドルすることはありません。

EntryPoint コントラクト

すべては、EntryPoint と呼ばれる単一の正規スマートコントラクトに収束します。これはシングルトンであり、バージョンごとに EVM チェーン全体で同一のアドレスにデプロイされ、操作の支払いに充てられるデポジットを保持します。bundlerの取引は、UserOperation の配列を伴う EntryPoint への呼び出しであり、EntryPoint はその後、厳格な二段階のループを実行します。

検証フェーズ では、各操作について、送信元アカウントの検証関数（および指定されていればpaymasterの検証関数）を呼び出し、署名、ノンス、支払いの取り決めをオンチェーンで再チェックしたうえで、支払う側から想定される最大コストを予約します。バッチ内のすべての操作が検証された後にのみ 実行フェーズ に移り、そこで各操作の calldata をそのアカウントにディスパッチして、送金、スワップ、その他のアクションを実際に実行し、続いて実コストを決済して未使用の予約分を返金します。

この分離は重要です。検証と実行が分離されているのは、状態を変更する作業が実行される前にバッチの支払い保証が確立されるようにするためであり、また EntryPoint が多数の操作にまたがってガスを一度に正確に計量できるようにするためです。さらに、ある操作が実行中に失敗しても、それがバッチ内の他の操作を巻き添えにしないことも意味します。

paymasterはどこに位置するか

paymaster は、アカウントに代わって UserOperation の支払いをすることに同意する、オプションのコントラクトです。UserOperation がpaymasterデータを含む場合、EntryPoint は検証フェーズ中に、そのpaymasterに対して、その操作をスポンサーするかどうか、そしてどのような条件で行うかを尋ねます。paymasterは、その判断とコンテキストのブロブを返します。実行後、EntryPoint は実際に使用されたガス量を伴うポスト・オペレーションのステップでpaymasterを呼び戻します。トークン課金型のpaymasterが正確な金額を決済するのは、ここです。paymasterは無条件で受け入れる（アプリがコストを吸収する、真のガスレス・スポンサー）こともできますし、価値と引き換えに受け入れることもできます。最も有用なのは、ネイティブガスの代わりに ERC-20 トークン でユーザーに課金することです。このコンポーネントをより深く見るには paymasterとは何か をご覧ください。paymasterは、「ユーザーが何で支払うか」を「ネットワークが何で支払われるか」から切り離す、フロー内のフックです。

ガスと失敗はどう扱われるか

ERC-4337 のガスは階層化されています。bundlerは外側の取引に対して本物の ETH を支払います。EntryPoint は各 UserOperation の検証と実行のガスを、それが宣言したリミットに対して計量します。そして責任を負う者、すなわちアカウントまたはそのpaymasterは、請求額を賄うのに十分な額を EntryPoint に預けていなければならず、それはバッチの最後に決済されます。知っておく価値のある帰結が一つあります。ERC-4337 の操作は、同等の素の取引よりもいくらか多くのガスを消費します。アクションそのものに加えて、コントラクトレベルの検証と EntryPoint の帳簿付けの分を支払っているからです。

失敗は、検証優先の設計によって封じ込められます。ある操作がオンチェーン検証中に失敗すればバッチ全体がリバートしてしまうため、bundlerはそうなる前にその操作を落としてバンドルを組み直します。オフチェーン・シミュレーションはまさにそのためにあります。ある操作が検証を通過したものの、その実行がリバートした場合、実行の効果はロールバックされますが、既に費やされたガスは依然として計算され支払われます。そのため、bundlerが誠実な作業に対して補填を受けないままになることはありません。この非対称性こそが、bundlerが非常に慎重にシミュレートする理由です。妨害攻撃に対する彼らの防御は、自らに返済しないものは一切取り込まないことなのです。

ライフサイクルを順に追う

1. ウォレットが UserOperation を組み立てます。sender、ノンス、calldata、ガスリミット、手数料パラメータ、そしてオプションのpaymasterデータです。
2. paymasterを使う場合は、操作がブロードキャストされる前に、paymasterがスポンサー条件に同意します。
3. アカウントの署名ロジックがそれに署名します。単一の ECDSA 鍵である必要はありません。
4. ウォレットがそれをbundlerの RPC に送信し、代替メムプールに入ります。
5. bundlerが、標準の制限オペコードとストレージのルールのもとで、それをシミュレートし検証します。
6. bundlerがそれを他の操作とともに、EntryPoint の handleOps を呼び出す一つの Ethereum 取引にパックし、ベース層のガスを支払います。
7. EntryPoint がすべての操作を検証し、それぞれの calldata を実行し、デポジットに対してコストを決済し、超過分を返金し、bundlerに補填します。

これがウォレット利用者にもたらすもの

仕組みは手が込んでいますが、その狙いは地味で実用的です。複数のアクションを一度の承認にまとめること（たとえば approve とスワップを一緒に行う）、スポンサードあるいはトークン払いの手数料、単一の secp256k1 鍵以外の署名方式、支出ポリシーとセッションキー、そしてソーシャルまたはデバイスに基づくリカバリーです。なお、EIP-7702 は通常の EOA が一時的にスマートアカウントのコードで実行することを可能にし、上で説明した ERC-4337 のインフラを置き換えることなく、これらの機能のいくつかについて差を縮めます。

WATS はこれをどう活用しているか

EVM チェーン上では、WATS はこのフローのうちまさに一つの要素、すなわちpaymasterのスロットに依拠します。WATS の Hot Wallet で送金、スワップ、ステーキングを行うとき、ウォレットが組み立てる UserOperation はpaymasterを指定し、そのpaymasterこそが、手数料をチェーンのネイティブなガストークンではなく ATS で請求できるようにするものです。おかげで、動かせるようにするためだけに、あらゆるネットワークで ETH、BNB、POL の細かな残高を抱えておく必要はありません。あなたがbundlerを運用したり、EntryPoint のバージョンを選んだり、bundlerの RPC キーを保有したりする必要もありません。それはインフラであり、ウォレットの仕事は有効な UserOperation を組み立てて送信することです。

誠実であるために、二点を明確にしておきます。第一に、ATS で支払うことは割引ではありません。ネットワークは通常どおりの手数料を徴収し、paymasterがそれを決済するので、変わるのはあなたの残高から出ていくトークンであって、根底にあるコストではありません。第二に、ERC-4337 は EVM 専用であるため、Solana と TON では、ここで説明した EntryPoint のフローではなく、同等のフィーペイヤーの取り決めがpaymasterの役割を果たします。ATS は LayerZero OFT であり、それによって単一の ATS 残高が Ethereum、Arbitrum、Optimism、Base、Polygon、BNB Chain、Solana、TON にまたがる手数料を賄えます。そして徴収された ATS はバーンされ、供給量は 100,000,000 から 30,000,000 のフロアへと減っていきます。WATS は全体を通じて完全にノンカストディアルです。鍵を保有するのはあなたであり、WATS が鍵を保有することは決してありません。

このフローを仕様書ではなく動くシステムとして見たいなら、具体的な一歩は、ネイティブなガストークンを一切持っていないチェーンで WATS Hot Wallet の送金を試してみることです。UserOperation もbundlerも EntryPoint も見えないところで仕事をし、手数料はあなたの ATS 残高から差し引かれます。ATS 手数料モデルの仕組み が、その全体を端から端まで解説しています。