Turbine：Solana 上的区块传播
本文讲什么？
数据可用性对区块链至关重要。它确保节点能够随时访问验证所需的全部信息，从而维持网络的完整性与安全性。然而，在保持高性能的同时确保数据可用性是一项重大挑战，尤其是在网络规模不断扩大时。
Solana 通过独特的架构设计应对了这一挑战，实现了持续的区块创建与传播。这得益于多项关键创新，例如领导者选择、Gulf Stream（无需内存池）和 Turbine（区块传播机制）。
Solana 的持续运行特性要求系统高效工作，确保所有验证者都能及时收到最新状态。最简单的方法是让领导者直接将所有区块传输给其他每个验证者。然而，鉴于 Solana 的高吞吐量，这种方法会大幅增加带宽及其他资源需求，并削弱去中心化程度。
带宽是一种稀缺资源，而 Turbine 是 Solana 的巧妙解决方案，用于优化从特定区块的领导者到网络其余部分的信息传播。Turbine 专门用于减轻领导者向网络发送数据时的出口压力。
本文将深入介绍 Turbine 的工作原理，以及它在 Solana 整体交易纳入流程中的关键作用。我们还会将 Turbine 与其他数据可用性解决方案进行比较，并讨论该领域尚待探索的研究方向。
什么是 Turbine？
Turbine 是一种多层区块传播机制，Solana 集群使用它向所有节点广播账本条目。Turbine 背后的核心思想已在学术界存在多年，这一点可从发表于 2004 年的论文以及近期的研究中得到印证。
传统区块链会按顺序或以泛洪方式将区块发送给所有节点，而 Turbine 采用了更有组织的方式，以尽量降低通信开销和单个节点的负载。从宏观层面看，Turbine 将区块拆分成更小的片段，再通过分层的节点结构传播这些片段。这样一来，单个节点无需与其他每个节点建立联系，只需和选定的少数节点通信。随着网络规模扩大，这一点愈发重要，因为传统传播方式会因所需通信量过于庞大而难以为继。因此，Turbine 可确保数据在 Solana 上快速、高效地传播。区块传播和验证的速度对于维持 Solana 的高吞吐量与网络安全至关重要。
此外，Turbine 还解决了数据可用性问题，确保所有节点都能高效访问验证交易所需的数据。这一过程不需要巨大的带宽，而带宽正是其他区块链网络常见的瓶颈。
Turbine 缓解了带宽瓶颈并确保区块快速传播，因此显著增强了 Solana 处理大量交易并维持精简、高效网络结构的能力。这一创新协议是 Solana 实现快速、安全且可扩展网络承诺的基石之一。
接下来，让我们深入了解 Turbine 的运行机制，以及它如何在 Solana 网络中传播区块。
Turbine 如何传播区块？
在区块传播（即传输给网络中的其他验证者）之前，领导者会根据传入的交易流构建区块并对其排序。区块构建完成后，就可以通过 Turbine 发送给网络的其余部分。**这一过程称为区块传播。**随后，投票消息会在验证者之间传递，并封装到区块数据中，以满足“已确认”或“已最终确定”的承诺状态。已确认区块是指获得账本绝大多数投票的区块，而已最终确定区块是指已获确认，且目标区块之上又构建了 31 个以上已确认区块的区块。有关承诺状态差异的更多说明，请参阅此处。我们将在后续文章中探讨共识的这一部分。
虽然领导者会构建并提议完整区块，但实际数据会以 shred（部分区块）的形式发送给网络中的其他验证者。shred 是验证者之间传输的原子单位。
从宏观层面看，Turbine 会将 shred 发送给预先确定的一组验证者，然后由这些验证者将其转发给新的一组验证者。下图概述了 shred 持续传播的过程：
在此示例中，验证者 1 是指定的时隙领导者。在其时隙期间（验证者会连续 4 个时隙被指定为领导者），验证者 1 构建并提议一个区块。验证者 1 首先通过名为 shredding 的过程，将区块拆分为称作 shred 的子区块。Shredding 会将区块数据拆分成最大传输单元（MTU）大小的 data shred（无需进一步分割为更小单元即可从一个节点发送至下一节点的最大数据量），并通过 Reed-Solomon 纠删码方案生成相应的 recovery shred。该方案有助于恢复数据，并确保数据在传输期间保持完整，这对于维护网络的安全性和可靠性至关重要。
这一 shredding 和传播过程可确保区块数据在 Solana 上快速、高效地分发，同时维持高吞吐量与网络安全。
纠删码
在 shred 通过 Turbine Tree 传播之前，系统会先使用 Reed-Solomon 纠删码对其编码。这是一种基于多项式的错误检测与纠正方案。纠删码是一种数据保护方法，即使部分数据在传输过程中丢失或损坏，也能恢复原始数据。Reed-Solomon 纠删码是一种特定的前向纠错（FEC）算法。
由于 Turbine 从根本上依赖下游验证者进行一系列数据包转发，这些验证者可能具有恶意（对抗性拜占庭节点），选择重新广播错误数据，也可能收到不完整的数据（网络丢包）。由于 Turbine 采用转发树结构，整个网络范围内的丢包影响会不断累积，数据包每经过一跳，无法到达目的地的概率都会增加。
从宏观层面看，如果领导者将区块中 33% 的数据包作为纠删码传输，那么即使网络丢失任意 33% 的数据包，也不会丢失区块。领导者可以根据网络状况动态调整这一数值（FEC 比率），并将近期观测到的全网丢包率和树深度等变量纳入考量。
为便于说明，我们来看一个 FEC 比率为 4:4 的 shred 组。
data shred 是领导者所构建原始区块的部分数据，而 recovery shred 则是通过 Reed-Solomon 生成的纠删码区块。
Solana 上的区块通常采用 32:32 的 FEC（64 个数据包中可丢失 32 个，无需重新传输）。根据 Solana 文档的说明，以下是较为保守的网络假设：
- 丢包率为 15%
- 50k TPS，每秒生成 6400 个 shred
32:32 的 FEC 比率可实现 ~99% 的区块成功率。此外，如果领导者希望提高区块成功的概率，也可以自行提高 FEC 比率。
Turbine 目前使用 UDP 传播区块，可带来显著的低延迟优势。据一位验证者运营者介绍，使用 UDP 将 6 MB 数据及其纠删码数据从 us-east-1 传输至 eu-north-1 需要 100ms，而 TCP 则需要 900ms。
Turbine Tree
Turbine Tree 是 Solana 使用的一种结构化网络拓扑，用于在验证者之间高效传播 shred（经过编码的区块数据）。当 shred 被正确编码并归入对应的 shred 组后，就可以通过 Turbine Tree 进行分发，让网络中的其他验证者获知最新状态。
每个 shred 组都会通过网络数据包发送到一个特殊的根节点，由该节点管理哪些验证者属于第一层（相距 1 跳）。随后执行以下步骤：
- **创建列表：**根节点将所有活跃验证者汇总到一个列表中，再根据每个验证者在网络中的质押量进行排序。质押权重更高的验证者会优先收到 shred，从而更快地发出自己的投票消息以参与共识。
- **打乱列表：**随后以确定性方式打乱该列表。系统会针对每个 shred，使用从时隙领导者 ID、时隙、shred 索引和 shred 类型派生的种子，根据验证者节点集合生成一棵“Turbine Tree”。每个 shred 组都会在运行时生成一棵新树，以降低静态树结构可能带来的安全风险。
- **形成分层：**随后从列表顶部开始，将节点划分到不同层级。划分依据是
DATA_PLANE_FANOUT值，它决定了 Turbine Tree 的宽度和深度。该值会影响 shred 在网络中的传播速度。当前的 DATA_PLANE_FANOUT 为 200，因此大多数验证者只相距 2 到 3 跳（领导者 -> 根节点 -> L1 -> L2）。
Turbine Tree 对所有节点公开，因此每个验证者都清楚自己应将该 shred 转发到哪里。鉴于当前 DATA_PLANE_FANOUT 的值为 200，Turbine Tree 通常是一棵 2 跳或 3 跳树，具体取决于活跃验证者的数量。
此外，如果节点没有收到足够的 shred，或丢失率超过 FEC 比率，节点可以回退到 gossip 和修复机制。在当前实现中，缺少足够 shred、无法重建区块的节点会向领导者发送重新传输请求。在确定性 Turbine 中，任何收到完整区块的节点都可以发送请求节点所需的修复 shred，从而将数据传输进一步下推至树中请求数据的区域。
比较 Solana 与 Ethereum 的区块传播
Solana 上的区块传播与 Ethereum 不同。以下是一些宏观层面的差异：
- Solana 的理想带宽要求（>1 Gbps）显著高于 Ethereum（geth 建议 >25 Mbps）。Solana 对带宽的要求更高，原因在于其区块更大、出块时间更短。Solana 的设计能够有效利用全部带宽来加速数据传输，从而降低延迟。尽管带宽峰值可能达到 1 Gbps，但并不会持续占用 1 Gbps。Solana 的架构专门支持带宽需求的突发增长。
- Solana 使用 Turbine 传播区块数据，而 Ethereum 使用标准 gossip 协议。在 Ethereum 上，区块数据的传播方式十分直接：每个节点都与网络中的其他所有全节点通信。新产生区块后，客户端会将其发送给对等节点，并批准区块中的交易，以完成验证。与 Solana 相比，Ethereum 的区块更小、出块时间更长，因此这一机制更适合 Ethereum。对于 Ethereum L2 rollup 数据（不包括 validium），传播同样遵循 gossip 协议，区块数据存储在 Ethereum L1 区块的“calldata”字段中。
- Ethereum 使用 TCP（通过 DevP2P 协议）传播区块，而 Solana 使用 UDP（社区中也有人支持迁移到 QUIC）。UDP 和 QUIC 之间存在一些需要权衡的因素：
- UDP 的单向特性使其延迟低于 QUIC，因为后者需要使用 QUIC 流。目前，社区仍在讨论如何在 QUIC 中实现单向流。
- QUIC 的支持者认为，虽然可以在 UDP 之上实现自定义控制流，但这需要大量工程投入，而 QUIC 原生支持此类功能，可减轻这方面的负担。两者的最终目标相同，但 QUIC 性能（延迟、吞吐量等）的上限，就是纯 UDP 当前所能达到的水平。
这些差异凸显了 Solana 与 Ethereum 各自独特的架构决策，它们共同决定了各自的性能、可扩展性和网络稳健性。如需更深入地分析 TCP、UDP 和 QUIC，请阅读我们的 Solana 与 QUIC一文。
未来研究问题
区块传播和数据可用性仍是开放的研究领域，许多团队都在设计自己独特的方法。尽管衡量指标可能不断演变，我们仍希望概述不同方法及其相关权衡：
- 围绕 Turbine 是否属于“数据可用性”（DA）机制，已经出现了一些讨论。从整个区块数据都会发布并由 Solana 上的所有其他验证者下载这一点来看，Turbine 确实是一种数据可用性机制。不过，Turbine 不支持数据可用性采样（DAS）。该功能可以帮助轻节点以更低的硬件要求验证状态。Celestia 等团队正在积极开发这一功能。与 Turbine 一样，DAS 也使用纠删码，但其明确目标是检测和防止数据扣留攻击。
- 对于 Solana Virtual Machine (SVM) L2，例如 Eclipse，由于没有验证者集合负责相互传递数据，Turbine 就不再适用。就 Eclipse 而言，区块数据会发布到 Celestia 以实现数据可用性，这使外部观察者能够运行欺诈证明，确保执行和状态转换正确。Eclipse 将成为首批在 Solana 网络之外实现 SVM 的项目之一。Pyth 也为名为“Pythnet”的预言机网络分叉了 SVM，并实际以独立侧链的形式运行。
- 在 Solana 上，全节点负责管理区块传播，同时也参与集成式区块链技术栈的其他部分，例如交易排序和共识。如果 Turbine 作为模块化组件在专用硬件上运行，其量化指标会如何？
- Turbine 会优先让质押权重更高的节点接收区块数据。长此以往，这是否会导致 MEV 更加中心化？
- 在生产环境中，EigenDA（可水平扩展的单播中继器）和 Celestia（数据可用性采样）等不同的数据可用性方案，与 Turbine 在原始吞吐量和信任最小化方面相比表现如何？
- Firedancer 旨在进一步提升数据传播能力，并针对稳定的 10 Gbps 带宽连接进行了优化。他们围绕 Turbine 实施的系统级优化，在消费级硬件和专业级硬件的生产环境中将表现如何？
- 目前，Solana 上的所有节点都是全节点（轻客户端实现仍在开发中）。Sreeram Kannan（EigenLayer）最近介绍了一种在 Turbine 之上实现 DAS-S 的方案。未来是否会支持适用于 Turbine 的 DAS 版本？能否实现带有 DAS 的轻客户端，在保持高数据吞吐量的同时，让资源需求低得多的轻客户端满足信任最小化要求？
总结
恭喜！本文介绍了 Turbine，以及它在 Solana 整体交易纳入流程中的工作方式。我们将 Turbine 与其他数据可用性解决方案进行了比较，并讨论了该领域中不同的开放研究方向。Solana 的 Turbine 协议利用结构化网络拓扑在验证者之间高效传播区块数据，充分体现了该网络对实现高吞吐量和低延迟的坚定承诺。
探索增强数据可用性、提高区块传播效率的方法，正在推动整个区块链社区的创新。通过比较 Solana 与 Ethereum 的区块传播机制，我们可以了解它们各自的优势与权衡，也能进一步探讨 EigenDA、Celestia 和 Firedancer 等新兴区块链解决方案未来将如何塑造这一生态系统。
高效数据传播和数据可用性的问题远未彻底解决。不过，Solana 在不损害安全性和信任最小化的前提下优化网络性能的方法与坚定承诺，值得肯定。
感谢 @dubbel06 和 @jon_charb 的审阅与建议。
其他资源 / 延伸阅读
订阅 Helius
及时了解 Solana 开发的最新动态，并在我们发布新内容时收到更新