扩展Base：加速去中心化

我们对故障证明组件的基准测试总结，以确保它们在我们的扩展工作中保持稳定

OP Stack 中的故障证明

Base 最近在主网上启动了故障证明，这标志着我们在逐步去中心化道路上的一个重要里程碑。故障证明允许任何人参与保护 Base，创建一个更值得信赖和开放的经济体。故障证明的一个核心属性是，如果至少有一个诚实的参与者，或“挑战者”参与故障证明游戏，那么游戏应该正确解决。它们是 Base 堆栈的关键组件，并且随着我们不断提高 Base 的吞吐量，我们需要确保我们的扩展工作不会引入与故障证明的任何不兼容性。因此，我们启动了一项专门的计划，旨在分析 OP Stack 中的故障证明系统将如何受到我们的扩展工作的影响，并确保我们能够继续安全地扩展故障证明。如今，Base 的故障证明系统利用了 Cannon 故障证明虚拟机 (FPVM)。你可以在此处阅读更多关于 OP Stack 中故障证明的信息。

Cannon 是 OP Stack 支持的第一个故障证明 VM (FPVM)。它结合了链上和链下组件，以便在 EVM 内部有效地运行 EVM，确保任何状态转换都可以被审计，并被无需许可地挑战。与仅确保交易具有确定性输出（例如，余额和代币转账）的典型以太坊实现不同，Cannon FPVM 模拟了一台以确定性方式运行的计算机——精确到单个 MIPS 指令——同时运行其自身的 EVM 实例。

识别约束

鉴于与故障证明相关的复杂性，今天的 Cannon 实现包含某些简化。Cannon 实现了一组最少的 unix 系统调用——刚好足够分配内存、读取和写入 preimage oracle，并优雅退出。值得注意的是，这不包括与创建和管理线程或其他并发原语相关的 syscall。由于 Cannon 是用 Go 编写的，Go 是一种为并发代码优化的垃圾回收语言，因此存在一些缺点。最重要的是，Cannon 一旦不再需要就无法清理内存，导致 footprint 不断增长，直到程序完成或达到 32 位 MIPS 架构施加的硬性限制。这意味着每次 Cannon 执行都对可用内存有硬性约束。由于执行行为完全是确定性的（故障证明系统的一个基本属性），任何导致 Cannon 耗尽内存的输入都将始终导致其失败。

Cannon 不仅在与其内存限制赛跑，而且还在与时间赛跑。Base 提供了一个设定的时间窗口，供任何人验证或挑战发布回 L1 的状态。在有两名玩家的故障证明争议游戏中，每个玩家只有 3 天多的时间从头到尾运行 Cannon 才能参与。由于 Cannon 提供了多个虚拟机抽象层，并针对确定性进行了优化，因此在 Cannon 上执行 block 的速度比在标准 Base 节点上慢很多个数量级。

为了在这些限制下安全地将故障证明发布到主网，我们需要确保所有 block 始终都是可证明的——尤其是在提高我们的 gas 目标时。换句话说，任何 block 组合都不能通过占用过多时间和内存来“破坏”Cannon。这当然意味着我们需要尽可能多地对系统进行压力测试。

引入新工具

为了应对这一挑战，我们构建了一个开源工具，用于在本地 devnet 中生成可重复的故障证明测试用例。我们首先在 Cannon 之外生成和执行这些测试，以更快地开发和迭代，然后将它们在较慢的 Cannon 环境中运行，以进行比较和指标收集。

每个测试场景都包含一个配置了给定 gas 目标的单个交易。此交易将部署一个合约，该合约将重复执行特定的操作模式，直到达到或超过 gas 目标。每个合约和相关的 forge 脚本都在上面链接的测试存储库中定义。这些测试场景以 4 个 gas 目标执行：1Mgas、2Mgas、3Mgas 和 20Mgas，以便生成和验证线性缩放模型，然后该模型使我们能够预测包含具有相同特征的 100Mgas 的 block 的影响。测试覆盖范围包括 ETH 转移、ERC20 转移、存储写入、存储读取、合约部署以及大多数预编译合约。我们省略了对 Cannon 中的资源约束没有风险的预编译，例如那些可以卸载到 L1 EVM 的预编译。

对于每个测试用例，我们专门评估了 Cannon MIPS 指令计数、内存使用情况和实际运行时间。我们在一个性能低于我们的生产挑战者的运行时环境中执行了这些测试。从这个基线开始，我们再次向下取整到一个非常保守的每秒 10M 指令的执行速度，以便预测每个测试装置的最坏情况挑战者证明时间。

我们学到了什么

