Raptr: 全球交易引擎的共识层

 作者: Andrei Tonkikh, Balaji Arun, Zhuolun Xiang, Zekun Li, Alexander Spiegelman

摘要简述

前缀共识是一种范式转变，让基于领导者（leader-based）的拜占庭容错（BFT）协议重焕生机。

Raptr 是一项全新的 BFT 共识协议，同时实现了高吞吐、低延迟和强鲁棒性三大难题的突破。

Raptr 引入前缀共识这一全新范式，将乐观和悲观设计的优势融合，实现快速确认区块同时不牺牲安全性。

在类主网环境中，Raptr 可实现 25 万 TPS 和 750 毫秒延迟，并在全网故障情况下依然保持稳定表现，而当下最领先的 DAG 协议在内的其他方案则难以维持性能。

高性能的关键：并行数据传播

近期的突破来自将交易传播从共识逻辑中解耦。通过允许所有节点并行广播交易，Narwhal 和 Bullshark 等协议消除了领导者瓶颈，提升了可扩展性，使得高吞吐在分布式环境中成为可能。

悲观路径：高延迟但稳健

Aptos 的 Jolteon* 搭配 Quorum Store 是典型的悲观路径设计。这种方式虽然鲁棒、可扩展，但数据传播需三轮消息交互，导致额外延迟。此延迟主要来源于认证流程：节点需广播交易批、收集签名、再广播摘要和聚合签名，最终才可进入共识阶段。

乐观路径：低延迟但脆弱

如 Cordial Miners 及其实现 Mysticeti 等协议基于未认证 DAG，省去了传播延迟，理想状态下延迟极低。但一旦出现网络波动（如 0.05% 丢包），延迟可能暴增 10 倍，因为需在关键路径上拉取缺失 DAG 节点。

Baby Raptr：优化悲观路径

Baby Raptr 以乐观方式消除了 Quorum Store 认证流程带来的延迟：它允许共识领导者在尚未获得完整证明的情况下直接提议批次摘要；节点只有在本地已拥有对应批次数据时才参与投票。这样可以减少两个消息轮次的延迟。

然而，这种方式也带来了类似未认证 DAG 协议的脆弱性：一旦节点缺失某个批次数据，就必须在投票前先行拉取，从而造成性能拖延。它是悲观路径的一种乐观化变体，但仍继承了未认证 DAG 设计中固有的脆弱问题。

Raptr：两者兼得的新设计

Raptr 是基于领导者的协议，融合了乐观与悲观传播的优点，提出了 前缀共识 这一新范式。每个节点对其本地拥有数据的最长前缀投票，确保即便有部分节点缺失数据，系统仍能推进共识流程。

算法创新

前缀投票与部分提交

传统的基于领导者的 BFT 协议采用二元投票机制：节点要么对整个提议区块投票，要么完全弃权。Raptr 完全重新思考了这一模式。与 Baby Raptr 类似，每轮领导者会提出一个包含一系列批次摘要的区块。但不同的是，Raptr 不要求节点在投票前必须拥有所有批次的数据。每个节点只需对其本地已有数据的最长前缀部分投票。

共识过程如下所示：

• 区块提议中仅包含批次的摘要，而非完整数据；
• 节点会对其本地已接收的最长批次前缀发起 QC 投票（QC-vote）；
• 当收集到一组 QC 投票构成法定多数时，生成一个法定证书（Quorum Certificate，简称 QC），用于证明某个前缀的有效性；
• 节点随后会基于所获得的 QC 发起 CC 投票（Commit Certificate Vote）；
• 收集到足够的 CC 投票后，形成提交证书（CC），从中确认并提交法定多数中最短的已认证前缀；

为保证跨轮次的安全性与活性，下一轮的领导者会基于以下二者之一提出新的区块：

• 上一轮中存在的完整前缀 QC，或
• 它观测到的提交证书（CC）或超时证书（TC）中最长的认证前缀。

超时证书（TC）与 CC 构造类似，由节点广播其已看到的最高 QC，并通过聚合这些超时信息来帮助下一轮恢复共识，尤其在领导者超时的情况下。

这一设计使数据的传播更具乐观性，同时允许共识以网络速度推进。即便部分节点尚未接收到所有数据，也能基于已有前缀参与投票，从而避免因慢节点或故障节点导致的关键路径阻塞。

安全性的核心在于前缀包含性：即便不同节点在某一轮提交的前缀不同，这些前缀也必然是彼此的扩展，确保最终区块链上的前缀一致可扩展。

下图展示了一个前缀共识链的结构。

在这个例子中，部分节点可能在第 2 轮仅提交了白色子区块作为前缀。然而，没有任何节点能够提交整个区块，因为下一轮的区块延续的是一个不包含最后子区块的前缀。

解耦可用性与安全性

将共识的可用性与安全性投票组解耦，是 Raptr 的另一项关键创新：

