一条高性能链的出块者要在几百毫秒里，把兆级字节的提案发给全网验证者：直发每个人，出块者的上行带宽先撑不住；丢给几个邻居转发，延迟被拉长，还依赖邻居肯不肯转发。Monad 的网络层为此专门造了一个组播协议，叫 RaptorCast。它把区块做纠删编码切片、按质押权重分派中继责任，用两层广播树把提案在一个网络往返内铺满全网。本文按官方文档拆这套机制。
先切片：Raptor 纠删码
组播的第一步是编码。出块者把提案用 Raptor 码——RFC 5053 记录的纠删编码的变体，文档说明 Monad 为提升小消息编码效率、降低编码计算复杂度做了修改——切成一组数据块，接收方只要集齐足够大的子集就能还原原文。冗余度由节点操作者按预期丢包率选择：文档举了一个算例，若网络丢包 20%、最多 33% 的节点故障或作恶，最坏情形约 53.6% 的数据块能到达目的地，出块者就应加发约 87% 的额外块来对冲。这套账的含义是：不走重传，靠冗余把可靠性买回来。
再分派：两层广播树
RaptorCast 给数据块建两层广播树：出块者站在树根，第一层只有一个非出块者节点，第二层是其余全部验证者。每个数据块可以对应一棵不同的树，而谁来当某个块的第一层中继，按验证者的质押权重比例分派——质押越重，负责中继的数据块越多。这样每个验证者的上行负载与消息大小成线性关系，而与验证者总数基本无关，整个网络的上传带宽都被用来搬运同一个区块。文档脚注同时承认：质押权重分布极端不均时，要偏离等上传性质才能保证交付，这是设计里明写的让步。
跑在 UDP 上，延迟封顶一个往返
传输层是 UDP，一个数据块一个包。默认 MTU 为 1480 字节，扣掉默认默克尔树深度 6 带来的头部开销后，每包留 1220 字节编码载荷。文档的对照算例：2 MB 区块对应 1640 个源数据块，按当前冗余系数 2.5 即 4100 个编码块，按权重分发给其他验证者。RaptorCast 刻意不做下游丢包检测与重传请求——那会破坏延迟预期；它的可靠性完全来自冗余与两层树结构。文档承诺的量化边界是：只要三分之二以上质押权诚实且在线，交付就有保证；最坏传播时间不超过全网最远两节点的一个往返时间。
为什么不用更简单的办法
文档先排除了两条直觉路线。第一条是出块者直接发给每个验证者：最简单，但提案动辄兆级——文档给的参照是一万笔、每笔 200 字节的交易就是 2 MB——出块者一方的上行带宽先耗尽。第二条是发几个邻居、由它们各自再广播：出块者压力小了，但消息要多跳才能到齐，最坏延迟被拉长，而且任何一跳的中间节点如果是作恶节点拒绝转发，整棵子树都收不到。RaptorCast 的取舍是把两者合成：转发责任仍在网络里分摊，但用纠删编码让每一跳都不再可靠传整块，只传自己权重对应的那部分数据块；丢包与单点拒转都变成可以被冗余吸收的噪声，安全边界仍锚在三分之二质押权诚实这条 BFT 常规假设上。
边界与适用
这套协议只负责验证者之间的提案分发，给全节点的区块传播走的是另一条路（文档归为次级分发机制），不能混为一谈。冗余度是操作者自选参数：多发送冗余能对冲丢包、让接收方更早完成解码，代价是占更多带宽。冗余系数、MTU、默克尔深度等取值都会随实现版本调整，文中数字以当时文档为准。本文按官方文档描述机制，不评估任何链的实际性能，也不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。