此段落內的文章

檢視更多

為何 ERC-4337 在 Layer2 的實現遠非那麼簡單？

Avatar
Whale
  • 更新於
追蹤

Frame 2085663465.jpg

本文整理自 imToken Labs 的 Alfred 在 ETHTaipei 大會中的分享

大家好，我是 Alfred。今天我將分享關於 ERC-4337 在 Layer2 上的實現挑戰與解決方案。我目前在 imToken Labs 擔任區塊鏈開發者，大家可以透過我的個人網站或 Twitter 與我交流。

核心差異

我們常預設 ERC-4337 在不同 Layer2 上的實現應與以太坊主網一致。然而，由於協議差異和跨鏈同步的複雜性，實際情況並非如此。

  • ​協議差異：各鏈的 EIP/RIP 支援、硬分叉節奏、操作碼實現、Gas 結構和費用機制不同。
  • ​非同步特性：無法透過單筆交易同步影響所有鏈上的帳戶狀態。

多鏈帳戶的本質

傳統 EOA vs. 智能合約錢包

  • ​EOA（外部帳戶）​：地址和私鑰天然跨鏈一致，僅資產狀態非同步
  • ​智能合約錢包（AA 帳戶）​：
    • 不同鏈上的合約地址可能不同（因部署邏輯差異）
    • 授權方式（如簽名機制）和所有權狀態可能不一致
    • 導致的問題不僅是資產碎片化，更是帳戶控制權的碎片化

所有權同步的問題

若在鏈 X 上修改帳戶所有權（如更新狀態變量），如何確保鏈 Y 同步更新？

當 transferOwnership() 在一條鏈成功而另一條鏈失敗時，會導致：

  • ​所有權狀態分裂：同一帳戶在不同鏈的實際控制權歸屬不同。
  • ​衍生問題：
    • 簽名驗證變更：若想從 ECDSA 切換為 Passkey 或多簽時，需全鏈同步更新驗證邏輯。
    • 密鑰遺失：用戶若遺失控制密鑰，無法統一恢復所有鏈上的帳戶權限。

這揭示了多鏈環境下智能合約錢包（AA）的核心難題：

  • ​同步機制缺失：需設計原子化的跨鏈狀態更新協議。
  • ​安全與恢復矛盾：去中心化環境下如何平衡即時性與最終一致性。

解決方案

是否存在能夠自動化多鏈授權更新或簡化管理流程的協議？

多鏈簽名：一次簽名，全鏈執行

該方案允許用戶僅需對單個用戶操作（userOp）簽名一次，即可將簽名廣播至多條鏈，無需逐鏈單獨簽名。目前主要有兩種實現方式：

  1. ​Coinbase 方案
    1. 直接修改 userOp 簽名結構
    2. 要求全域統一的 Nonce 策略（確保所有鏈上的 Nonce 正確遞增）
    3. 簽名中不包含 Chain ID，使同一簽名可跨鏈通用
    4. ​局限性：僅適用於特定操作（如所有權變更、合約升級），且需所有鏈同時執行成功，否則可能導致 Nonce 不同步
  2. ​Zerodev 默克爾樹方案
    1. 將不同鏈的特定操作分組至默克爾樹中
    2. 聚合多條鏈的 userOpHash 生成單一默克爾根
    3. 用戶只需對默克爾根簽名一次，即可實現多鏈執行

兩種方案均繞過了簽名驗證時的 Chain ID 限制

  • Coinbase 方案完全忽略 Chain ID
  • Zerodev 方案透過默克爾根內嵌所有可能的 Chain ID

錢包服務商支援方案

另一種解決方案是依託錢包服務商來管理多鏈授權體系。基於網頁的錢包需建立資料庫即時追蹤各鏈認證方式，例如：

  • X 鏈使用 PassKeyX
  • B 鏈使用 PassKeyB
  • C 鏈使用 ECDSA

透過這種方式，既能保障用戶體驗的無縫銜接，又避免用戶手動查詢區塊鏈瀏覽器確認簽名機制。

此外，錢包還應具備以下功能：

  • ​跨鏈狀態預警系統：當檢測到不同鏈間授權機制不一致時主動觸發告警
  • ​一鍵同步功能：透過單次操作統一所有鏈的授權方式

該方案的實施將顯著降低多鏈 AA 帳戶的使用複雜度，提升用戶體驗。

