涡轮：Solana上的区块传播

13 分钟阅读

2023年10月24日

这篇文章的内容是什么？

数据可用性对区块链至关重要。它确保所有必要的信息能被节点方便地访问，以便进行验证，维护网络的完整性和安全性。然而，在网络扩展的情况下，确保数据可用性同时维持高性能是一个重大挑战。

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个以上确认的区块建立在目标区块之上的区块。提交状态的差异在此处做了更多解释。这部分共识会在未来的文章中探讨。

当领导者构建并提出整个区块时，实际数据作为shreds（部分区块）发送到网络中的其他验证者。Shreds是验证者之间发送的原子单位。

从高层来看，Turbine将shreds发送给预定的验证者集合，这些验证者再将这些shreds中继到新的一组验证者。以下图示概述了shred传播的连续过程：

在这个例子中，验证者1是指定的插槽领导者。在它的插槽期间（验证者在4个连续插槽中被分配领导者），验证者1构建并提出一个区块。验证者1首先通过称为_shredding_的过程将区块分解成称为_shreds_的子块。Shredding将区块数据拆分为最大传输单元（MTU）大小的data shreds（可以从一个节点发送到下一个节点而不会碎片化的小数据量），通过Reed-Solomon消失编码方案生成相应的recovery shreds。此方案有助于数据恢复并确保在传输过程中数据的完整性，这对于维护网络的安全性和可靠性至关重要。

这种shredding和传播的过程确保了Solana中的区块数据快速而高效的分发，维护了高吞吐量和网络安全。

消失编码

在shreds通过Turbine树传播之前，首先使用Reed-Solomon消失编码进行编码，这是一种基于多项式的错误检测和修正方案。消失编码被用作数据保护方法，以便在传输过程中即使某些部分丢失或损坏时仍能恢复原始数据。Reed-Solomon消失编码是一种特定的前向错误纠正（FEC）算法。

因为Turbine基本上依赖下游验证者的一系列数据包重传，因此这些验证者可能是恶意的（[对抗性的拜占庭节点](https://www.igi-global.com/dictionary/byzantine-node/3182#:~:text=A%20participant%20in%20a%20system,forwarding%20messages%20to%20other%20participants.）通过选择重新广播错误的数据或接收不完整的数据（网络数据包丢失）。由于Turbine的重传树结构，任何网络范围内的数据包丢失都会加重，数据包未能到达目的地的概率在每一次跳跃中增加。

在高层而言，如果领导者以消失编码的形式传输区块数据包的33%，那么网络可以丢失任何33%的数据包而不会丢失区块。领导者能够根据网络状况动态调整这个数字（FEC率），考虑到最近观察到的网络范围内的数据包丢失和树的深度等变量。

为简化起见，让我们检查FEC率为4:4的一组shred。

_data shreds_是领导者构建的原始区块中的部分区块，而_recovery shreds_是Reed-Solomon生成的消失编码区块。

Solana上的区块通常利用32:32的FEC（可以丢失64个数据包中的32个，无需重传）。根据Solana文档，以下是一些保守的网络假设：

• 数据包丢失率为15%
• 每秒生成50k TPS，产生6400 shreds

32:32的FEC率 yields 带来了约99%的区块成功率。此外，领导者有权提高FEC率，以增加区块成功的概率。

Turbine当前使用UDP进行区块传播，提供巨大的延迟优势。根据一个验证者的运营商，从_us-east-1_到_eu-north-1_使用UDP传输6 MB +消失编码数据需要100毫秒，而TCP则需要900毫秒。

Turbine树

Turbine树是Solana用于促进shreds（编码区块数据）在验证者之间高效传播的结构化网络拓扑。一旦shreds成功编码到相应的shred组中，它们就准备通过Turbine树进行传播，以通知网络中的其他验证者最新状态。

每个shred组通过网络数据包发送到一个特殊的根节点，该节点管理属于第一层（距离1跳） 的哪些验证者。然后执行以下步骤：

1. 列表创建： 根节点将所有活跃的验证者聚合到一个列表中，并根据每个验证者在网络中的赌注大小进行排序。拥有更高赌注权重的验证者将被优先接收到shreds，更快地响应自己的投票消息以达成共识。
2. 列表打乱： 然后，以确定性的方式对该列表进行打乱。这将创建一个由验证者节点集生成的“Turbine树”，随机种子来自插槽领导者id、插槽、shred索引和shred类型。每个shred组在运行时都会生成一个新树，以减轻与静态树结构相关的潜在安全风险。
3. 层次形成： 然后，节点根据列表的顶部划分为多层，划分依据为DATA_PLANE_FANOUT值，该值决定了Turbine树的宽度和深度。此值影响shreds在网络中传播的速度。当前的DATA_PLANE_FANOUT为200，因此大多数验证者只有2-3跳（领导者->根节点-> L1 -> L2）。

Turbine树被所有人知晓，确保每个验证者确切知道他们负责中继哪一个shred。根据当前DATA_PLANE_FANOUT值200，Turbine树通常是2跳或3跳的树（取决于活跃验证者的数量）。

此外，节点能够在没有足够shreds或丢失率超过FEC率时回归到gossip和修复。如果当前实现下，一个节点缺乏足够的shreds来重建区块，则会向领导者发送重传请求。在确定性Turbine下，任何收到完整区块的节点可以发送请求节点所需的修复shreds，从而推动数据传输深入请求数据的树区域。

比较Solana与Ethereum的区块传播

在Solana上，区块传播与Ethereum不同。以下是一些高层次的区别：

• Solana的理想带宽需求（>1 Gbps）显著高于Ethereum的（geth建议>25 Mbps）。这种更高的带宽需求是由于Solana的区块大小更大和区块时间更快。Solana的设计使得可以有效利用整个带宽以加速数据传输，从而降低延迟。虽然有带宽高峰达到1 Gbps，但并非始终以1 Gbps的速度使用。Solana的架构专门支持带宽需求的峰值。
• Solana使用Turbine进行区块数据传播，而Ethereum使用标准的gossip协议。在Ethereum中，区块数据传播以简单的方式进行：每个节点与网络中的每个节点通信。一旦有一个新区块，客户端会通过将其发送到其对等方并批准区块中的交易来验证该区块。此机制适合Ethereum，因为其区块大小更小且区块时间更长。对于Ethereum L2汇总数据（不包括validiums），传播也遵循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）机制的地位。Turbine在某种意义上充当数据可用性机制，因为整个区块数据被Solana上的所有其他验证者发布和下载。尽管如此，Turbine缺乏对数据可用性抽样（DAS）的支持，这一特性有助于轻节点以降低硬件要求进行状态验证。这是诸如Celestia等团队积极发展的重点。与Turbine类似，DAS也利用消失编码，但旨在检测和防止数据隐匿攻击。
• 对于像Eclipse的Solana虚拟机（SVM） L2，Turbine失去了相关性，因为没有验证者集传递数据。在Eclipse的案例中，区块数据被发布到Celestia以获得数据可用性——这使外部观察者能够运行欺诈证明，以确保正确的执行和状态转变。Eclipse将是SVM在Solana网络之外的第一批实现之一。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的审阅和评论。

附加资源 / 进一步阅读

• Turbine区块传播
• 了解消失编码
• Ethereum区块
• Pyth Perseus网络升级
• EigenDA简介：汇总的超大规模数据可用性
• Firedancer

• 原文链接： helius.dev/blog/turbine-...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，在这里修改，还请包涵～