Solana 交易流水线：TPU 四阶段流水线

本技术指南解释了 Solana 交易流水线 TPU 四阶段流水线及其如何支持并行处理。

Solana 大约每 400 毫秒生成一个新区块。大多数区块链一次处理一个交易，在开始下一个交易之前等待每个交易完成。Solana 则不然。

Solana 交易流水线是 Solana 的交易处理单元将传入交易通过四个顺序阶段的方法：获取 (Fetch)、签名验证 (SigVerify)、记账 (Banking) 和写入 (Writing)。多个交易批次同时通过这些阶段，因此，当一个批次正在被写入账本时，下一个批次已经正在被验证，而第三个批次已经正在被获取。这种并行处理使得 Solana (SOL)，即 Solana 区块链（所有交易记录的分布式账本）的原生资产，能够实现远超大多数 Layer-1 网络的吞吐量。

Solana 由 Anatoly Yakovenko 开发，他是一位前高通工程师，于 2017 年发布了历史证明白皮书，引入了使流水线速度成为可能的加密时钟机制。Solana Labs，这家总部位于旧金山的开发该协议的组织，将流水线作为其验证者客户端的核心功能实现。结果是该网络已成为去中心化金融 (DeFi) 应用的领先平台，包括去中心化交易所、借贷协议和需要亚秒级交易最终性的链上衍生品市场。

广为引用的区块链三元悖论认为，区块链只能优先选择三个特性中的两个：可扩展性、安全性和去中心化。Solana 的交易流水线是其对可扩展性维度的架构性解决方案。本文涵盖了流水线是什么，四个 TPU 阶段在机械上如何工作，历史证明如何实现流水线，Gulf Stream 和 Turbine 如何包装流水线的输入和输出，Sealevel 如何将流水线原理扩展到智能合约执行，Solana 在架构上如何与以太坊相比，以及流水线文档化的权衡和局限性所在。

目录

1. 什么是 Solana 交易流水线？（以及它对 SOL 的重要性）
2. Solana 的 TPU 流水线如何工作：四阶段详解
3. 历史证明：使流水线成为可能的加密时钟
4. Gulf Stream：交易如何在就绪前进入流水线
5. CPU 流水线类比：为什么 Solana 的架构对工程师来说应该很熟悉
6. Turbine：流水线的输出如何到达网络
7. Sealevel：将流水线扩展到智能合约执行
8. Solana vs. 以太坊：流水线架构比较
9. Solana 流水线架构的局限性、拥堵和实际权衡
10. 关于 Solana 交易流水线的常见问题解答
11. Solana 交易流水线与 SOL 投资论点

什么是 Solana 交易流水线？（以及它对 SOL 的重要性）

Solana 交易流水线是一种将交易处理分解为不同阶段，并在多个交易批次之间并行运行这些阶段的技术，从而使验证者硬件的任何一部分都不会空闲等待另一阶段完成。将其想象成汽车装配线：不同的车辆同时处于不同的站点，流水线在下一辆车进入之前永远不会停下来等待一辆车完全完成。

Solana 从计算机处理器那里借鉴了这一想法。现代 CPU 通过指令级流水线实现高吞吐量：当一个指令正在执行时，下一个指令正在被解码，而再下一个指令已经正在被获取。Solana 在验证者级别将相同的逻辑应用于交易。CPU 阶段到 Solana TPU 阶段的完整映射将在下面的 CPU 类比部分中介绍，但核心原则是相同的：始终保持每个阶段的运行。

大多数区块链按顺序处理交易，这意味着一个验证者必须完成一个交易（或一批交易）的所有处理，然后才能开始下一个。这种顺序模型产生了一个吞吐量上限，该上限完全由单个操作链的运行速度决定。流水线通过跨专用硬件组件并行运行多个操作来打破该上限，从而在无需加快每个单独阶段运行速度的情况下，降低了确认延迟（从提交交易到接收最终化的时间）。

根据 Solana 的技术文档，Solana 的理论 TPS（每秒交易量）约为 65,000 笔。这代表了流水线在理想条件下的最大值。实际的非投票 TPS 远低于此，通常在 2,000 到 4,000 TPS 之间，具体取决于网络负载和交易构成。Solana 将验证者投票交易与用户生成的非投票交易分开计数；包括投票在内的总 TPS 数字更高，但作为面向用户的吞吐量指标，其意义较小。相比之下，以太坊在 Layer-1 上处理大约每秒 15 到 30 笔交易，而比特币处理大约每秒 7 笔交易。

