Base OP Stack 安全审计：EVM 等效性掩盖下的 29 项检查

“EVM 等效”是 L2 安全中最危险的短语。

开发者从 OP Stack 文档中听到它，在架构评审中重复它，并以此为理由将 L1 合约不加修改地部署到 Base。逻辑看起来天衣无缝：如果 Base 运行相同的操作码、相同的 Solidity、相同的执行客户端（op-geth），那么相同的合约就应该能正常工作。

事实并非如此。

Base 的 OP Stack 架构在区块时间、Gas 经济学、交易来源语义、跨域消息认证和状态最终性方面引入了差异，这些差异会悄无声息地打破专为以太坊主网设计的合约中的假设。一个在 L1 上执行三小时的基于 block.number 的冷却时间，在 Base 上只执行 33 分钟。一个在 L1 上限制管理员访问的 tx.origin 检查，在存款交易中会允许一个别名化的攻击者地址通过。一个只计算执行成本而忽略 L1 数据费用的 Gas 预估，会低估网络上每笔交易的价格。

这些并不是假设的边缘情况。它们是区分安全的 Base 部署与被洗劫的协议的实际攻击面。

本指南细分了审计员和开发者在 Base 上构建或评审智能合约时必须考虑的特定架构差异、已知漏洞类别、桥接机制和工具配置。目标是：实现一个每个 L2 特定假设都经过记录、测试和硬化处理的部署 —— 而不是一个用“EVM 等效”代替实际安全分析的部署。

理解 OP Stack 执行模型

Base 是一个构建在 Optimism 的 OP Stack 之上的 Optimistic Rollup，由 Coinbase 于 2023 年 8 月在以太坊主网上推出。该架构将执行与结算分离到几个不同的组件中：

• 定序器 (Sequencer) —— 由 Coinbase 运营的单一节点，负责对交易进行排序，每 2 秒产生一个 L2 区块（Flashblocks 的目标是 200 毫秒预确认），并将压缩后的批次提交给以太坊。定序器不能窃取资金，但在交易排序和审查方面拥有单方面权力。
• Batcher —— 压缩 L2 交易数据并将其发布到以太坊 L1。自 Dencun 升级（EIP-4844）以来，Base 使用携带 Blob 的交易来实现数据可用性，与 Calldata 相比大幅降低了 L1 发布成本。
• 提案者 (Proposer) —— 向 L1 提交输出根（L2 状态承诺）。自 2024 年 10 月起，提案是无许可的 —— 任何人都可以通过 DisputeGameFactory 合约提交，并缴纳 0.08 ETH 的保证金。
• 故障证明系统 (Fault proof system) —— 使用 Cannon FPVM（一种基于 MIPS 的指令级执行环境）在链上重放任何 L2 状态转换。纠纷解决遵循交互式 二分博弈，将分歧缩小到单个指令步骤。
• 派生流水线 (Derivation pipeline) —— op-node 监控 L1 以查找 TransactionDeposited 事件、存款交易和批次数据。它根据 L1 数据确定性地重建 L2 链状态。

安全模型是乐观的：L2 状态转换被假定为有效，除非在争议窗口期间被主动挑战。此流水线中的每个组件 —— 定序器排序、批次发布延迟、故障证明时机、派生确定性 —— 都引入了合约可能违反的假设。

映射操作码和状态差异

在 Bedrock 升级之后，OP Stack 通过运行一个经过最小修改的以太坊执行客户端实现了 EVM 等效。“最小修改”仍然意味着经过了修改。以下差异是那些会破坏实际合约的差异：

审计动作

• 标记每个 block.number 引用。如果用于时间计算，建议替换为 block.timestamp。

• 标记每个 tx.origin 检查。验证合约是否可以接收 L1→L2 存款以及是否处理了别名。请参阅我们对 tx.origin 钓鱼漏洞 的深入研究。

• 验证 Gas 预估是否包含 L1 数据费。使用未签名的 RLP 编码交易调用 GasPriceOracle.getL1Fee(bytes) 以获取实际成本。

