多鏈帳戶抽象解析：探索加密基礎設施的未來

近日，以太坊社區會議（EthCC 7）在比利時布魯塞爾舉行，這是歐洲規模最大的以太坊年度活動，重點關注技術和社區。本屆會議共有超過350名區塊鏈行業一線的意見領袖發表演講，其中一位開發者發表了題爲"揭示未來：多鏈帳戶抽象解析"的演講。

演講核心要點

• 帳戶抽象（AA）主要包括籤名抽象和支付抽象兩個關鍵點。籤名抽象讓用戶可以選擇任何喜歡的驗證機制，支付抽象則允許使用多種交易支付選項。這種靈活性提供了更安全、更優的用戶體驗。

• 在ERC-4337和原生AA中，"驗證"階段的入口點函數是固定的，而在"執行"階段，只有原生AA中的入口點是固定的。驗證交易的限制和執行交易的步驟在不同實現中有各自的特點和限制。

• 在EVM兼容鏈上實施ERC-4337，有兩個關鍵區別：Rollup設計中的協議差異和地址計算方式的差異，導致在L1和L2之間實現ERC-4337時出現難以注意的開發細節。

帳戶抽象介紹

什麼是帳戶抽象

帳戶抽象（AA）主要包括兩個關鍵點：

1. 籤名抽象：用戶可以選擇任何喜歡的驗證機制，而不僅限於某些數字籤名算法（如ECDSA）。

2. 支付抽象：用戶可以使用多種交易支付選項，如使用ERC-20資產代替原生資產支付，或讓第三方贊助交易。

這種靈活性提供了更安全、更優的用戶體驗。帳戶抽象的目標是通過多種方式實現這兩個關鍵點。

ERC-4337簡介

目前，以太坊協議中的外部擁有帳戶（EOA）存在一些限制，例如固定的籤名方法和支付設計。ERC-4337通過引入更靈活的帳戶管理和交易處理方法來解決這些問題。

• userOp結構：在ERC-4337中，用戶將userOp結構發送到Bundler。Bundler收集多個userOp，並通過調用handleOps函數將它們發送到EntryPoint合約。

• EntryPoint合約：該合約像操作系統一樣處理交易，主要功能包括：

  • 調用帳戶合約中的validate函數，確保userOp獲得帳戶所有者授權。
  • 收取費用。
  • 調用帳戶合約中的execute函數，執行userOp的目標操作。

原生AA介紹

在以太坊中，帳戶分爲EOA和合約帳戶。然而，在原生AA中，每個帳戶都是一個合約，且交易處理機制直接嵌入到區塊鏈協議中。

各區塊鏈網路中的AA設計：

• ERC-4337帳戶抽象：以太坊、Arbitrum、Optimism、Base、Linea、Scroll、Polygon PoS
• 原生帳戶抽象遵循ERC-4337：StarkNet和zkSync時代
• 具有隱私設計的原生帳戶抽象：Aztec

ERC-4337和原生AA的區別

操作系統角色

AA OS需要解決以下問題：

• 誰決定Gas價格？
• 誰決定交易順序？內存池在哪裏？
• 誰觸發入口點函數？
• 什麼決定了交易處理的流程？

在ERC-4337中，這些角色通過Bundler和EntryPoint Contract協同完成。

在原生AA中，用戶將其userOps發送給官方服務器的操作員/排序器，而不是Bundler和EntryPoint Contract。

在StarkNet中，Sequencer負責處理所有這些任務。

在zkSync中，Era與其他AA實現的主要區別在於Operator需要與bootloader（系統合約）配合工作。Bootloader打開一個新塊，定義其參數（包括塊參數和其他Gas參數），並接收來自Operator的交易以進行驗證。

合約接口

由於三個步驟的存在，帳戶合約接口在不同實現中是相似的，這些入口點函數只能由AA OS調用：

• ERC-4337：驗證用戶操作
• zkSync：驗證交易、交易支付、執行交易
• StarkNet：execute、validate、validate_declare、validate_deploy

在ERC-4337和原生AA中，"驗證"階段的入口點函數是固定的，而在"執行"階段，只有原生AA中的入口點是固定的。

驗證步驟的限制

由於驗證交易沒有成本限制（本質上，驗證交易是調用視圖函數），攻擊者可以對內存池進行DoS攻擊，從而破壞捆綁器（EIP-4337）或運算符/排序器（原生AA）。

EIP-4337定義了禁止哪些操作碼以及如何限制存儲訪問。zkSync Era放寬了一些OpCode的使用：

• 合約邏輯只能訪問自己的存儲槽。如果帳戶合約的地址是地址A，它可以訪問：

  • 屬於地址A的存儲槽
  • 屬於任何其他地址A的存儲槽
  • 屬於任何其他地址的存儲槽keccak256(A || X)：這意味着直接使用地址作爲映射中的鍵（例如，映射(address => value)），相當於訪問槽keccak256(A || X)。例如，ERC-20合約中的資產餘額。

• 合約邏輯無法訪問全局變量，例如區塊號。StarkNet也不允許外部合約調用。

執行步驟的限制

在zkSync中，執行系統調用需要確認系統標志的存在。例如，增加nonce的唯一方法是與NonceHolder交互，而部署合約則需要與ContractDeployer交互。系統標志確保帳戶開發人員有意識地與系統合約進行交互。

在ERC-4337和StarkNet中，執行階段沒有特殊限制。

隨機數

• 在ERC-4337中，入口點隨機數的設計區分了192位密鑰值和64位隨機數值。
• 在zkSync中，NonceHolder系統合約管理nonce，確保嚴格遞增，即將隨機數增加1。
• 在StarkNet中，nonce也是嚴格遞增的，但是沒有抽象的nonce來由特定的合約管理。

使用第一個事務進行部署

• ERC-4337在userOp結構中包含initcode字段，以在其第一個userOp中部署發送者（帳戶合約）。
• 在StarkNet和zkSync中，用戶必須將第一筆交易發送給算子/排序器來部署帳戶合約。

zkSync中的特殊設計

如果你直接將ETH從以太坊EOA轉移到zkSync，無需部署定制帳戶合約，你將收到一個具有相同地址的默認帳戶。該帳戶可以像以太坊EOA一樣工作，並且也由相應的以太坊EOA的私鑰控制。

這帳戶類型是版本None而不是version1。你不能調用DefaultAccount的函數，因爲它沒有在內核空間部署任何代碼。

L1的4337和L2的4337的區別

在EVM兼容鏈上實施ERC-4337有兩個關鍵區別：協議差異和地址差異。

協議差異

Rollup設計中，L2需要將數據上傳到L1以進行安全和結算。在ERC-4337的背景下，與此上傳過程相關的費用，例如L1安全費和blob費用，應該被包括在內在預驗證Gas中。確定預驗證Gas中適當的上傳費用是一個重大挑戰。

地址差異

zkSync ERA的create函數中的地址編碼方式與以太坊和OP匯總不同。此外，StarkNet使用獨特的哈希函數進行地址計算。在EVM兼容鏈上的ERC-4337背景下，我們通常假設地址計算在各鏈上是一致的。然而，有一個難以注意的細節可能會導致以太坊和L2中的ERC-4337實現之間的帳戶合約地址不同。

關鍵問題是在硬分叉中添加新的操作碼。例如，如果L2鏈不支持上海硬分叉，並且在編譯時未指定EVM版本，push0的引入會導致字節碼改變，即使Solidity代碼是相同的。