ERC-4337 dummy signature 與 gas token 轉帳
在ERC-4337 Gas Estimation中，我們討論了 ERC-4337 中 gas 的運作方式，以及我們進行 gas 估算的方法。透過這個方法，我們應該能夠為使用者提供提交 user operation 所需的準確數值。可惜事情並沒有那麼簡單。
讓我們深入探討幾個讓 ERC-4337 gas 估算變得更複雜的問題。
什麼是虛擬（dummy）signature 值？
在大多數智慧合約帳戶的實作中，signature 欄位是在鏈下計算的，方式是對 user operation 進行 hash，再用某種簽章機制（最常見的是 ECDSA）對該 hash 進行簽署。這個 signature 會在驗證階段由帳戶合約在鏈上驗證。
舉例來說，SimpleAccount 使用EIP-191簽章機制對 hash 進行處理，並在其 validateUserOp 函式中透過 OpenZeppelin 的 ECDSA library 在鏈上驗證。
這個 signature 必須在 gas 估算完成之後才能計算，因為那些欄位會被包含在 hash 之中。
然而，gas 估算步驟中有部分需要 signature 欄位已經被填入：preVerificationGas 和 verificationGasLimit 。
preVerificationGas
在本系列第一篇文章討論 preVerificationGas 估算的段落中，我們提到 bundler 用來計算未被計量的 gas 的三種運算方式。
請注意，第 2 步和第 3 步（計算 user op 在 calldata gas 成本中所佔的份額，以及在任何執行 gas overhead 中所佔的份額）都直接取決於 user operation 的長度與內容，包括 signature 欄位。
verificationGasLimit
幾乎所有有實際用途的智慧合約帳戶實作都需要某種形式的 signature 驗證。這個 gas 需要被估算！這個估算過程不能發生 revert，否則就無法計算出 verification gas。
那我們該如何選擇要使用哪個 signature 呢？
如何計算虛擬 signature 值
為了解決這些問題，許多 ERC-4337 bundler 會使用「Dummy Signature」，這個值必須由呼叫 eth\_estimateUserOperationGas 的一方根據特定的帳戶類型提供。
限制條件
這個 dummy signature 有幾項限制：
- dummy 值的長度應等於該帳戶合約中最大的 signature 長度，並且必須包含該帳戶有效的最大數量非零位元組。
a. 這樣可以確保
preVerificationGas的計算能夠涵蓋最差情況下 signature 對 calldata 和 entry point overhead 成本的影響。 - 這個 dummy 值在提供給帳戶的驗證函式時，必須導致最差情況下的 gas 使用量，且不能造成 revert。
- 這個 dummy 值不應該是任何有效 user operation 的合法 signature。
SimpleAccount 的 dummy signature 值範例，可在我們針對 eth_estimateUserOperationGas 方法的文件中找到。
這個 dummy signature 具有以下特性：
- 長度與 ECDSA signature 完全相同
- 包含 ECDSA signature 中允許的最大數量非零位元組
- 它是一個有效的 ECDSA signature（讓
.recover\(\)呼叫不會 revert） - 它不是任何已知 user operation 的 signature，因此
SimpleAccount永遠會回傳SIG\_VALIDATION\_FAILED
帳戶實作者需要確保他們撰寫的驗證函式，能夠接受 dummy signature 作為輸入。
這代表：
- 只對不可能是 dummy signature 的 signature 使用
REVERT。當提供的是 dummy signature 時，回傳SIG\_VALIDATION\_FAILED。 - 注意不要讓 dummy signature 的失敗判斷「提早結束」。也就是說，dummy 值應該完整跑完整個驗證函式，並使用最大量的 gas。
- 實務上，這表示要移除任何提早 return 的邏輯。帳戶驗證函式可能會很早就判斷出 signature 無效，但仍應繼續執行函式邏輯，直到最後才回傳失敗結果。
如何計算虛擬 paymasterAndData 值
上述相同的要求也適用於 gas 估算期間的 paymasterAndData 欄位：對於任何依賴 gas 欄位數值（例如用於計算 signature）的 paymaster 實作，我們都必須解決提供 dummy 值的同樣問題。
限制條件
這個 dummy paymasterAndData 有幾項限制：
- dummy 值的長度應等於最大的
paymasterAndData長度，並且必須包含該帳戶有效的最大數量非零位元組。 a. 這樣可以確保preVerificationGas的計算能夠涵蓋最差情況下paymasterAndData對 calldata 和 entry point overhead 成本的影響。 - 這個 dummy 值在提供給 paymaster 的驗證函式時，必須導致最差情況下的 gas 使用量，且不能造成 revert。
- 這個 dummy 值不應該是任何有效 user operation 的合法
paymasterAndData。
舉例來說，一個依賴於對 user operation hash 進行贊助簽章驗證的 sponsoring paymaster，在估算期間需要提供一個具有上述類似特性的 dummy paymasterAndData 值：
- 這個 dummy 值必須包含一個有效的 paymaster 合約地址
- 針對
preVerificationGas計算所需的最大長度與位元組值 - 當提供給 paymaster 的驗證函式時，必須消耗最大量的 gas，並回傳
SIG\_VALIDATION\_FAILED
Paymaster 實作者需要確保他們撰寫的驗證函式，能夠接受 dummy paymasterAndData 作為輸入。
這代表：
- 只對不可能是 dummy 一部分的資料使用
revert。改為回傳SIG\_VALIDATION\_FAILED。 - 注意不要讓 dummy 的失敗判斷「提早結束」。也就是說，dummy 應該完整跑完整個驗證函式，並使用最大量的 gas。 a. 實務上，這表示要移除任何提早 return 的邏輯。paymaster 驗證函式可能會很早就判斷出 signature 無效，但仍應繼續執行函式邏輯，直到最後才回傳失敗結果。
Gas token 轉帳
verificationGasLimit 的估算必須將驗證階段中任何 token 轉帳的 gas 成本納入考量。許多 user op 在驗證期間會進行 token 轉帳，用來預付 gas 費用，並在操作結束時針對未消耗的 gas 進行退款。
這裡有兩種情況：
- 沒有 Paymaster——這是從 sender 轉帳 ETH 到 entry point 合約。
- 有 Paymaster——這可以是任何形式（在規範允許的規則範圍內），但通常會是從 sender 轉帳 ERC-20 token 到 paymaster。
如果帳戶資金不足會發生什麼事？
如果 maxFeePerGas 被設為非零值，當帳戶沒有足夠的 token 支付費用時，驗證期間的轉帳就會發生 revert。這代表使用者必須先為帳戶注入資金，才能嘗試估算 gas。
一個目前無法實現的理想流程：
- 估算 gas
- 為帳戶注入 gas 所需資金
- 送出 operation
一個可能的解決方式，是告訴使用者在呼叫 eth\_estimateUserOperationGas 時，讓 maxFeePerGas 保持未設定，或設為零。然而，這會導致 gas 成本被設為零，進而讓任何需要進行的 token 轉帳金額也變成零。在許多帳戶／paymaster 類型中，gas 成本為零時會跳過對 transfer 的呼叫。這會導致當使用零值 maxFeePerGas 時，出現 gas 低估的情況。
另一個問題與使用非零 maxFeePerGas，並嘗試採用本系列第一篇文章中「Attempt 3: Binary Search」所定義的二分搜尋估算方法有關。
該方法的第一步，是使用一個最大 gas 值來確認該 operation 是可行的。但 sender 可能沒有足夠的資產能在該最大值下支付 gas，而 bundler 也不一定有足夠的資訊能確定費用 token 的餘額（例如在 ERC-20 paymaster 的情況下），以決定正確的上限值。
Alchemy 的 bundler 如何解決涉及 token 轉帳的 gas 估算問題？
Rundler 針對 eth\_estimateUserOperationGas 所採取的方法如下：
沒有 paymaster 的情況
- Rundler 永遠會忽略
maxFeePerGas和maxPriorityFeePerGas，並將其設為 0。 - Rundler 永遠會在
verificationGasLimit上加上固定的 10K gas，用來涵蓋從 sender 轉帳 ETH 存款給 entry point 的成本。 - 客戶端不需要做任何變更。
💡 第一點與 ERC-4337 規範有所出入，該規範表示「gas limit（與價格）參數是選填的，但若有指定則會被使用」
有 paymaster 的情況
- Rundler 永遠會忽略
maxFeePerGas和maxPriorityFeePerGas，並將其設為 0。 - 如果任何 paymaster 邏輯是根據費用數值來決定是否執行（例如 ERC-20 轉帳的情況），Rundler 的
verificationGasLimit就一定會被低估。 - 使用這類 paymaster 的使用者，必須自行在客戶端考量因非零費用所產生的額外 gas。
舉例來說，如果使用的是一個會在驗證階段執行轉帳的 ERC-20 paymaster，就應該在 eth\_estimateUserOperationGas 回傳的 verificationGasLimit 上，永遠加上固定的 75K gas。這需要客戶端了解自己所呼叫的 paymaster 合約，並事先知道因轉帳而導致的 gas 成本低估情況。
💡 Alchemy 的 aa-sdk 讓 paymaster middleware 能夠相應地調整這個 gas limit。
這對開發者來說代表什麼？
Dummy 值與 token 轉帳的問題，會影響到建構智慧合約帳戶、paymaster 以及帳戶客戶端的開發者。
智慧合約帳戶開發者
智慧合約帳戶開發者需要確保，能夠根據帳戶驗證函式的執行方式，在客戶端始終決定出一個 dummy signature 值。這個 signature 不能造成 revert，並且必須產生最大的 gas 估算值。
Paymaster 開發者
Paymaster 開發者必須確保，能夠根據 paymaster 驗證函式的執行方式，始終決定出一個 dummy paymasterAndData 值。這個值不能造成 revert，並且必須產生最大的 gas 估算值。
💡 Alchemy 在其 sponsoring paymaster 中，透過 alchemy_requestGasAndPaymasterAndData 將 gas 估算流程與模擬流程結合，為使用者簡化了這個問題。
帳戶客戶端開發者
如果帳戶客戶端開發者整合的 paymaster 會在驗證階段執行轉帳（或任何其他依據費用數值而定的邏輯），並且使用 Alchemy 的端點來進行估算，就需要將與該轉帳相關的潛在 gas，加到估算所回傳的 verificationGasLimit 中。
敬請期待後續文章，我們將介紹更多 ERC-4337 gas 估算的複雜之處！
🦀
延伸閱讀
本系列共四篇文章，接下來的文章將探討在 Optimism 與 Arbitrum 等 layer 2 區塊鏈上估算 gas 的挑戰，以及 signature aggregator 的相關議題。
本系列將以 user operation 費用估算流程的完整說明作結。如果你錯過了第一篇文章，可以先了解 ERC-4337 gas 估算的運作方式！
Alchemy 電子報
搶先掌握最新發布消息
訂閱我們的電子報
取得 Alchemy 最新產品更新與資源
輸入您的電子郵件地址，即表示您同意接收我們的行銷通訊與產品更新。您了解 Alchemy 會依照我們的隱私權聲明處理所收到的資訊。您可以隨時取消訂閱。
