ペイマスターとは?

ペイマスターは、他人のユーザーオペレーションのガスを支払うスマートコントラクトだ。ERC-4337は、アプリがチェーンのネイティブトークンで手数料をスポンサーするか、ユーザーがUSDCなどのERC-20トークンでその手数料を払えるようにするために導入した。操作を送ったバンドラーへの返済は、引き続きネイティブトークンで行われる。

仕事はそれだけだ。新しいユーザーはUSDCを持っていてETHを持っていない。スワップもミントも、最初のアカウントデプロイも始まらない。送信者が払えないトランザクションを、ネットワークは受け付けないからだ。ペイマスターは、アプリが定めたルールのもとでその手数料を負担するコントラクトだ。

ウォレットではない。バンドラーでもない。送信者は通常スマートアカウントだ。バンドラーは、ユーザーオペレーションを1つのトランザクションにまとめるオフチェーンのサービスだ。エントリーポイントは、全員を検査し、呼び出しを実行し、バンドラーに返済するオンチェーンのコントラクトだ。ペイマスターは、その返済を負担すると合意する側だ。

ペイマスターとは?

ペイマスターは、エントリーポイントにネイティブガストークンのデポジットを持つERC-4337コントラクトだ。ユーザーオペレーションがそのペイマスターを指名すると、エントリーポイントは送信者からではなく、ペイマスターのデポジットから手数料を引く。

ユーザーオペレーションは、ペイマスターアドレスを paymasterAndData（古いEntryPoint）か、分かれた paymaster と paymasterData（EntryPoint v0.7以降）に載せる。そのデータは、ペイマスターがすでに承認したスポンサーシップを見分けるためのものだ。Alchemyのペイマスターでは、32バイトにパックした時間範囲のあとに65バイトの署名が続く。

ペイマスターがなければ、スマートアカウントは何かをする前にETH、またはそのチェーンがガスに使うトークンを持っていなければならない。あれば、アプリが払うか、ユーザーがすでに持っているトークンで払える。

ペイマスターはいつ使うべきか?

行動する人が、チェーンのガストークンを持つべきでないときにペイマスターを使う。

長く残る理由は二つだ。

スポンサーシップ。アプリが払う。新規ユーザーがオンボーディングを終える、キャンペーンが最初の操作を負担する、あるいはプロダクトがカードネットワーク手数料を隠すフィンテックのようにガスを隠す。手数料を決済するのは、エントリーポイント上のペイマスターのデポジットだ。

ERC-20での支払い。ユーザーはトークン、多くの場合ステーブルコインで払い、ペイマスターはそれでもバンドラーへネイティブトークンで決済する。そのトークンがチェーンのガストークンになるわけではない。ペイマスターは価格を提示し、トークンを受け取り、自分のネイティブトークンのデポジットでネットワークに払う。

両方を同時に動かせる。一部のユーザーはスポンサーし、他のユーザーにはUSDCで払ってもらう。どちらにするかはポリシーが決める。

ペイマスターはどう動くか?

ペイマスター自身はトランザクションを送らない。送るのはバンドラーだ。エントリーポイントがペイマスターを呼び出し、そのあとバンドラーに返済する。

スポンサーされたユーザーオペレーションの順序はこうだ。

1. 送信者が、ペイマスターを指名したユーザーオペレーションに署名する。
2. バンドラーがバンドルを EntryPoint.handleOps に送る。
3. エントリーポイントは、ペイマスターのデポジットがその操作の最悪コストを賄えるか確認する。デポジットが低すぎると、操作は AA31 paymaster deposit too low で失敗する。
4. エントリーポイントは送信者の validateUserOp を呼ぶ。ペイマスターが払うので、この操作のためにアカウントへ資金のデポジットは求められない。
5. エントリーポイントはペイマスターの validatePaymasterUserOp を呼ぶ。ペイマスターが拒否すれば、操作は実行されない。
6. エントリーポイントが送信者の呼び出しを実行する。
7. 検証が空でないcontextを返した場合、エントリーポイントは postOp を呼び、ペイマスターが精算できるようにする。たとえばERC-20トークンを引き落とす。
8. エントリーポイントはペイマスターのデポジットからバンドラーに払う。ペイマスターがなければ、送信者自身のデポジットがバンドラーに払う。

ペイマスターはどの関数を実装する必要があるか?

ペイマスターのインターフェースには二つの関数がある。

