【英文长推】深入理解 Solana、Monad 与 Celestia 的区块传播逻辑

Chainfeeds 导读：

Solana 的 Turbine、Monad 的 RaptorCast 及 Celestia 的 Vacuum，谁的区块传播速度最快？

文章来源：

https://x.com/ShivanshuMadan/status/1909637635167125970

文章作者：

shivamadan.eth

观点：

shivamadan.eth：Solana 在数据传播方面采用了高度优化的双阶段流程：准备阶段（Preparation）和传播阶段（Dissemination）。在准备阶段，Solana 使用了名为 Gulfstream 的机制，并结合 swQOS（stake-weighted Quality of Service）实现高性能的事务分发。与以太坊等系统拥有的全球 mempool 不同，Solana 的每个 leader 节点维护的是本地 mempool。这种本地化设计消除了多跳 gossip 带来的拥堵开销，显著提高了交易吞吐量。DApp 将交易提交到 RPC 节点，RPC 节点再单跳将交易通过 Gulfstream 转发给即将出块的 leader，由于 leader 排期是预先已知的，任意验证者都能将交易精准路由至下一轮的领导者。在传播阶段，Solana 使用 Turbine 引擎进行块数据传播。Turbine 机制将整个区块打包成多个碎片（shreds），每个最多约 1280 字节，并通过类树形结构分发至整个网络。具体来说，leader 首先将 shreds 发送给根节点，根节点再根据 stake 权重组织其他验证者分层分发。高 stake 节点优先收到碎片，继而转发给下一层。当前 fanout 参数设置为 200，大多数验证者只需 2-3 跳即可获取完整区块数据。Turbine 同时采用了擦除编码（Erasure Coding）技术，即使部分 shreds 丢失，只要获得一定数量，也可恢复整块数据。这一机制支持流水线式验证与投票，在 leader 出块的同时提高整个网络的响应速度。 Monad 的数据传播设计深受 Solana 启发，也分为准备和传播两个阶段。在准备阶段，Monad 不依赖全球 mempool，而是由各验证者维护本地 mempool，并将交易定向发送给未来三位 leader 节点的本地存储池中。每个 epoch 初确定一次 leader 排序，RPC 节点可根据此计划将交易精准路由。如此设计在保证高效带宽利用的同时，也提高了交易被纳入区块的速度。在传播阶段，Monad 使用名为 RaptorCast 的机制。这一机制与 Turbine 相似，但结构更为扁平化。具体来说，RaptorCast 仅需 2 个跳数完成数据分发，采用 NxN 的广播机制（N 为验证者总数）。首先，leader 将区块擦除编码为若干小碎片，然后将这些碎片一次性分发至所有验证者，每个节点根据其 stake 权重接收不同数量的数据块；随后，所有验证者将收到的碎片再次广播给所有其他验证者。这种机制确保了网络中 99% 的节点能在 2 跳内完成整个区块的数据获取。其最大传播延迟不超过最长单跳的 2 倍，大幅缩短了区块传播周期。 Celestia 的数据传播架构被称为 Vacuum!，与 Solana 和 Monad 的推送式（push-based）方法不同，它采用懒加载的拉取式（pull-based）模型，在延迟与吞吐之间做出了更偏向后者的权衡。其准备阶段包含两个部分。第一部分是预通告（Pre-announcement）：在区块生产前，验证者通过 gossip 网络传播称为 VAC（Validator Availability Certificate）的结构，声明验证者 X 拥有交易 Y，并将在 H 高度之前保持可用。VAC 本质上是一种承诺，避免了交易全量传播造成的带宽浪费，仅传播高优先级交易的承诺信息。第二部分是数据检索：当节点检测到其尚未持有的 VAC 时，会基于容量和优先级等标准决定是否发起 WantBlob 请求，主动拉取数据。这种按需拉取机制与 VAC 的 gossip 联动，允许数据在网络中仅流转一次。传播阶段开始时，leader 仅需广播一个精简区块（compact block），其中包含交易承诺、bitmap 和元数据映射等信息。多数节点通过 VAC 提前获取了数据，因此仅需进行完整性验证与必要数据填补。若个别低优先级交易尚未同步，节点可立即请求并快速完成数据恢复。整体来看，Vacuum! 实现了近乎理论最大吞吐的数据同步效率，区块大小与总数据传输量接近 1:1。虽然增加了一跳延迟，但由于请求与响应管线化执行，该设计依然具有极高的效率，尤其适用于地理分布广泛的大规模网络环境。