地址一致性问题

跨鏈保持相同地址至關重要，否則可能引發嚴重問題：

  • ​用戶體驗受損
    • 從外部帳戶（EOA）角度看，用戶期望其帳戶地址在所有 EVM 兼容鏈上保持一致。
  • ​資產轉移風險
    • 發送者可能無意中將資產轉入接收者在另一條鏈上無法控制的地址，導致資金永久遺失。
  • ​跨鏈橋的潛在隱患
    • 部分跨鏈橋預設用戶地址在目標鏈上存在且由用戶控制。若用戶未核實目標鏈地址狀態，可能將資產轉入他們沒有控制權的地址。
  • ​ENS 域名風險
    • 在 EVM 兼容鏈上使用相同地址註冊 ENS 域名的用戶可能面臨意外風險。
    • ENS 系統預設註冊地址與以太坊主網地址一致，但在 L2 上可能並不成立。

根源：硬分叉差異

各鏈合約地址差異主要由協議分歧導致，具體包括：

  • L2 是否及時同步 L1 的硬分叉升級
  • L2 是否完整支援 L1 的預編譯合約及 EIP/RIP 標準
  • L2 協議的特殊設計，例如：
    • zkSync 對 CREATE/CREATE2 操作碼採用不同編碼規則，影響地址生成邏輯
    • 以太坊主網不支援某些 L2 專屬功能（如 RIP-7212 的 P256 預編譯合約）

為何之前不是問題？

過往的硬分叉（如 The Merge 升級中的 EIP-4399：DIFFICULTY 操作碼改為 PREVRANDAO）僅影響少數合約，未引發廣泛討論。

但新的升級（如 PUSH0 指令）幾乎影響所有合約，使得地址一致性成為當前關鍵挑戰。ERC-4337 標準與智能合約錢包近年來的普及，進一步放大了跨鏈地址一致性的重要性。

過往與未來硬分叉的影響

上海（Shapella）升級 - PUSH0 操作碼

上海升級引入的 PUSH0 操作碼後，部分鏈（如 Arbitrum、Optimism）初期未支援該指令。為確保地址控制權，開發者需明確指定 EVM 版本及 Solidity 編譯器版本。目的在於保持代理工廠（Proxy Factory）地址不變。

​解決方案：使用 --evm-version paris 和 --use 0.8.19，避免編譯器生成 PUSH0 操作碼。

​坎昆（Dencun）升級 - TSTORE/TLOAD 操作碼

坎昆升級中的瞬態存儲指令 TSTORE 影響可能弱於 PUSH0，因為目前 Solidity 編譯器禁止在高級代碼中直接使用瞬態存儲：

  • 當前限制：瞬態存儲僅能透過內聯彙編（TSTORE/TLOAD 操作碼）操作。
  • 未來風險：一旦 EOF（EVM 對象格式）正式上線，類似地址一致性挑戰或將重現。

解決方案

如何確保同一合約在不同鏈上生成相同地址？答案：​必須同時固定 EVM 版本與 Solidity 版本。
然而，隨著硬分叉不斷引入新操作碼，兼容性維護將愈發複雜：

  • 當前聚焦 PUSH0，需權衡 0.8.20 vs. 0.8.19 及 Shanghai vs. Paris 版本差異
  • 未來坎昆升級引入 TSTORE/TLOAD 後，開發者或需具備選擇性啟用能力（如啟用 PUSH0 但禁用 TSTORE，或同時禁用兩者）
  • 選項組合與決策標準將隨時間呈指數級增長

開放性問題

如何制定選擇策略？是否存在普適性的選擇方法或決策指南？

關鍵要點

  • ​切勿假設帳戶在所有鏈上地址相同——這是根本性的思維轉變
  • ​善用 ENS 域名系統，透過更一致且用戶友好的尋址方式提升體驗

費用（PVG）問題

對錢包服務商而言，​L2 預驗證 Gas（PVG）計算的複雜性源於需同時覆蓋 L2 執行成本與 L1 數據提交成本。下面會解析 PVG 的核心邏輯與計算框架：

PVG 解析

Bundler 將用戶操作（userOp）發送到入口點合約（Entry Point）的行為是一個常規交易（也稱為打包交易 bundleTransaction），它是驗證階段（Verification Phase）和執行階段（Execution Phase）的超集。具體來說，此操作中部分 gas 成本並未在 VerificationGasLimit 和 CallGasLimit 中被定義。

