BUPT20-Turbine 机制拆解

Dora Dōjo
1

Dora Dōjo Workshop
资助金额：100 USDT
分享者：北邮在读硕士 Syshems
本项目由Dora Dōjo资助，文章转载请联系
Telegram: @DoraDojo0
WeChat: @DoraDojo0

Turbine 是 Solana 区块链使用的 multi-layer 区块传播机制，用于向所有节点广播账本。Turbine 背后的核心思想已经在学术界存在了很多年。本课题旨在探讨 Turbine 是如何工作的，拆解 Solana 上的区块传播机制，并与以太坊的区块传播进行比较，探索未来区块传播和数据可用性可能的样子。

一、Solana 概述

公链的效率主要指其处理交易的能力，也就是吞吐量 TPS ，该指标受限于区块大小和出块速度。大区块方向的探索饱受诟病，公链扩容叙事主要围绕出快速度。

Solana 扩容主要基于：高效利用网络带宽、减少节点间通讯次数、加快节点运算速度三大方面，缩短了出块和共识通讯的时间，但也降低了系统可用性（安全）。

  • 共识：
    • Leader 名单公示：
      在每个 Epoch 开始前，网络会提前公开出块者 Leader 名单，在整个 Epoch（2~4天）内，出块者会按照名单指定的次序，每过 4 个 Slot 轮换一次。基于单一可信的新区块数据源，缩减了共识通讯开销，但也可能带来贿赂、针对性攻击等安全隐患。

image
image1250×709 87 KB 

- 共识投票：
类似以太坊确认最终性。节点无需再通过「流言协议」进行一对一的投票信息互换，Leader 集中汇总所有 Validator 的投票，**再把这些投票打包写进交易序列里，一次性推送到网络中**。以 ETH 网络为例，若全网节点数量为 N ，则每个节点至少接收 2/3×N 个投票，整个网络产生的通讯次数至少为 2/3×N² 。而 Solana 的共识将通讯次数降至常数 N 甚至是 logN 的数量级。

image
image2000×1081 110 KB 

- PoH：
Solana 中引入 PoH 时钟是为了解决分布式网络中缺乏单个可信时间源的问题。Leader 实质上在交易序列中发布了全网一致的计时器（时钟），PoH 给不同的交易事件盖上序号，生成交易序列。**一般而言，Leader 会时刻不停的执行 SHA256 函数，得到新的 X ，把序列不断向前推进。如果有交易事件，就将其作为外部输入，插进序列里；最终发布的交易序列形式为：**{T1, 序号3, 紧邻X3;}, {T2, 序号5, 紧邻X5;}, {T3, 序号8, 紧邻X8;}, {T4, 序号10, 紧邻X10;}, { POH 序列初始值 X1;}

image
image2000×329 38 KB

  • 传输：
    • Gulf Stream：
      由于提前公开 Leader 名单，Solana 节点无需在本地维护交易池。客户端在接收到交易后，直接转发到 Leader 处打包为交易序列。但由于该机制设计，节点在收到交易后无法过滤拦截垃圾和重复交易，容易造成 Leader 节点宕机。
    • Turbine 传输协议：
      Solana 的 Leader 节点发布的是交易序列而非真实的区块。在 PoH 和 Gulf Stream 的配合下，Solana 实现了类似 BT 种子的传输方式。Leader 会把生成的交易序列切成 X 个不同的碎片，分别发送给质押资产最多的 X 个 Validators ，再由他们传播给其他 Validators 。Validator 群体会自行交换收到的碎片，在本地拼凑完整的交易序列，最终构建区块。

image
image2000×1080 83.5 KB 

- 投票垄断：
实际上，33% 的质押份额掌控在前 22 个节点中，67% 的份额掌控在前 91 个节点中。结合前文所说的传输机制，这些节点最先收到 Leader 发出的交易序列，也会率先给出投票。而只要得到这 91 个节点的投票，Leader 发布的交易序列便可敲定。从某种角度看，这些节点抢跑在其他节点之前。另一方面，如果前 22 个节点串谋，便可使网络陷入混乱。

image
image2000×979 140 KB 

- 交易序列：
在 Solana 的设定中，Leader 实质将共识投票作为交易事件来处理，其发布的交易序列中，节点投票信息占比超过 70% 以上。因此，实际与用户交易相关的 TPS 远没有想象中高。

二、Turbine 传输机制

带宽是一种稀缺资源，Turbine 是一种 multi-layer 的区块传播机制，旨在优化「从 leader 到网络其他节点」的交易序列的传输。与其他区块链采用的 flooding 广播方式不同，Turbine 采用更结构化的方法来最大限度地减少通信成本，减少单个节点的负载。

概括的说，Turbine 将交易序列（区块）分解成更小的块，并以「节点层次」的结构进行传播。在该结构下，单个节点只需与选定的几个节点进行通信，而非全网所有节点。随着网络规模的扩大，这一点变得越来越重要。

此外，Turbine 在不需要大量带宽的情况下解决了数据可用性问题，确保所有节点都可以访问所需的数据以有效地验证交易。这是其他区块链网络中的面临瓶颈。

1、Turbine 原理概述

Leader 生成交易序列后，下一步需要做的就是序列广播。

image
image1920×994 86.1 KB

Shreds 是交易序列的一部分。总的来说，Turbine 负责获取 shreds，并将它们发送到一组预定的 validator ，随后由验证器再将这些 shreds 转发给新的一组 validator 。

  • Leader 构建的交易序列在 validator 中是以 shreds 的形式传播。
  • shreds 的大小刚好是 MTU(Maximum Transmission Units)，也就是节点之间单次所能传输的最大数据量。
  • validator 收到 shreds 后，通过 Reed-Solomon 纠删码方案生成其他 shreds ，保证传输过程中的数据完整性。