关键统计数据

Solana 的 TPU 流水线大约每 400 毫秒生成一个新区块，比以太坊的约 12 秒区块时间快约 30 倍。 理论 TPS：约 65,000。实际非投票 TPS：约 2,000-4,000（随网络负载变化）。

TPS 方法论说明：65,000 的数字是 Solana 技术文档中的理论最大值。实际非投票吞吐量随网络状况而异。2,000-4,000 的数字不包括投票交易。以太坊数字代表 Layer-1 吞吐量，不包括 Layer-2 解决方案。

实现这一目标的机制是 Solana 的交易处理单元 (TPU)，这是一个运行在每个领导验证者内的四阶段流水线。下一部分将解释该流水线在机械上是如何操作的。

Solana 的 TPU 流水线如何工作：四阶段详解

Solana 速度背后的机制是交易处理单元 (TPU) 内的一个四阶段流水线，它在每个时段内运行在领导验证者内部，通过每个阶段的专用硬件同时处理多个交易批次。

什么是交易处理单元 (TPU)？

在 Solana 中，交易处理单元 (TPU) 是每个验证者节点内负责实际执行交易处理的流水线引擎。这是 Solana 的领域特定术语，与机器学习中使用的 Google 的 Tensor Processing Unit 无关。

TPU 在每个约 400 毫秒的时隙内仅在领导者验证者 (leader validator) 上运行。非领导者验证者则运行交易验证单元 (TVU)，负责重放并验证由领导者生成的区块。Solana 通过确定的领导者计划 (Leader Schedule) 来确定哪个验证者担任领导者，该计划在每个纪元（epoch，约 2 到 3 天）提前发布，根据每个验证者的质押权重为其分配领导者时隙。正是这一计划使得 Gulf Stream 的交易预路由成为可能，详见下文 Gulf Stream 章节。

有关 TPU 架构的技术细节，请参阅 Solana 官方 TPU 文档) 和 Solana 时隙时间文档.)

Solana TPU 流水线的四个阶段

TPU 流水线通过四个连续阶段处理交易，每个阶段由专用硬件处理，每个阶段在向下一阶段传递输出的同时，从前一阶段接收新的输入。

1. 获取 (Fetch)： 网络堆栈通过 QUIC（一种现代传输协议，取代了原始的 UDP 连接以改进拥塞控制）接收原始交易数据包。获取阶段是流水线的进货码头。它从 Gulf Stream 在时隙开始前已成交的预加载缓冲区中拉取交易，并将验证后的数据包传递给 SigVerify。

2. 签名验证 (SigVerify)： GPU 验证传入交易的加密签名。每笔 Solana 交易都包含一个或多个数字签名，在发生任何状态更改之前必须对其进行验证。GPU 加速允许在此单个阶段内并行运行数千个签名验证。SigVerify 是身份验证检查站：通过的交易进入银行阶段；失败的交易将被丢弃。

3. 银行 (Banking)： CPU 将验证后的交易应用于账本状态，执行账户借记和贷记，并处理智能合约状态更改。银行阶段是流水线的会计部门，也是计算密集度最高的阶段。它也是高负载下的主要瓶颈：当交易量超过银行阶段的处理能力时，流水线会开始丢弃交易，而不是将它们排队。

4. 写入 (Writing)： NVMe SSD 将确认的账本条目写入磁盘，该阶段通过 Turbine 将生成的区块数据广播给网络的其余部分。写入阶段是调度和记录阶段：一旦完成，该区块就存在于链上并开始传播。

核心流水线机制同时在所有四个阶段运作。当批次 N 处于银行阶段时，批次 N-1 已处于写入阶段，而批次 N+1 已处于 SigVerify 阶段。没有任何阶段会等待另一阶段完成当前批次后再开始下一批次。这就是流水线实现并行吞吐量的方式：在时隙的每一刻，每一块硬件都处于占用状态。

[需要图表：DIAGRAM-01] 四阶段流水线展示了批次 A、B、C、D 同时处于不同阶段。批次 A：写入 (NVMe SSD)。批次 B：银行 (CPU)。批次 C：SigVerify (GPU)。批次 D：获取 (网络)。箭头显示每个批次在各阶段的进展，以及在所有四个阶段的同时运作。

谁来运行流水线？验证者与领导者计划