• 通过 0x4200...0015 处的 L1Block 预部署合约访问 L1 状态，而不是通过操作码。请注意，L1Block 的值每 L1 区块（约 12 秒）更新一次 —— 相对于 L1 最新状态，它们天生是滞后的。

• • *

识别预部署合约攻击面

Base 继承了 0x4200... 地址命名空间的完整 OP Stack 预部署 生态系统。这些不是可选的库 —— 它们是管理桥接、费用收取和链状态的系统级合约。任何与之集成的协议都必须了解它们的接口和信任假设。

关键细节：所有预部署合约都是可升级的代理。ProxyAdmin 控制着所有这些合约。截至 2025 年 4 月，由三个必需方（Base 安全委员会、BaseMultisig2、OpFoundationOperationsSafe）批准的升级可以立即执行 —— 没有 时间锁。这是每个构建在 Base 上的协议都继承的系统性信任假设。

缓解 OP Stack 故障证明漏洞

由于 Base 完整继承了 OP Stack 故障证明系统，该系统中发现的所有漏洞都直接适用于 Base。2024 年的三个发现值得详细关注：

二分博弈中的计时器操纵

2024 年 3 月，Offchain Labs（Arbitrum 开发团队）披露了测试网上 OP Stack 故障证明系统中的两个关键漏洞：

• 通过计时器继承接受欺诈根：FaultDisputeGame 中的“国际象棋时钟”机制允许恶意行为者通过祖孙关系从诚实参与者的声明中继承计时器信用。通过提交一个欺诈性的根，等待诚实的挑战，然后在最后一秒做出响应，攻击者会导致诚实的挑战超时，而欺诈性的根保持未被反击的状态。在关键时刻仅需一个区块的 L1 审查就足以强制接受无效的状态根。
• 拒绝诚实根：同样的计时器操纵反过来也有效 —— 攻击者可以击败正确的根声明，阻止有效的取款。

两者都在主网部署前得到了修复。教训是：二分博弈计时逻辑是一个需要形式化分析的关键攻击面。任何直接与争议博弈合约交互的协议都必须验证解决逻辑是否经过了针对计时攻击的审计。

GameType 验证绕过

一项审计结果显示，格式错误的 GameType（用于选择争议博弈实现的 uint32）可能会通过 OptimismPortal.sol 中的验证检查，从而可能导致取款通过安全属性较弱的博弈进行。

op-challenger 中的 Blob 数据处理

离线组件 op-challenger 错误处理了涉及 EIP-4844 Blob 数据的交易，导致 Cannon 中的链上和链下执行轨迹出现偏差。由于故障证明依赖于完全相同的执行，这种偏差可能允许恶意提案者构造一个无法挑战的无效状态。

审计动作

• 不要构建绕过 7 天争议窗口的取款逻辑。故障证明系统是防止无效状态根掏空网桥的唯一机制。

• 监控 OP Stack 安全披露。故障证明漏洞会影响超级链（Superchain）上的每个链，包括 Base。

• 如果你的协议与 DisputeGameFactory 或 OptimismPortal2 交互，请审计 GameType 验证并确保你的逻辑能够处理博弈解决的边缘情况（例如，受攻击时 Guardian 切换到 PermissionedDisputeGame）。

• • *

审计桥接集成层

桥接基础设施是任何 L2 生态系统中价值最高的 攻击面。Base 使用标准的 OP Stack 跨域消息传递 协议。其机制是不对称的：存款速度快且有保证；取款速度慢且依赖故障证明。

L1→L2 存款

流程：用户调用 OptimismPortal (L1) 上的 depositTransaction() → 触发 TransactionDeposited 事件 → op-node 派生存款交易 → L2 执行引擎处理该交易。

安全属性：

• 存款保证包含在每个阶段第一个 L2 区块的开头。
• 存款交易缺乏加密签名（v、r、s 均归零） —— 真实性由 L1 包含和规范派生保证。
• 身份验证使用加密派生的 sourceHash：keccak256(bytes32(uint256(0)), keccak256(l1BlockHash, bytes32(uint256(l1LogIndex))))。
• 地址别名适用：当 L1 合约发送存款时，其地址在 L2 上会偏移 0x1111...1111。如果没有这一点，攻击者可以在 L1 和 L2 的相同地址部署合约，跨链伪造身份，并绕过授权。

