X Layer 上的 Flashblocks：实现 200ms 最终性与零重组

本文将对 Flashblocks 的工程细节进行深入的技术分析。我们将详细介绍 X Layer 排序器上的自定义 Flashblocks 构建器集成方案、保障 Flashblock 最终性的零重组保护系统，以及为下游消费者提供超低延迟链状态更新的业界领先 RPC 架构。

这对 DeFi 应用（DEX、钱包）、支付、游戏和实时交互类场景极为重要，因为交易和链状态延迟得到了显著降低。

• 支付：即时支付确认

• DeFi：交易和头寸即时更新

• 交易市场：快速、无摩擦的结算流程

• 游戏：实时操作，无需等待

标准 Flashblocks 架构 — 由 Flashbots 设计并部署在其他 OP 链上采用提议者构建器 (Proposer-Builder Separation, PBS) 模型。它在现有排序器旁引入了两个关键的 Sidecar 组件：

• Rollup-boost：一个位于共识层（op-node）和执行层之间的代理，拦截 Engine API 调用并管理 Flashblock 载荷（payload）状态。

• Op-rbuilder：基于 op-reth 运行的协议外构建器，负责实际的增量 Flashblock 构建，并通过 WebSocket 将载荷流式传输至 rollup-boost。

然而，在使用该架构将 Flashblocks 集成到我们的排序器时，我们发现该方案无法满足 X Layer 排序器的生产吞吐量目标 (以 gas/s 衡量)。我们识别了 3 个关键优化方向，以显著提升排序器吞吐量：

1. Rollup-boost 与构建器之间的状态不一致。 Rollup-boost 组件（充当提议者角色）是有状态的 — 它从构建器的 WebSocket 流中持续累积待处理的 Flashblocks 序列，并将该序列作为规范载荷（canonical payload）。因此，在载荷解析（payload resolution）时，可能出现竞态条件 — rollup-boost 解析其缓存的序列时，构建器仍在继续产出新的 Flashblocks，导致已提交载荷与构建器实际本地构建的载荷之间存在被丢弃的 Flashblocks（即发生重组）。这将导致后续 engine_newPayload 链状态同步在底层 Reth 引擎上发生缓存未命中（cache miss），触发对同一构建器已构建载荷的昂贵重新验证。这进一步浪费了宝贵的出块时间，严重影响排序器的最大吞吐量。

2. 两个执行层客户端的冗余执行。 默认架构将 op-rbuilder 和排序器的默认执行层（op-geth）作为独立的执行客户端维护。两个载荷构建器从本地共享的交易池中构建相同的载荷任务，导致计算和部署开销翻倍，同时需要在所有执行层之间进行状态同步。

3. 状态根延迟计算带来同步开销。 默认设计通过跳过构建器上的状态根（state root）计算来优化 Flashblock 构建时间。然而，这意味着 rollup-boost 仍然需要向默认执行层发送额外的 engine_ForkchoiceUpdate 请求，以重新执行完整载荷来计算状态根 — 这又增加了一次同步操作和重新执行全部载荷交易的开销，并在载荷解析期间阻塞等待状态根计算完成。

因此，构建器以空状态根将已构建载荷提交至其引擎状态树。与状态不一致问题（第 1 点）类似，这会在构建器的链状态同步时触发完整的昂贵载荷重新验证，因为由于区块哈希不匹配，本地构建区块的缓存未命中将 100% 发生。

区块构建工作流程现在变得简洁明了：

1. 每 200ms，主排序器构建下一个 Flashblock，从交易池中获取交易并执行，然后通过 WebSocket 订阅将新的 Flashblock 广播给 Flashblock 订阅者。

2. 载荷解析时（engine_getPayload），Flashblocks 载荷构建器广播最后一个 Flashblock，异步计算状态根，并将该载荷提交到本地引擎状态树。

3. 链状态同步时（engine_newPayload），新的 unsafe 载荷将始终命中缓存，载荷验证被完全跳过 — 因为不再会发生竞态条件或状态不一致。下一个区块构建可以立即开始。

4. engine_forkchoiceUpdated 推进链头。下一个区块周期开始。

性能提升源于消除了所有冗余工作：

• 单一数据源。 仅有一个执行层、一个载荷状态。由于构建器和提议者是同一进程，状态不一致不可能发生。

• 载荷提交零缓存未命中。 每次 engine_newPayload 都命中引擎状态树中本地构建的区块。我们在持续负载下测得 100% 的缓存命中率。

• 无冗余重新执行。 状态根仅在载荷解析期间由构建载荷的同一执行层异步计算一次。无需向第二个执行层发送外部 FCU 请求。

• 单执行层计算/内存开销。 每个排序器仅部署一个执行客户端而非两个，降低了基础设施成本并消除了跨进程同步开销。

在旧架构中，Flashblocks 重组的发生频率过高，无法安全使用 — 例如，每当主排序器发生切换时，Flashblocks 重组发生的概率为 100%，因为新的主排序器会直接从头开始重建区块，丢弃所有已传播的 Flashblocks。

因此，将延迟降低到 200ms 只有在这 200ms 的确认是最终的情况下才有意义。我们在 X Layer 多排序器部署中进行了大量工程优化，通过引入构建器 P2P 协议和 Flashblocks 重放保护来消除 Flashblock 重组。我们构建了一套完整的零重组保护系统，在所有正常运行场景下保障应用层的 Flashblock 最终性。

