此组别内的文章

查看更多

为什么 ERC-4337 在 Layer2 的实现没有那么简单？

Avatar
Whale
  • 更新
关注

Frame 2085663465.jpg

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

大家好，我是 Alfred。目前在 imToken Labs 担任区块链开发者，今天我将分享关于 ERC-4337 在 Layer2 上的实现挑战与解决方案。  

核心差异

我们常默认 ERC-4337 在不同 Layer2 上的实现应与以太坊主网一致。然而，由于协议差异和跨链同步的复杂性，实际情况并非如此。

  • 协议差异：各链的 EIP/RIP 支持、硬分叉节奏、操作码实现、Gas 结构和费用机制不同。  
  • 异步特性：无法通过单笔交易同步影响所有链上的账户状态。

多链账户的本质  

传统 EOA vs. 智能合约钱包  

  • EOA（外部账户）：地址和私钥天然跨链一致，仅资产状态异步
  • 智能合约钱包（AA 账户）：  
    • 不同链上的合约地址可能不同（因部署逻辑差异）  
    • 授权方式（如签名机制）和所有权状态可能不一致
    • 导致的问题不仅是资产碎片化，更是账户控制权的碎片化

所有权同步的问题  

若在链 X 上修改账户所有权（如更新状态变量），如何确保链 Y 同步更新？

当 transferOwnership() 在一条链成功而另一条链失败时，会导致：

  • ​所有权状态分裂：同一账户在不同链的实际控制权归属不同。
  • ​衍生问题：
    • ​签名验证变更：若想从 ECDSA 切换为 Passkey 或多签时，需全链同步更新验证逻辑。
    • ​密钥丢失：用户若丢失控制密钥，无法统一恢复所有链上的账户权限。

这揭示了多链环境下智能合约钱包（AA）的核心难题：

  • ​同步机制缺失：需设计原子化的跨链状态更新协议。
  • ​安全与恢复矛盾：去中心化环境下如何平衡即时性与最终一致性。

解决方案  

是否存在能够自动化多链授权更新或简化管理流程的协议？

多链签名：一次签名，全链执行

该方案允许用户仅需对单个用户操作（userOp）签名一次，即可将签名广播至多条链，无需逐链单独签名。目前主要有两种实现方式：

1. Coinbase 方案

  • 直接修改 userOp 签名结构
  • 要求全局统一的 Nonce 策略（确保所有链上的 Nonce 正确递增）
  • 签名中不包含 Chain ID，使同一签名可跨链通用
  • ​局限性：仅适用于特定操作（如所有权变更、合约升级），且需所有链同时执行成功，否则可能导致 Nonce 不同步

2. Zerodev 默克尔树方案

  • 将不同链的特定操作分组至默克尔树中
  • 聚合多条链的 userOpHash 生成单一默克尔根
  • 用户只需对默克尔根签名一次，即可实现多链执行

两种方案均绕过了签名验证时的 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

  • ​L1 Cost（Layer 1 安全成本）​
    包括 Rollup 合约在 Layer 1 上的处理费用和 calldata 存储费用。这是为了确保交易数据最终在 Layer 1 上得到验证和存储。​
    • 计算公式：L1Cost = L1GasPrice * L1CalldataSize
  • ​L2 Cost（Layer 2 处理成本）​
    即交易在 Layer 2 上执行所需的 Gas 费用（打包交易 bundleTx 的费用）。
    • ​计算公式：L2Cost = L2GasPrice * L2GasUsed

总 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. ​跨链账户需新型同步与授权机制
    1. 多链签名
    2. 钱包供应商支持
  2. ​地址分叉不可避免但可管理
    1. 勿假设跨链地址一致
    2. 采用 ENS 等通用解决方案
  3. ​Layer2 的 PVG 计算复杂度超预期
    1. 关注 RIP-7560 标准化进展
    2. 自建 Bundler 以优化成本
  4. ​生态协作决定 AA 未来
    1. 基础设施（Bundler/Paymaster服务商）
    2. 钱包开发商
    3. Rollup 团队

ERC-4337 在 Layer2 的落地不仅是技术挑战，更是全生态的协作适应过程。唯有各方紧密配合，账户抽象才能真正成为跨链标准。