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

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

• 协议差异：各链的 EIP/RIP 支持、硬分叉节奏、操作码实现、Gas 结构和费用机制不同。

  
  

• 异步特性：无法通过单笔交易同步影响所有链上的账户状态。

▶ 传统 EOA vs. 智能合约钱包

• EOA（外部账户）：

  地址和私钥天然跨链一致，仅资产状态异步。

  
  

• 智能合约钱包（AA 账户）：

  不同链上的合约地址可能不同（因部署逻辑差异）。

  授权方式（如签名机制）和所有权状态可能不一致。

  导致的问题不仅是资产碎片化，更是账户控制权的碎片化。

  
  

▶ 所有权同步的问题

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

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

所有权状态分裂：

同一账户在不同链的实际控制权归属不同。

衍生问题：

1. 签名验证变更：若想从 ECDSA 切换为 Passkey 或多签时，需全链同步更新验证逻辑。

2. 密钥丢失：用户若丢失控制密钥，无法统一恢复所有链上的账户权限。

这揭示了多链环境下智能合约钱包（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 系统默认注册地址与以太坊主网地址一致，但在 Layer2 上可能并不成立。

各链合约地址差异主要由协议分歧导致，具体包括：

• Layer2 是否及时同步 Layer1 的硬分叉升级。

• Layer2 是否完整支持 Layer1 的预编译合约及 EIP/RIP 标准。

• Layer2 协议的特殊设计，例如：

• zkSync 对 CREATE/CREATE2 操作码采用不同编码规则，影响地址生成逻辑。

• 以太坊主网不支持某些 Layer2 专属功能（如 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）问题

对钱包服务商而言，Layer2 预验证 Gas（PVG）计算的复杂性源于需同时覆盖 Layer2 执行成本与 Layer1 数据提交成本。下面会解析 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 构成

1. 处理 EntryPoint 合约中 userOp 的成本（即打包交易 bundleTransaction 的固有开销）

• 例如：以太坊基础交易成本 21,000 Gas 以及 handleOps 函数中其他操作的额外开销（这些开销不包含在验证阶段或执行阶段的循环内）。

  
  

• Calldata 存储成本：当需要处理的 calldata 增加时（例如从 1 笔 ERC-20 转账扩展到 30 笔调用），以下费用会上升：

  
  

• 内存扩展成本（由 MLOAD/MSTORE 等操作引发，计算公式为 (perWord + 31) / 32）

• 交易固有 Gas（Intrinsic Gas）

2. 额外费用

• 内存池优先打包费：为从内存池（mempool）中优先打包 userOp 支付的费用。

• 区块构建者优先权费用：Bundler 为让区块构建者（Block Builder）优先处理其打包交易（bundleTx）支付的费用（最终转嫁给 userOp 的发送者）

• Layer2 交易费用需覆盖 Layer1 的安全成本：这是当前的核心焦点。

当前讨论重点是如何在 Layer 2 上合理计算 PVG，而非 Bundler 的盈利模式

▶ 如何在 Layer2 上计算 PVG（预验证 Gas）？

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

• Layer1 Cost（Layer 1 安全成本）

  包括 Rollup 合约在 Layer 1 上的处理费用和 calldata 存储费用。这是为了确保交易数据最终在 Layer 1 上得到验证和存储。

  
  

  计算公式：L1Cost = L1GasPrice * L1CalldataSize

  
  

• Layer2 Cost（Layer 2 处理成本）

  即交易在 Layer 2 上执行所需的 Gas 费用（打包交易 bundleTx 的费用）。

  
  

  计算公式：L2Cost = L2GasPrice * L2GasUsed

总 Gas 消耗需包含 Layer 2 执行成本和 Layer 1 安全成本的等效 Gas 折算：TotalGasUsed = L2GasUsed + L1SecurityFee

其中：

1. L1SecurityFee：将 Layer 1 的 calldata 成本转换为 Layer2 的 Gas 消耗量。

   
   

2. 计算公式：L1SecurityFee = (L1GasPrice * L1CalldataSize) / L2GasPrice

   
   

3. 逻辑：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，覆盖 Layer2 处理成本和 L1 安全成本中无法通过验证 / 执行阶段动态计算的部分：

PVG = PVGForL2 + PVGForL1

1. PVGForL1：即 Layer 1 安全成本的等效 Gas（L1SecurityFee）。

   
   

2. PVGForL2：Layer 2 上除验证阶段（VerificationGasLimit）和执行阶段（CallGasLimit）外的固定开销，例如：

1. 交易固有成本（如 Layer2 基础 Gas）

2. 内存扩展（MLOAD/MSTORE 操作）

3. 其他链下处理开销（如 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 数据提交成本（即 Layer1 安全费用）。其他固定开销则通过 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 年第二季度才支持 P256 预编译，这意味着从 Layer2 部署 RIP-7212 到服务商全面支持之间，存在超过半年的空窗期。

从产品角度来看，若需规模化运营并紧跟最新技术，最佳方案是自建 Bundler 与 Paymaster。

▶ 工具

不影响合约逻辑，但可能影响 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 的落地不仅是技术挑战，更是全生态的协作适应过程。唯有各方紧密配合，账户抽象才能真正成为跨链标准。