validatePaymasterUserOp は検証中に走る。ユーザーオペレーション、そのハッシュ、最大コストを受け取る。contextのバイト配列と検証結果を返す。空でないcontextは、実行後に postOp を走らせる合図だ。空のcontextは、精算するものが残っていないことを意味する。

postOp は呼び出しのあと、そのcontextが空でなかった場合にだけ走る。ERC-20ペイマスターが送信者からトークンを移すのはここだ。呼び出しがrevertした場合にも走り、ペイマスターが失敗に反応できるようにする。mode引数が、どちらの場合かを伝える。

どちらの関数も、エントリーポイント以外の呼び出し元を拒否しなければならない。どこからでも呼べるペイマスターは、承認していない操作のスポンサーに騙されうる。

ペイマスターにはどんな種類があるか?

ERC-4337は公式の製品を二つ定義しているわけではない。定義しているのは一つのインターフェースだ。チームは、誰が支払うかを決めるのか、ユーザーに何を請求するのかでペイマスターを分ける。

検証型ペイマスター

検証型ペイマスターは、オフチェーンのサービスに操作の承認を求め、その承認をオンチェーンで確認する。通常の確認は、ユーザーオペレーションに対する署名で、あとから再利用できないよう時間窓に縛ることが多い。

これが、アプリのためにガスをスポンサーするオンチェーンペイマスターの形だ。アプリのバックエンド、またはガスポリシーのサービスが、この送信者、この呼び出し、このコストを許可すると決める。コントラクトが信頼するのは署名だ。AlchemyのOnchain Paymasterポリシーはこう動く。ポリシーがユーザーオペレーションを承認し、alchemy_requestGasAndPaymasterAndData がペイマスターアドレス、署名済みデータ、ガス見積もりを返す。推奨のGas Sponsorshipポリシーは違う。バンドラーでスポンサーし、ペイマスターフィールドは返さない。

検証型ペイマスターは、カードや法定通貨の課金の背後にも置ける。オフチェーンのサービスが先に支払いを確認する。オンチェーンのコントラクトが見るのは、手数料がカバーされているという署名だけだ。

ERC-20ペイマスター

ERC-20ペイマスターは、トークンペイマスターやデポジットペイマスターとも呼ばれ、ユーザーにERC-20トークンで請求する。エントリーポイントは、ペイマスターのデポジットから、それでもネイティブトークンでバンドラーに払う。postOp、設計によっては検証ステップが、デポジットを補充できるようトークンを集める。

為替レートは、ユーザーが署名する前に固定しなければならない。Alchemyは、操作が採掘されたときではなく、スポンサーシップに署名した瞬間にToken Prices By Address APIの見積もりをロックする。署名と取り込みのあいだで価格が動くと、ユーザーがすでに同意した手数料が変わる。

トークンの動かし方は二つある。

• 実行後。最初に使うモードだ。ユーザーオペレーションにトークン承認を含められるので、別の承認トランザクションはいらない。トークン転送が失敗すると操作全体がrevertするが、使ったガスの責任はスポンサーに残る。先にシミュレーションする。シミュレーションは保証ではない。
• 実行前。転送は validatePaymasterUserOp の中で起きる。ペイマスターは、以前の approve かpermit署名によるallowanceをすでに持っていなければならない。allowanceがなければ操作は拒否される。ガスはより多くかかり、ユーザーに見える手順が増える。

どちらのモードでも、バンドラーへの支払いはペイマスターのネイティブトークンのデポジットからだ。ユーザーからUSDCを取っても、そのデポジットの必要は消えない。

ウォレットはどうやってペイマスターデータを要求するか?

ウォレットがスポンサーシップ用の私的なAPIをそれぞれ発明するべきではない。ERC-7677はペイマスターのウェブサービス標準だ。アプリはペイマスターサービスのURLを渡す。ウォレットはそのURLで二つのJSON-RPCメソッドを呼ぶ。

• pm_getPaymasterStubData は、ユーザーが署名する前にウォレットがガスを見積もれるよう、ダミーのペイマスターフィールドを返す。
• pm_getPaymasterData は、バンドラーへ送る署名済みユーザーオペレーションの最終フィールドを返す。

サービスはEntryPointのバージョンを判別しなければならない。v0.6は paymasterAndData を期待する。v0.7以降は paymaster と paymasterData を期待する。

