zkSync中的原生Account Abstraction介紹_SYN:KSY

作者：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

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

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

Kyber Network在zkSync Era上部署KyberSwap聚合器和流動性協議:6月21日消息，Kyber Network宣布，已在zkSync Era上部署KyberSwap聚合器和流動性協議，集成Mute、Switch、SyncSwap、Velocore等DEX。[2023/6/22 21:52:57]

而支付抽象旨在為用戶提供多種交易支付選項。例如，可以使用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會順序處理每筆交易：

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

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

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

zkSync Era上TVL突破3.2億美元:金色財經報道，據 L2BEAT 數據，zkSync Era上的鎖倉額（TVL）已突破3.2億美元，24小時漲幅13.65%，創歷史新高。[2023/5/28 9:46:31]

調用用戶帳戶合約上的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 代幣。

智能合約錢包Argent Layer2版本正式上線zkSync:12月24日，智能合約錢包Argent宣布其Layer2版本正式上線zkSync，目前已與zkSync網絡內DEX平臺ZigZag完成集成，用戶現可通過1美元的固定費用使用Argent在Layer2上的交易服務。該服務目前僅支持ETH、USDT、USDC、WBTC、DAI和FRAX。[2021/12/24 8:02:18]

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完成系統調用。

Matter Labs 將 Uniswap V2 智能合約和前端遷移至 zkSync 2.0 測試網:10月13日消息，Matter Labs 宣布將 Uniswap V2 智能合約和前端遷移至功能完備的 zkSync 2.0 測試網上，該端口名為 UniSync，為在 zkSync 2.0 上第一個遷移的 Solidity DApp。另外，Matter Labs 表示，UniSync 不隸屬于 Uniswap Labs，將在即將推出的 zkSync 2.0 主網啟動 Uniswap 實例。[2021/10/13 20:25:02]

上述代碼示例中涉及與`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代幣

以太坊二層解決方案zkSync 2.0上線zkEVM測試網Alpha版:據官方消息，以太坊擴容項目Matter Labs宣布，以太坊二層解決方案zkSync 2.0上線zkEVM測試網Alpha版，用戶已經可以使用區塊瀏覽器查看zkSync 2.0上的活動。該版本主要成果包括完成zkEVM指令集；用Solidity和Zinc編寫的智能合約現在可以編譯成zkEVM字節碼；完成全節點集成，能夠成功部署和執行編譯后的智能合約。[2021/6/1 23:00:17]

- 使用信用卡向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 支付的交易，那流程如下：

借由 NonceHolder 確認 nonce 是否合法

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

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

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

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

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

如果 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 相關的其他文章，以獲得更多相關信息。

金色財經

企業專欄

閱讀更多

金色財經 善歐巴

web3中文

金色早8點

YBB Capital

吳說Real

元宇宙簡史

Tags：SYNSYNCzkSyncKSYSynapsezksync幣什么時候能買zksync幣交易所zksync幣發行量

UNI