zkSync中的原生Account Abstraction介紹

作者：Written by ChiHaoLu，imToken Labs

本文主要介紹了zkSync這個Layer2解決方案中抽象賬戶（AA、抽象帳戶）的發展及相關內容。重點將放在三個部分：

• 帳戶合約：帳戶類型，帳戶合約的重要入口點和相關重點

• 交易：AA交易的驗證方式和執行方式、流程

• 手續費：交易手續費、Paymaster

目錄

• 導言

• zkSync AA合約簡要概覽

• zkSync時代的費用模型和Paymaster

• 總結與比較

• 結束語

背景

• 熟悉智能合約錢包及其常見特性

• 大致了解以太坊交易的運作方式

• 大致了解EIP-4337的運作模式

• 大致了解ZK（有效性）Rollup的運作模式

• Quick Look at the zkSync

這里為了方便閱讀，不需要深入理解zkSync，簡要回顧一下zkSync的基本信息。 zkSync主要有兩個版本，1.0版（zkSync Lite）和2.0版（zkSync Era）。

zkSync 1.0版僅支持EOA（外部賬戶）且不支持智能合約（僅支持代幣轉賬和交換），而zkSync 2.0，即zkSync Era，屬於原生AA（抽象賬戶）（所有賬戶類型都是合約，沒有EOA ，即以太坊中的EOA和合約賬戶的區別），同時兼容EVM（以太坊虛擬機），支持使用Rust、Yul、Vyper、Solidity等開發智能合約。

下文提到的zkSync若無特別指稱，均指的是zkSync 2.0，即zkSync Era。

在zkSync Era中，還存在多個System Contract，可以理解為它們將zkSync的一些重要操作系統功能實現在智能合約中。這些System Contract都是預編譯合約，從未被部署（直接在節點中運行），但它們都有一個正式地址。

執行AA協議時，zkSync會通過一些System Contract來進行邏輯運算和判斷，例如在驗證nonce時，是由NonceHolder來判斷，而執行抽象賬戶機制和收取手續費是由bootloader來判斷，下文會逐一介紹它們。

Recap Account Abstraction

賬戶抽象的核心概念可以總結為兩個關鍵點：簽名抽象和支付抽象。

簽名抽象的目標是使各種賬戶合約能夠使用不同的驗證方案。這意味著用戶不受限於只能使用特定曲線的數字簽名算法，而可以選擇任何他們喜好的驗證機制。

而支付抽象旨在為用戶提供多種交易支付選項。例如，可以使用ERC-20代幣進行支付，而不是使用原生代幣，或者可以由第三方贊助交易，甚至是其他更特別的支付模式。

zkSync 2.0中的賬戶可以像EOA一樣發起交易，但也可以利用其可編程性來實現任意邏輯，如合約賬戶。這就是我們所謂的帳戶抽象（Account Abstraction），它融合了以太坊中兩種賬戶類型的優勢，使AA賬戶的使用體驗更加靈活，從而實現了上述兩種目標：簽名抽象和支付抽象。

zkSync Era中的AA機制

在zkSync Era中，zkSync AA的最重要角色是bootloader，它是一個System Contract，主要用於處理交易以及執行AA機制，對應於EIP-4337的EntryPoint Contract。 bootloader無法被用戶調用（只能由Operator觸發），也從未被部署（直接在節點上運行），但它具有一個正式地址（可用於收款）。

Operator是ZK Rollup中的重要角色，是中心化的Off-Chain Server，與可能見過的Sequencer類似，負責從外部觸發bootloader等System Contract。

原生的帳戶抽象協議（例如StarkNet、zkSync）基本上都是參考EIP-4337進行設計，zkSync的實現中，用戶會將交易發送給Operator，Operator會將交易發送給bootloader，並開始一系列的處理。

從區塊的角度來看：

當bootloader接收到來自Operator的輸入時，bootloader會首先為該區塊定義一些環境變量（如燃氣價格、區塊號、區塊時間戳等）。然後，bootloader會順序讀取交易列表，首先查詢該帳戶合約是否同意該交易（即AA機制中的調用validate function），然後將它們放入區塊中。

每筆交易驗證通過後，Operator會驗證該區塊是否足夠大，以便發送給驗證者（或是否超時）。如果足夠大或超時，Operator會關閉該區塊，停止向bootloader添加新交易，並完成交易執行。

從交易的角度來看，當Operator觸發bootloader後，bootloader會順序處理每筆交易：

1. 確認用戶帳戶合約地址對應的nonce是否合法

2. 調用用戶帳戶合約上的validate function進行驗證