Solana 验证者是物理运行 TPU 流水线的节点运营商。每个验证者都是一台运行 Solana 软件的专用服务器，负责生成区块（如果它是当前的领导者）或验证并重放由领导者生成的区块（使用 TVU）。

领导者计划为每个约 400 毫秒的时隙分配运行 TPU 的验证者。该计划在每个纪元开始时从质押权重的验证者集合中确定性地计算得出，因此验证者可以提前几天知道即将到来的领导者时隙。这种可预测性使 Gulf Stream 能够在其时隙开始之前将交易预路由给即将上任的领导者，确保获取阶段缓冲区在时隙开始时已满。

运行 TPU 流水线需要企业级硬件：用于 SigVerify 阶段的专用 GPU、用于银行阶段的高核心数 CPU、用于写入阶段的企业级 NVMe SSD 以及用于获取阶段的高带宽网络。这些要求大大高于以太坊的验证者硬件阈值，这产生了一个在局限性章节中讨论的中心化权衡。有关当前的验证者硬件规格，请参阅 Solana 验证者要求文档.)

历史证明：使流水线化成为可能的加密时钟

历史证明 (PoH) 是一种加密机制，它允许 Solana 的流水线以硬件允许的最快速度运行，而无需验证者在推进到下一阶段之前相互通信以就每个交易批次的时间达成一致。

该机制运作如下：PoH 产生一系列连续的 SHA-256 哈希，其中每个哈希都以之前的哈希作为输入。由于计算 SHA-256 需要可测量且可验证的时间，因此生成的哈希序列构成了一个加密证明，证明链中记录的任何两个事件之间经过了特定量的时间。每个验证者都可以独立验证此序列，而无需联系其他验证者。

这与流水线化的联系是直接的。如果没有 PoH，流水线需要在每个阶段暂停，并等待网络就当前交易批次的排序达成共识，然后才能开始下一阶段。节点间的通信往返将是主要的延迟因素，使得在网络规模下实现 400 毫秒的时隙时间变得不可能。PoH 通过提供一个所有验证者都可以本地检查的共享、可验证时钟来消除这种等待。流水线的推进是基于 PoH 时钟，而不是网络消息的往返。

Anatoly Yakovenko 在 2017 年发表的历史证明白皮书)中介绍了历史证明，这得益于他在高通公司工作期间在分布式系统方面的背景。

PoH 不是权益证明 (Proof of Stake)。

历史证明不是 Solana 的共识机制。它是一个对事件进行排序并证明经过时间的加密时钟。Solana 使用权益证明（特别是 Tower BFT，它是其实用的拜占庭容错实现）进行共识，这决定了哪些验证者在经济上有资格参与以及谁领导每个时隙。PoH 提供排序和计时。权益证明提供经济安全性和抗女巫攻击能力。这些是不同的功能。

有关历史证明运作方式的完整说明，包括其加密构造及其与 Solana 共识机制的关系，请参阅我们的[历史证明专项说明]。

PoH 提供时钟。Gulf Stream 确保流水线的收件箱始终是满的。

Gulf Stream：交易如何在流水线准备就绪前进入

Gulf Stream 是 Solana 的交易转发协议，它确保流水线的获取阶段永远不会因为等待交易到达而闲置。大多数区块链将未确认的交易保存在全局内存池中，等待任何验证者提取它们。Solana 没有全局内存池。Gulf Stream 用确定的预路由取代了这种模式。

该机制分四个步骤运作：

1. Solana 的领导者计划提前发布哪个验证者将领导接下来的每个约 400 毫秒时隙。
2. 当用户或应用程序提交交易时，Gulf Stream 将其直接路由到将领导下一个相关时隙的验证者，而不是路由到共享池。
3. 当该验证者的领导者时隙开始时，其获取阶段缓冲区已经预加载了交易。
4. 获取阶段从这个预加载的缓冲区中拉取交易，而不是等待交易在时隙期间到达。

这种无内存池设计带来了三个可衡量的优势：它减少了确认延迟，因为交易等待时间更短；它消除了全局内存池对每个验证器的内存开销；并且它大幅降低了每个验证器的内存需求。

这种权衡是重要的：由于没有持久的交易缓冲区，未被快速处理的交易会被丢弃而不是排队。用户会收到“交易已过期”的错误，并必须重新提交。在高网络负载下，这种行为是导致拥堵事件的机制之一，正如在局限性部分所讨论的那样。