Alchemyは、Onchain Paymasterポリシー向けにこれらの pm_ メソッドを実装している。alchemy_requestGasAndPaymasterAndData はペイマスターフィールドとガス見積もりをまとめて返す。alchemy_requestPaymasterAndData は古いメソッドで、非推奨になる。Bundler Sponsored Operationsはこれらのメソッドを使わず、ペイマスターフィールドも返さない。

EIP-7702はペイマスターを置き換えたか?

置き換えていない。EIP-7702は、外部所有アカウントが、1つのトランザクションのあいだ、またはその委任を変えるまで、スマートコントラクトのコードへ委任できるようにする。別のコントラクトウォレットを先にデプロイしなくても、アカウントは呼び出しをまとめ、スマートアカウントの機能を使える。ガスを払う誰かは、それでも必要だ。

その流れがオンチェーンペイマスターを使うなら、払うのは引き続きそのペイマスターで、送るのは引き続きバンドラーだ。0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108 にデプロイされたEntryPoint v0.8は、EIP-7702の検査をネイティブに加える。ユーザーオペレーションのハッシュに委任アドレスが含まれ、エントリーポイントはその委任が一致するか確認する。公開されているGas Managerのリクエスト例が対象にするのは、0x0000000071727De22E5E9d8BAf0edAc6f37da032 のEntryPoint v0.7だ。アカウントが前提にしているEntryPointを渡す。バンドラーとエントリーポイントは、その認可を理解しなければならない。

EIP-7702は、既存のEOAでもスポンサーシップを使えるようにした。ERC-4337からペイマスターをなくしたわけではない。Alchemyの推奨ポリシーであるGas Sponsorshipは、委任されたEOAもカバーでき、その経路ではユーザーオペレーションにペイマスターを載せない。それはバンドラーのポリシーであり、エントリーポイントの変更ではない。

スポンサーするガスをどう制限するか?

制限のないスポンサーシップポリシーは、頼まれたものを何でもカバーする。ポリシーは、バンドラーの前、またはペイマスターコントラクトの前に置く許可と拒否のリストだ。

Gas Managerでは、スポンサーシップのポリシーに次を設定できる。

• 全体の最大支出（USD）
• 送信者ごとの最大支出と、ユーザーオペレーションごとの最大支出
• スポンサーする操作の最大件数（全体と送信者ごと）
• 送信者のallowlistとblocklist
• 開始時刻と終了時刻
• スポンサーシップの有効期限（ミリ秒）。署名済み承認が有効な長さだ

最後の二つは、オンチェーンペイマスターでは別物だ。開始と終了はポリシーを区切る。有効期限は一つのペイマスター署名を区切る。Bundler Sponsored Operationsは、ユーザーオペレーションごとの最大支出を必須にする。バンドラーはその金額まで再送する。この経路では、ペイマスター署名がないので、有効期限はバンドラーがユーザーオペレーションを受理したときに始まる。

支出上限ではないルールには、webhookを付ける。Gas ManagerはあなたのURLを呼び、応答で操作を許可するか拒否する。approveOnFailure は、その呼び出しがエラーになるかタイムアウトしたときの扱いを選ぶ。動かし続けたいなら承認、厳しくしたいなら拒否だ。デフォルトは拒否だ。

ポリシーはダッシュボードで作るか、Gas Manager Admin APIで作る。ERC-20のルールも同じ形で、受け入れるトークンと、回収が実行後かどうかも含む。

Alchemyはどうやってガスをスポンサーするか?

Gas Managerはポリシーを持つ。いつもオンチェーンペイマスターだとは限らない。

推奨のポリシータイプはGas Sponsorshipで、Bundler Sponsored Operationsが支えている。BSOは、バンドラーが eth_sendUserOperation で署名済みユーザーオペレーションを受け取ったときに、そのポリシーを検査する。ユーザーオペレーションはペイマスターフィールドを持たず、呼び出すペイマスターコントラクトもない。Bundlerがガスを負担し、ポリシーのユーザーオペレーションごとの最大支出まで送信を再試行する。Rundlerは、私たちが運用するオープンソースのバンドラーだ。

Onchain Paymasterポリシーは、EVMでのもう一つの選択だ。これは検証型ペイマスターだ。ユーザーが署名する前にペイマスターフィールドを要求し、ユーザーオペレーションはペイマスター署名を載せ、エントリーポイントはペイマスターのデポジットからバンドラーに返済する。

