OP Stack的基准测试 - Optimism

TL;DR:

• 我们正在大力投入对 OP Stack 进行基准测试——重点关注在完整 devnet 上的端到端基准测试
• 我们将瓶颈识别视为首要交付物，而不是脚注
• 我们在具有用户体验护栏的代表性工作负载下测量可持续的“实际工作”
• 这是我们系列基准测试博文中的第一篇

大多数区块链基准测试在生成数字方面很出色，但在解释其含义方面则不尽如人意。你会看到“X TPS”或“Y gas/秒”，但你不会看到交易组合、硬件、状态形态、故障模式、端到端吞吐量，以及系统在持续负载下是否保持稳定。我们的行业经常痴迷于 TPS，最终却优化了错误的东西：一个头条数字，而不是持续的、用户可见的容量。

对于工程师和运营商来说，这种框架提供了一幅不完整的图景，几乎无法使用。如果你无法重现结果，就无法比较版本。如果你无法解释瓶颈，就无法解决它。这就是为什么我们将瓶颈视为首要输出：每次运行都应该告诉你什么限制了吞吐量以及原因。

出于这些原因以及更多原因，我们正在为 OP Stack 构建一个基于工作负载的端到端基准测试框架：在实际条件下，通过护栏和证据，测量实际容量。

我们的目标不是一个华而不实的峰值指标。而是让扩展工作可预测。扩展往往是基准测试的最终目标。但要实现这一点，我们首先必须拥抱持续学习的状态。学习系统实际能承受什么，什么会首先崩溃，以及不同的选择（协议、客户端、配置、基础设施）如何改变性能包络的形态。

基准测试是我们如何将这种学习转化为有用的东西：一个共享的、可辩护的真实来源，工程师可以围绕它进行迭代，运营商可以围绕它进行规划，合作伙伴可以信任它。

这篇帖子是对我们如何思考对 OP Stack 进行基准测试的介绍：我们测量什么，为什么仅凭“TPS”已不足够，以及我们的方法与现状有何不同。

在接下来的帖子中，我们将深入探讨定义（我们计算什么）、方法论（我们如何使结果可重现），以及基准测试输出如何转化为实际工程决策。

为什么基准测试很重要（以及为什么它比看起来更难）

在 OP Labs，我们正在大力投入基准测试，因为我们认为它是使 OP Stack 更快、更安全、更易于操作的最高杠杆方式之一。我们不希望性能只是一系列一次性测试、英勇的调试会话或基准测试的民间传说。为了突破以太坊扩展的极限，我们需要一个像工程一样严谨的测量系统。

如果你在加密领域待过一段时间，你就会看到经典的性能辩论：

“我们有 X TPS，和 Y gas/秒……我们更快，因为我们的数字更大。”

这些数字没错。它们通常只是不完整，因为它们回答的问题与人们实际关心的问题不同：

“在不降低用户体验的情况下，系统端到端地能承受多少实际工作？”

这是我们最关心的基准问题。当一个系统被推到极限时，它很少以整洁的、单变量的方式失败。它作为一个系统失败：

• 延迟增加
• 包含时间增加（交易在 mempool / 队列中等待更长时间才能被包含）
• 尾部百分位数出现尖峰
• 验证器节点落后
• 工程团队开始收到告警

重要的是：这些不是谜团。在链“宕机”之前，你通常可以在指标中看到它即将发生。基准测试是我们如何在受控条件下发现这些早期预警信号，以便在不通过惨痛的教训学习的情况下提高实际容量。

全网络、端到端基准测试

现状：仅执行的基准测试

加密领域的大多数性能数字仍然来自仅执行的测试：一个节点、一个客户端、系统的一个狭窄部分。即使在 L2 世界——“性能”显然不仅仅是 EVM 执行——你看到的大多数基准测试仍然类似于执行层测试。

有一些值得注意的例外，但默认将整个 rollup 管道作为基准测试对象仍然不常见。这太狭窄了。这有点像在测试台上测试汽车引擎的功率并声称你已经测量了整辆车。有用吗？当然。足够吗？远非如此。