Gulf Stream 直接连接到 Fetch 阶段。

Gulf Stream 使用确定性的 Leader Schedule（领导者计划）将交易预先路由给即将到来的领导者。当验证器的 TPU Fetch 阶段激活时，它会从预加载的缓冲区中提取数据，而不是从全局内存池中提取。这就是为什么在正常情况下，Solana 的管道在 Fetch 阶段很少需要等待输入。

如果 Gulf Stream 是管道的输入机制，那么 Turbine 就是输出机制。

CPU 管道类比：为什么 Solana 的架构对工程师来说应该很熟悉

Solana 的交易管道借鉴了使现代 CPU 快速运行的相同架构原理：指令级流水线。这不是一个比喻。该设计在架构上受到 Patterson 和 Hennessy 的基础著作《计算机组织与设计》中所述的相同吞吐量技术的启发。

CPU 指令管道的工作原理如下。CPU 不是等待一条指令完成所有处理阶段后再获取下一条指令，而是将执行分解为顺序阶段（获取、解码、执行、写回），并在不同的指令上同时运行这些阶段。当指令 N 正在执行时，指令 N+1 正在解码，指令 N+2 已经正在获取。结果是，吞吐量与管道阶段的数量成正比增加，而无需任何单个阶段运行得更快。

Solana 的 TPU 管道将相同的原理应用于交易。阶段到阶段的映射是直接的：

[需要图示：DIAGRAM-02]

并排比较图。左侧：具有获取、解码、执行、写回阶段的 CPU 指令管道，并带有显示并发指令处理的波形箭头。右侧：具有获取、SigVerify、Banking、Writing 阶段的 Solana TPU 管道，并带有显示并发批处理的波形箭头。在类比阶段之间有映射线。

类比适用的地方： 两种架构都通过保持所有阶段同时运行来实现吞吐量提升。两者都不会等待一项完成才开始下一项。两者都以波浪式处理项目，在任何给定时刻都有多个项目处于不同阶段。根本的洞察是相同的：顺序处理会浪费硬件容量；管道并行消除了这种浪费。

类比失效的地方： 三个重要的区别使 Solana 的管道与 CPU 管道区分开来。

第一，Solana 的管道运行在通过网络连接的分布式硬件组件上，而不是在单个芯片内。网络条件会影响管道性能，这是 CPU 所没有的。

第二，故障模式不同。CPU 管道风险包括数据依赖（一条指令需要尚未完成的前一条指令的输出）和分支预测错误（处理器沿错误路径获取了指令）。Solana 管道的风险在性质上是不同的：交易垃圾信息通过使 Banking 阶段的处理能力过载而充当结构性风险，网络拥堵充当减慢 Fetch 和 Writing 阶段的停滞条件。这些是外部的、需求驱动的风险，而不是内部的、数据依赖的风险。

第三，Solana 的管道没有乱序执行的等效项。历史证明（Proof of History）时钟强制执行每个批次内严格的交易排序，因此管道不能像 CPU 可以重新排序指令以避免数据风险那样，重新排序交易以避免冲突。

理解这个类比及其局限性，是区分对 Solana 速度的表面知识与真正架构洞察的关键。

Turbine：管道的输出如何到达网络

Turbine 是 Solana 的区块传播协议，它负责处理管道 Writing 阶段完成后发生的事情。如果 Gulf Stream 确保管道始终有数据输入，那么 Turbine 确保管道的输出尽可能高效地到达网络的其余部分。

在 Writing 阶段将已确认交易批次提交给账本后，Turbine 将生成的区块分解成称为**碎片（shreds）**的小数据包，并通过验证器组成的树形网络进行传播。Turbine 不会同时将整个区块广播给所有验证器（这会需要领导者巨大的上行带宽），而是将传播负载分配到网络中。树中的每个验证器接收一部分碎片，并将其转发给树下方的其他验证器，其原理类似于 BitTorrent 如何通过让多个节点分担分发负载来分发文件。（Turbine 使用结构化的树而不是点对点群集，这对网络可靠性来说是一个重要的区别。）

与流水线兼容的设计在这里很重要：碎片开始向网络的其余部分传播，而领导者验证器已经在通过管道处理下一个交易批次。区块传播和区块生产并行运行。区块 N 的网络级传播不会导致区块 N+1 的生产暂停。