已知边缘情况：如果 L1 合约通过 OptimismPortal 存入 ETH，而相应的 L2 执行失败（逻辑错误、Gas 不足），ETH 将被铸造到 L2 上的别名发送者地址。如果 L1 发送者合约无法控制其别名的 L2 对应项，这些资金将永久滞留。

L2→L1 取款

流程（3 步，全部在 L1 上完成最终确定）：

1. 发起：在 L2 上调用 L2ToL1MessagePasser.initiateWithdrawal()。在合约的 Merkle-Patricia 树中存储一个取款哈希。
2. 证明：包含该取款的输出根在 L1 上提议后，向 OptimismPortal2.proveWithdrawalTransaction() 提交一个 Merkle 证明。
3. 最终确定：争议窗口（约 7 天）过后且状态根被确认，调用 OptimismPortal2.finalizeWithdrawalTransaction()。

最小取款时间：从提交证明起约 7 天。

安全层：

• Guardian 角色（Optimism 安全委员会）可以在博弈解决后的空隙窗口期间拒绝已确定的根。
• DelayedWETH 持有争议博弈保证金，如果博弈解决错误，会有延迟支付以便重定向。
• Guardian 可以在遭受主动攻击时将系统切换到 PermissionedDisputeGame。

跨域消息认证

CrossDomainMessenger 系统在两个方向上提供经过身份验证的跨链函数调用。关键安全考量：

• 重放保护 —— 消息包含一个 Nonce。验证两个 Messenger 合约中的 Nonce 处理是否正确。
• 失败消息重放 —— 失败的消息可以在目标链上重放。目标合约必须是幂等的，以便安全处理。
• 发送者认证 —— xDomainMessageSender() 返回经过身份验证的跨链发送者，但仅当由 Messenger 合约本身调用时才有效。合约在信任此值之前必须验证 msg.sender == address(messenger)。
• Gas 预估 —— 跨链消息必须预留 L1 和 L2 的执行成本。Gas 不足的消息会失败并进入重放队列。

审计动作

• 验证每个跨域消息处理程序在执行特权逻辑前都会检查别名化的发送者地址。

• 测试存款失败场景。当存款的 L2 执行失败时会发生什么？资金是否可以追回？

• 确认取款处理程序是幂等的。针对被作废的根所证明的取款必须能够针对有效的根重新证明，而不会产生双重支付。

• 在与桥接连接的合约上实施速率限制和熔断机制。桥接漏洞不应演变成整个协议的破产。有关 100 多个特定检查项，请参阅我们的 桥接安全清单。

• 如果集成了第三方桥（Across、Stargate、Hop），请审计其特定的信任模型：私钥托管、挑战期、预言机 依赖以及流动性池的偿付能力假设。

• • *

防御定序器级别的威胁

Base 运行由 Coinbase 运营的单一中心化定序器。这是一个结构性限制，而非错误 —— 但它产生了一个合约必须围绕其设计的特定威胁模型。

审查与排序

• 定序器拥有单方面的交易排序权。假设在基础设施层面可能存在夹心攻击和抢跑交易。有关缓解策略，请参阅我们的 MEV 保护 指南。
• 在定序器层面进行 OFAC/监管过滤是可能的。来自受制裁地址的交易可能会被拒绝。
• 定序器不能窃取资金，但对时间敏感交易（预言机更新、清算、拍卖出价、治理投票）的审查可能导致间接资金损失。

停机

• 如果定序器离线，则不会处理新的 L2 交易。2025 年 8 月 5 日，Base 在区块 33,792,704 处经历了约 33 分钟的产块停滞。
• 一种更隐蔽的失败模式：定序器继续产生 L2 区块并发布预确认，但未能将批次发布到 L1。这会造成一种状态偏差，用户看到“已确认”的交易，但这些交易没有 L1 数据可用性支持。
• 在长时间停机期间，价格 预言机 会失效，流动性指标变得波动，杠杆仓位在网络恢复的瞬间容易受到级联清算的影响。