Wallet APIsは、ユーザーオペレーションを手で組み立てるべきでないアプリのために、両方の上に置かれる。BSOのポリシーIDをスマートウォレットクライアントに渡すか、1回の呼び出しに渡す。SDKはその呼び出しをポリシーの下でスポンサーする。EIP-7702の流れでは、wallet_prepareCalls が返すのはユーザーが署名する認可であり、ユーザーオペレーションではない。だから下に書くガスフィールドのゼロ化は、そこには当てはまらない。送信者はスマートアカウントか、スマートアカウントのコードへ委任したEOAだ。wallet_prepareCalls と wallet_sendCalls は、引き続きバッチングとEIP-7702の委任を付ける。

Bundler Sponsored Operationはどう送るか?

タイプをBundler Sponsored OperationsにしたGas Managerポリシーを作り、Max Spend Per UOを設定する。その上限は必須だ。バンドラーはその金額まで再試行する。

低レベルの統合は、署名済みユーザーオペレーションを eth_sendUserOperation で送る。ポリシーIDを x-alchemy-policy-id ヘッダーに入れ、maxFeePerGas、maxPriorityFeePerGas、preVerificationGas をゼロにする。バンドラーはそのゼロを、ガスを埋めて操作をスポンサーする合図として扱う。このポリシーで alchemy_requestGasAndPaymasterAndData を呼んではいけない。BSOのユーザーオペレーションにペイマスターアドレスもペイマスター署名もない。

適格かどうかは、バンドラーが操作を受け取ったときに決まる。ポリシーの上限にすでに達していれば、送信は失敗する。バンドラーが受理したあとでも、操作はスポンサーシップの有効期限の前にバンドルへ入らなければならない。入らなければ、バンドラーはそれを落とす。

オンチェーンペイマスターはいつ使うか?

ユーザーオペレーションがペイマスターコントラクトを指名しなければならないときに、Onchain Paymasterポリシーを使う。ERC-20のガス支払いもこれに含まれる。ユーザーはトークンで払い、ペイマスターはそれでもバンドラーへネイティブトークンで決済する。alchemy_requestGasAndPaymasterAndData かERC-7677の pm_ メソッドでフィールドを要求し、Bundlerで送る。ポリシーはユーザーが署名する前に検査される。ペイマスター署名は期限切れになるので、操作はその窓の内側で送らなければならない。

スポンサーするガスはいくらか?

Gas Manager FAQに公開されているGas Managerの手数料はこうだ。

• テストネットのスポンサーシップは、どのプランでも無料だ。
• 無料プランにメインネットのスポンサーシップは含まれない。
• Pay as you goは、カバーしたメインネットガスに8%を上乗せする。ガスクレジットを買うか上限を手配するまで、常設のメインネット枠はない。
• Enterpriseの手数料と上限は個別だ。

カバーしたガスは月次の請求に加算される。ガスクレジットは一度きりのUSD購入で、その請求に適用され、使い切るまで繰り越す。使用量アラートは、スポンサーシップ上限の50%、75%、90%、100%で請求管理者に届く。スポンサーシップはバッチで承認されるので、忙しいポリシーは上限をわずかに、短時間だけ超えうる。

ERC-20のガス支払いは同じ上限にカウントされる。オンチェーンペイマスターでは、オンチェーンで決済されるのは引き続きネイティブトークンのデポジットだ。Bundler Sponsored Operationsはそのデポジットを使わない。ドキュメントはBSOのガスを、オンチェーンの決済コストに、バンドラーの再試行とより速い取り込みのためのサービス料を足したものとして価格づけしている。

どのネットワークがガススポンサーに対応しているか?

ネットワークの一覧は、チェーンが追加されるたびに変わる。Gas ManagerとBundlerの対応は機能サポート表に従う。Bundler Sponsored Operationsは、Alchemyがガススポンサーを提供するすべてのチェーンで動き、MegaETHは除く。ERC-20のガストークンはポリシーごとに有効にする。ダッシュボードの一覧が上限ではない。Token Prices By Address APIに価格があるとき、または小数桁数が同じ参照トークンを指定したとき、Admin APIでカスタムトークンを追加できる。

デプロイアドレスは、EntryPointのバージョンと新しいネットワークとともに動く。コピーした一覧ではなく、対象ネットワークのGas Managerドキュメントにあるアドレスを使う。