工程上的好处是，Solana 在不要求每个验证器节点都具备企业级上行带宽的情况下，实现了高区块带宽。只有领导者验证器承担全部生产负载；传播负载分布在整个网络中。

TPU 管道的输入/输出包装器：

Gulf Stream：管道输入（在槽位开始之前预先将交易路由给即将到来的领导者）。 Turbine：管道输出（通过验证器树网络分发验证后的区块数据作为碎片）。 两者共同确保 TPU 管道在两端都不会空闲。

Turbine 处理的是区块级别的管道输出。Sealevel 将流水线原理进一步扩展到智能合约执行层。

Sealevel：将流水线扩展到智能合约执行

交易流水线并没有止步于 TPU。Sealevel 将相同的并行处理原理扩展到智能合约执行，它是 Solana 最被低估的架构优势之一。

Sealevel 是 Solana 的并行智能合约运行时。它允许数千个智能合约（在 Solana 架构中称为程序（programs），这与以太坊术语不同，对开发者很重要）同时执行，而不是顺序执行。以太坊的 EVM（以太坊虚拟机）在单线程上处理智能合约，这意味着每个区块一次只能执行一个智能合约。Sealevel 使用所有可用的 CPU 核心并行执行多个程序。

该机制依赖于Solana的账户模型。每个Solana交易必须预先声明它将读取和写入的账户。Sealevel利用这些声明将交易分类到不重叠的组中：访问不同账户的交易可以同时执行，而不会有状态冲突的风险，而共享账户的交易则必须按顺序处理以保持正确性。

这种预先声明的要求是Solana开发者在构建程序时必须考虑的设计约束。程序必须预先声明它们将访问的所有账户，这与以太坊更宽松的状态访问模型不同，后者不预先声明合约存储的访问。

与TPU流水线的并行性是直接的。正如TPU流水线通过同时处理不同阶段的不同交易批次来保持所有四个硬件阶段的运行一样，Sealevel通过同时执行不冲突的程序来保持所有可用CPU核心的运行。将所有硬件始终保持运行的原则在此执行层面上得到了应用。

要深入了解账户声明和Solana的账户模型如何实际运作，请参阅我们的“Solana账户模型详解”文章。

Solana vs. Ethereum: A Pipeline Architecture Comparison

Solana与以太坊的性能差异归结于一个根本性的架构选择：并行流水线处理与顺序交易执行。

以太坊的EVM在单线程队列中处理交易。一个交易必须完成后，下一个才能开始。这种设计是故意的：顺序执行简化了状态管理，使智能合约的行为更容易理解，并允许验证者使用消费级硬件参与，从而形成一个广泛且相对去中心化的验证者集。以太坊目前拥有约90万或更多的活跃验证者。

相比之下，Solana的并行TPU流水线通过四个专用硬件阶段同时处理多个交易批次。GPU加速签名验证。CPU通过Sealevel并发地应用跨越不冲突程序的的状态更改。NVMe SSD处理写入，而Turbine则并行运行传播。这种设计产生了显著更高的Layer-1吞吐量，但它要求更高的硬件配置，并形成一个更集中的验证者集，约有2000名活跃验证者。

性能数据是具体的。以太坊的出块时间约为12秒；Solana的区块时间（slot time）约为400毫秒。以太坊的Layer-1 TPS约为15至30；Solana的真实世界非投票TPS约为2,000至4,000，取决于网络状况。（比特币作为参照，每秒处理约7笔交易。）以太坊的Layer-2解决方案，包括Arbitrum和Optimism，极大地提高了以太坊在其Layer-1基础之上的有效吞吐量，这是比较原始Layer-1数据时的一个重要背景。

有关这些架构在投资和开发维度上的详细比较，请参阅我们的“Solana vs. Ethereum架构全面比较”文章。

没有哪种架构在根本上是优越的。两者都代表了在广受引用的区块链三元悖论中的深思熟虑的权衡。以太坊为了去中心化和丰富的Layer-2生态系统而牺牲了吞吐量。Solana为了Layer-1吞吐量而牺牲了去中心化。哪种权衡更适合特定的应用程序或投资理论，取决于具体需求。

Solana的流水线架构的局限性、拥堵和诚实的权衡

Solana的流水线架构提供了文档化的性能优势，并伴随着文档化的权衡。无论是出于开发还是投资目的，理解这两者对于认真评估该网络都是必要的。

当流水线过载时：拥堵是如何发生的

