Flashblocks：深度解析 - OP Mainnet 上的 250 毫秒预确认 - Optimism

链上应用成败取决于用户体验。如果交易感觉缓慢或不可预测，以太坊可扩展性的承诺就会落空。这就是 Flashblocks 的用武之地，它是由 Flashbots 构建的流式区块构造层，现在已部署到 Optimism 的 OP Mainnet。Flashblocks 没有等待标准的 2 秒区块时间，而是将区块分解为更小的块，并每 250 毫秒发出一次。这创造了一个预确认流——交易将被包含的强烈信号——为用户和应用程序提供近乎即时的反馈。

为什么这很重要？ 因为用户体验至胜。当交易感觉是即时的，应用程序会变得更具吸引力和可信度。DeFi 交易者可以快速反应，游戏可以响应迅速地更新，社交应用程序感觉很灵敏。

在这篇文章中，我们将介绍 Flashblocks 的工作原理、我们的基础设施设置、我们添加的可靠性和安全保障，以及我们为使其投入生产所做的性能改进。

Flashblocks 如何工作

Flashblocks 的核心是重新构想了交易在 OP Mainnet 中的流动方式。在传统模型中，排序器每 2 秒构建一个区块。在该区块生成之前，用户不知道他们的交易是否会被包含。

Flashblocks 通过引入流式区块构造打破了这个等待游戏。Flashblocks 不是将所有内容都保留到区块最终确定为止，而是每 250 毫秒发出这些逻辑子区块。每个 Flashblock 都包含最终将成为规范区块一部分的交易的一部分。其他节点可以立即开始执行这些交易，用户几乎可以立即看到他们的操作反映出来。

最终区块仍然每 2 秒生成一次，包含正确的状态根和所有共识保证。Flashblocks 不会取代最终性——它们在最终性的基础上分层了一个 UX 级别的预确认系统。

Optimism 的基础设施设置

引入 Flashblocks 需要仔细设计一种能够处理流式区块而不破坏协议正确性的基础设施。目标很明确：

1. 无需更改协议即可实现近乎即时的 UX：保持底层合约不变

2. 通过构造确保安全：始终针对规范构建器 (geth) 进行验证

3. 感知到领导者的传播：只有活跃的排序器才能发出 Flashblocks

4. 稳定的开发者界面：通过标准 JSON-RPC 公开 Flashblocks

核心组件

为了实现这一点，引入或调整了几个组件：

• op-node (共识客户端): 未修改。发出 Engine API 调用，并且不知道 Flashblocks。

• op-geth (执行客户端): 充当规范构建器和验证回退

• op-rbuilder (修改后的基于 reth 的执行客户端): 构建规范区块并以 250 毫秒的节奏发出 Flashblocks

• rollup-boost: 在 op-node 和执行客户端之间进行调解，针对 op-geth 验证 op-rbuilder 的输出并选择可信来源

• op-conductor: 管理排序器编排，确保只有当前的领导者转发 Flashblocks

• flashblocks-websocket-proxy: 通过监听所有 conductor 但仅转发领导者的流来提供稳定的 WebSocket 端点

• Flashblocks 感知的 RPC 节点: 订阅代理并使用子区块更新来扩充 eth_getBlockByNumber("pending")

控制平面

部署通过 rollup-boost 中的三种模式进行控制：

• Off: 没有 Flashblocks。所有 engine 调用都仅转发到 op-geth 。

• Dry Run: 影子验证。Engine 调用转发到 op-rbuilder 和 op-geth，但仅接受 op-geth 的 payload。记录差异以供分析。

• On: 生产模式。op-rbuilder 被视为主要的区块构建器，其 payload 被使用并与 op-geth 进行交叉检查，并在需要时自动回退。

数据平面

一旦 Flashblocks 处于活动状态，数据流如下所示：

1. op-rbuilder 以 250 毫秒的间隔发出 Flashblocks（请注意，该间隔是可配置的）

2. rollup-boost 过滤掉从 op-rbuilder 监听到的过时/重新组织的 Flashblocks，并转发剩余的 Flashblocks。针对 op-geth 验证 op-rbuilder 返回的 payload