3. 驗證通過後，帳戶合約會將gas fee匯入bootloader的地址（或通過Paymaster，後文會介紹），bootloader會檢查自己是否收到足夠的款項。

4. 調用用戶帳戶合約上的execute function執行交易。

以上的前三步對應著EIP-4337的驗證循環（Verification Loop），第四步則對應著EIP-4337的執行循環（Execution Loop）。

這裡主要進行了一個概述性的介紹，每一步的細節和角色將在接下來的詳細說明中逐一闡述。

zkSync 抽象帳戶合約快速概覽

Nonce

zkSync 的賬戶nonce 被記錄在一個名為NonceHolder 的系統合約中，通過映射（mapping）的方式記住每組(account_address, nonce) 對是否被使用，用以判斷nonce 是否合法。

根據前文所述，在Operator 觸發bootloader 後的第一步是檢查nonce。因此，在每筆交易開始之前，NonceHolder 將用於確認當前使用的這組nonce 是否合法（目前僅檢查是否已使用）。如果nonce 合法，將進入驗證階段（Verification Phase），此時nonce 將被標記為已使用；如果不合法，則交易（驗證）將失敗。

關於zkSync 當前nonce 的重點：

儘管當前用戶可以同時向賬戶發送具有不同nonce 的多筆交易進行執行，但由於zkSync 不支持並行處理，因此不同nonce 的交易仍將按順序進行處理。

理論上，用戶可以使用任何256 位的非零整數作為nonce，但zkSync 仍建議使用incrementNonceIfEquals 作為管理nonce 的方式，以確保它是按順序遞增的（目前zkSync 的AA 機制僅確認未使用過的nonce，但官方文件表示未來可能會要求順序遞增）。

賬戶合約

在zkSync 中的賬戶合約有以下四個必要的入口點（Entry Point），分別是：

• validateTransaction：在驗證階段被調用，以確認此次操作是否經過賬戶所有者的授權，用戶可以在這裡定制自己的驗證邏輯（例如各種簽名算法、多籤等）。

• payForTransaction：當交易手續費由該賬戶支付（而不是使用paymaster）時，操作員將調用此函數向bootloader 地址支付至少tx.gasprice * tx.gaslimit 的ETH。

• prepareForPaymaster：當交易手續費將由Paymaster 支付時，操作員將調用此函數以完成與paymaster 的交互前準備工作。 zkSync 提供的示例是批准Paymaster 的ERC-20 代幣。

• executeTransaction：在驗證階段成功通過且成功收取手續費後，此函數將用於執行用戶希望實現的操作（例如與合約互動、匯款等行為）。

關於Paymaster、手續費數量（tx.gasprice * tx.gaslimit）等內容將在後續章節中解釋。

在zkSync的賬戶中還有一個非必需的保險函數executeTransactionFromOutside。當無法執行操作時（例如序列生成器沒有響應或發現zkSync存在監管風險時），可以使用“逃跑機制”將資金提取到L1。這部分與AA協議沒有太大的關係，因此不會在此詳細描述，有興趣的人可以查看官方文件和zkSync的規範。

驗證函數的要點和限制

在validateTransaction函數中，可以實現各種定制邏輯，例如如果賬戶已經實現了EIP-1271標準，可以直接將EIP-1271中的驗證邏輯套用在validateTransaction中，或者參考zkSync官方文檔中的多簽名賬戶合約實現。

同時，在EIP-4337的Verification Phase中為了避免DoS威脅，有一些限制（不能涉及外部的操作碼以及有限的深度等），在zkSync中也有類似的限制，例如：

1.合約邏輯只能觸及自己的槽位（如果賬戶合約的地址為A）：

– 屬於地址A的槽位

– 任何其他地址的槽位A

– 任何其他地址的槽位keccak256(A||X)，即可以直接使用地址作為映射的鍵（例如映射(address=>value)），也等同於允許訪問槽位keccak256(A||X)，以實現擴展。例如ERC-20上的代幣餘額。

2.合約邏輯不得使用全局變量，例如block.number

執行函數的要點和限制

在executeTransaction函數中需要注意的是，如果要執行系統調用（System Call），需要確保具有isSystem標誌。因為這些系統合約對賬戶系統的影響非常大，例如增加nonce的唯一方式是與NonceHolder互動，要部署合約必須與ContractDeployer互動，使用isSystem標誌可以確保賬戶開發者有意識地與系統合約互動。

然而，建議在實現時可以使用zkSync提供的SystemContractsCaller庫，以避免自己處理isSystem標誌，並使用其中的systemCallWithPropagatedRevert完成系統調用。