• 可用性：只需 f+1 个 QC-vote 即可证明某个区块前缀是可用的（确保至少有一个诚实节点持有该数据）。
• 安全性：其余用于构成 2f+1 的 QC 的投票可以对应较短的前缀。

这种灵活性使得 Raptr 即使在只有部分节点拥有完整数据的情况下，也能以网络速度推进共识，极大提升了其在数据丢失或网络分区情况下的鲁棒性。

下图展示了 Raptr 中对前缀进行非二元投票的示意。

四个节点（R1、R2、R3、R4）各自接收到同一区块中不同的交易批次子集（绿色），并就它们本地可用的最长前缀进行投票。在本例中，R1、R2 和 R3 的 QC-vote 共同认证了前缀 3（满足 f+1 的可用性投票组），而 R2、R3 和 R4 的 QC-vote 则认证了前缀 4。在形成 QC 之后，节点会基于已认证的前缀进行 CC-vote 投票。R1、R2 和 R3 的 CC-vote 提交了前缀 3，而 R2、R3 和 R4 的 CC-vote 提交了前缀 4。下一轮区块提案将基于这些 CC 中最长的已认证前缀进行扩展，在该示例中为前缀 4。

架构创新

Raptr 不仅在算法层面进行了革新，还融合了多项工程驱动的实用优化，确保其在真实世界中的可扩展性：

• 网络分离：共识协议消息与交易数据通过不同的 TCP 通道进行传输，从而减少对关键路径逻辑的延迟干扰。值得注意的是，这种分离在非认证的 DAG 协议中尤为难以实现，因为这些协议中共识逻辑与数据传播高度耦合。
• 聚合签名：Raptr 使用了专为前缀投票设计的高效签名方案，使得投票和提交证书的形成速度更快，同时避免签名验证成为性能瓶颈。
• 信誉机制：协议会追踪所有领导者与交易批次创建者的行为。对于频繁出错的节点，系统会降低其优先级，从而提升整体延迟表现并增加完整区块被提交的概率。
• 缓解三角不等式效应：Raptr 设定了批次最小时间限制，即只有当一个批次传播时间足够长、被大部分节点接收后，领导者才能将其摘要纳入提案。这一机制可避免因传播不均而导致的部分投票，是在网络存在三角不等式（即某些消息路径显著慢于其他路径）时的重要性能优化手段。

实验评估

尽管许多共识协议在理想条件下表现优异，真实部署中却不可避免地面临网络不稳定的挑战。验证节点分布在全球各地，网络常常遭遇丢包、延迟和消息丢失等问题。为全面评估 Raptr 的性能，我们在理想场景与网络不稳定环境下，分别将其与最新的共识协议进行了对比。

最佳情况：强网络，无故障

在一个由 100 个地理分布节点组成的测试网络中，Raptr 在延迟低于 1 秒的条件下实现了每秒 26 万笔交易（TPS）的峰值性能。此外，Raptr 在整个负载范围内始终保持低且稳定的端到端延迟：在 10,000 TPS 时延迟为 610 毫秒，在 250,000 TPS 时仅为 755 毫秒。如下图所示，这一表现几乎是领先 DAG 协议吞吐量的两倍，延迟最多降低了 40%。

值得强调的是，Raptr 同时具备悲观型数据传播设计（如现有 Aptos 部署中采用的 Quorum Store + Jolteon*）的高吞吐优势，以及乐观设计（如 Baby Raptr）的低延迟特性。

网络异常下的表现

在真实世界的部署中，短暂性故障与消息丢失是无法避免的。下图展示了在两种不同的网络环境下，Raptr 相对于最新 DAG BFT 协议的性能对比。

首先，我们评估了协议在 0.05% 消息丢包率 条件下的行为（图中红色虚线表示测试开始时间）。

随后，我们将消息丢包率提高至 1%：

我们的实验评估表明：

• Mysticeti 在仅 0.05% 的消息丢包下就出现显著性能下降，这是由于其未认证的 DAG 结构需要在共识关键路径上获取丢失的 DAG 节点；
• Shoal++ 和 Baby Raptr 在 0.05% 丢包下表现出中等程度的退化，而在 1% 丢包时则性能明显恶化；

Raptr 则表现出极强的鲁棒性和稳定性。得益于前缀共识机制，Raptr 在只有部分数据可用的情况下依然可以推进共识。即使在 0.05% 的丢包条件下，Raptr 几乎没有性能下降，而其他主流共识协议延迟最高增加 10 倍。在 1% 丢包下，Raptr 的延迟仅增加约 15%，吞吐量几乎保持不变。

结论

通过引入前缀投票、部分区块提交，以及将可用性与安全性解耦，Raptr 实现了拜占庭容错（BFT）协议的“圣杯”：超高吞吐、近最优延迟和强大的去中心化鲁棒性。

这不仅是一次渐进式的优化，而是一种范式的转变 —— 前缀共识重新定义了共识协议的设计方式，真正实现了悲观设计的健壮性与乐观路径的速度并存。

完整内容详见论文原文。