确定性RaptorCast v1：流水线新高度

RaptorCast 是 Monad 的区块传播协议。领导者对区块进行纠删编码，并在两跳内将分片分散到验证者集合中，无论区块大小或验证者数量如何，都能高效地将区块传递给每个验证者。

确定性 RaptorCast (v1) 是在 MIP-10 中指定并在 monad-bft#2811 中实现的重设计。拓扑结构和 Raptor 码的使用保持不变。变化的是编码的生成和提交方式：驱动编码的种子成为轮次、领导者身份和提案时间戳的公开函数；每个编码符号的位置由该种子固定；并且单个 Merkle 根覆盖整个编码，而不是每 32 个数据包批次一个根。

关键收益是：验证者只需验证一个分片与根的一致性，即可对该 Merkle 根进行投票，不再需要等待完整的区块重组完成。此外，v1 防御了两类可能导致领导者拖慢网络的领导者不当行为。

v0 的简要回顾

RaptorCast 的任务是尽快将大型区块提案从领导者传递给每个验证者。两种明显的方法在 Monad 的目标吞吐量下都失败了。

Gossip（以太坊和大多数其他区块链使用）让每个节点将区块转发给少数对等节点，这些对等节点再继续转发。带宽分布在整个网络中，但传输可能需要多跳，并且区块到达给定验证者所需的跳数没有严格限制。

从领导者直接传输到每个验证者给出了可预测的一跳数，但代价是领导者的带宽。拥有 1 Gbps 上行链路的领导者，将 2 MB 区块串行发送给 1000 个验证者，大约需要 16 秒。支持 Monad 的高吞吐量目标将要求验证者拥有数十 Gbps 的上传带宽，增加了参与门槛并影响去中心化。（更长的版本请参见 Category Labs 的 设计文章。）

RaptorCast 做到了两全其美。每个验证者都在两跳内接收到重建区块所需的所有数据，并且每个验证者的带宽要求最小——大约为区块大小的 3 倍，与验证者数量无关。

四个设计选择实现了这一点：

1. UDP 与每个分片的身份验证。 TCP 的可靠性保证伴随着重传和队头阻塞，这些表现为延迟。RaptorCast 运行在 UDP 上，将数据包丢失视为正常情况，这意味着每个分片必须携带足够的元数据以使接收者能够验证其来自领导者且未被篡改——每个数据包上都带有一个签名和一个证明。

2. 用于容忍丢包的纠删编码。 每个区块使用 R10 Raptor 码编码为比严格所需更多的分片。任何足够大的分片子集都可以解码回原始区块，无论哪些特定的分片到达。只要接收者从大约 2.5K 个传输的分片中收集到大约 K 个分片，解码就会成功。

3. 用于摊销签名的 Merkle 批处理。 使用 ECDSA 单独签名每个分片会占用领导者的大量 CPU。相反，领导者将 32 个分片分组，构建一个小的 Merkle 树，并且只对根进行签名。每个数据包携带签名的根以及一个约 100 字节的 Merkle 证明，证明其在叶子中的位置。一个签名覆盖 32 个分片，并且任何分片都可以独立地针对根进行验证。

4. 两跳扇出，按权益比例。 领导者向每个验证者发送大致与其权益成比例的分片份额。每个验证者将其份额重新广播给所有其他人。通过 2.5 倍冗余，即使控制最多 1/3 权益并丢弃所有接收数据的对手，也无法阻止诚实验证者收集所需的约 K 个分片。限制因素变为聚合网络带宽，而不是领导者的链路。

v1 改变了 v0 运作方式的两个方面。

