什麼是 User Operations?

發布於 2023年6月26日閱讀時間 2 分鐘

使用者操作（User operations）是包含交易細節的物件，會代表發送者的智能合約帳戶執行。使用者操作是一種偽交易物件，讓 Account Abstraction 得以運作，而不需要對 Ethereum 及支援 ERC-4337 的第二層區塊鏈進行共識層變更。

無論是要開發智能合約錢包（SCWs），或是要讓去中心化應用程式相容於 SCWs，了解定義使用者操作的參數、使用者操作欄位在建構過程中如何被填入、使用者操作如何被 bundler 打包，以及如何由 paymaster 驗證與執行，都會很有幫助。

透過我們的 Embedded Accounts 與帳戶抽象基礎設施，讓新使用者可以建立內嵌電子郵件與 passkey 錢包！

觀看：以 Solidity 建構並執行使用者操作

使用者操作包含哪些欄位？

使用者操作（UOs）包含與一般交易相似的欄位（例如 sender、to、calldata、maxFeePerGas、maxPriorityFee、signature 與 nonce），但也有幾個專屬於使用者操作結構的新欄位，包括 callGasLimit、verificationGasLimit、preVerificationGas，以及 paymasterAndData。

UO 欄位的定義可以在官方 ERC-4337 規格文件中找到。以下是簡要說明：

callGasLimit - 主執行呼叫要使用的 gas
verificationGasLimit - 完成驗證步驟要使用的 gas
preVerificationGas - 支付給 bundler，用以涵蓋預驗證執行與 calldata 成本的 gas
paymasterAndData - 贊助的 paymaster 位址，以及要傳送給 paymaster 的資料

Alchemy AA 基礎設施團隊工程師 David Philipson 撰寫的「You Could Invented Account Abstraction」系列文章第一部分，說明了使用者操作的設計與架構。

接下來，讓我們了解正確填入使用者操作各欄位的標準流程。

傳送使用者操作的流程是什麼？

將使用者操作（user op）傳送給 bundler 的典型流程包含多個步驟：

建構部分填入的使用者操作，填入 sender、nonce、initCode 與 callData
透過 eth_estimateUserOperationGas 向 bundler RPC 估算部分使用者操作的 gas
填入 preVerificationGas、verificationGasLimit、callGasLimit
若使用的 paymaster 不依賴使用者操作的內容（例如 ERC20 paymaster），可以在此步驟填入 paymasterAndData。
估算此操作所需的 gas 費用，並填入 maxFeePerGas 與 maxPriorityFeePerGas
（選用）將使用者操作傳送給贊助的 paymaster 進行簽署，並填入 paymasterAndData
這個步驟必須在此時完成，因為 paymaster 的簽章需要上述所有欄位都已填入。
簽署使用者操作，填入 signature，並透過 eth_sendUserOperation 將使用者操作傳送給 bundler

雖然開發者可以使用原生的 ethers.js 取得每個使用者操作欄位的值，但也有一些 web3 開發工具可以讓 UO 的建構更容易。

開發者可以使用什麼工具來建構使用者操作？

像是 Alchemy 開源的 AA SDK 這類使用者操作建構工具，比起使用原生 ethers.js 製作使用者操作更加容易。

Alchemy 的 AA SDK

Alchemy 的 AA SDK 是以 viem 建構的，提供開發者輕量化的套件。GitHub 上的 aa-sdk 也透過 aa-ethers 函式庫支援 ethers.js 的 signers 與 providers。

使用 aa-sdk 建構使用者操作的主要好處之一，是它提供兩個實用方法：

sendUserOperation - 處理 gas 估算、請求 paymasterAndData、簽署等等
sendTransaction - 將交易物件資料（from、to、data 與 value）轉換為使用者操作

建構使用者操作的操作順序相當複雜，而 Alchemy 的 AA-SDK 透過執行一連串的操作來簡化 UO 的建構：先以 getDummyPaymasterData，再以 estimateGas 估算 gas，接著執行 getFeeData，最後執行 getPaymasterAndData。

在取得使用者操作各欄位的值之後，它會使用 target、callData 與選用的 value 來建構並簽署使用者操作。接著它會將使用者操作傳送給 bundler，並取得該使用者操作的雜湊值。

如果你想使用 Alchemy 的 paymaster、其他 paymaster，或是打算為自己的 SmartAccounts 加入支援，請閱讀 Alchemy AA SDK 文件，其中有完整說明如何輕鬆建立 UOs。

使用者操作如何被加入使用者操作記憶體池（mempool）？

在使用者操作被加入 mempool 之前，必須先通過一系列檢查，以確認它符合 ERC-4337 規格中所定義的預期行為。使用者操作也必須通過驗證模擬檢查，以確認它是有效的，並且能夠支付其 gas 費用（無論是透過發送者的錢包，還是透過 paymaster 的贊助政策）。

1. 檢查使用者操作的有效性

初步的一系列檢查說明於 ERC-4337 規格中的「Client behavior upon receiving a UserOperation」章節，以下為摘要：

發送者必須是既有的合約，或是 initCode（用於建立合約）不為空（但兩者不可同時成立）
若 initCode 不為空（因為此使用者操作會建立帳戶），則需判斷該 factory 是否已質押
verificationGasLimit 必須足夠低（小於或等於 MAX_VERIFICATION_GAS）
preVerificationGas 必須足夠高，以支付 calldata gas 及額外的 overhead gas 費用
paymasterAndData 必須為空，或以 paymaster 位址開頭
若存在 paymaster，其在鏈上必須有非空的程式碼、有資金可支付此使用者操作，且未被禁止使用
callgas 至少要等於一筆非零數值的 CALL 所需的成本
maxFeePerGas 與 maxPriorityFeePerGas 必須高於客戶端可接受的最低值
發送者在池中沒有其他的使用者操作（或此使用者操作是為了取代既有項目而建構的）

有許多規則會影響這些檢查，詳細內容都在規格文件中有完整說明。

在這篇使用者操作的入門介紹中，我們的目的只是傳達用來判斷使用者操作有效性的高層次檢查。

2. 模擬使用者操作

一旦使用者操作通過這些基本檢查，客戶端就需要模擬該使用者操作，以驗證它是否有能力支付其執行成本，無論是使用自己的資金還是透過 paymaster。

為了模擬使用者操作，bundler 會呼叫 simulateValidation() 方法，該方法接著會呼叫發送者帳戶上的 validateUserOp 函式；若將由 paymaster 贊助執行此使用者操作所需的 gas 費用，則會呼叫 paymaster 合約帳戶上的 validatePaymasterUserOp。

呼叫 simulateValidation() 方法之後，它會以 ValidationResult 回應進行 revert。此函式被 revert 是預期中的行為，這被視為成功的結果。

如果 ValidationResult 以不同的錯誤進行 revert，代表該使用者操作未通過驗證模擬，因此不會被加入 mempool。若使用者操作回傳 sigFail，則會被排除於 mempool 之外；此外，若 validUntil 回應已過期，UO 也可能會被排除於 mempool 之外。

注意： 如果使用者操作中存在 initCode，帳戶工廠（account factory）將會建立一個帳戶，接著模擬程序將會使用這個新建立的帳戶繼續進行。

現在使用者操作已經完成建構、檢查、模擬，並加入 mempool，接下來就可以將它傳送給入口點（entry point）合約進行驗證與執行了！