本文主要讨论的是数据可用性对于区块链的重要性。数据可用性确保了所有节点能够轻松获取验证所需的信息，这对于维护网络的完整性和安全性至关重要。然而，随着网络规模的扩大，保持高性能的同时确保数据的可用性是一个重大挑战。
Solana通过独特的架构设计应对了这一挑战，促进了区块的持续创建和传播。这得益于几项关键创新，如领导者选举机制、Gulf Stream（消除了mempool的需求）以及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发送给网络的其他部分了。这个过程被称为区块传播。验证者之间会传递投票消息,这些消息被封装在区块数据中,以满足"已确认"或"已最终确认"的承诺状态。已确认的区块是获得了超过多数ledger投票的区块,而已最终确认的区块是已确认的并且在其之上建立了31+个已确认区块的区块。承诺状态的差异将在未来的帖子中探讨。
在Solana交易生命周期中,Turbine的位置可以用以下可视化图表表示:
虽然领导者构建和提议完整的区块,但实际数据作为碎片(部分区块)发送给网络中的其他验证者。碎片是在验证者之间传输的基本单元。
从高层次来说,Turbine接收碎片并将其发送到一组预先确定的验证者,这些验证者然后将这些碎片中继给一组新的验证者。下图概述了碎片传播的连续过程:
尽管称之为"区块传播",但数据实际上是在碎片级别传播的,如上图所示。
在这个例子中,验证者1是指定的槽领导者。在其槽(验证者被指定为连续4个槽的领导者)期间,验证者1构建并提议一个区块。验证者1首先通过一个称为切碎的过程将区块分解成称为碎片的子区块。切碎将区块数据划分成MTU大小的数据碎片(一个节点到下一节点可以发送的最大数据量,而不需要将其分成更小的单位),并通过Reed-Solomon消除编码方案生成相应的恢复碎片。这一方案有助于数据恢复,并确保在传输过程中数据的完整性,这对于维护网络的安全性和可靠性至关重要。
这种切碎和传播的过程确保了Solana网络上区块数据的快速高效分发,维持了高吞吐量和网络安全。
消除编码
在通过Turbine树传播碎片之前,它们首先使用Reed-Solomon消除编码进行编码,这是一种基于多项式的错误检测和纠正方案。消除编码用作数据保护方法,以便即使在传输过程中有一些部分丢失或损坏,也可以恢复原始数据。Reed-Solomon消除编码是一种特定的前向错误纠正(FEC)算法。
由于Turbine从根本上依赖于下游验证者进行一系列数据包重传,这些验证者可能是恶意的(拜占庭式的对抗性节点),选择重新广播不正确的数据或接收不完整的数据(网络数据包丢失)。由于Turbine的重传树结构,任何网络范围内的数据包丢失都会被放大,而数据包到达目的地的概率在每跳后都会降低。
从高层次来说,如果领导者将区块数据包的33%传输为消除编码,那么网络就可以丢弃33%的数据包而不会丢失该区块。领导者有能力根据网络状况动态调整这个数字(FEC速率),考虑最近观察到的网络范围内的数据包丢失和树深度等变量。
为了简单起见,让我们看一下一个FEC速率为4:4的碎片组。
一个示例碎片组。4个 out of 8 个数据包可能被篡改或丢失,但不会影响原始数据。
数据碎片是由领导者构建的原始区块的部分块,而恢复碎片是通过Reed-Solomon生成的消除编码块。
Solana上的区块通常使用32:32的FEC(32个 out of 64 个数据包可以丢失而不需要重传)。正如Solana文档所述,这些是以下保守的网络假设:
数据包丢失率为15% 每秒生成6400个碎片的50k TPS 32:32的FEC速率产生约99%的区块成功率。此外,领导者有权提高FEC速率以增加区块成功的概率。
Turbine目前使用UDP进行区块传播,提供了巨大的延迟优势。根据一位验证者操作员的说法,使用UDP从us-east-1传输6MB+消除编码数据到eu-north-1需要100ms,而TCP需要900ms。
Turbine树
Turbine树是Solana用于促进碎片(编码区块数据)在验证者之间有效传播的结构化网络拓扑。一旦碎片被正确编码成相应的碎片组,它们就准备通过Turbine树传播,让网络中的其他验证者了解最新的状态。
每个碎片组通过一个网络数据包发送到一个特殊的根节点,该节点管理哪些验证者属于第一层(1跳)。然后执行以下步骤:
- 列表创建:根节点聚合所有活动的验证者到一个列表,然后根据每个验证者在网络中的权益进行排序。拥有较高权益的验证者将优先接收碎片,使他们能够更快地响应并发送自己的投票消息进行共识。
- 列表混洗:这个列表然后以确定性的方式被混洗。这创建了一个"Turbine树",其从每个碎片的槽领导者id、槽、碎片索引和碎片类型派生的种子生成验证者节点集。每个碎片组都会在运行时生成一个新的树,以减轻与静态树结构相关的潜在安全风险。
- 层级形成:节点然后根据DATA_PLANE_FANOUT值被划分为层级,从列表的顶部开始。该值决定了Turbine树的广度和深度,影响碎片在网络中的传播速度。当前的DATA_PLANE_FANOUT是200,所以大多数验证者只有2-3跳远(领导者->根->L1->L2)。
Turbine树是众所周知的,确保每个验证者都知道他们负责中继那个碎片的确切位置。Turbine树通常是一个2跳或3跳的树(取决于活跃验证者的数量),因为当前的DATA_PLANE_FANOUT值为200。
此外,如果节点没有收到足够的碎片,或者丢失率超过FEC速率,它们能够回退到八卦和修复。在当前的实现中,缺少重建区块所需的足够碎片的节点会向领导者发送重新传输请求。在确定性的Turbine中,任何收到完整区块的节点都可以发送请求节点需要的修复碎片,从而将数据传输进一步推进到请求数据的树的区域。
Solana与以太坊的区块传播对比
Solana的区块传播与以太坊有所不同。以下是一些高层次的差异:
Solana的理想带宽要求(>1 Gbps)明显高于以太坊(geth建议>25 Mbps)。这更高的带宽要求归因于Solana更大的区块大小和更快的区块时间。Solana的设计允许有效利用整个带宽来加快数据传输,从而降低延迟。虽然带宽会突增到1Gbps,但它并不一直使用1Gbps。Solana的架构专门支持带宽需求的突增。
Solana采用Turbine进行区块数据传播,而以太坊则使用标准的八卦协议。在以太坊上,区块数据的传播是以简单的方式进行的:每个节点与网络中的其他每个全节点进行通信。一旦有新的区块,客户端将通过向其对等方发送该区块并批准该区块中的交易来验证它。这种机制适用于以太坊,因为它的区块大小更小,区块时间也更长,相比之下Solana的区块大小和区块时间都更短。对于以太坊L2 rollup数据(不包括validiums),传播也遵循八卦协议,区块数据存储在以太坊L1区块的"calldata"字段中。
以太坊使用TCP(通过DevP2P协议)进行区块传播,而Solana使用UDP(并有一些社区支持转向QUIC)。在UDP和QUIC之间存在一些权衡:
UDP的单向性导致较低的延迟,而QUIC需要QUIC流。人们正在就将单向流纳入QUIC进行讨论。
QUIC的支持者声称,虽然可以在UDP上执行自定义流控,但这需要大量的工程努力,而QUIC通过原生支持此类功能来缓解这一问题。最终目标是一样的,但QUIC的性能(延迟、吞吐量等)上限是纯UDP的当前状态。
这些差异突出了Solana和以太坊采用的独特架构决策,这些决策有助于它们各自的性能、可扩展性和网络鲁棒性。如果想更深入地了解TCP、UDP和QUIC,可以查看我们关于Solana和QUIC的文章。
未来的研究问题
区块传播和数据可用性仍然是开放的研究领域,许多团队正在制定自己独特的方法。虽然指标可能会随时间而变化,但我们希望提供不同方法及其相关权衡的概述:
一些讨论围绕着Turbine作为"数据可用性"(DA)机制的地位。从某种意义上说,Turbine确实充当了数据可用性机制,因为整个区块数据都在被发布和由Solana的所有其他验证者下载。然而,Turbine缺乏对数据可用性采样(DAS)的支持,这是一个有助于轻节点以较低的硬件要求验证状态的功能。这是Celestia等团队的一个积极发展重点。与Turbine一样,DAS也利用了消除编码,但其目的是检测和预防数据withholding攻击。
对于像Eclipse这样的Solana虚拟机(SVM) L2,Turbine就失去了相关性,因为没有验证者集来传递数据。在Eclipse的情况下,区块数据被发布到Celestia以确保数据可用性 - 这使得外部观察者能够运行欺诈证明,以确保执行和状态转换的正确性。Eclipse将是首批在Solana网络之外实施SVM的项目之一。Pyth也为其自己的oracle网络"Pythnet"分叉了SVM,并有效地作为自己的侧链运行。
在Solana上,全节点管理区块传播,同时也参与区块链栈的其他部分,如交易排序和共识。如果Turbine作为一个模块化组件在专用硬件上运行,它的定量指标会是什么?
Turbine优先选择拥有更高权益的节点首先接收区块数据。这会随着时间推移导致更多的MEV集中化吗?
EigenDA(横向可扩展的单播中继器)和Celestia(数据可用性采样)等不同的数据可用性方法,与Turbine在生产环境中相比,在原始吞吐量和最小化信任方面会有什么样的表现?
Firedancer旨在进一步提高数据传播,并针对10 Gbps带宽连接进行了优化。他们对Turbine进行的系统级优化,在消费级硬件和专业级硬件上的性能会如何?
目前,Solana上的所有节点都是全节点(轻客户端实现仍在开发中)。EigenLayer的Sreeram Kannan最近描述了在Turbine之上实现DAS-S的实现。Turbine会有DAS版本的支持吗?能否实现基于DAS的轻客户端,在保持高数据吞吐量的同时满足最小化信任?
结论
祝贺你!在这篇文章中,我们研究了Turbine以及它在Solana更广泛的交易包含景观中的工作方式。我们将Turbine与其他数据可用性解决方案进行了比较,并讨论了这个领域开放的不同研究途径。Solana的Turbine协议体现了该网络致力于通过利用结构化网络拓扑高效传播区块数据来实现高吞吐量和低延迟的承诺。
寻找方法来增强数据可用性,并使区块传播更加高效,推动了整个区块链社区的创新。对Solana和以太坊区块传播机制的比较分析,阐明了它们各自的优势和权衡,并启发了人们对EigenDA、Celestia和Firedancer等新兴区块链解决方案如何塑造这个生态系统的更深入的讨论。
高效的数据传播和数据可用性的解决方案还远未完成。但Solana采取的方法和坚定致力于在不牺牲安全性和最小信任的前提下优化网络性能的态度,受到了热烈的欢迎。