强制包含 (Forced inclusion)

用户可以通过向 L1 上的 OptimismPortal.depositTransaction() 提交交易来完全绕过定序器。协议保证这些存款交易出现在相应阶段第一个 L2 区块的开头。如果定序器遗漏了它们，输出根将变得无效并会被挑战。

强制包含路径的延迟由 FORCE_INCLUSION_PERIOD 定义 —— 最长可达 12 小时。任何协议关键流程（清算、拍卖、治理确定）必须设计为能够容忍这种延迟。

对承诺-揭示方案的审计启示：揭示窗口绝不能短于 L1 确认深度 + FORCE_INCLUSION_PERIOD。否则，具有 L1 审查能力的验证者可以通过 L1 存款路径抢跑揭示过程。

审计动作

• 测试定序器停机场景：如果 1 小时没有产生 L2 区块，你的协议会发生什么？12 小时呢？24 小时呢？

• 设计优雅降级：如果预言机更新或 Keeper 交易停止到达，请实施带有延长执行窗口的备用逻辑。

• 不要假设排序公平。与 L1 上区块构建者相互竞争不同，Base 的单一定序器单方面控制交易池。

• • *

硬化代理升级路径

在 Gas 廉价的 L2 上，升级交易成本低廉 —— 恶意升级也是如此。OP Stack 使用带有独立 ProxyAdmin 权限的透明 代理模式，以解决函数选择器冲突。有关全面概述，请参阅我们的 代理可升级性安全清单 和 升级模式安全指南。

在 Base 主网上，ProxyAdmin 位于 0x4200...0018。L1 桥接管理合约由 Gnosis Safe 多签钱包控制。Base 主网 ProxyAdmin 的所有者是 0x7bB41C3008B3f03FE483B28b8DB90e19Cf07595c。

升级特定的漏洞类别

• 无保护的初始化程序：代理不能使用构造函数。如果 initialize() 函数缺少 initializer 修饰符，攻击者可以在部署后重新初始化合约，覆盖权限变量。这是已部署合约中最常见的 访问控制 失败之一。
• 存储布局冲突：升级必须保持先前实现中的精确插槽顺序。重新排序、删除或调整状态变量大小会破坏持久状态。
• 权限混淆：ProxyAdmin 所有者绝不能与协议的功能管理器重合。一个被社会工程学的 upgradeToAndCall 可以将实现重定向到攻击者控制的合约。

审计动作

• 在所有代理合约上运行 slither-check-upgradeability，以自动检测 存储布局 违规。

• 验证初始化程序受到保护，且在部署后不能被重新调用。

• 确认实现合约中不存在 selfdestruct（即使在 EIP-6780 之后）。

• 为你协议自身的升级实施 时间锁，独立于 Base 系统合约是否有时间锁。在参数更改生效前给用户退出的时间。

• 监控 OP Stack 网络升级（Bedrock、Ecotone、Fjord、Jovian）。每一次都可能改变 Gas 定价、费用计算和故障证明行为。在主网激活前在测试网上测试你的合约。

• • *

为 Base 配置审计工具

由于 Base 在字节码级别是 EVM 等效的，标准的 Solidity 审计工具只需最少的配置即可工作。字节码是相同的 —— 工具分析的是源码和字节码，而不是链运行时。但如果没有显式配置，自动化工具无法捕捉到 L2 特有的问题。

工具矩阵

自动化工具遗漏的内容

手动评审对于以下内容是强制性的：

• 跨域消息认证失败
• 存款路径上的地址别名处理不当
• 时间敏感逻辑中的定序器依赖假设
• L1 数据费对协议经济的影响
• 预部署合约交互的正确性（特别是 L1Block 的滞后性）
• 故障证明失效下的取款流程正确性和幂等性

有关分层安全方法的更广泛视角，请参阅我们的 深度防御工作流。

