作者介绍：本文作者 Ryan Chern 曾任 Solana 的工程实习生，也曾是 Quantum Labs 的联合创始人。现任职于加密货币研究中心 Blackhawk Research。
数据可用性对于区块链而言至关重要，它能够确保节点可以轻松访问所有必要的信息以进行验证，从而维护网络的完整性和安全性。然而，在保持高水平性能的同时确保数据可用性是一项重大挑战，尤其是随着网络规模的扩大。
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 个已确认的区块。此处详细解释了承诺状态的差异。这部分共识将在以后的文章中探讨。
当领导者构建并提出整个区块时，实际数据会作为碎片（部分区块）发送到网络中的其他验证者。碎片是验证器之间发送的原子单元。
在较高级别上，Turbine 获取碎片并将它们发送到一组预定的验证器，然后验证器将这些碎片转发给一组新的验证器。下图概括了碎片传播的连续过程：
在此示例中，验证者 1 是指定的槽领导者。在其时隙期间（验证者被指定为 4 个连续时隙的领导者），验证者 1 构建并提议一个区块。验证器 1 首先通过称为粉碎的过程，将块分解为称为碎片的子块。
粉碎将块数据拆分为最大传输单元 (MTU) 大小的数据碎片（可以从一个节点发送到下一个节点而不将其分成更小的单元的最大数据量），并通过 Reed-Solomon 擦除生成相应的恢复碎片编码方案。该方案有助于数据恢复并确保传输过程中数据的完整性，这对于维护网络的安全性和可靠性至关重要。
这种分解和传播过程可确保块数据在 Solana 中快速高效地分发，从而保持高吞吐量和网络安全。
纠删码
在通过 Turbine 树传播碎片之前，首先使用里德-所罗门擦除编码（Reed-Solomon erasure coding，一种基于多项式的错误检测和纠正方案）对它们进行编码。纠删码作为一种数据保护方法，即使在传输过程中某些部分丢失或损坏，也可以恢复原始数据。Reed-Solomon 纠删码是一种特定类型的前向纠错 (FEC) 算法。
由于 Turbine 从根本上依赖于下游验证器的一系列数据包重传，因此这些验证器可能是恶意的（通过选择重播不正确的数据来对抗拜占庭节点或接收不完整的数据（网络数据包丢失）。由于 Turbine 的重传树结构（retransmission tree structure），任何网络范围内的数据包丢失更加复杂，并且数据包未能到达目的地的概率在每一跳（hop）上都会增加。
在较高级别上，如果领导者将块的 33% 的数据包作为纠删码传输，那么网络可以丢弃任意 33% 的数据包而不会丢失块。领导者能够根据网络状况动态调整此数字（FEC 速率），并考虑最近观察到的网络范围内的数据包丢失和树深度等变量。
为简单起见，我们来检查 FEC 率为 4:4 的碎片组。
数据碎片是领导者构建的原始块的部分块，而恢复碎片是里德-所罗门生成的纠删码块。
Solana 上的块通常利用 32:32 的 FEC（64 个数据包中的 32 个数据包可能会丢失，无需重新传输）。正如 Solana 文档所述，以下是保守的网络假设：
· 丢包率 15%
· 50k TPS 每秒生成 6400 个碎片
32:32 的 FEC 速率产生约 99% 的区块成功率。此外，如果领导者选择增加区块成功的概率，他们有权提高 FEC 率。
Turbine 目前使用 UDP 进行区块传播，提供巨大的延迟优势。根据验证者运营商的说法，使用 UDP 将 6 MB + 纠删码数据从 us-east-1 传输到 eu-north-1 需要 100 毫秒，而 TCP 需要 900 毫秒。
Turbine 树
Turbine 树是 Solana 使用的一种结构化网络拓扑，用于促进验证器之间碎片（编码块数据）的有效传播。一旦碎片被正确编码到各自的碎片组中，它们就可以通过涡轮树传播，以通知网络中的其他验证器最新的状态。
每个碎片组都通过网络数据包发送到一个特殊的根节点，该根节点管理哪些验证器是第一层的一部分（1 跳之外）。然后执行以下步骤：
1. 列表创建：根节点将所有活跃验证者聚合到一个列表中，然后根据每个验证者在网络中的权益进行排序。具有较高权益权重的验证者将优先获得更快的碎片，从而使他们能够更快地用自己的投票消息做出响应以达成共识。
2. 列表改组：然后以确定性方式对该列表进行改组。这将使用从插槽领导者 ID、插槽、碎片索引和碎片类型派生的种子，从每个碎片的验证器节点集生成一个「Turbine 树」。在运行时为每个碎片组生成一棵新树，以减轻与静态树结构相关的潜在安全风险。
3. 层形成：然后从列表顶部开始将节点划分为层。划分基于 DATA_PLANE_FANOUT 值，该值决定涡轮树的宽度和深度。该值会影响碎片在网络中传播的速度。当前 DATA_PLANE_FANOUT 为 6。
众所周知的 Turbine 树确保每个验证者确切地知道他们负责中继该碎片的位置。假定当前 DATA_PLANE_FANOUT 值为 6，Turbine 树通常是 4 或 5 跳树（取决于活动验证器的数量）。
此外，如果节点没有获得足够的碎片或者丢失率超过 FEC 率，则节点能够回退到闲话并进行修复。在当前的实现下，缺乏足够碎片来重建块的节点会向领导者发送重传请求。在确定性涡轮机下，任何接收到完整块的节点都可以发送请求节点所需的修复碎片，从而将数据传输进一步向下推送到树中请求数据的区域。
比较 Solana 和以太坊之间的区块传播
Solana 上的区块传播与以太坊不同。以下是一些高级别的差异：
1. Solana 的理想带宽要求（>1 Gbps）明显高于以太坊（geth 建议>25 Mbps）。这种更高的带宽要求归因于 Solana 更大的块大小和更快的块时间。Solana 的设计可以有效利用整个带宽来加快数据传输，从而减少延迟。虽然带宽峰值高达 1 Gbps，但并没有始终如一地使用 1 Gbps。Solana 的架构专门满足了带宽需求的高峰。
2. Solana 使用 Turbine 进行区块数据传播，而以太坊则使用标准的八卦协议。在以太坊上，块数据传播以简单的方式进行：每个节点与网络中的每个其他全节点进行通信。一旦有新的区块，客户端将通过将其发送给其对等方并批准该区块中的交易来验证它。这种机制适合以太坊，因为与 Solana 相比，它的区块大小更小，区块时间更长。当涉及以太坊 L2 汇总数据（不包括 validium）时，传播也遵循八卦协议，块数据存储在以太坊 L1 区块的「calldata」字段中。
3. 以太坊使用 TCP（通过 DevP2P 协议）进行区块传播，而 Solana 使用 UDP（在一些社区支持下过渡到 QUIC）。UDP 和 QUIC 之间需要考虑一些权衡：
· 与 QUIC 相比，UDP 的单向性导致延迟更低，因此需要 QUIC 流。关于将单向流实施到 QUIC 中的讨论正在进行中；
· QUIC 的拥护者声称，虽然自定义控制流可以通过 UDP 完成，但它需要大量的工程工作，而 QUIC 通过本机支持此类功能来减轻这种工作量。最终目标是相同的，但 QUIC 性能的上限（延迟、吞吐量等）是纯 UDP 的当前状态。
这些区别凸显了 Solana 和以太坊采用的独特架构决策，这有助于提高它们各自的性能、可扩展性和网络稳健性。有关 TCP、UDP 和 QUIC 的更深入分析，请查看我们关于 Solana 和 QUIC 的文章。
未来的研究问题
区块传播和数据可用性仍然是开放的研究领域，许多团队都制定了自己独特的方法。虽然指标可能会不断发展，但我们希望提供不同方法及其相关权衡的概述：
1. 关于 Turbine 作为「数据可用性」（DA）机制的一些讨论已经浮出水面。Turbine 充当数据可用性机制，整个区块数据由 Solana 上的所有其他验证器发布和下载。尽管如此，Turbine 缺乏对数据可用性采样（DAS）的支持，该功能可以帮助轻节点在降低硬件要求的情况下验证状态。这是 Celestia 等团队积极的开发重点。与 Turbine 一样，DAS 也使用纠删码，但这样做的明确目的是检测和防止数据隐瞒攻击。
2. 对于 Solana 虚拟机 (SVM) L2（例如 Eclipse），Tubrine 失去了相关性，因为没有设置验证器来在其之间传递数据。就 Eclipse 而言，区块数据被发布到 Celestia 以获得数据可用性——这使得外部观察者能够运行欺诈证明，以确保正确的执行和状态转换。Eclipse 将成为 Solana 网络本身之外 SVM 的首批实现之一。Pyth 还为自己的预言机网络「Pythnet」分叉了 SVM，并作为自己的侧链有效运行。
3. 在 Solana 上，完整节点管理区块传播，同时还参与集成区块链堆栈的其他部分，例如交易排序和共识。如果 Turbine 作为模块化组件在专用硬件上运行，其定量指标是什么？
4. Turbine 优先考虑权重较高的节点首先接收区块数据。随着时间的推移，这会导致 MEV 更加集中化吗？
5. 就原始吞吐量和信任最小化而言，不同的数据可用性方法（例如 EigenDA（水平可扩展的单个单播中继器）和 Celestia（数据可用性采样））与生产中的 Turbine 相比如何？
6. Firedancer 旨在进一步增加数据传播，并针对强大的 10 Gbps 带宽连接进行了优化。他们围绕 Turbine 进行的系统级优化在消费级硬件和专业级硬件的生产中将如何表现？
7. 目前，Solana 上的所有节点都是完整节点（轻客户端实现仍在开发中）。Sreeram Kannan (EigenLayer) 最近描述了在 Turbine 之上实现 DAS-S。是否会支持适用于 Turbine 的 DAS 版本？是否可以实施具有 DAS 的轻客户端来保持高数据吞吐量，同时轻客户端（资源要求低得多）满足信任最小化？
结论
恭喜！在本文中，我们研究了 Turbine 及其在 Solana 更广泛的交易包容领域中的工作方式。我们将 Turbine 与其他数据可用性解决方案进行了比较，并讨论了对该领域开放的不同研究途径。Solana 的 Turbine 协议证明了网络致力于通过利用结构化网络拓扑在验证器之间有效传播块数据来实现高吞吐量和低延迟。
寻找增强数据可用性并提高区块传播效率的方法可以推动更广泛的区块链社区内的创新。对 Solana 和以太坊的区块传播机制的比较分析揭示了它们各自的优势和权衡，并激发了人们对新兴区块链解决方案（例如 EigenDA、Celestia 和 Firedancer）如何在未来塑造这个生态系统进行更深入的讨论。
高效数据传播和数据可用性的解决方案还远未完成。然而，Solana 在不影响安全性和信任最小化的情况下，优化网络性能的方法和坚定承诺受到热烈欢迎。
原文链接