从这些测试中，我们确定了两种在使用模式方面最突出的资源约束，即 p256Verify 和 ECAdd 预编译，如下详述。重要的是，我们验证了这些约束不会将我们的扩展工作限制在 60Mgas/秒以下。

p256Verify：时间密集型

p256Verify 预编译（在 RIP-7212 中引入）消耗每个 gas 单位最多的 Cannon 指令，并且不能简单地使用现有的 L1 预编译 preimage 执行模式在链上 MIPS.sol 合约中加速，因为它尚未部署在 L1 上。以每个 gas 大约 10,000 条 Cannon 指令，并使用极其保守的每秒 10,000,000 条指令的执行估计值，p256Verify 预编译可能消耗每个 gas 约 1 毫秒。在更高的 block gas 限制 100Mgas 下，以这些性能特征执行可能需要长达 28 小时。幸运的是，这仍然远低于约 3.5 天的挑战超时，并且对挑战者设置的 minor 改进，例如更快的硬件或软件优化，可以大大缩短此持续时间。

p256Verify：给定实际和估计 gas 使用量的内存使用量和运行时（毫秒）

ECAdd：内存密集型

ECAdd 预编译显示了相对于 gas 使用量的最大内存消耗率，约为每 gas 7 字节。验证一个主要由 ECAdd 预编译组成的 20Mgas block 需要大约 250MB 的 Cannon 内存（包括大约 135MB 的 L1 block 开销），这表明遵循此模式的 100Mgas block 可能会使用大约 690MB 的内存。这仍然远低于 32 位 MIPS Cannon 堆限制（约 1.1GB），并且允许在真实 L1 block 的典型消耗之上有高达 2 倍的误差裕度。

ECAdd：给定实际和估计 gas 使用量的内存使用量和运行时（毫秒）

由于加速的预编译、存储读取/写入、合约部署或 ETH 或简单 ERC-20 代币的转移导致 gas 消耗的 modest 增加，指令计数、内存使用量和实际运行时间没有实质性增加。与其他简单的 EVM 字节码相比，其他非加速预编译（如 SHA256 和 ECMul）消耗了相对大量的指令和内存，但即使在大大增加的 block gas 限制下，也不足以对故障争议游戏的完整性构成任何风险。

Span batch 的影响

另一个重要的发现是，Cannon 的资源使用量不仅受正在验证的单个 L2 block 内容的影响，还受同一 span batch 中包含的所有 L2 block 内容的影响。这意味着，即使单个 block 可能需要包含约 200Mgas 的 ECAdd 预编译才能破坏 Cannon（远远超过今天的 gas 限制），但包含 10 个 block 的 span batch 也可以轻松超过这个限制，并且还有剩余空间。为了降低这种风险，我们将 Base 主网的 span batch gas 限制设置为非常保守的 120Mgas，并根据每个 block 的 gas 限制限制每个 batch 的 L2 block 数量。

展望未来

随着 Base 每 2 秒构建一个 block，并且每个 block 的限制为 120Mgas，我们可以在当前版本的 Cannon 上扩展到大约 60Mgas/秒。这比我们今天的水平大约增加了 3 倍，但远低于我们的 1Gigagas/秒的 north star 目标。幸运的是，目前正在进行许多工作流程，这将有助于与我们的目标一起扩展故障证明。

OP Stack 贡献者目前正在开发对 Cannon 的两项重大升级，这将解决内存限制，并在许多较小的改进和优化的基础上：多线程 (MT) 和 64 位 Cannon。MT Cannon 将引入运行时垃圾回收，防止内存使用量以无限的方式增长。此外，将 Cannon 从 32 位 MIPS 架构迁移到 64 位架构将允许堆增长许多数量级，从而有效地为运行时提供无限内存。多线程和 64 位 Cannon 目前正在接受审计，应该可以在未来几个月内上线测试网。

此外，Base 工程团队正在与其他 OP Stack 核心贡献者合作开发即将推出的 Holocene OP Stack 硬分叉。此升级增加了 partial span batch 验证，通过消除故障证明程序执行 batch 中所有 L2 block 的需求来减少资源约束

既然我们已经开发了一套基本的故障证明测试、工具和参考数据，我们计划对 OP Stack 的所有未来更改进行基准测试，以确保我们能够继续安全地扩展 Base 和更广泛的 Superchain，并将世界带入链上。

附录

为了透明起见，我们在下面包含了我们每次测试的原始数据。所有测试均使用从 v1.9.1 op-stack 版本 构建的 Cannon 和 op-program 二进制文件，使用 go 1.21。

ETH 转移

ERC20 转移

存储写入

存储读取

微型合约的部署

SHA256，带小型输入

SHA256，带大型输入

微型合约的部署

RIPEMD160，带小型输入

RIPEMD160，带大型输入

Blake2f

Modexp

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