image
image1340×794 96.6 KB

2、Reed-Solomon 纠删码

Shreds 在传入 Turbine Tree 进行传输之前，需要先经过 Reed-Solomon 纠删码进行编码处理。纠删码作为一种前向纠错 (FEC, Forward Error Correction) 数据保护方案，即使在传输过程中部分数据丢失或损坏，也可以恢复原始数据。

由于 Turbine 从根本上依赖于下游验证器的一系列数据包重传，这些验证器可能是恶意的（选择广播错误数据）或接收不完整的数据（网络数据包丢失）。由于 Turbine 传播的树状结构，网络范围内的任何数据包丢失都会加剧，丢包概率在每一跳上都会增加。

总的来说，如果 Leader 将交易序列 33% 的数据传入纠删码，那么网络可以丢弃任意 33% 的数据包而不会影响数据恢复。 Leader 能够根据网络状况动态调整此数字（也就是 FEC 速率），综合考虑树深度和丢包情况后作出调整。

image
image1920×679 90.2 KB

8个数据包中有4个可能被篡改或丢失，而不会对原始数据产生影响

Solana 的区块通常利用 32:32 的 FEC（当 64 个数据包中的 32 个数据包可能会丢失，无需重新传输）。如 Solana 文档所述，以下是网络的保守假设：

  • 丢包率为 15%
  • 50k TPS 情况下，每秒生成 6400 个 shreds

32:32 的 FEC 速率产生约 99% 的区块成功率。 此外，Leader 可以选择提高 FEC 率，从而增强区块传播的成功概率。

Turbine 目前使用 UDP 进行区块传播，具有很小的延迟。根据节点运营商的数据，使用 UDP 将 6 MB + 纠删码数据从 us-east-1 传输到 eu-north-1 需要 100 毫秒，而 TCP 需要 900 毫秒。

3、Turbine Tree

Turbine Tree 是 Solana 使用的一种结构化网络拓扑，用于促进验证器之间 shreds 的有效传播。 一旦 shreds 被正确（纠删码）编码，它们就可以通过 Turbine Tree 传播，告知网络中的其他验证器最新的状态。

image
image1150×680 116 KB

Shreds 通过网络包的方式发送到一个特殊的根节点 (root node)。根节点负责管理验证器及其所属的层级（例如 hop1， hop2），并执行以下步骤：

  1. 创建列表：根节点负责将所有的活跃验证器聚合到一个列表中，并根据验证者在网络中的质押量进行排序。具有质押多的验证者将优先收到 shreds，可以更快地投票响应以达成共识。
  2. 列表改组：随后以确定的方式对列表进行改组，改组使用到的 seed 是由 slot leader id, slot, shred index 和 shred type 决定的。最终为每个 shred 组生成一棵 Turbine Tree。“涡轮树”是在运行时为每个碎片组新生成的，以减轻与静态树结构相关的潜在安全风险。
  3. 节点分层：随后根据 Turbine Tree 的结构，从列表顶部开始将节点划分为层。分层需要参考 DATA_PLANE_FANOUT 值（目前是 200），该值决定涡轮树的宽度和深度。 不同数值会影响 shreds 在网络中传播的速度，目前大多数验证器仅相距 2-3 跳（leader → root → L1 → L2）。

如果节点没有获得足够的 shreds 来恢复区块，或丢失率超过 FEC 率，则节点能够回退到 gossip 模式向其他验证器所要 shreds 并进行修复。 目前的实现方式是，缺乏 shreds 的节点直接向 Leader 发送重传请求。

三、对比以太坊区块广播

Solana 的区块传播，对比以太坊有以下区别：

  • Solana 对带宽的要求 (>1 Gbps) 高于以太坊的要求 (>25Mbps)，这是由于 Solana 的区块更大，对出快速度有更高的要求。
  • Solana 采用 Turbine 传播机制，而以太坊使用简单的 gossip 传输协议。以太坊中，每个节点与网络中的所有其他全节点直接通信；一旦产生新的区块，客户端将验证区块内的交易，并广播到网络中的其他节点。与 Solana 相比，gossip 机制更适合以太坊，因为以太坊区块更小，出块时间更长。
  • 以太坊使用 TCP 协议 (通过 DevP2P protocol)，而 Solana 使用 UDP 协议（一些社区的支持过渡到 QUIC，目前仍在讨论）。

写在最后

关于「高效的数据传播」和「数据可用性的解决方案」的探索还远远没有完成。关于 Turbine 的研究一直在进行，很多项目探索 Turbine 是否可以作为通用的 DA 方案。从某种意义上来说，Turbine 充当了 Solana 的数据可用性机制，但 Turbine 不支持 DAS ，无法支持轻节点的验证。尽管 Turbine 和 DAS 都采用了纠删码，但在 DAS 中使用主要是为了避免数据扣留攻击（data withholding attacks）。

  • 对于 SVM Layer2（例如 Eclipse）来说，Turbine 失去了它的作用，因为没有验证器集来连接二者实现数据传递，区块数据只能发布到 Celestia 上。
  • 当前所有的 Solana 节点都是全节点，EigenLayer 的 CEO Sreeram Kannan 提出基于 Turbine 实现 DAS-S 方案。
  • Firedancer 围绕 Turbine ，旨在进一步增强 Solana 的数据传输，并针对稳健的 10 Gbps 带宽连接进行了优化。他们所做的系统级优化在消费级硬件和专业级硬件的生产中表现如何值得期待。

参考

**Ryan Chern：**https://twitter.com/ryanchern/status/1716941141831270798

**Full article：**Turbine: Block Propagation on Solana

****CatcherVC：****https://www.chainfeeds.xyz/feed/detail/20390210-48f7-4aa5-b6e1-ccb8eba39a6f