3. op-conductor 监听来自 rollup-boost 的 Flashblocks，并且只有在其排序器是领导者的情况下才进一步转发它们。

4. flashblocks-websocket-proxy 聚合来自领导者流的 Flashblocks 并公开单个稳定的端点

5. RPC 节点使用该流并每 250 毫秒更新一次待处理区块视图

这种架构确保可以安全地流式传输 Flashblocks，而不会将用户暴露于冲突或过时的数据。

可靠性和安全性

只有在可信的情况下，快速确认才有用。稍后消失的预确认会破坏用户信心。这通过几个保障措施来解决。

Re-org 安全 一个挑战是防止 Flashblocks 在意识到它们具有过时的 payload_ids 或被重新组织出来后“泄漏”。为了解决这个问题，rollup-boost 跟踪与每个 Flashblock 绑定的 payload ID。如果 Flashblock 属于一个已被无效的区块（payload），则在到达客户端之前将其丢弃。这保证了用户永远不会看到幻像预确认。

感知领导者的转发 由于存在多个排序器，因此任何时候只能有一个领导者。op-conductor 通过仅在其排序器拥有领导权时才转发 Flashblocks 来强制执行此操作。如果领导权发生变化，则新设置的领导者开始生成和转发 Flashblocks，而之前的领导者停止。这有助于解决多头场景，即多个 op-rbuilder（因此，rollup-boost）可能发出 Flashblocks，尽管它们不是领导者状态。

验证和回退 为了对区块构建更有信心，必须针对 op-geth 交叉检查 op-rbuilder 生成的 payload。如果它发散或滞后超过阈值，rollup-boost 会立即将 payload 切换回 op-geth。用户仍然会看到可靠的区块数据，只是没有 Flashblocks 直到构建器恢复。

运营强化 最后，该系统旨在抵抗运营故障和 DoS 攻击。Flashblocks 代理是水平扩展和速率限制的。特定于提供商的代理（例如 QuickNode、Ankr 等）需要 API 密钥，从而隔离了租户并防止了嘈杂的邻居压垮系统。

结果是一个安全网，Flashblocks 增强了 UX，而永远不会破坏 OP Mainnet 的规范保证。

性能增强

大规模部署 Flashblocks 揭示了多个瓶颈，每个瓶颈都需要有针对性的解决方案。

磁盘 I/O

op-rbuilder 是 I/O 密集型的，标准的 SSD 无法跟上。延迟导致错过了 Flashblock 间隔。为了解决这个问题，op-rbuilder 被部署在 NVMe 支持的主机上。还构建了一个内部快照/恢复工具来拍摄一致的快照并快速启动新节点，从而使发布和事件恢复更快。

Mempool 处理 使用 Flashbots 的 Contender 进行负载测试显示，op-rbuilder 上的待处理交易量激增。由于这个原因，即使在用户交易等待时，它也产生了空区块。这可以追溯到 reth 和 geth 之间的 mempool 默认值差异。通过调整诸如 txpool.max-account-slots 和 txpool.max-new-pending-txs-notifications 之类的参数，mempool 现在可以更平稳地处理突发交易，从而使区块构建器保持忙碌状态。

防止空区块 在极少数情况下，尽管进行了之前的修复，op-rbuilder 仍然可能产生几乎为空的区块，而 op-geth 产生具有交易的相同区块。为了防止这种情况，添加了称为“gas-used”的区块选择策略。它的工作原理是确保如果 op-rbuilder 生成的区块使用的 gas 比 op-geth 生成的区块少 10%，则 rollup-boost 会丢弃它，而选择 op-geth 的区块。这消除了“空区块”的极端情况。

超时 考虑到我们的网络拓扑，默认的 BUILDER_TIMEOUT 和 L2_TIMEOUT 值 (1000ms) 对于 Flashblocks 的流式传输节奏来说过于激进。它们导致了错误和重试。通过将这些超时值提高到适合我们拓扑的值，几乎消除了与超时相关的错误，而没有牺牲响应能力。