在 v0 中，每个 32 分片组的 Merkle 树仅存在于该组内部。它作为一种签名摊销技巧存在：对根的一个 ECDSA 签名覆盖所有 32 个分片，每个分片携带其成员证明。不同组的根彼此之间或与正在编码的区块没有关联。v1 将编码中的每个分片放在一个 Merkle 树下，并签署该单个根。树更深，因此每个数据包的证明从约 100 字节增长到最多 280 字节。作为回报，根成为对整个区块的绑定承诺：一个验证者在验证了一个分片与根的一致性后，就知道领导者承诺了什么，并且可以在不等待解码的情况下对区块进行投票。

v0 还让领导者对编码符号 ID (ESI) 的选择不受约束；协议中没有东西固定领导者产生分片的 ESI。这种灵活性在实践中并没有带来任何好处，并且它使网络面临局部减速攻击的风险。v1 根据公开数据确定性地指定 ESI 到位置的映射，因此每轮只有一个有效的编码。

v1 额外关闭的两种攻击

v0 中编码选择的自由度打开了两种值得指出的具体攻击。

第一种是 不对称活性。Raptor 码具有度数分布，其中一小部分分片是 singleton：度数-1 的分片直接揭示一个中间符号。剥离式解码器依赖这些分片来取得进展；如果没有足够多的 singleton，它会退回到缓慢的高斯消元。v0 领导者可以对抗性地选择其 ESI 集——将 singleton 发送给受青睐的验证者，而只将高度数修复分片发送给目标——并且 v0 无法检测到这一点，因为领导者发送的每个分片都是单独有效的。

第二种是 混合承诺双花。由于 v0 的 Merkle 根一次只覆盖 32 个分片，并且 ESI 映射不是固定的，恶意领导者可以构建一个单一的根，其 32 个叶子来自两个不同有效载荷的编码。接收到不同子集的验证者支持相同的承诺，同时拥有来自不同区块的分片。领导者签名没有自相矛盾，因此协议没有可归因的双花证据。

v1 改变了什么

规范种子

某轮的 Raptor 编码源自一个种子：

seed = H(round, leader_id, proposal_timestamp)

每个验证者都可以从分片头部已有的数据计算出这个种子。一旦种子固定，编码也就固定了：位置 i 的 ESI 正好是 i，分片 c_i 是在该种子下区块的 Raptor 编码在 ESI i 处产生的任何内容。

验证者会拒绝时间戳超出可接受时钟窗口的分片，因此领导者无法通过尝试多个时间戳来寻找有利的度数分布从而进行种子捣鼓。在窗口内，没有种子选择能给领导者对结果编码的有意义控制。

单个全局 Merkle 根

v1 在编码的所有 n 个分片上构建一个 Merkle 树，而不是每 32 个分片批次一个树。树更深（最大深度 15，而 v0 为 6），因此每个数据包的 Merkle 证明从 100 字节增长到最多 280 字节。然后整个编码位于一个承诺之下：

(c_1, ..., c_n) = RaptorEnc(B, seed)
R               = MerkleRoot(c_1, ..., c_n)
σ               = Sign(round, timestamp, R)

这对 (R, σ) 是轮次的编码承诺。每个分片数据包携带相同的 R 和 σ，以及其位置 i、其 Merkle 证明 π_i 和分片 c_i。

每轮承诺跟踪

每个验证者记录给定轮次中它首先看到的编码承诺 (R, σ)。如果稍后在同一轮次中从同一个领导者到达一个具有不同 R 或 σ 的分片，则这两个承诺共同构成可归因于领导者的双花签名证据。

这关闭了两种攻击：v1 每轮只有一个有效的编码，因此对抗性 ESI 选择不是一个自由度，并且来自同一领导者的任何两个相互矛盾的承诺都是协议可以采取行动的可签名证据。

解码-重新编码验证

在收集到足够多的分片进行解码后，验证者恢复出有效载荷 B，在相同种子下对 B 重新运行编码器，并检查：

MerkleRoot(RaptorEnc(B, seed)) == R

这之所以有效，是因为种子固定了 ESI 到位置的映射；重新编码 B 会产生与原始承诺相同的相同顺序的分片。v0 没有可用的等效检查，因为 ESI 集没有被任何公共信息固定。