Solanaにペイマスターはあるか?

ERC-4337のものはない。Solanaにエントリーポイントもユーザーオペレーションもない。Gas ManagerはそれでもSolanaの手数料をスポンサーする。alchemy_requestFeePayer が、トランザクションへのfee payer署名と、手数料およびrentの見積もりを返す。プロダクトの仕事は同じで、アプリがネットワーク手数料を払う。仕組みはペイマスターではない。Solanaのトランザクションを validatePaymasterUserOp に向けてはいけない。

バンドラーは悪意のあるペイマスターをどう制限するか?

ペイマスターのストレージは、それを使うバンドル内のすべての操作で共有される。敵対的な validatePaymasterUserOp 一つで、そのバンドルのあとの操作を失敗させられる。これは単一ユーザーに対してではなく、バンドラーに対するサービス拒否だ。

ERC-4337は、レピュテーションスコアとスロットリング、そしてステークで応える。ステークはスラッシュされず、引き出せる。攻撃者が試行のたびに新しいペイマスターを安くデプロイできないようにするためにある。他の操作を無効にし続けるペイマスターを、バンドラーは禁止することもできる。規則はERC-4337のレピュテーションの節にある。

よくある質問

ERC-4337のペイマスターとは?

ペイマスターは、ユーザーオペレーションのガスを払うスマートコントラクトだ。チェーンのネイティブトークンをエントリーポイントに預け、validatePaymasterUserOp で操作を承認し、そのデポジットからバンドラーに返済する。手数料をそのままスポンサーすることも、ユーザーからERC-20トークンを集めて、それでもバンドラーへはネイティブトークンで決済することもできる。

ペイマスターとバンドラーの違いは?

バンドラーはユーザーオペレーションを送り、チェーンへ先に払う。オンチェーンペイマスターはそのコストを負担するかを決め、エントリーポイントを通じてバンドラーに返金する。Bundler Sponsored Operationはペイマスターコントラクトを飛ばす。バンドラーは署名済み操作を受け取ったときにGas Managerのポリシーを検査し、自分でガスを負担する。アプリに要るのはポリシーと、その操作を受け付けるバンドラーだ。ペイマスターコントラクトが要るのはオンチェーンの経路だけで、ERC-20のガス支払いも含まれる。

ユーザーはUSDCでガスを払えるか?

払える。ERC-20ペイマスターはトークン価格を提示し、スマートアカウントからUSDC（または有効な別トークン）を取り、ネイティブガストークンでバンドラーに払う。承認を同じユーザーオペレーションにまとめられるよう、回収は実行後を選ぶ。その転送が失敗すると操作はrevertし、スポンサーはそれでもガスを負担する。

EIP-7702はペイマスターを置き換えたか?

置き換えていない。EIP-7702はEOAがコントラクトコードへ委任できるようにする。ユーザーオペレーションがオンチェーンペイマスターを指名するとき、そのペイマスターはそれでもバンドラーに資金を出す。EntryPoint v0.8は委任を検査する。Alchemyの推奨ポリシーであるGas Sponsorshipは、その委任されたEOAを、ユーザーオペレーション上のペイマスターなしでカバーできる。

Alchemyのガススポンサーはいくらか?

テストネットは無料だ。メインネットのスポンサーシップは無料プランにない。Pay as you goは、クレジットか上限を足したうえで、カバーしたメインネットガスの8%だ。Enterpriseの価格は個別だ。ローンチの予算を組む前に、Gas Manager FAQの現行表を確認する。

ガスのスポンサーはどう始めるか?

アプリがガスをスポンサーするなら、Gas Sponsorshipポリシーを作る。それはBundler Sponsored Operationsを使う。低レベルの呼び出し側は、ポリシーIDを x-alchemy-policy-id ヘッダーで送り、maxFeePerGas、maxPriorityFeePerGas、preVerificationGas をゼロにする。Wallet APIsの呼び出し側は同じポリシーIDを渡し、ペイマスターフィールドは組み立てない。ユーザーオペレーションがペイマスターを指名しなければならないとき、ERC-20ガスを含めて、Onchain Paymasterポリシーと alchemy_requestGasAndPaymasterAndData またはERC-7677の pm_ メソッドを使う。最初に開くのは、BSOガイド、ポリシータイプ、ポリシールールだ。