仅执行的基准测试通常回答：

• “单个节点执行特定类型交易的速度有多快？”
• “在干净、受控的设置中，我们能达到的最大数字是多少？”

对于协议工程师和运营商最终关心的问题，例如端到端包含行为、持续负载下的稳定性以及当前瓶颈究竟是什么，它们帮助较小。

我们的方法：完整 devnet，端到端（附带瓶颈诊断）

我们的方法从相反的方向开始：我们在一个完整的 devnet 上对 OP Stack 进行端到端测试，因为那里会暴露出真正的限制——排队、协调成本、尾部延迟，以及只有当整个系统承受压力时才能看到的故障模式。

我们希望使用真实的流量模式来获得系统级真相。

端到端 devnet 基准测试回答：

• “在用户体验开始下降之前，整个系统能承受多少？”
• “什么会首先崩溃，为什么？”
• “如果我们改变一件事，下一个瓶颈会转移到哪里？”

对于 rollup 来说，“性能”是整个管道协同工作的产物：交易摄取和传播、排序和区块构建、执行、状态访问和存储行为、L1 协调和发布、持续负载下的节点健康状况，以及围绕这一切的所有事物（加上混乱的事情：方差、故障模式、恢复）。

这不是最简单的路径。全系统测试比单节点测试更嘈杂，也更难做到完美的可重复性。但它们也能发现生产中实际重要的问题：包含时间飙升、故障率上升、无法排空的积压以及节点落后。

更重要的是：每次运行都应以瓶颈诊断结束，而不仅仅是一个头条数字。一旦端到端运行指向一个真正的限制因素，我们就可以使用微基准测试进行放大，隔离测量该组件——但我们从整个系统开始，这样就不会优化错误的东西。

一个简单的例子：你将 sequencer 区块构建性能提高了一倍，但区块无法通过 p2p 足够快地到达验证器节点，因此验证器节点落后。端到端基准测试使这显而易见。

TPS 和 Gas/秒

TPS 是一个诱人的数字。它是科技行业的标准，非常熟悉且直观。但这带来的问题是，并非所有交易都相同。

一个简单的 ETH 转账花费约 21,000 gas。它触及两个账户余额，不执行任何合约逻辑，也不携带 calldata。它是轻量级、可预测且可并行化的——两个具有不重叠账户的转账具有零状态依赖性，可以并发运行。

另一方面，链上 ZK 证明验证（Groth16 或 PLONK）花费约 200,000 到 2,000,000+ gas。其中大部分成本来自通过 ecPairing 预编译进行的椭圆曲线配对操作——45,000 基础 gas 加上每个点对 34,000 gas——证明、公共输入和验证密钥都作为 calldata。内存扩展显著，并且该调用对节点施加真实的 CPU 压力。

而且，两条运行相同 gas/秒数字的链可能在完全不同的资源上遇到瓶颈——一个在执行上，一个在状态根计算上——需要完全不同的扩展投入来解决。

两笔交易。相同的 gas 使用量。网络上的负载完全不同。

这就是为什么头条 TPS 是错误的指标——它将工作负载复杂性扁平化为一个单一数字，几乎无法告诉你实际吞吐量。有意义的基准测试衡量系统在代表性工作负载下可以承受的能力，并使用这些结果发现瓶颈，而不仅仅是分数。

一个 rollup 可以通过推送廉价、同质的交易来“实现大量 TPS”，而这些交易与用户在现实世界中进行的交易并不相似。Gas/秒有类似的问题：它将多维系统压缩为单个标量，可以以不一定能改善用户结果的方式进行优化。

随着工作负载多样化（更多合约密集型活动、不同的 calldata 模式、不同的状态访问行为、不同的延迟敏感性），你开始更少关注“多少交易”，而更多关注：

• 这些交易代表了哪些类型的操作？
• 它们能否长期持续？
• 包含时间和故障率是否保持健康？
• 当你提高负荷时，什么会首先崩溃？