我们高可用集群中的每个排序器（主节点和从节点）都通过 op-rbuilder 内置的 P2P 层维护持久化的点对点连接。当主排序器产出一个新的 Flashblock 时，它会原子性地将 Flashblock 载荷广播到所有对等排序器，并在该层处理广播失败，然后再向已连接的 RPC 节点订阅者广播。

该 P2P 层有两个作用：确保集群中所有节点拥有一致的 Flashblock 状态，并为下一节中描述的重放机制提供传输通道。

当主排序器切换发生时（由于故障、重启或常规轮换），新提升的主排序器会检查其缓存：如果载荷构建任务与当前缓存的 Flashblock 序列匹配（在其作为从节点时累积），我们将通过重放这些 Flashblocks 而非从头重建载荷，防止这些已广播的 Flashblocks 被丢弃或重组。

这意味着已广播的 Flashblocks 具有原子性，已包含在已传播 Flashblock 中的每笔交易都保持包含且顺序不变，出现在新主排序器的区块中。从 RPC 节点和下游消费者的角度来看，排序器切换是不可感知的 — 没有 Flashblocks 被回退，应用层的 Flashblock 最终性得到保障。

每个 RPC 节点通过 WebSocket 连接到 Flashblock 载荷流 — 可以直接连接排序器集群，也可以连接另一个 RPC 节点（形成中继广播协议）。在设计 Flashblocks RPC 层时，我们采用了混合同步方案：同时消费传入的 Flashblocks 并维持默认的 EL/CL 区块同步。为此，我们设计了以下 4 个核心组件，使 Flashblocks 状态累积层能够运行在规范链状态之前。

1. FlashblockStateCache：覆盖规范链的内存数据存储，维护待处理状态（最新链状态）和已完成区块状态的确认缓存（confirm cache），这些状态领先于规范链头。对 latest 标签的 RPC 查询从确认缓存头部读取；对 pending 标签的查询从当前待处理序列读取。

2. FlashblockSequenceValidator：使用 Reth 高度优化的 PayloadProcessor 执行传入的 Flashblock 交易序列，该处理器包含优化缓存（稀疏前缀树缓存和执行缓存）。我们还将其与默认的 Reth 引擎载荷验证器共享。

3. XLayerEngineValidator：统一控制器，将 Reth 的 BasicEngineValidator 和 FlashblockSequenceValidator 封装在单个互斥锁（mutex）之后，以确保共享载荷处理器的状态一致性。该控制器保障了混合同步方案中的一致性，防止两个输入源（Flashblocks 和传入的默认完整区块）之间的竞态条件。

4. FlashblocksRpcService：顶层服务，消费 WebSocket 流，管理传入的 Flashblock 增量数据，并与 Flashblocks 验证执行任务协调工作。

我们 RPC 层的性能来源于一套新颖的三级状态缓存层次结构，每一级在状态生命周期中承担不同的角色 — 从乐观预确认状态一直到持久化磁盘存储。

• 待处理缓存（Pending cache）：排序器正在构建的当前进行中的待处理区块。每当一个 Flashblock 到达（FB0、FB1、FB2……），FlashblockSequenceValidator 增量执行累积的序列。使用 pending 标签的 RPC 查询直接从该缓存读取。需要注意的是，稀疏前缀树状态会被更新，但中间 Flashblocks 的状态根计算被跳过以最小化延迟，仅在完整序列时才进行计算。

• 确认缓存（Confirm cache）：已完全执行并通过状态根验证、但仍领先于规范链的已确认区块状态的内存缓存覆盖层。使用 latest 标签的 RPC 查询从该缓存状态读取，使 RPC 节点的 Flashblocks 状态同步与 Reth 引擎的规范链状态解耦。

1. Flashblock 增量数据到达：通过 WebSocket 流传入 → FlashblocksRpcService 将原始载荷累积在 RawFlashblocksCache 中，并将构建参数加入 ExecutionTaskQueue。

2. 增量执行：FlashblockSequenceValidator 从任务队列中消费。Flashblocks 序列通过 Reth 载荷处理器进行验证，包括：

   1. 基于传入增量交易的乐观并行账户状态预热（pre-warming）

   2. 增量揭示多重证明（multiproof）并在哈希状态更新时更新稀疏前缀树

   3. 执行增量交易并更新待处理状态，不进行状态根计算

3. 序列完成：序列结束时，验证器通过在稀疏前缀树流水线上解析状态根任务来计算完整的状态根，并利用高度优化的稀疏前缀树缓存计算状态根。已完成的区块从待处理缓存提升到确认缓存。

4. 引擎缓存命中：当共识层发送 engine_newPayload 时，XLayerEngineValidator 检查 Flashblock 状态缓存，对已验证的区块完全跳过载荷重新验证。规范链向前推进。

5. 规范链驱逐：handle_canonical_block 管理 Flashblocks 状态缓存，当规范链状态到达相应的区块高度时，驱逐确认缓存中的条目。

6. 持久化刷写：引擎树将新的规范区块状态刷写到第三级磁盘数据库。

1. Flashblocks 访问列表支持（EIP 7928）：fBAL 已在 xlayer-builder 的开发版本中得到支持。我们计划进一步优化 Flashblocks RPC 同步，利用 fBAL 实现并行交易执行验证。

2. xlayer-builder 上的稀疏前缀树缓存支持：进一步优化 X Layer 排序器的整体链吞吐量。

Flashblocks 在 X Layer 上的实现是迈向链上交互即时体验的关键一步。通过重新思考默认架构并构建专用基础设施，我们实现了能够开启全新链上应用类别的延迟水平 — 从实时交易到互动游戏，再到即时支付。