ERC-4337のダミー署名とガストークン転送

ERC-4337 Gas Estimationでは、ERC-4337でガスがどのように機能するか、そして我々のガス見積もり手法について解説した。この手法により、ユーザーがuser operationを送信する際に正確な値を提供できるはずだ。しかし、それほど単純ではない。

ここでは、ERC-4337のガス見積もりを複雑にする他のいくつかの問題を見ていく。

ダミーsignature値とは何か

ほとんどのスマートコントラクトアカウント実装では、signatureフィールドはuser operationをハッシュ化し、そのハッシュを何らかの署名方式（最も一般的なのはECDSA）で署名することでオフチェーンで計算される。この署名は、検証フェーズにおいてアカウントコントラクトによってオンチェーンで検証される。

例えば、SimpleAccountはEIP-191署名方式を使用しており、OpenZeppelinのECDSA libraryを用いてvalidateUserOp関数内でオンチェーン検証されるハッシュに対して署名を行う。

この署名はガス見積もり後に計算されなければならない。なぜなら、それらのフィールドはハッシュに含まれるからだ。

しかし、ガス見積もりのステップの中にはsignatureフィールドが埋まっていることを要求する部分がある：preVerificationGasとverificationGasLimit である。

preVerificationGas

本シリーズのpart oneにあるpreVerificationGas見積もりのセクションで、bundlerが計測不能なガスを計上するために使う3つの計算について解説した。

ステップ2と3（user opのcalldataガスコストに占める割合の計算と、実行ガスオーバーヘッドに占めるuser opの割合の計算）は、いずれもuser operationの長さと内容に直接依存しており、signatureフィールドもこれに含まれる点に注意してほしい。

verificationGasLimit

有用なスマートコントラクトアカウント実装のほぼすべてが何らかの署名検証を必要とする。このガスは見積もる必要がある。この見積もりプロセスはrevertしてはならず、そうでなければverification gasを実装できない。

どの署名を使うべきかをどうやって選ぶのか？

ダミーsignature値の計算方法

これらの問題を解決するため、多くのERC-4337 bundlerは、アカウントの種類に応じてeth\_estimateUserOperationGasの呼び出し元が提供する必要がある「Dummy Signature」を使用する。

制約

このダミー署名にはいくつかの制約がある：

1. ダミー値の長さは最大署名長と等しくなければならず、そのアカウントで有効な非ゼロバイト数の最大数を含まなければならない。 a. これにより、preVerificationGasの計算がcalldataへの寄与とentry pointのオーバーヘッドコストについて最悪ケースの署名を考慮できるようになる。
2. ダミー値は、アカウントのvalidation関数に渡された際に最悪ケースのガス使用量を引き起こさなければならず、revertを引き起こしてはならない。
3. ダミー値は、いかなる有効なuser operationに対しても有効な署名であってはならない。

SimpleAccount用のダミーsignature値は、eth_estimateUserOperationGasメソッドに関する我々のドキュメントに記載されている。

このダミー署名は以下の特性を持つ：

1. ECDSA署名の正確な長さである
2. ECDSA署名で許容される非ゼロバイト数の最大数を持つ
3. 有効なECDSA署名である（そのため.recover\(\)の呼び出しがrevertしない）
4. 既知のuser operationに対する署名ではないため、SimpleAccountは常にSIG\_VALIDATION\_FAILEDを返す

アカウント実装者は、ダミー署名を供給できるようにvalidation関数を書く必要がある。

これは以下を意味する：

1. ダミー署名になり得ない署名に対してのみREVERTを使用する。ダミー署名が供給された場合はSIG\_VALIDATION\_FAILEDを返す。
2. ダミー署名に対する失敗の「ショートサーキット」を起こさないよう注意する。つまり、ダミー値はvalidation関数全体を通過し、最大量のガスを使用するべきである。
3. 実際には、これは早期returnを取り除くことを意味する。アカウントのvalidation関数が署名が無効であることを早期に判断することはあり得るが、関数のロジックは最後まで実行し続け、最後に失敗を返すべきである。

ダミーpaymasterAndData値の計算方法

上記と同じ要件が、ガス見積もり中のpaymasterAndDataフィールドにも適用される：ガスフィールドの値に依存するpaymaster実装（署名の計算などのために）であれば、ダミー値を供給するという同じ問題を解決しなければならない。

制約

このダミーpaymasterAndDataにはいくつかの制約がある：

1. ダミー値の長さは最大paymasterAndData長と等しくなければならず、そのアカウントで有効な非ゼロバイト数の最大数を含まなければならない。 a. これにより、preVerificationGasの計算がcalldataへの寄与とentry pointのオーバーヘッドコストについて最悪ケースのpaymasterAndDataを考慮できるようになる。
2. ダミー値は、paymasterのvalidation関数に渡された際に最悪ケースのガス使用量を引き起こさなければならず、revertを引き起こしてはならない。
3. ダミー値は、いかなる有効なuser operationに対しても有効なpaymasterAndDataであってはならない。

例えば、user operationハッシュに対するスポンサーシップ署名の検証に依存するsponsoring paymasterは、見積もり時に上記と同様の特性を持つダミーpaymasterAndData値を供給する必要がある：

1. ダミー値は有効なpaymasterコントラクトアドレスを含まなければならない
2. preVerificationGasの計算のための最大長と最大バイト値
3. paymasterのvalidation関数に渡された際、最大ガスを消費し、SIG\_VALIDATION\_FAILEDのreturn値をもたらさなければならない

Paymaster実装者は、ダミーpaymasterAndDataを供給できるようにvalidation関数を書く必要がある。