这是我们专注于在具有护栏的代表性工作负载下测量实际工作的另一个原因。

工作负载

我们没有追逐一个通用的头条数字，而是定义了工作负载：版本化、有文档记录的交易类型组合，代表一类真实的链上活动。

这很重要，因为链上活动正在快速分化。稳定币支付工作负载与 DeFi 交易工作负载完全不同——不同的交易类型、不同的状态访问模式、不同的资源限制、不同的延迟要求。随着 OP Stack 为更多金融科技、新金融和机构用例以及消费者 DeFi 提供支持，单一的吞吐量数字不仅不完整，而且具有积极的误导性。它告诉你一条链很快，却没有告诉你它在什么方面快。

基于工作负载的基准测试是我们解决这个问题的方法。每个工作负载都有一个名称和一个版本，一个定义的交易组合，以及一个预期解释，为运营商和合作伙伴提供了根据其特定用例评估系统的公平比较的基础。如果你正在构建一个稳定币支付轨道，你应该确切地知道链在支付工作负载下的表现，而不是一个不代表你的用户的通用工作负载。

工作负载还可以防止你意外地对错误的东西进行基准测试。一个具体的例子：稳定币支付工作负载受数据可用性限制——高交易量，每笔交易计算量低。DeFi 交易工作负载受执行限制——高计算量，来自并发池交互的显著状态争用。相同的链，相同的硬件，完全不同的绑定约束。如果你的基准测试不反映实际工作负载，你就会优化错误的东西却浑然不知。

护栏

如果你必须破坏用户体验才能获得吞吐量，那么它实际上并不算数。因此，我们仅当系统保持在定义的“护栏”内时，才认为吞吐量有效，例如：

• 交易包含时间保持在可接受的范围内
• 故障率保持在低水平
• 持续负载下的稳定性（无无限积压）
• 尾部的可预测行为

这也意味着，完全被垃圾邮件占用的新容量不会增加吞吐量，有意义的收益有助于用户采取行动。

这是“最大持续”基准测试的核心：我们不接受降低用户体验的胜利。如果 p50 看起来很棒，但 p99 却一片狼藉，你没有赢——你只是转移了问题。

瓶颈是交付物

以一份充满数字和图表的报告结束的基准测试只是一半的基准测试。我们希望每次有意义的运行都能获得：

• 一个可辩护的头条结果，以及
• 对限制我们的因素的清晰、有证据支持的解释

这将性能调优从猜谜游戏转变为科学。伴随我们图表的是工程师实际使用的工件：跨百分位数的系统指标、性能分析/跟踪输出以及用于有意义地比较运行的结构化上下文。

目标是缩短从“我们看到了回归 / 我们达到了上限”到“这是证据，这是限制因素，这是下一步要修复的内容”的循环时间。

这个循环就是复利优势。

目标

总而言之，这些是我们的基准测试平台的目标：

• 熟练度：构建一个我们信任（并且可以解释）的标准化、可重复的系统
• 信心：无忧地进行生产更改。尽早发现任何回归
• 公开方法论，以便生态系统可以重现并在此基础上构建我们的结果
• 为我们的可扩展性路线图提供信息：使用证据来优先处理实际推动限制的因素

接下来

这篇帖子是“为什么”和“大局观方法”：在一个完整的 devnet 上，通过护栏，端到端地测量实际性能。

在接下来的帖子中，我们将更具体地阐述。计划主题包括：

• 链上动作/秒：我们所说的“实际工作”是什么意思，我们计算什么，不计算什么
• 工作负载：我们如何定义和版本化交易组合，以便结果随着时间推移保持可比性
• 护栏：“持续”的真正含义是什么，以及为什么 p95/p99 与头条数字同等重要
• 可重现性：我们如何使运行在不同版本和环境之间保持一致和可辩护
• 瓶颈：我们如何从基准测试结果得出清晰的“这是限制因素”的故事，供工程师采取行动

如果你曾看到一张 TPS 图表并想“酷，但这到底意味着什么？”，我们将在接下来的帖子中具体阐述这一点。

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