感知领导者的转发 为了防止多个 op-rbuilder 同时生成 Flashblocks 的罕见的多头场景，与 Base 合作增强了 op-conductor，以通过 rollup-boost 监听来自 op-rbuilder 的 Flashblocks，并且仅在其排序器是领导者时才转发它们。这确保了代理只看到一个权威流，即使其他构建器继续在本地生成。

Mempool 重新广播器 另一个微妙的问题是 op-geth 和 op-rbuilder 在交易接受方面的差异。有时，geth 接受的交易会被 rbuilder 拒绝，从而导致包含延迟。由 Base 贡献的 mempool 重新广播器现在定期运行，以对两个 mempool 进行区分并将缺少的交易重新插入到 op-rbuilder 中。这种自我修复机制提高了交易的一致性并减少了丢弃的交易。

启动和同步安全 最后，从创世区块同步新的 op-rbuilder 节点非常缓慢。为了解决这个问题，现在可以将现有 NVMe 支持的节点的快照恢复到新主机上。然后使用专用的 op-node-rbuilder 通过“共识层”同步模式而不是“执行层同步模式”进行同步，从而大大加快了该过程。在此期间，rollup-boost 以 off 模式运行，以避免导致 FCU 调用触发“执行层”同步。

总而言之，这些改进使 Flashblocks 能够在真实条件下维持可靠的 250 毫秒的节奏，同时最大限度地降低运营风险。

衡量的影响

• 待处理交易池稳定性

  • 之前： 频繁的峰值高达 4,000 笔交易；持续稳定在 1,000 笔左右。

  • 之后： 基线约为 ~60 笔交易，偶尔峰值达到 ~100 笔交易。

  • 影响： 稳定状态积压减少约 94% (1,000 → 60)，最坏情况下的峰值减少 97.5% (4,000 → 100)。

• Flashblocks 重组暴露

  • 之前： 在 10 天的时间内浮出水面的 600+ 笔重组的 Flashblocks。

  • 之后： 0 笔暴露（在 rollup-boost 处过滤）。

  • 影响： 100% 防止用户可见的重组 Flashblocks。

• op-rbuilder 支持存储

  • 之前（网络连接的 SSD）： 零星的区块时间降级至 2.5–3.0 秒。

  • 之后（NVMe 支持的主机）： 接近 100% 的健康链和区块以目标节奏进行。

• op-rbuilder 启动和同步

  • 之前： 从头开始恢复需要 几天到几周。

  • 之后： 通过 NVMe 快照 + 恢复 + 共识层追赶，所需时间 <8 小时。

  • 影响： 数量级 更快的恢复和更安全的发布。

结论

总而言之，这些更改将 Flashblocks 从一个有希望的原型转变为一个生产强化的路径。

感知领导者的转发、在 rollup-boost 处进行重组过滤以及 gas-used 回退消除了主要的故障模式，例如重组的 Flashblocks、空区块和 mempool 漂移，而 NVMe I/O、调整的 txpool 参数和适当大小的超时可维持真实负载下的 250 毫秒节奏。

在运营上，快照/恢复、双实例代理和 mempool 重新广播缩短了恢复时间并减少了事件的影响范围。结果是一个更快、更安全且更易于操作的系统，而无需客户端更改其使用 JSON-RPC 的方式。

为 Superchain 带来更快的 UX

Flashblocks 为 OP Mainnet 带来了阶跃式的改进 - 通过每 250 毫秒流式传输预确认，它们改变了 DeFi、游戏和社交应用程序的 UX - 所有这些都无需协议级别的更改。对于开发者来说，这意味着围绕立即反馈的假设设计应用程序。交易结算更快，游戏感觉更流畅，用户保持参与。

这仅仅是个开始。在接下来的几个月中，我们将测试更低的 flashblock 时间并将此设置平台化，以将其带给整个 Superchain。如果你正在考虑部署应用程序或启动链，请了解更多 关于 Optimism 的高性能特性如何帮助加速你的愿景。

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