上述代碼示例中涉及與`DEPLOYER_SYSTEM_CONTRACT`進行交互。帳戶開發者最常遇到的系統合約情況是我們要使用帳戶來部署一個合約，此時必須與`ContractDeployer`這個系統合約進行交互。在這種情況下，帳戶開發者需要與`ContractDeployer`合約進行通信，以確保成功部署合約並執行所需的操作。

zkSync時代的費用模型和Paymaster

費用和Gas 限額

zkSync的費用模型與以太坊非常相似，費用代幣仍然是ETH。然而，除了基本的計算和寫入槽位成本外，與其他Layer2解決方案（如Arbitrum、Optimism）一樣，zkSync還需要考慮發佈到L1的額外成本（安全費用）。由於發布數據到L1上的燃氣價格非常不穩定，因此在每個區塊開啟（開始記錄交易）時，zkSync的Operator會定義以下動態參數：

– gasPrice：以gwei為單位的燃氣價格，即前文提到的交易對像中的tx.gasprice

– gasPerPubdata：在以太坊上發布一個字節的數據所需的燃氣數量

此外，與EIP-4337不同，zkSync不需要定義三種燃氣限制：verificationGas、executionGas和preVerificationGas，而只需要一個gasLimit來包含以上所有費用成本，因此用戶需要確保gasLimit足夠涵蓋Verification階段、Execution階段以及上傳數據到L1的安全費用等所有費用成本。這個費用成本包含在前文提到的交易對像中的tx.gaslimit。

將這兩者相乘（tx.gasprice * tx.gaslimit）就可以得到這筆交易支付給bootloader的手續費數量。

Paymaster

Paymaster主要在用戶交易支付手續費階段，代替用戶的帳戶合約向bootloader支付ETH。用戶可以選擇不同的Paymaster和支付模式來支付手續費，例如（但不限於）：

– 在交易發起前或交易執行後向Paymaster支付ERC-20代幣

– 使用信用卡向Paymaster合約充值

– Paymaster將持續為用戶免費支付部分或全部手續費

用戶與Paymaster互動的方式取決於不同的協議，可以是中心化也可以是去中心化；可以在交易前，也可以在交易後；可以使用ERC-20代幣也可以使用法定貨幣，甚至可以是免費的。

zkSync的Paymaster合約主要由兩個函數組成，分別是validateAndPayForPaymasterTransaction（必需）和postTransaction（可選），兩者都只能被bootloader調用：

– validateAndPayForPaymasterTransaction是整個Paymaster合約中唯一必須實現的函數。當操作員收到的交易附帶Paymaster參數時，表示手續費不由用戶的帳戶合約支付，而是由Paymaster支付。此時，操作員將調用validateAndPayForPaymasterTransaction來判斷該Paymaster是否願意支付這筆交易的手續費。如果Paymaster同意，該函數將向bootloader發送至少tx.gasprice * tx.gaslimit的ETH。

– postTransaction是一個可選函數，通常用於退款（將未使用完的燃氣退還給發件人）。然而，當前的zkSync尚不支持此操作。

zkSync中的Paymaster在實現了postTransaction後才會執行postTransaction，這一點與EIP-4337不同，EIP-4337在validatePaymasterUserOp沒有返回上下文時不會調用postOp，反之亦然。

綜合以上，舉例來說用戶現在想要發送一筆手續費由Paymaster 支付的交易，那流程如下：

1. 藉由NonceHolder 確認nonce 是否合法

2. 呼叫用戶Account Contract 上的validateTransaction 進行驗證，確認交易由帳戶擁有者授權

3. 呼叫用戶Account Contract 上的prepareForPaymaster，裡面可能會執行例如approve 一定數量的ERC-20 Token 給Paymaster 或是不做任何事

4. 呼叫Paymaster Contract 上的validateAndPayForPaymasterTransaction 確認Paymaster 願意支付並且收取手續費，同時Paymaster 向用戶收取一定數量的ERC-20（前面approve 的）

5. 確認bootloader 收到正確數量（至少tx.gasprice * tx.gaslimit）的ETH 手續費

6. 呼叫用戶Account Contract 上的executeTransaction 執行用戶想要的交易

7. 如果Paymaster Contract 有實作postTransaction 且gas 仍然足夠（沒有out of gas error），那就執行postTransaction

最後一步即便out of gas error 導致不能執行postTransaction，這筆AA 交易也算是成功，只是省略掉呼叫postTransaction 的動作而已。

更深入探究zkSync 的Paymaster 會發現它的Verification Rules 和4337 稍有不同（zkSync Paymaster 可以踩任何其他合約的slot）、同時也有各種不同的type（例如Approval-based），這部分由於比較細節所以有興趣深入的人可以參考官方文件或我之前的實作。