应用 L2 安全清单

这是整合后的清单。每一项都对应于上文记录的特定差异或漏洞类别。请将此与我们的 审计前清单 结合使用以获得最大覆盖范围。

操作码与状态

• [ ] 所有 block.number 引用均已针对 L2 时间进行评审（2 秒/区块 vs. 12 秒）
• [ ] 时间相关逻辑使用 block.timestamp 而非 block.number
• [ ] 通过 L1Block 预部署合约而非操作码访问 L1 状态
• [ ] 考虑了 L1Block 的滞后性（数值滞后于 L1 最新状态最多约 12 秒）
• [ ] PREVRANDAO 未用于安全关键的随机性
• [ ] 针对 L1→L2 存款路径处理了 tx.origin 别名
• [ ] Gas 预估通过 GasPriceOracle.getL1Fee() 包含了 L1 数据费
• [ ] 未对 L2 上的通缩基础费用机制做任何假设

定序器弹性

• [ ] 协议能够容忍定序器停机（已测试 1 小时、12 小时、24 小时场景）
• [ ] 清算/拍卖/治理流程能够容忍 12 小时强制包含延迟
• [ ] 针对停机期间过时的价格喂价实现了预言机备用逻辑
• [ ] 不假设交易排序公平性

桥接安全

• [ ] 跨域消息处理程序在信任 xDomainMessageSender() 前验证了 msg.sender == messenger
• [ ] 地址别名在认证逻辑中被正确应用/去别名化
• [ ] 已测试存款失败场景（L2 执行失败、Gas 不足）
• [ ] 取款处理程序在故障证明失效循环中是幂等的
• [ ] 遵守了 7 天取款延迟 —— 没有任何 UX 或逻辑假设 L2→L1 会快速结算
• [ ] 桥接连接合约上的速率限制和熔断机制
• [ ] 独立审计了第三方桥的信任模型

可升级性

• [ ] 在所有代理合约上运行了 slither-check-upgradeability
• [ ] 初始化程序受 initializer 修饰符保护，不可重复调用
• [ ] 验证了所有升级版本的存储布局兼容性
• [ ] 实现合约中没有 selfdestruct
• [ ] 升级具有协议级时间锁，独立于系统级控制
• [ ] 合约已针对测试网上即将到来的 OP Stack 升级进行了测试

重放与跨链身份

• [ ] 强制执行 EIP-155 —— 所有签名负载中都嵌入了链 ID (8453)

• [ ] 跨链消息 Nonce 已验证，并带有到期时限

• [ ] 不假设 L1 和 L2 上的相同地址意味着相同的字节码

• [ ] 承诺-揭示窗口考虑了 L1 确认深度 + FORCE_INCLUSION_PERIOD

• • *

参考：关键地址（Base 主网）

联系我们

在 Zealynx，我们专注于 L2 智能合约安全 —— 也就是这些漏洞存在的 EVM 机制、Rollup 架构和跨链信任边界的精确交汇点。无论你是在 Base、Optimism 还是任何 OP Stack 链上部署，我们的团队都会针对自动化工具遗漏的 L2 特定差异进行审计 —— 申请审计。

想要通过更多此类深入分析保持领先？订阅我们的时事通讯，确保你不会错过未来的见解。

FAQ: Base L2 安全审计

1. 什么是 EVM 等效性，为什么它不能保证 Base 上的安全？

EVM 等效性意味着 Base 通过经过最小修改的执行客户端（op-geth）运行与以太坊主网相同的字节码指令和执行逻辑。然而，等效性仅适用于操作码行为 —— 而不适用于周围的链环境。区块时间（2 秒对比 12 秒）、双重 Gas 费用模型（L2 执行 + L1 数据费）、存款交易的交易来源别名化，以及定序器控制的时间戳都与以太坊 L1 不同。依赖于区块计时的延迟、tx.origin 检查或单费用 Gas 预估的合约在 Base 上的表现会不同 —— 或者完全崩溃 —— 尽管运行着完全相同的字节码。