当交易量超过Banking阶段的处理能力时，就会发生流水线拥堵。事件序列是特定的。Banking阶段落后于传入的交易量。由于Solana的无内存池Gulf Stream设计不维护持久的交易缓冲区，无法快速处理的交易会被丢弃而不是排队。用户会收到“交易过期”的错误，并必须重新提交。在极端拥堵水平下，验证者可能无法达成共识，因为相对于总交易量，流水线无法足够快地处理投票交易，导致网络停滞。

Solana在2021年9月、2022年1月和2022年5月等期间经历了重大的网络中断。原因并非完全一致。在某些情况下，过量的交易量压垮了Banking阶段的处理能力。在其他情况下，原因包括协调一致的交易垃圾邮件活动、软件错误或与流水线吞吐量限制无关的共识故障。将Solana的所有中断都归咎于流水线是不准确的。流水线处理能力限制在特定条件下被超出时，确实促成了一些中断事件，而其他中断则有单独的根本原因。

有关Solana网络事件及其原因的记录历史，请参阅我们的“Solana网络中断：历史及其对投资者的意义”文章。

自2022年以来，Solana已进行多项架构更改以解决流水线拥堵问题：

• QUIC协议采用：Solana用QUIC（一种提供UDP所缺乏的拥堵控制和连接管理的现代传输协议）取代了Fetch阶段的原始UDP连接。QUIC使Fetch阶段在高负载下能更智能地管理交易摄入，降低低成本交易垃圾邮件的有效性。
• 质押加权服务质量 (SWQoS)：Solana引入了质押加权服务质量（SWQoS），它优先处理从质押权重更高的验证者转发的交易。这降低了低质押行为者通过垃圾交易淹没流水线，以牺牲合法用户交易为代价消耗Banking阶段处理能力的能力。
• 优先费用：用户可以向交易附加优先费用，在需求高峰期表明愿意支付更高费用以通过流水线进行更快处理。
• Firedancer：Firedancer是由Jump Crypto开发的一个独立的验证者客户端实现，目前正在开发中，旨在通过提供一个减少单一实现风险的替代客户端来显著提高流水线吞吐量并提高网络弹性。

Solana 对验证者硬件的高要求产生了可衡量的去中心化权衡。运行 TPU 流水线需要用于 SigVerify 阶段的企业级 GPU、用于银行阶段的高核心数 CPU、用于写入阶段的企业级 NVMe SSD，以及用于 Fetch 和 Turbine 的高带宽网络。这些规格为家庭验证者制造了巨大的成本障碍。

结果是验证者集合比以太坊更加集中。Solana 拥有约 2,000 名活跃验证者；以太坊拥有约 900,000 名或更多（两个数字均有波动，应以当前网络数据为准）。Solana Labs 和 Solana 基金会已明确承认这一权衡：硬件要求是吞吐量优先设计选择的刻意结果，代表了 Solana 在区块链三元悖论的可扩展性-去中心化轴上的立场。这种权衡是否可以接受，取决于评估者的优先事项。

常见问题解答：Solana 交易流水线

什么是 Solana 的交易处理单元 (TPU)？

Solana 的交易处理单元 (TPU) 是验证者节点内物理处理交易的流水线引擎。这是 Solana 的术语，与 Google 用于机器学习的 Tensor Processing Unit（张量处理单元）完全无关。TPU 仅在每个约 400 毫秒插槽的领导验证者上运行，并通过四个阶段操作：Fetch（获取）、SigVerify（签名验证）、Banking（银行）和 Writing（写入）。非领导验证者则运行 TVU（交易验证单元）来验证和重放区块。

什么是历史证明，它与流水线有什么关系？

历史证明 (PoH) 是一种加密时钟，产生可验证的、时间排序的 SHA-256 哈希序列。PoH 通过消除验证者在推进每个流水线阶段之前进行通信并就交易顺序达成一致的需求，从而实现了流水线化。如果没有 PoH，节点间的通信延迟将成为主要瓶颈；有了 PoH，流水线根据共享的、本地可验证的时钟推进，无需网络往返。

什么是 Solana 中的 Gulf Stream？

Gulf Stream 是 Solana 的无内存池交易转发协议。Gulf Stream 不会将未确认的交易保留在全局池中，而是使用确定的领导者计划 (Leader Schedule)，在插槽开始前将交易直接路由到即将到来的领导验证者。当领导者的 Fetch 阶段激活时，它会从预加载的缓冲区中提取数据。这种预路由正是 Solana 能够维持约 400 毫秒插槽时间，而无需 Fetch 阶段等待交易到达的原因。