Summary & Comparison

通過前文的解釋，我們已經了解了賬戶合約具有哪些重要的入口點，以及它們的作用和相關限制。同時，我們也了解了系統合約的功能。接下來，讓我們對在zkSync 中一個自動操作（AA）交易從構建到完成的過程進行總結，同時我也會提供更詳細的參考資料，以供那些希望深入了解的人參考：

1. 用戶在本地使用SDK 或錢包構建交易對象（例如：from、to、data、value等）。

2. 用戶對該交易進行簽名。這裡的簽名不一定是傳統的EIP-712 格式和ECDSA 曲線簽名。 zkSync 還支持EIP-2718 和EIP-1559，選擇簽名方式和驗證方式的關鍵在於通過帳戶合約中的驗證函數進行驗證。

3. 將已簽名的交易通過RPC API 發送給操作員（Operator）。此時交易進入待處理狀態。操作員將交易傳遞給bootloader（調用bootloader 合約上的processL2Tx 函數），開始一系列的AA 協議流程。

4. Bootloader 會檢查Nonce 是否合法，使用NonceHolder 進行檢查。

5. Bootloader 會調用用戶賬戶合約上的validateTransaction 函數，以確認此交易已獲得帳戶所有者的授權。

6. Bootloader 收取手續費有兩種方式，具體收費方式取決於交易參數（構建交易對象時是否附帶paymaster 參數）：

a. 調用payForTransaction 函數與賬戶合約收取手續費；

b. 調用prepareForPaymaster 和validateAndPayForPaymasterTransaction 函數與Paymaster 合約收取手續費。

7.「呼叫payForTransaction 來跟Account 合約手續費」或者「呼叫prepareForPaymaster 和validateAndPayForPaymasterTransaction 來跟Paymaster 合約手續費」

8. 檢查bootloader 是否已收到至少tx.gasprice * tx.gaslimit 數量的交易手續費。

9. Bootloader 會調用用戶賬戶合約上的executeTransaction 函數來執行交易。

10. （可選）如果使用Paymaster 支付手續費，bootloader 會調用postTransaction 函數。如果Paymaster 沒有實現postTransaction，或者gas 已耗盡，將跳過此步驟。

以上的4.~7.步為驗證階段（定義在bootloader的l2TxValidation），第8.~9.步執行階段（定義在bootloader 的l2TxExecution）。

EIP-4337、StarkNet 和zkSync 時代的比較

基本上這三者的AA機制流程都相仿，皆為驗證階段→手續費機制（由賬戶合約支付或者Paymaster）→執行階段，主要差別有：

• 執行AA 機制的角色是：在zkSync 時代中開啟與其他兩者AA 的差別在於Operator 需要和bootloader（系統合約）一起配合，例如bootloader 會開啟一個新區塊並定義該區塊的相關參數，接收操作員發送來的交易者並進行驗證。在4337 中這部分由Bundler 與EntryPoint 協作，而在StarkNet 中這部分全部由Sequencer 負責。

• Gas Cost 是否需要考量到L1 安全費用：L2 的AA 都需要考慮這個上傳數據到L1 的費用，不只是推送提到的ZK（Validity）Rollups Native AA，在Optimistic Rollups 實作4337 時也需要算入L1安全費用（計算在preVerificationGas 中，細節可見Alchemy 相關文件）。

• 是否可以在賬戶合約部署前發送出交易：在StarkNet 和zkSync 時代中都沒有像4337 的EntryPoint 有initCode 這個字段允許替用戶部署賬戶合約，所以其都不在可以配置賬戶前發送出交易。

對比

由於StarkNet尚無已實現的Paymaster機制、zkSync也尚未完成gas退款機制的設計，所以一些比較細節的比較在這裡就沒有列出。

另外，目前的4337 bundler我們完成了P2P mempool，且zkRollups 的Sequencer 和Operator 也還是唯一的官方服務器，所以都有一定中心化的成分存在。

在開發流程上zkSync 由於沒有與各家bundler串接的問題（只需要與Operator API 交互），所以使用起來4337 很容易，開發帳戶合約（SDK）的體驗也更好；同時zkSync 可以使用Solidity作為合約開發語言，所以也不需要在StarkNet 開發中跨過Cairo的門檻。

結語

由於StarkNet 和zkSync 都屬於本地AA（Native AA）的範疇，因此你也可以參考我之前撰寫的StarkNet AA 介紹文章，題為《StarkNet Account Abstraction 簡介》（Introduction of StarkNet Account Abstraction）。此外，你還可以閱讀與EIP-4337 相關的其他文章，以獲得更多相關信息。