解码出与 R 不一致的有效载荷的验证者将丢弃它。

在解码前投票

该协议现在保证任何两个解码出与 R 一致的分片的正确验证者将恢复出相同的有效载荷。不再存在两个诚实验证者看到相同的根却重建出不同区块的状态。

因此，验证者可以在只要有单个分片针对签名根得到验证后，就对 R 进行投票，无需等待完全解码。它最终解码出的内容将与每个其他诚实投票者解码出的内容匹配。在 v0 中，在解码前对 Merkle 根进行投票是不安全的，因为根不绑定到唯一有效载荷。

将解码从共识关键路径中移除带来了显著的吞吐量收益。

monad-bft 中的实现

PR #2811 将 v1 协议与 v0 一起加入，采用四阶段推出，让网络逐步过渡。之前的三个 PR 清理了 v0 代码以实现这一点：

• #2866 统一了分片验证管道，使 v0 和 v1 共享解析、验证和解码。分片验证移至 RaptorcastPacket 方法下，解码缓存停止进行应用消息哈希验证。
• #2970 在按权益比例分片分配器中添加了轮询分配模式。与现有比例策略相同的每个验证者分片数量，但分片 ID 交错。v1 使用此功能使分配从种子可预测。
• #2978 用具体的 EvenPartition 和 StakePartition 类型替换了动态分发的 ChunkAssigner trait，明确了 Partition → OrderedNodes → ChunkAssignment → materialize() 管道。在相同更改中，次级 RaptorCast 也采用了 Fisher-Yates 洗牌和轮询分配。

v1 数据包丢弃了 v0 携带的一个字段：分片头部中的 20 字节 recipient_hash。v0 使用它来告诉转发节点某个数据包是否是给它的。v1 的分配可以从种子和验证者集合计算得出，因此每个验证者可以直接推导出其预期的分片 ID，并丢弃任何不匹配的内容。解码器缓存也重新键控：v0 以应用消息哈希为键，v1 以 Merkle 根为键，因为根是该轮次的规范承诺。

线路格式、2.5x / 2.0x 冗余因子、两跳扇出、次级 RaptorCast 组结构以及速率限制都保持不变。

这解锁了什么

主要好处是验证者可以更快地投票，因为他们不再需要在签名前拥有完整的区块。

Monad 已经将共识与执行解耦。投票不是对该区块交易的最终裁决——执行处理落后 D 个区块。投票证明的是共识有效载荷本身：提议者的头部和一个延迟的 Merkle 根，该根应与验证者自己在 D 个区块前产生的执行结果匹配。

v1 改变了“收到共识有效载荷”的要求。在 v0 中，投票意味着“我拥有这个区块，并且它满足区块有效性规则”——例如，区块内的所有交易都是有效的。这需要完整的区块。在 v1 中，投票意味着“我拥有这个签名的头部加上至少一个能针对 Merkle 根 R 验证的分片，其中 R 承诺了在规范种子下的确定性编码。”对这些投票的 QC 证明超级多数收到了相同的头部和相同的 R。

提议者在事后受到约束。一旦到达足够多的分片来解码区块，验证者在种子下重新编码它，重新计算 Merkle 根，并确认其与 R 匹配。如果不匹配，验证者丢弃区块，认为 QC 的投票无效——它们是在错误前提下投出的——并像提议者错过了其时段一样继续。确定性意味着每个诚实验证者独立解码得出相同的结论，这正是使得在投票时承诺 (header, R) 安全的原因。

流水线收益使确定性 RaptorCast 成为自然的下一步。v1 允许系统继续推动信息传输的极限，让验证者一收到分片就能投票。下一个领导者可以开始将投票聚合到 QC 中，并在前一个区块的分片仍在传输过程中时开始生成下一个区块。区块时间不再受完整区块传播的限制。

查看详情：MIP-10。

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