換句話說，​PreVerificationGas 覆蓋了所有無法透過鏈上 gasleft() 變化來驗證的 gas 成本，這部分費用由 Bundler 支付。

在 Tenderly 的 Gas 分析圖中，你可以看到那些不被包含在 _validatePrepayment()（驗證階段）和 _executeUserOp()（執行階段）中的 gas 消耗量，這部分應由 Bundler 承擔。

PVG 構成

  • ​處理 EntryPoint 合約中 userOp 的成本​（即打包交易 bundleTransaction 的固有開銷）
    • 例如：以太坊基礎交易成本 21,000 Gas
    • 以及 handleOps 函數中其他操作的額外開銷（這些開銷不包含在驗證階段或執行階段的循環內）
  • ​Calldata 存儲成本：當需要處理的 calldata 增加時（例如從 1 筆 ERC-20 轉賬擴展到 30 筆調用），以下費用會上升：
    • 記憶體擴展成本（由 MLOAD/MSTORE 等操作引發，計算公式為 (perWord + 31) / 32）
    • 交易固有 Gas（Intrinsic Gas）
  • ​額外費用
    • 內存池優先打包費：為從內存池（mempool）中優先打包 userOp 支付的費用
    • 區塊構建者優先權費用：Bundler 為讓區塊構建者（Block Builder）優先處理其打包交易（bundleTx）支付的費用（最終轉嫁給 userOp 的發送者）
    • ​Layer2 交易費用需覆蓋 Layer1 的安全成本：這是當前的核心焦點。

當前討論重點：如何在 Layer 2 上合理計算 PVG，而非 Bundler 的盈利模式

如何在 Layer2 上計算 PVG（預驗證 Gas）？

在 Layer2 上，Bundler 提交打包交易（bundleTx）的總成本需涵蓋 ​Layer1 安全成本和 ​Layer2 處理成本，即：TotalCostForBundleTx = L1Cost + L2Cost

  1. ​L1 Cost（Layer 1 安全成本）​
    • 包括 Rollup 合約在 Layer 1 上的處理費用和 calldata 存儲費用。這是為了確保交易數據最終在 Layer 1 上得到驗證和存儲。
    • ​計算公式：L1Cost = L1GasPrice * L1CalldataSize
  2. ​L2 Cost（Layer 2 處理成本）​
    • 即交易在 Layer 2 上執行所需的 Gas 費用（打包交易 bundleTx 的費用）。
    • ​計算公式：L2Cost = L2GasPrice * L2GasUsed
  3. ​總 Gas 消耗需包含 Layer 2 執行成本和 Layer 1 安全成本的等效 Gas 折算：
    TotalGasUsed = L2GasUsed + L1SecurityFee

其中：

  • ​L1SecurityFee：將 Layer 1 的 calldata 成本轉換為 Layer2 的 Gas 消耗量。
  • ​計算公式：
    L1SecurityFee = (L1GasPrice * L1CalldataSize) / L2GasPrice
  • ​邏輯：
    Layer 1 的 calldata 存儲費用（以 ETH 計價）需按 Layer 2 的 Gas 價格折算為等效 Gas 量。例如，若 L1 存儲 1 KB calldata 需支付 10，而 L2GasPrice 為 0.001 per gas，則等效 Gas 消耗為 10 / 0.001 = 10,000 gas。

​PVG 的組成
PVG 是預驗證 Gas，覆蓋 ​L2 處理成本和 ​L1 安全成本中無法透過驗證/執行階段動態計算的部分：PVG = PVGForL2 + PVGForL1

  • ​PVGForL1：即 Layer 1 安全成本的等效 Gas（L1SecurityFee）。
  • ​PVGForL2：Layer 2 上除驗證階段（VerificationGasLimit）和執行階段（CallGasLimit）外的固定開銷，例如：
    • 交易固有成本（如 L2 基礎 Gas）
    • 記憶體擴展（MLOAD/MSTORE 操作）
    • 其他鏈下處理開銷（如 Bundler 的調度成本）

完整公式推導

TotalGasUsed = (VerificationGasLimit + CallGasLimit) + PVG  

             = (VerificationGasLimit + CallGasLimit + PVGForL2) + PVGForL1  

             = L2GasUsed + L1SecurityFee 