2. 什么是 Base 上的地址别名，它如何破坏访问控制？

地址别名是应用于 L1→L2 存款交易的一种安全机制。当一个 L1 合约（而非 EOA）向 Base 发送存款时，发送者地址会通过增加 0x1111000000000000000000000000000000001111 进行偏移。这可以防止攻击者在 L1 和 L2 的相同地址部署合约，从而伪造跨链身份。当智能合约使用 tx.origin 进行访问控制时，问题就出现了：在存款交易中，tx.origin 返回的是别名地址，而不是原始的 L1 发送者。任何基于 tx.origin 的授权检查都会失败，或者更糟，为非预期的地址通过。接收 L1→L2 存款的合约必须在其认证逻辑中显式处理别名。

3. 为什么 block.number 在 Base 上的表现与在以太坊上不同？

以太坊 L1 约每 12 秒产生一个区块，而 Base 每 2 秒产生一个区块 —— 快了六倍。这意味着任何使用 block.number 来衡量时间跨度的逻辑执行速度都会比预期快六倍。一个在以太坊主网执行约 3.3 小时的 1,000 区块冷却时间，在 Base 上仅执行约 33 分钟。归属计划、治理时间锁、拍卖窗口和速率限制逻辑都需要从以区块计数转换为以时间戳计数。解决方法是改用 block.timestamp，无论区块产出率如何，其表现都是一致的。

4. 如果 Base 定序器宕机了会发生什么 —— 它会影响我的协议吗？

是的。Base 运行由 Coinbase 运营的单一中心化定序器。如果它离线，则不会处理新的 L2 交易。在停机期间，价格预言机喂价会过时，待处理的清算无法执行，拍卖截止日期可能会在没有出价的情况下过期，治理提案可能会失效。当定序器恢复时，排队交易的突然处理可能会因价格过时而触发级联清算。协议必须实施优雅降级：带有备用逻辑的预言机过时检查、为时间关键操作延长执行窗口，以及当在定义的阈值内没有新区块到达时暂停敏感功能的熔断机制。用户仍然可以通过 L1 存款强制包含交易，但会有长达 12 小时的延迟。

5. Base 上的双重 Gas 费用模型如何影响智能合约经济学？

与以太坊 L1 用户支付单一执行 Gas 费不同，Base 交易产生两部分成本：L2 执行 Gas（便宜，类似于任何 L2）和 L1 数据费（用于将交易数据发布到以太坊以实现数据可用性）。L1 数据费通常在总交易成本中占主导地位，并随着以太坊 L1 Gas 价格和 Blob 基础费用而波动。硬编码 Gas 假设、实施基于 Gas 的退款机制或在不查询 0x420...000F 处的 GasPriceOracle 预部署合约的情况下估算交易成本的协议将系统性地低估操作。使用未签名的 RLP 编码交易调用 GasPriceOracle.getL1Fee(bytes) 以获得准确的总成本。此外，L2 基础费用不会被销毁（它们累积在 BaseFeeVault 中），这破坏了任何假设 ETH 通缩机制的代币经济模型。

6. Base 上 7 天的取款延迟是什么，我的协议可以绕过它吗？

7 天取款延迟是 Optimistic Rollup 安全模型的基础。当从 Base 向以太坊 L1 提取资产时，用户必须：(1) 在 L2 上发起取款，(2) 在输出根被提议后在 L1 上提交 Merkle 证明，并且 (3) 在最终确定前等待争议窗口（约 7 天）。这个窗口允许任何人通过故障证明系统挑战无效的状态根。任何协议都不应构建绕过或缩短此延迟的逻辑 —— 它是防止恶意提案者通过欺诈性状态根掏空网桥的唯一机制。如果你的用户需要更快的 L2→L1 流动性，请集成第三方快速桥（Across、Stargate、Hop），它们使用自己的流动性池来垫付取款，但要独立审计该桥的信任模型：私钥托管、预言机依赖和池偿付能力假设都是额外的攻击向量。

术语表

查看完整术语表 →

• 原文链接： zealynx.io/blogs/base-l2...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～