此段落內的文章

檢視更多

imToken 在 EthCC 7 的演講分享：揭示未來：多鏈帳戶抽象解析

Avatar
Whale
  • 更新於
追蹤

WechatIMG2816.jpg

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

本屆以太坊社群會議（EthCC 7）共有超過350 名活躍在區塊鏈產業一線的意見領袖發表演講，來自imToken Labs 的Alfred 受邀參與，並在大會上發表主題為「揭示未來：多鏈帳戶抽象解析」的演講，以下為演講全文：

大家好，我是 Alfred，現任 imToken Labs 的區塊鏈開發人員。今天，我向大家介紹 ERC-4337 和 Native AA 的概念，討論它們之間的差異，並重點分析 L1 和 L2的 4337 標準的主要差異。

帳戶抽象介紹

什麼是帳戶抽象

帳戶抽象化（AA）主要包括兩個關鍵點：簽名抽象化和支付抽象。

  • 簽章抽象：使用者可以選擇任何喜歡的驗證機制，而不僅限於某些數位簽章演算法（如 ECDSA）。
  • 支付抽象：用戶可以使用多種交易支付選項，例如使用 ERC-20 代幣取代原生代幣支付，或讓第三方贊助交易。

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

什麼是 ERC-4337

ETHCC 分享整理 - 2.png

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

  • userOp 結構：在 ERC-4337 中，使用者將 userOp 結構傳送到 Bundler。 Bundler 收集多個 userOp，並透過呼叫 handleOps 函數將它們傳送至 EntryPoint 合約。
  • EntryPoint 合約：該合約像作業系統一樣處理交易，主要功能包括：
    1. 呼叫帳戶合約中的 validate 函數，確保 userOp 已獲得帳戶所有者授權。
    2. 收取費用。
    3. 呼叫帳戶合約中的 execute 函數，執行 userOp 的目標操作。

什麼是原生 AA

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

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

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

如果你對 Aztec Native AA 或 EIP-3074、EIP-7702 感興趣，今天我們將重點放在 ERC-4337 之後的原生 AA。詳細資訊請參考我寫的文章，列在文末。

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 的交易以進行驗證。

ETHCC 分享整理 - 3.png

合約介面

由於三個步驟的存在，帳戶合約介面在不同實作上是相似的。這些入口點函數只能由 AA OS 呼叫。

  • ERC-4337: 驗證使用者操作
  • zkSync: 驗證交易、交易支付、執行交易
  • 斯塔克網：執行、證實、驗證聲明、驗證部署

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

驗證步驟的限制

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

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

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

  • 屬於位址 A 的儲存槽
  • 屬於任何其他位址A的儲存槽
  • 屬於任何其他位址的儲存槽 keccak256 (A || X)：這意味著直接使用位址作為映射中的鍵（例如，映射 (address => value) ），相當於存取槽 keccak256 (A || X)。例如，ERC-20 合約中的代幣餘額。

2.合約邏輯無法存取全域變量，例如區塊號。 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 的私鑰控制。

L1 的 4337 和 L2 的 4337 的區別

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

協議差異

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

地址差異

ETHCC 分享整理 - 4.png

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

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

結語

以下是一些資源，供你了解更多有關帳戶抽象的資訊。請隨時聯絡我，如果你有任何疑問，可以在 Twitter 上找到我。