最終，​PVG 的完整計算公式為：
PVG = PVGForL2 + (L1GasPrice * L1CalldataSize) / L2GasPrice

解決方案：基於 RIP-7560 的 builderFee 重構 PVG 計算

為解決 Layer 2 上 PVG 計算的複雜性，RIP-7560 提出原生跨 Rollup 帳戶抽象標準，引入 builderFee 概念，將 PVG 拆分為更清晰的模組化費用結構。以下是其核心邏輯：

在 RIP-7560 中，userOp（或稱為 RIP-7560 交易）的字段定義中，​PVG 被替換為 builderFee，明確指向 ​Layer1 數據提交成本​（即 L1 安全費用）。其他固定開銷則透過 AA_BASE_GAS_COST 等常量定義，簡化計算模型。

maxPossibleGasCost = AA_BASE_GAS_COST + validationGasLimit + paymasterValidationGasLimit + callGasLimit + paymasterPostOpGasLimit 

用戶操作建議

由於 PVG 計算的複雜性可能導致不合理收費，建議用戶可以自建 Bundler 或與 Bundler 服務商建立合作。

合約可訪問性

基礎設施

可能影響合約邏輯

  • 大多數 EVM 兼容的 Layer2 支援以太坊的所有預編譯合約，但部分鏈（如 Scroll）因電路限制可能無法完全支援某些預編譯。例如：
  • ​P256 驗證器：在 RIP-7212 提案落地前，我們常依賴 Daimo 的 P256 驗證器，要求目標鏈需部署該驗證器；而 RIP-7212 實施後，需鏈上直接支援 P256 預編譯合約。

服務

不影響合約邏輯，但可能影響產品穩定性

許多服務（如 Bundler、Paymaster、Relayer）都依賴於節點，它們在實際發送交易或執行簽名前，通常需先在鏈上進行模擬操作。例如 ​Alchemy Bundler​（廣泛使用的服務商）預計在 2025 年 Q2 才支援 P256 預編譯，這意味著從 Layer2 部署 RIP-7212 到服務商全面支援之間，存在超過半年的空窗期。

🚢 OP 主網已透過 Fjord 升級支援 RIP-7212，Superchain 生態現可調用新功能：https://t.co/LM3UHnx53R
— OP Labs (@OPLabsPBC) 2024 年 7 月 10 日

從產品角度來看，若需規模化營運並緊跟最新技術，最佳方案是自建 Bundler 與 Paymaster。

開發者仍需面對複雜選擇，比如「該選哪種 Bundler 和 Paymaster 組合？」當前工具尚可，但仍有百倍優化空間。
— Georgios Konstantopoulos (@gakonst) 2025 年 2 月 20 日

工具

不影響合約邏輯，但可能影響 SDK 或腳本

除服務支援外，還需關注開發框架和工具（如 Foundry、Slither）是否適配新特性。硬分叉前後常存在生態工具適配的過渡期，此時部署合約、上線產品或升級合約均存在風險。例如 ​Foundry 的 Create2 Factory 和 MultiCall3 合約若未在目標鏈部署，可能導致部署腳本或測試用例失效。因此建議等待工具生態穩定後再上線關鍵功能。

總結

本次探討聚焦 ERC-4337 在 Layer2 的複雜性，涵蓋帳戶同步、授權機制、地址一致性、PVG 計算等核心挑戰，關鍵結論如下：

  1. ​跨鏈帳戶需新型同步與授權機制
    • 多鏈簽名方案（如 Coinbase/Zerodev）
    • 錢包供應商支援體系
  2. ​地址分叉不可避免但可管理
    • 破除「跨鏈地址必然一致」的假設
    • 採用 ENS 等通用尋址方案
  3. ​Layer2 的 PVG 計算複雜度超預期
    • 需同時考量 L1 安全成本與 L2 執行成本
    • 關注 RIP-7560 標準化進展
    • 自建 Bundler 以精準控制成本
  4. ​生態協作決定 AA 未來
    • 基礎設施（Bundler/Paymaster 服務商）需適配新協議
    • 錢包開發商需設計無縫跨鏈體驗
    • Rollup 團隊需保持硬分叉同步

ERC-4337 在 Layer2 的落地不僅是技術挑戰，更是全生態的協作適應過程。唯有基礎設施提供商、錢包開發者、Rollup 團隊緊密配合，帳戶抽象才能真正成為跨鏈標準。