Sealevel 是 Solana 的并行智能合约运行环境。它通过要求每笔交易预先声明其将读写的账户，允许数千个智能合约（在 Solana 架构中称为程序）同时执行。Sealevel 识别非重叠的交易，并在所有可用的 CPU 核心上并行运行它们，将相同的并行处理原则从 TPU 流水线扩展到了智能合约执行层。

流水线拥堵是导致部分 Solana 停机的原因之一，但并非全部。当交易量超过银行阶段的容量时，无内存池设计会导致交易被丢弃而非排队，在极端拥堵时，验证者可能会失去共识。Solana 还经历过由软件漏洞、共识故障以及与流水线吞吐量限制无关的协调交易垃圾信息引起的停机。自 2022 年以来，QUIC 的采用和 SWQoS 已减少了由拥堵引发的故障。

Solana 的理论 TPS 约为 65,000，代表了根据 Solana 技术文档在理想条件下的流水线最大值。现实世界中的非投票 TPS 通常在 2,000 到 4,000 之间，具体取决于网络负载、交易类型构成和验证者性能。Solana 将验证者投票交易与用户生成的交易分开计数；包含投票的总数更高，但作为面向用户的性能指标意义较小。

Solana 为什么比以太坊快？

在 Bybit 探索 SOL

使用 Solana 价格页面) 查看当前的 SOL 市场数据，或者如果现货交易符合您的目标，请访问 SOL/USDT 现货市场)。Bybit 的交易活动与提交 Solana 链上交易不同；在 Solana 网络上充值或提现 SOL 时，可能仍会产生网络费用。

经验丰富的衍生品交易者还可以查看 SOLUSDT 永续市场.)。衍生品涉及额外风险，且不提供现货 SOL 的所有权。

Solana 交易流水线与 SOL 投资逻辑

Solana 的交易流水线是一项真正的架构创新，而非营销口号。四阶段 TPU 流水线代表了针对第 1 层吞吐量的一种连贯工程方法。历史证明提供了加密时钟，让流水线在无需网络共识延迟的情况下推进。Gulf Stream 预加载了流水线的输入。Turbine 分发流水线的输出。Sealevel 则将相同的并行原理延伸到了智能合约的执行中。

对于持有或评估 Solana (SOL) 的投资者而言，理解流水线意味着理解 Solana 性能差异化的技术基础。该架构的速度优势是结构性的，而非偶然的。它源于在交易生命周期的每一层应用并行处理原则的具体工程选择。

这些工程选择带来了真正的权衡。2021 年和 2022 年的拥堵事件表明，在对抗性或极端负载条件下，无内存池设计和银行阶段的吞吐量上限是真实的约束。高昂的验证者硬件要求导致验证者集合比以太坊更集中，这代表了在区块链三元悖论的可扩展性-去中心化轴上的刻意取舍。Solana 持续的架构演进，包括 QUIC 的采用、SWQoS 的部署，以及由 Jump Crypto 开发中的 Firedancer 客户端，反映了一个正积极致力于提高这些限制的协议。这些代表了发展轨迹，而非已解决的问题。

Solana 的流水线吞吐量使其成为了需要亚秒级交易最终性的 DeFi 应用程序的重要平台。以太坊仍然是一个有效的架构选择，其侧重点不同：更广泛的去中心化、成熟的第 2 层生态系统以及更庞大的开发者群体。这两个网络在生产区块链中各占据独特地位。

免责声明： 本文仅供教育目的，并不构成投资建议、财务建议、交易建议或任何其他形式的建议。Solana (SOL) 是一种加密货币。加密货币是高波动性资产，具有重大的亏损风险。在做出投资决策之前，请务必自行进行研究并咨询合格的理财顾问。

此主题群组的相关阅读：

• [历史证明详解]：我们的历史证明 (Proof of History) 专门详解
• [什么是 Solana (SOL)？完整指南]：Solana (SOL) 完整指南
• [Solana 质押：如何赚取 SOL 奖励]：Solana 质押指南
• Solana vs. Ethereum：完整架构对比: 完整 Solana vs. Ethereum 架构对比
• [什么是 Solana 中的 Gulf Stream？]：Gulf Stream 详解
• [Solana 网络中断：历史及其对投资者的意义]：Solana 网络中断历史