Solana Turbine：区块传播解析
Learn how Solana Turbine propagates blocks across validators using shreds, Reed-Solomon coding, and neighborhood trees for 65,000 TPS throughput.
Solana Turbine 区块传播描述了区块数据如何被分割成碎片并分发给验证者。本文中的图示均为历史数据或目标值，除非明确标明日期；实际槽位时间、拓扑结构、数据包丢失和实现行为均会有所不同。
引言：为何区块传播决定区块链速度
一次性将完整区块发送给数千名验证者，将需要每个验证者从单个来源下载整个区块，这会造成带宽瓶颈，并且随着网络规模的扩大而变得更糟。Solana (SOL) 是一种高性能的 Layer-1 区块链（一种无需中心化权威即可记录和验证交易的分布式账本网络），它通过其专用的区块传播协议 Turbine 来解决这个问题。
早期的 Solana 材料引用了近 65,000 TPS 的理论吞吐量和近 400 毫秒的目标槽位时长。这些是设计参考而非保证的实时测量值，并且一个槽位并不总是会生产一个区块。Turbine 是 Solana 历史架构框架中描述的区块数据传播机制。
区块传播位于共识机制之下：验证者（拥有账本副本、验证交易并对区块有效性进行投票的服务器）在收到并从碎片重建区块之前，无法对其有效性进行投票。这种依赖性意味着 Turbine 的速度直接促成了 Solana 共识性能的实现。Solana 上的每项智能合约交互，从去中心化金融 (DeFi) 交易到 NFT 的铸造，都依赖于区块足够快地到达验证者，以便在下一个槽位内得到确认。
以下内容涵盖了 Turbine 的定义、五步机制、技术参数、性能贡献、安全权衡以及与以太坊和 Avalanche 的直接对比。
本文内容
- 什么是 Solana Turbine 区块传播？
- 关键术语：Turbine 术语快速参考指南
- Turbine 如何传播区块：分步详解
- Turbine 的技术参数
- Turbine 与 Solana 的性能：将区块传播与 TPS 联系起来
- Turbine 安全吗？安全模型和已知攻击向量
- Solana Turbine 与以太坊及其他 Layer-1 区块链对比
- Turbine 在 Solana 架构中：全部 8 项创新
- Turbine 的演变：从 2017 年的白皮书至今
- 关于 Solana Turbine 的常见问题
- 结论：Turbine 对 Solana 未来为何重要
- 延伸阅读和主要来源
什么是 Solana Turbine 区块传播？
定义
Solana Turbine 是 Solana 的区块传播协议，它是一种机制，通过该机制，新产生的区块被分割成数千个称为“碎片”（shreds）的固定大小数据包，并通过称为“邻域树”（neighborhood tree）的分层树状结构分发到验证者网络。Reed-Solomon 纠删码可以恢复在传输中丢失的任何数据包，从而确保验证者即使在不利的网络条件下也能重建完整区块。
Turbine 之所以存在，是因为简单的广播无法扩展。如果区块领导者（为给定槽位指定生产区块的验证者）同时将整个区块直接发送给所有验证者，那么每个验证者都需要独立下载完整的区块。在 Solana 的网络中，拥有 2,000 多个活跃验证者，这种方法将需要来自单个源的 O(n) 带宽，这意味着随着网络中添加的验证者数量增加，带宽成本会线性增长。
Turbine 通过借鉴 BitTorrent 协议的核心原理，实现了 O(log n) 的带宽扩展。BitTorrent 点对点文件分发协议通过将大文件分割成小块并在多个节点上同时分发这些小块，而不是从一个服务器提供，从而有效地传输大文件。Turbine 将相同的理念应用于区块链区块传播：区块领导者不向每个验证者传输完整区块，而是将其分割成碎片，并通过分层的验证者树进行路由，每一层将碎片向下转发。
这个类比有其局限性值得注意。BitTorrent 作为一种平坦的点对点网络运行，所有参与者都被平等对待。Turbine 则使用带有质押加权定位的分层树，这意味着质押 SOL 更多的验证者位于树的较高位置，更早接收到碎片。这一区别对于理解 Turbine 的效率及其安全权衡很重要。
Turbine 由 Solana Labs 联合创始人 Anatoly Yakovenko 设计，并在 Anatoly Yakovenko (2017) 的原始 Solana 白皮书. 中首次提出。自 2020 年 3 月 Solana 主网测试版发布以来，该协议已持续生产。
关键术语：Turbine 术语快速参考指南
在详细介绍 Turbine 的工作原理之前，以下是您在本文中将遇到的核心术语。
| 术语 | 通俗定义 | 在 Turbine 中的作用 |
|---|---|---|
| Turbine | Solana 的区块传播协议，负责将新区块分发到验证者网络。 | 本文的主要主题；包含下方所有组件的系统。 |
| Shred (碎片) | 通过将区块分割成片段以进行网络传输而创建的固定大小（约 1.5 KB）的数据包。 | Turbine 在网络上传输数据的基本单位。 |
| Data Shred (数据碎片) | 由分割区块产生的原始区块数据片段之一。 | 承载区块中的实际交易数据。 |
| Coding Shred (编码碎片) | 由 Reed-Solomon 纠删码生成的冗余数据包，不属于原始区块数据。 | 允许验证者即使在数据碎片传输丢失的情况下也能重建区块。 |
| Block Leader (区块领导者) | 通过 Solana 的确定性领导者调度选出的，为给定槽位生产区块的验证者节点。 | 通过分割区块并传输到 Layer 1 来启动 Turbine 过程。 |
| Neighborhood Tree (Fanout Tree) (邻域树/扇出树) | Turbine 将碎片向下路由时，分层组织的验证者分层结构。 | 赋予 Turbine O(log n) 带宽效率的路由拓扑。 |
| Reed-Solomon Erasure Coding (Reed-Solomon 纠删码) | 一种数学技术，可生成编码碎片，从而在数据包丢失的情况下重建区块。 | Turbine 的容错机制；处理高达约三分之一的数据包丢失。 |
| Fanout Factor (扇出因子) | 邻域树各层中，每个节点传输到的验证者数量（约 200）。 | 决定每层覆盖多少验证者以及以多快的速度到达整个网络。 |
| Slot (槽位) | Solana 的大约 400 毫秒区块生产窗口，在此期间区块领导者必须生产和传播区块。 | 为共识的进行设定 Turbine 必须满足的时间限制。 |
| Stake-Weighting (质押加权) | 将更高质押的验证者置于邻域树较高位置的做法。 | 确保质押最多的验证者最先接收碎片，同时引入轻微的中心化权衡。 |
Turbine 如何传播区块：分步详解
Turbine 通过五个步骤来传播区块：区块领导者将区块切片（shred），里德-所罗门码（Reed-Solomon coding）生成冗余数据包，生成的切片流经一个基于质押权重的邻居树，直到每个验证节点都持有足够的切片来重构完整的区块。下面的每个步骤都完整涵盖了该过程的一个阶段。
第 1 步：区块领导者产生区块
每个区块都始于区块领导者（也称为区块生产者），即为给定插槽（slot）指定并根据 Solana 的确定性领导者计划提前选定的验证节点。根据 Solana 的领导者计划文档,)，该计划衍生自历史证明 (PoH) 时钟，即 Solana 的加密计时机制。由于领导者计划是公开且确定性的，任何验证节点都可以在插槽开始前验证谁将是下一个区块领导者。
区块领导者收集由 Gulf Stream（Solana 的交易转发协议，在当前区块定产前将未确认交易推送到预期的下一个领导者）转发的交易，并将它们组装成一个完整的区块。组装完成后，区块领导者开始 Turbine 过程。
第 2 步：区块被切片为数据包
根据 Solana 的技术文档，区块领导者将完成的区块分解为固定大小的数据包，称为 shreds（切片），每个切片的大小约为 1.5 KB。这些原始区块数据碎片被称为数据切片。一个全尺寸的 Solana 区块可以产生数千个数据切片，具体取决于区块大小。
可以将切片过程想象成将一个大文件拆分成数千个小的电子邮件附件，并通过不同的路径路由每一个附件：即使有几个附件延迟到达，完整的文件也会在目的地重新组装。其核心优势是并行传输。由于树中的每个验证节点同时接收和转发不同的切片，网络无需等待一次大型的顺序传输即可开始分发数据。
Turbine 的切片不是分片（sharding）。分片是将区块链的状态或交易处理拆分到多个并行的子网络中，由不同的验证节点子集验证状态的不同部分。Turbine 切分区块纯粹是为了传输效率：整个 Solana 验证节点网络验证的是同一个完整的区块状态。碎片化是一种交付机制，而不是分区策略。
第 3 步：里德-所罗门码生成冗余切片
**里德-所罗门纠删码（Reed-Solomon erasure coding）**生成第二类切片，称为编码切片。这些是冗余数据包，允许任何验证节点即使在原始数据切片在传输中丢失一部分的情况下也能重构完整区块。这种区别很重要：数据切片承载实际的区块内容；编码切片承载数学衍生的冗余，可以填补空缺。
一个有用的类比：里德-所罗门纠删码的功能类似于二维码。即使二维码的一部分被遮挡或损坏，剩余部分中编码的冗余信息仍足以解码完整信息。二维码类比有一个值得注意的局限：二维码是静态对象，而 Turbine 的纠删码作用于具有特定数值恢复阈值的流式切片批次。
根据 Solana 的实现，只要验证节点收到大约总切片数（数据加编码总和）的三分之二，就可以重构完整区块。这意味着协议在重构失败前可以容忍大约三分之一的数据包丢失。里德-所罗门码是一项成熟的技术，在 CD、DVD、卫星通信和其他应用中有数十年的生产使用经验，这证明了 Turbine 的容错机制是建立在成熟的工程之上，而非实验性设计。技术参数引自 Solana 白皮书) 和 Solana 官方 Turbine 文档.)
第 4 步：切片通过邻居树进行分发
邻居树（也称为扇出树）是 Turbine 分发切片的层级路由结构，它将 Solana 的验证节点组织成多个层级，每一层从上一层接收切片并向下游重新传输。下面的结构展示了该树如何在两个层级间扩展：
第 0 层 (区块领导者)
|
+-- Layer 1: 约 200 个验证节点 (每个接收唯一的切片子集)
|
+-- Layer 2: 最多约 40,000 个验证节点 (200 x 200，每个 Layer 1 验证节点转发给另外约 200 个)鉴于每层约 200 的扇出系数，邻居树在两到三层内即可覆盖 Solana 完整的活跃验证节点集（根据 Solana 基金会网络统计，约为 2,000 多个验证节点）。通过两层结构，该树在数学上可覆盖多达 40,000 个验证节点 (200 x 200)，远超当前的活跃节点规模。
可以将此结构想象成邮政分拣网络：中心枢纽将批次发送到区域分拣中心，分拣中心派送到当地邮局，最后派送到个人地址。每一层仅处理总负载的一小部分，没有单个节点承担全部带宽成本。然而，与中立的邮政系统不同，Turbine 的邻居树是基于质押权重的。在 Solana 基于权益证明的共识机制 (Tower BFT) 下，质押 SOL 较多的验证节点位于树的顶端附近，确保他们最早收到切片。
树的拓扑结构在每个插槽还会使用源自 PoH 时钟的可验证随机性进行随机化，这意味着任何验证节点都可以在不信任中心方的情况下独立验证随机源。由于树在每个插槽都会变化，敌对验证节点无法预测谁将在下一轮成为他们的邻居。这种随机化是 Turbine 防御日蚀攻击（eclipse attacks，攻击者试图包围目标验证节点并扣留切片）的主要手段。
其结果是 O(log n) 的带宽扩展，这意味着带宽需求相对于验证节点数量的增长是缓慢的。随着 Solana 验证节点数量的增加，这一特性使得 Turbine 的设计价值日益凸显。
第 5 步：验证节点重构区块并投票
一旦验证节点收到足够的切片以达到纠删码阈值（约占该区块总切片的三分之二），它就会重构完整区块并向 Tower BFT（塔式拜占庭容错，Solana 基于权益证明的共识机制）提交投票。验证节点在重构完成前无法投票，这就是为什么 Turbine 的传播速度直接限制了共识吞吐量。
传播过程是围绕 Solana 的目标插槽节奏设计的，但实际的时间安排和验证节点覆盖范围随网络和实现条件而变化。如果传播在该窗口内完成，共识将继续并开始下一个插槽。如果没有完成，该插槽可能会被跳过，从而暂时降低吞吐量。
当切片丢失时会发生什么？
核心事实
当切片在传输中丢失时，只要总数据包丢失率低于该区块传输的所有切片的大约三分之一，Solana 的里德-所罗门纠删码允许验证节点从收到的编码切片中重构完整的区块。
二维码的类比在这里同样适用：只要有足够的模式留存，完整的信息就能被解码。当数据包丢失保持在恢复阈值以下时，验证节点会从到达的数据切片和编码切片的任何组合中重构区块。
当丢包率超过该阈值时，验证者会向持有缺失分片的邻近验证者发出修复请求。该修复机制会增加延迟，但除非修复无法在槽窗口内完成，否则不会立即导致槽跳过。
在严重网络拥塞的情况下，当丢包广泛分布于整个网络而非仅限于一条路径时，多个验证者可能无法在槽窗口内重建其区块。这种级联效应会导致槽跳过，在极端情况下，还会导致 Solana 在 2021 年和 2022 年主要拥塞事件期间经历的网络降级类型。此后，Solana Labs 根据这些事件调整了 Turbine 的拥塞处理。拥塞与槽跳过之间的联系将在下面的安全部分讨论。
Turbine 的技术参数
下表总结了 Turbine 的关键运行参数，这些参数摘自 Solana 的官方文档和 Solana 白皮书。随着协议的演进，Solana Labs 可能会更新这些参数；请在 Solana 官方 Turbine 文档.) 中验证当前值。
| 参数 | 值 | 来源 |
|---|---|---|
| 分片大小 | ~1.5 KB/分片 | Solana 文档 (docs.solana.com/cluster/turbine-block-propagation) |
| 每层扇出因子 | ~200 个验证者 | Solana 白皮书；Solana 文档 |
| 覆盖全网络的典型层数 | 2-3 层 | Solana 文档 |
| 2 层内可触达的验证者 | ~40,000 (200 x 200) | Solana 文档 (源自扇出因子) |
| 纠删码恢复阈值 | ~1/3 丢包容忍度 | Solana 白皮书 |
| 目标第一层传播 | 100 毫秒以下 | Solana 文档运行目标 |
| 目标全网络传播窗口 | 约 400 毫秒槽内 | Solana 白皮书；Solana 文档 |
| 带宽缩放 vs. 朴素广播 | O(log n) vs. O(n) | Solana 白皮书 |
Turbine 与 Solana 的性能：连接区块传播与 TPS
Solana 白皮书及后续评论曾提及近 65,000 TPS 的理论吞吐量。实际吞吐量取决于日期、工作负载、投票包含、过滤和软件版本，因此，在没有测量方法学的情况下不应展示实时的非投票 TPS 范围。Turbine 是结果的一个组成部分，而非独立的 TPS 保证。
因果链如下。Turbine 以足够快的速度传播分片，使得网络中的验证者能够在约 400 毫秒的槽窗口内重建区块并进行投票。共识得以进行。下一个槽开始。Solana 保持其槽节奏。由于每个槽可以包含数千笔交易，维持该节奏便是产生高 TPS 的原因。传播延迟会中断节奏并导致 TPS 下降；维持节奏则 TPS 保持高位。
理论 TPS 与实际 TPS 之间的区别值得特别关注。Solana 的原始 TPS 数据（可达到更高数字）包含验证者投票交易，这些是代表用户提交交易的内部共识消息。非投票 TPS（与其他区块链的吞吐量更具可比性的数据）通常在 2024-2025 年的实际负载下运行在 2,000 到 4,000 之间，根据 Solana Labs 的性能文档。65,000 的数字是假设理想条件下的理论上限；它并非对平均网络行为的描述。
Turbine 的 O(log n) 带宽设计还防止了随着验证者数量的增长，传播层成为瓶颈。采用朴素广播方法，验证者数量翻倍，每个发送节点所需的带宽也翻倍。借助 Turbine 的树形结构，验证者数量翻倍仅增加一层（每个现有节点约增加 200 个验证者），这意味着带宽需求缓慢增长而非线性增长。
关键要点
Turbine 不执行交易；它传播区块数据。传播性能会影响投票和吞吐量，但 Turbine 不保证固定的 TPS 数字、槽节奏或最终确定时间。
Turbine 安全吗？安全模型和已知攻击向量
Turbine 包含三个核心安全机制：每槽重新洗牌的随机路由、基于 质押 加权的树位置以及 Reed-Solomon 纠错码冗余。每个机制都解决了特定的攻击面，尽管每个机制也引入了一个值得诚实审视的权衡。
邻里树使用源自 PoH 时钟的可验证随机性每槽重新洗牌，这意味着恶意验证者无法预测下一个槽中的邻近验证者是谁。这一点很重要，因为分层分发树的主要攻击向量是 Eclipse 攻击：恶意行为者将验证者定位在目标验证者周围并扣留分片，阻止该验证者重建区块，从而阻止其投票。
由于树拓扑结构每槽都会改变，攻击者无法可靠地维持这种包围。区块领导者（通过确定性领导者调度）是提前已知的，但传播路径则不是。这种不对称性是一种有意的安全设计：关于谁产生区块的透明度，与关于这些区块如何传输的不透明度相结合。
这种保护是有限的。拥有足够 质押 的攻击者可能在连续的重组中出现在多个位置，在目标验证者附近维持一定的统计存在。随机路由增加了 Eclipse 攻击的成本和复杂性，但并未使其对资源充足的对手不可能。
基于 质押 加权将高 质押 验证者置于邻里树的较高位置，这意味着它们比低 质押 验证者更早接收分片，这为大型 质押 操作带来了结构性优势。首先接收分片的验证者可以比其低 质押 同行更早开始重建和投票，这在共识过程中带来了轻微的时间优势。
诚实的批评：拥有足够大 质押 集中度的验证者理论上可以利用这种早期访问来尝试区块扣留策略，延迟其投票以获得信息优势。Tower BFT 的共识最终确定规则旨在限制此类策略的有效性，并且 质押 集中度分布在约 2,000 多个活跃验证者之间（根据 Solana 基金会的网络统计数据），这限制了极端的集中度。Solana 基金会还运行 质押 委托计划，旨在将 质押 更广泛地分布给较小的验证者。尽管如此，大型验证者的结构性优势是真实的，并且值得在评估 Solana 的去中心化状况时予以考虑。
2021 年至 2022 年间 Solana 的主要网络中断大多数是由交易处理管道拥塞引起的，而非 Turbine 特定的故障，尽管极端拥塞会给区块传播层带来压力。当交易量在那些时期压倒 Solana 的处理管道时，正在产生和分片处理的区块数量也随之增加，传播层面临比网络带宽能够干净吸收的更多的同时分片批次。
结果是广泛的丢包，超过了许多验证者同时的纠删码恢复阈值，导致了槽位跳过级联，而不是孤立的个体故障。此后 Solana Labs 对拥堵处理进行了工程改进，包括更改网络如何管理交易摄入以及 Turbine 在高负载下如何处理传播。有关当前工程状态，请参阅 Solana Labs 工程博客. 停机历史是 Turbine 生产记录的事实，而非理论风险，并且是评估 Solana 技术韧性的相关背景信息。
Solana Turbine 与 Ethereum 及其他 Layer-1 区块链
Solana 传播区块的速度比 Ethereum 快，主要因为 Turbine 使用层次化邻域树并行分发分片 (shreds)，而 Ethereum 使用消息传播协议 (gossip protocol)，验证者将区块广播给随机子集节点，这些节点再转发给他们的节点，这在规模化时是一种根本上更慢的拓扑结构。下表比较了 Solana、Ethereum 和 Avalanche 在对区块传播最重要的维度上的差异。
| 属性 | Solana (Turbine) | Ethereum (Gossip Protocol) | Avalanche (Snowflake/DAG) |
|---|---|---|---|
| 传播方法 | 层次化邻域树；分片逐层分发 | Gossip：随机节点广播，转发直至网络范围 | Snowflake/Snowball DAG；基于采样的协议，带有重复的随机轮询 |
| 数据单元 | 分片 (Shreds)（约 1.5 KB 固定大小的数据包） | 完整区块或区块头（可变大小） | DAG 共识后通过 Gossip 转发的区块 |
| 出块时间 | 约 400ms 槽位时间 | 约 12 秒 | 约 1-2 秒（最终性因子网络而异） |
| 容错机制 | 瑞德-索罗门纠删码（容忍约 1/3 的丢包） | 冗余的 Gossip 路径；从节点重新请求区块 | 重复的随机采样提供概率性容错 |
| 带宽扩展 | O(log n)：随着验证者数量增加而缓慢增长 | O(n) 每跳：Gossip 在每轮中传播到随机比例的节点 | 通过概率采样实现亚线性扩展；比纯粹的 Gossip 扩展性更好 |
| 去中心化方法 | 质押加权树；质押较高的验证者先接收分片 | 相等的节点选择；无基于质押的拓扑加权 | 通过子网络成员资格选择验证者；不同的去中心化模型 |
一项值得明确指出的区别是：Solana 本身使用消息传播协议进行集群信息共享和协议元数据，但 Turbine 取代了消息传播协议用于区块传播这一特定任务。正是 Turbine 的层次化树结构在规模化区块分发方面比 Gossip 的扁平拓扑结构性能更优。
Ethereum 的消息传播协议（验证者将区块广播给随机子集节点，这些节点再转发给他们的节点，通过多轮将区块传播到整个网络）更容易实现，并且产生更均匀的节点选择，不偏袒任何基于质押的验证者。该设计反映了 Ethereum 对广泛去中心化和无需许可参与的优先考虑。其权衡是传播速度：跨大型验证者集合的多轮 Gossip 会产生以秒而非毫秒计数的出块时间。
Turbine 与 BitTorrent 协议在两个方面有所不同，而上表并未完全涵盖。BitTorrent 使用扁平的点对点群集，所有参与者都是平等的；Turbine 使用一个层次化树结构，其中有质押加权的中心节点。BitTorrent 对文件组装没有时间限制；Turbine 必须在 400ms 的槽位窗口内完成，否则将错过共识。这些分歧是针对区块链特定需求而进行的设计响应，而 BitTorrent 模型并未面临这些需求。
Avalanche 的 Snowflake/Snowball DAG 传播采用了一种不同的方法：重复随机轮询小型验证者子集以达成概率性共识，而不采用单一区块领导者模型。该设计通过采样而非树结构提供亚线性带宽扩展，并且比 Ethereum 产生更快的最终性，同时仍与 Turbine 的基于分片的方法根本不同。每种设计在速度和去中心化（一方面）与容错和复杂性（另一方面）之间做出了不同的权衡。表格呈现了这些权衡；声明一种架构优越会误解设计空间。
Turbine 在 Solana 架构中的作用：全部 8 项创新
Turbine 是 Anatoly Yakovenko 在 2017 年 Solana 白皮书 (whitepaper) 中引入的八项架构创新之一，每项创新都旨在解决区块链基础设施中不同的性能瓶颈。完整列表如下：
- 历史证明 (Proof of History, PoH): Solana 的加密计时机制，一种可验证延迟函数，可在无需验证者通信即可达成时间一致性的情况下创建事件排序的历史记录。PoH 不是共识机制；它是一个时钟。它定义了 Turbine 运行的槽位结构。
- Tower BFT: Solana 的基于质押的共识机制 (Consensus Mechanism)，是实用拜占庭容错 (PBFT) 的一个变体，使用 PoH 时钟来减少达成最终性时的消息开销。
- Turbine: 区块传播，本文主题。Turbine 通过分片 (shreds) 和邻域树将新生成的区块分发给所有验证者。
- Gulf Stream: Solana 的交易转发协议。Gulf Stream 在当前区块最终确定之前将未确认的交易推向前一个预期区块的领导者，从而减少领导者组装区块所需的时间。
- Sealevel: Solana 的并行智能合约 (Smart Contract) 执行引擎，它同时处理数千个不重叠的智能合约，而不是顺序处理。
- Pipelining: 一种交易处理流水线，将交易验证的不同阶段分配给专用硬件，允许多个区块在不同的处理阶段并行验证。
- Cloudbreak: Solana 的水平扩展账户数据库，针对验证者存储硬件上的并发读写进行了优化。
- Archivers: 分布式账本 (Distributed Ledger) 存储节点，将历史区块链数据从验证者卸载到单独的存储层，从而降低验证者硬件要求。
Gulf Stream 和 Turbine 在交易生命周期中按顺序运行。Gulf Stream 在区块生产开始之前将未确认的交易路由到预期的区块领导者；然后 Turbine 在生产完成后将生成的区块分发到所有验证者。这两个协议共同处理从提交到网络范围分发的整个交易生命周期。
这八项创新由 Solana Labs 的联合创始人 Anatoly Yakovenko 于 2017 年首次发布的 Solana 白皮书 (whitepaper) 提出。
验证者视角
Turbine 的邻域树位置会影响验证者的硬件要求。位于 Layer 1（更靠近区块领导者）的验证者会首先接收分片，并必须将其转发给大约 200 个 Layer 2 验证者，这需要比 Layer 2 验证者更高的上传带宽，后者仅转发给他们分配的子邻域。质押水平决定树中的位置：质押较高的验证者占据 Layer 1 的位置，并应据此配置。运营商应参考 Solana Labs 当前的硬件建议，因为主网 (mainnet) 启动以来的最低规格已有所发展。
Turbine 的演变：从 2017 年白皮书到今天
Turbine 最早是在 2017 年由 Solana Labs 的 Anatoly Yakovenko 撰写的原始 Solana 白皮书 (whitepaper) 中提出的，使其成为该协议的创始架构决策之一，而不是后来添加的功能。2017 年的规范确立了核心设计：基于分片 (shred) 的区块碎片化、用于分发的扇出树以及用于容错的瑞德-索罗门纠删码。
Solana 的主网测试版于 2020 年 3 月启动，首次将 Turbine 推向生产环境。初步部署确认了设计的核心特性，但也暴露了理论规范未能完全预料到的现实世界条件，特别是交易拥堵与传播负载之间的相互作用。
继 2021 年和 2022 年的网络压力事件之后，Solana Labs 对 Turbine 的拥堵处理进行了工程改进，包括调整在网络负载高时分片批次的排队和传输方式。这些改进并未改变协议的基本架构，但改善了其在运行范围极端情况下的表现。
Turbine 现已在日处理数百万笔交易的网络上连续运行四年多。这一生产记录为“Turbine 是经过验证的方法还是实验性方法”这一问题提供了明确的答案：它是一个生产协议，经过了大规模的实战考验，拥有可追溯到 2017 年规范的文档化工程传承。有关当前协议参数和最新工程变更，请参阅 Solana Labs 工程博客.
关于 Solana Turbine 块传播的常见问题解答
以下问题解答了关于 Solana Turbine 设计和性能的最常见疑问。
什么是 Solana Turbine？
Turbine 是 Solana 用于在 400 毫秒的区块时间窗口内将新产生的区块传输到网络中每个验证节点（validator）的协议。它通过将区块分割成碎片（shreds）并通过分层邻域树（hierarchical neighborhood tree）进行路由，并使用 Reed-Solomon 纠删码处理传输过程中丢失的任何数据包。其结果是快速、带宽高效的区块分发，并且随着验证节点数量的增长而扩展。
碎片（shred）是 Turbine 用于区块传输的基本数据包，大小约为 1.5 KB。有两种类型：数据碎片（data shreds），包含原始区块内容；以及编码碎片（coding shreds），由 Reed-Solomon 纠删码生成，冗余数据包，即使某些数据碎片在传输中丢失，也能重建区块。
区块领导者（block leader）将区块分割成数据碎片，并通过 Reed-Solomon 编码生成编码碎片。这些碎片通过邻域树进行传输：区块领导者向大约 200 个 Layer 1 节点发送，每个节点再转发给大约 200 个 Layer 2 节点，在两到三层内覆盖所有活动的验证节点，并在大约 400 毫秒的区块时间内完成。
Solana 使用 Turbine 的分层邻域树，该树同时在许多验证节点之间并行分发碎片，实现了 O(log n) 的带宽扩展。以太坊使用一种 gossip 协议，需要经过多个顺序的随机节点重新广播才能达到全网络覆盖，产生大约 12 秒的区块时间，而 Solana 的区块时间大约为 400 毫秒。两种设计都反映了深思熟虑的架构优先级。
Turbine 包括随机路由（邻域树每区块时间窗口使用可验证的随机数进行重排）、Reed-Solomon 冗余（可容忍大约三分之一的数据包丢失）和 质押加权定位。随机路由使得执行的日蚀攻击（eclipse attacks）显著更加困难。 质押加权引入了一个轻微的中心化权衡：质押较高的节点会更早收到碎片，从而产生结构性优势，而 Tower BFT 的共识规则在一定程度上抵消了这种优势。
当数据包丢失率低于总碎片数量的大约三分之一时，Reed-Solomon 纠删码允许验证节点从幸存的数据碎片和编码碎片中重建完整区块。超过此阈值，验证节点会向持有缺失碎片的邻近节点发送修复请求。如果在区块时间窗口内无法完成修复，该区块时间窗口可能会被跳过。
Turbine 的 质押加权确实为高 质押节点带来了结构性优势，它们会更早收到碎片，并在邻域树中占据更高的位置。这是一个真实的权衡。缓解因素包括 Solana 分布在 2,000 多个活跃验证节点上，Tower BFT 的共识规则限制了早期碎片访问的价值，以及 Solana 基金会旨在拓宽 质押 分布的 质押 委托计划。
Turbine 由 Solana Labs 的联合创始人 Anatoly Yakovenko 设计，并首次在 2017 年发布的 Solana 白皮书 中进行了规范。Solana Labs（工程组织，区别于负责生态系统治理的 Solana 基金会）维护并持续开发该协议。
Gulf Stream 和 Turbine 是 Solana 交易生命周期中的顺序协议。Gulf Stream 在区块生产开始之前就将未确认的交易路由到预期的区块领导者，这样领导者就可以在等待交易到达的同时开始组装区块。然后，Turbine 在生产完成后将完成的区块分发给所有验证节点。
根据 Solana 白皮书，在理想条件下，Solana 的理论最大 TPS 约为 65,000。在现实世界条件下，根据 Solana Labs 的性能文档，截至 2024-2025 年，观察到的非投票 TPS 通常在每秒 2,000 到 4,000 笔交易之间。有时引用的更高原始 TPS 数字包括了验证节点投票交易，这些是内部共识消息，而不是用户交易。
Solana 相关指南
在 Bybit 上探索 SOL
读者可以查阅 当前 SOL 市场信息) 或 SOL/USDT 现货 市场.)。这些链接提供市场信息和访问权限；它们不验证技术声明，也不暗示 SOL 适合每一位读者。
Turbine 是使 Solana 大约 400 毫秒的区块时间窗口得以实现的技术机制：没有快速、带宽高效的区块传播，Solana 的验证节点就无法足够快地接收和投票区块，从而无法维持高吞吐量所需的区块节奏。该设计通过碎片化（shred-based fragmentation）、分层树分发和 Reed-Solomon 容错能力的结合，解决了真正的可扩展性瓶颈——朴素广播的 O(n) 带宽问题。
该设计带来了值得理解的权衡。 质押加权的树定位为大型验证节点提供了结构性优势。随机路由可以减轻日蚀攻击，但不能完全消除针对资源充足的攻击者。如 Solana 2021-2022 年的故障记录所示，在极端网络拥堵下，传播层可能会受到压力。这些都不是否定性的问题；所有这些都是为了换取协议提供的速度和带宽效率而做出的架构权衡。
Turbine 自 2020 年以来已在生产环境中运行，并根据实际情况进行了改进。随着 Solana 验证者数量的增长，O(log n) 的扩展特性变得越来越重要：验证者集每增加一倍，仅增加一个树层级，而不是使带宽成本翻倍。这一特性使得该设计在规模化时具有持久性。Turbine 区块传输的速度和可靠性也是使 Solana 成为高频去中心化金融 (DeFi) 应用的可行基础设施层的关键，在这些应用中，传输延迟直接影响交易确认结果。
核心要点
Turbine 是使 Solana 的速度主张变得可信的工程基础。了解它如何将区块分割成碎片（shreds）、通过质押加权的邻域树路由这些碎片，以及通过 Reed-Solomon 纠错码恢复丢失的数据包，是评估这些性能主张是否基于健全架构的最清晰方式。该设计具有真正的优势和真正的权衡；在对 Solana 基础设施进行任何诚实的技术评估时，这两者都值得重视。
延伸阅读与主要来源
以下主要来源为本文中的主张提供了技术基础。
- Turbine 区块传输 (Solana 文档): 由 Solana Labs 工程师维护的 Turbine 官方技术文档。
- Anatoly Yakovenko 编写的原始 Solana 白皮书 (2017): Turbine 以及 Solana 所有八项架构创新的创始规范。
- Solana Labs 工程博客: 来自 Solana Labs 的最新工程更新、协议改进和事后分析。
- Solana GitHub: turbine 源代码:): 为想要直接研究 Turbine 实现的开发者提供的源代码。
- Solana 基金会网络统计: 当前的验证者数量、质押分配数据和网络健康指标。
本文仅供教育目的，不构成财务或投资建议。加密货币投资具有重大风险。在做出任何投资决策之前，请务必自行研究。