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

2024年7月8日至11日，歐洲規模最大的以太坊年度活動——以太坊社區會議（EthCC）在比利時布魯塞爾舉行，重點關注技術和社區發展。

本屆以太坊社區會議（EthCC 7）邀請了超過350名區塊鏈行業一線的意見領袖發表演講。imToken Labs的開發者Alfred受邀參與，並發表了題爲"揭示未來：多鏈帳戶抽象解析"的演講。

演講要點概覽

• 帳戶抽象（AA）的兩個核心：籤名抽象和支付抽象。籤名抽象允許用戶選擇任意驗證機制，支付抽象則提供多種交易支付選項，共同提升安全性和用戶體驗。

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

• 在EVM兼容鏈上實施ERC-4337時，主要存在兩個關鍵差異：Rollup設計中的協議差異和地址計算方式的差異。這些差異導致在L1和L2之間實現ERC-4337時出現一些容易被忽視的開發細節。

帳戶抽象簡介

1. 帳戶抽象的定義

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

• 籤名抽象：用戶可自由選擇驗證機制，不再局限於特定的數字籤名算法（如ECDSA）。
• 支付抽象：用戶可使用多種交易支付選項，如用ERC-20資產替代原生資產支付，或由第三方贊助交易。

這種靈活性大大提升了安全性和用戶體驗。帳戶抽象旨在通過多種方式實現這兩個核心目標。

2. ERC-4337解析

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

• userOp結構：在ERC-4337中，用戶將userOp結構發送到Bundler。Bundler收集多個userOp，並通過調用handleOps函數將它們發送到EntryPoint合約。
• EntryPoint合約：該合約類似操作系統，處理交易的主要功能包括：
  • 調用帳戶合約中的validate函數，確保userOp獲得帳戶所有者授權。
  • 收取費用。
  • 調用帳戶合約中的execute函數，執行userOp的目標操作。

3. 原生AA介紹

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

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

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

ERC-4337與原生AA的區別

1. 操作系統角色

AA OS需要解決以下問題：

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

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

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

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

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

2. 合約接口

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

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

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

3. 驗證步驟的限制

由於驗證交易沒有成本限制，攻擊者可能對內存池進行DoS攻擊，從而影響捆綁器（EIP-4337）或運算符/排序器（原生AA）。

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

• 合約邏輯只能訪問自己的存儲槽。如果帳戶合約的地址是地址A，它可以訪問：
  • 屬於地址A的存儲槽
  • 屬於任何其他地址A的存儲槽
  • 屬於任何其他地址的存儲槽keccak256(A || X)：這意味着直接使用地址作爲映射中的鍵，相當於訪問槽keccak256(A || X)。例如，ERC-20合約中的資產餘額。
• 合約邏輯無法訪問全局變量，如區塊號。StarkNet也不允許外部合約調用。

4. 執行步驟的限制

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

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

5. 隨機數

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

6. 使用第一個事務進行部署

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

7. zkSync中的特殊設計

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

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

L1的4337和L2的4337的區別

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

1. 協議差異

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

2. 地址差異

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

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