これは以下を意味する：

1. ダミーの一部になり得ないデータに対してのみrevertを使用する。代わりに SIG\_VALIDATION\_FAILEDを返す。
2. ダミーに対する失敗の「ショートサーキット」を起こさないよう注意する。つまり、ダミーはvalidation関数全体を通過し、最大量のガスを使用するべきである。 a. 実際には、これは早期returnを取り除くことを意味する。paymasterのvalidation関数が署名が無効であることを早期に判断することはあり得るが、関数のロジックは最後まで実行し続け、最後に失敗を返すべきである。

ガストークンの転送

verificationGasLimitの見積もりでは、検証フェーズ中のトークン転送のガスコストを考慮しなければならない。多くのuser opは、ガスの前払いのためにトークン転送を行い、操作の最後に消費されなかったガス分の返金を行う。

これには2つのケースがある：

1. Paymasterなし - senderからentry pointコントラクトへのETH転送となる。
2. Paymasterあり - 仕様の許容範囲内であれば何でもよいが、多くの場合senderからpaymasterへのERC-20トークン転送の形をとる。

アカウントに十分な資金がない場合どうなるか

maxFeePerGasが非ゼロ値に設定されている場合、アカウントが手数料を支払うのに十分なトークンを保有していなければ、検証中の転送はrevertする。つまり、ユーザーはガス見積もりを試みる前にアカウントに資金を入れておかなければならないということだ。

現時点では実現できない望ましいワークフロー：

1. ガスを見積もる
2. ガス用にアカウントに資金を入れる
3. operationを送信する

ここでの解決策の一つは、eth\_estimateUserOperationGas呼び出し時にmaxFeePerGasを未設定のまま、またはゼロに設定するようユーザーに伝えることだ。しかし、これによりガスコストがゼロになり、発生すべきトークン転送の値もゼロになってしまう。多くのアカウント/paymasterの種類では、ガスコストがゼロだとtransferへの呼び出しがスキップされる。これにより、ゼロのmaxFeePerGasが使われた場合にガスの過小見積もりが発生する。

もう一つの問題は、非ゼロのmaxFeePerGasを使用し、本シリーズpart 1の「Attempt 3: Binary Search」で定義されたbinary search見積もりアプローチを試みることに関係する。

そのアプローチの最初のステップは、最大ガス値を使用してoperationが可能であることを確認することだ。senderはその最大値でガスを支払うのに十分な資産を持っていない可能性があり、bundlerは手数料トークン（ERC-20 paymasterのケースなど）の残高を判断するのに十分な情報を常に持っているわけではないため、正しい上限を決定できない。

Alchemyのbundlerはトークン転送を伴うガス見積もりをどう解決しているか

eth\_estimateUserOperationGasに対してRundlerが採用しているアプローチは以下の通りだ：

Paymasterなしのケース

• RundlerはmaxFeePerGasとmaxPriorityFeePerGasを常に無視し、0に設定する。
• Rundlerは、senderからentry pointへのETHデポジット転送を考慮するため、verificationGasLimitに常に10Kガスを静的に加算する。
• クライアント側の変更は不要である。

Paymasterありのケース

• RundlerはmaxFeePerGasとmaxPriorityFeePerGasを常に無視し、0に設定する。
• paymasterのロジックが手数料の値に対して条件付きである場合（ERC-20転送のように）、RundlerのverificationGasLimitは常に過小見積もりとなる
• これらのpaymasterのユーザーは、非ゼロの手数料によって発生する追加のガスをクライアント側で考慮する必要がある。

例えば、検証フェーズ中に転送を行うERC-20 paymasterを使用している場合、eth\_estimateUserOperationGasからのverificationGasLimitのreturn値に常に75Kガスを静的に加算する。これには、クライアントが呼び出し先のpaymasterコントラクトを認識しており、転送によるガスコストの過小見積もりについて事前知識を持っていることが必要となる。

これは開発者にとって何を意味するか

ダミー値とトークン転送の問題は、スマートコントラクトアカウント、paymaster、アカウントクライアントを構築する開発者に影響を与える。

スマートコントラクトアカウント開発者

スマートコントラクトアカウント開発者は、アカウントのvalidation関数がどのように動作するかに基づいて、ダミー署名値が常にクライアント側で決定可能であることを確保する必要がある。この署名はrevertを引き起こしてはならず、最大のガス見積もりをもたらさなければならない。

Paymaster開発者

Paymaster開発者は、paymasterのvalidation関数がどのように動作するかに基づいて、ダミーpaymasterAndData値が常に決定可能であることを確保しなければならない。この値はrevertを引き起こしてはならず、最大のガス見積もりをもたらさなければならない。

アカウントクライアント開発者

検証フェーズ中に転送を行う（あるいは手数料の値に基づく他のロジックを持つ）paymasterと統合しており、見積もりにAlchemyのエンドポイントを使用しているアカウントクライアント開発者は、見積もりによって返されるverificationGasLimitに、その転送に伴う潜在的なガスを加算する必要がある。

ERC-4337ガス見積もりの他の複雑な問題について解説する後続の記事にご期待いただきたい！

🦀

続きを読む

この4部構成シリーズの次の記事では、OptimismやArbitrumのようなlayer 2ブロックチェーン上でのガス見積もりの課題と、signature aggregatorについて解説する。

シリーズの締めくくりとして、user operationの手数料見積もりプロセスの解説を行う。part oneを見逃した方は、ERC-4337ガス見積もりの仕組みについて学んでほしい！

• How ERC-4337 Gas Estimation Works
• L2 Gas and Signature Aggregators
• User Operation Fee Estimation