Solana 执行层概述

进阶

9/10/2024, 2:08:23 PM

本文介绍了 Solana 区块链的运营机制，该平台以其高性能和低延迟著称。报告探讨了 Solana 设计和运营的复杂性，包括其交易生命周期、共识机制，以及如 SVM Rollups 和 ZK 压缩等关键特性。

前言

“我们比世界上任何人都更了解小型、高速、低成本的优势，现在我们将这些概念应用于区块链。” — Greg Fitzgerald，Solana 联合创始人

Solana 是一个以高性能、低延迟而闻名的区块链平台，具有速度、效率和用户体验方面的特点。它有独特的集成架构，能够在全球去中心化的网络中处理每秒数千笔交易。区块时间为 400 毫秒，交易费用仅为几美分，它在速度和成本效益上均表现出色。本文将深入探讨 Solana 的设计和操作复杂性，分析其关键机制和网络拓扑结构，这些因素共同促成了其强大的能力。

Solana 采用了一体化的区块链开发方法，充分利用了创始团队在构建分布式系统方面的多年经验。Solana 的核心原则之一是软件不应成为硬件的障碍。这意味着软件应充分利用其运行的硬件，并与其共同扩展。作为一个统一的生态系统，所有构建在这一区块链上的应用程序都继承了可组合性，使它们能够无缝互动和相互构建。这种架构还确保了直观的用户体验，无需桥接、单独的链 ID 或流动性碎片化。

Solana 正在快速发展，最近的进展包括 SVM Rollups 和 ZK 压缩，这些都是重要的扩展解决方案。虽然这些项目未来可能会影响我们对 Solana 的认知，但目前它们仍处于非常早期的开发或采用阶段，因此在本报告中不予涵盖。

交易生命周期

在本报告中，我们主要通过典型交易的生命周期来理解 Solana。为了构建一个基本的 Solana 交易理解模型，我们可以将流程概述如下：

用户发起交易，所有交易都被发送到当前的主区块生产者（即领导者）。领导者将这些交易汇总成一个区块，执行它们，从而更新其本地状态。
这个交易区块随后会在网络中传播，供其他验证者执行和确认。

本报告的后续部分将扩展此模型，并深入探讨这一过程的更多细节，从用户这一关键参与者开始。

请记住

对 Solana 核心协议的重大更改需要经过正式透明的过程，即提交 Solana 改进文档（SIMD），并接受社区成员和核心工程团队的公开批评。SIMD 会由网络进行投票表决。

六大阶段介绍

我们将在本报告中引用上述的六阶段图示，因为它为我们理解Solana核心元素之间的关系提供了一个一致的框架。

前面的章节根据这六个阶段进行了安排。最后的章节——Gossip、Archive、Economics和Jito——则涵盖了所有未尽之处。需要注意的是，有些章节会跨越多个阶段，而有些阶段会出现在多个章节中。

这种重叠是不可避免的，因为六大阶段框架有其局限性。实际上，Solana是一个复杂的分布式系统，具有许多相互依赖的元素。

用户

“Solana有潜力成为加密领域如同苹果公司那样的项目”——Solana联合创始人Raj Gokal

用户的旅程通常始于设置和资助钱包应用程序。Solana上有多个流行的钱包应用程序，既有本地移动应用，也有浏览器扩展。

钱包通过加密生成用户的密钥对，包括公钥和私钥。公钥作为账户的唯一标识符，所有网络参与者都能知道。用户在Solana上的账户可以被视为一个数据结构，保存与其在Solana区块链上的互动相关的信息和状态。因此，公钥类似于文件名：公钥唯一标识Solana区块链上的账户，就像文件名唯一标识文件系统中的文件一样。Solana上的公钥以32字节的Base58编码字符串表示。

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

私钥，也称为秘密密钥，可以看作是访问和修改账户的密码或访问密钥。使用私钥进行签名是区块链处理授权的方式。知道私钥意味着对账户拥有绝对的控制权。Solana的私钥也是32字节长。密钥对是由公钥（前半部分）和私钥（后半部分）组成的64字节组合。示例：

3j15jr41S9KmdfughusutvvqBjAeEDbU5sDQp8EbwQ3Hify2pfM1hiEsuFFAVq8bwGywnZpswrbDzPENbBZbd5nj

[63,107,47,255,141,135,58,142,191,245,78,18,90,162,107,197,8,33,211,15,228,235,250,30,185,122,105,23,147,115,115,86,8,155,67,155,110,51,117,0,19,150,143,217,132,205,122,91,167,61,6,246,107,39,51,110,185,81,13,81,16,182,30,71]

私钥也可以从助记词种子短语中派生，通常为12个或24个单词。这种格式常用于钱包，方便备份和恢复。多个密钥可以从一个种子短语中确定性地派生出来。

Solana采用Ed25519，这是一种广泛使用的椭圆曲线数字签名算法，用于其公钥加密需求。Ed25519因其密钥大小小、签名大小小、计算速度快以及对许多常见攻击的免疫性而受到青睐。每个Solana钱包地址代表Ed25519椭圆曲线上的一个点。

用户用私钥签署交易。该签名包含在交易数据中，其他参与者可以使用发送者的公钥进行验证。此过程确保交易未被篡改并得到相应私钥所有者的授权。签名还充当交易的唯一标识符。

Solana 交易

发送交易是改变 Solana 状态的唯一方法。任何写入操作都是通过事务执行的，并且事务是原子性的——要么事务尝试执行的所有操作都发生，要么事务失败。交易，更正式地称为“交易消息”，包含四个部分：标头、帐户地址列表、最近的区块哈希和指令。

标头：标头包含对帐户地址列表的引用，指示哪些帐户必须签署交易。
账户地址列表：该列表包括在交易过程中将被读取或写入的所有账户。为每个交易构建这样的列表是Solana独有的要求，开发人员可能会面临挑战。然而，事先了解交易将与哪些状态交互，能够实现许多其他区块链无法做到的优化。
最近的区块哈希：这个字段用于防止重复和过时的交易。最近的区块哈希在150个区块后过期（大约1分钟）。默认情况下，RPC每2秒尝试转发交易，直到交易被最终确定或最近的区块哈希过期，此时交易将被丢弃。
指令：这些构成了交易的核心部分。每个指令代表一个特定的操作（例如，转账、铸币、销毁、创建账户、关闭账户）。每个指令指定要执行的程序、所需的账户以及执行该指令所需的数据。

交易中的指令数量首先受到其大小的限制，最大可达1,232字节。此外，还有对可引用的账户数量的限制。最后，交易的复杂性也受到计算单位（CUs）的限制。计算单位量化了处理交易所需的计算资源。

请记住
SOL的最小单位称为“lamport”，等于SOL的十亿分之一，类似于比特币中的satoshi。lamport以计算机科学家和数学家Leslie Lamport的名字命名，他的研究奠定了现代分布式系统的许多理论基础。

执行交易的SOL费用分为两部分 - 基础费用和优先费用。基础费用是每个签名固定为5000 lamports，不论交易的复杂性如何——通常，每个交易有一个签名。

优先费用在技术上是可选的，但在区块空间需求高峰期变得必要。这些费用以微lamports（lamport的百万分之一）计算每个计算单位。它们的目的是作为价格信号，使交易在经济上更具吸引力，以便验证节点将其包含在区块中。

总费用 = 优先费用 + 基础费用

优先费用 = 计算单位价格（微lamports）x 计算单位限制

目前，所有交易相关费用的50%被销毁，永久从流通中移除，而剩余的50%归区块生产者所有。即将引入的新变化（SIMD 96）将允许100%的优先费用归区块生产者，基础费用保持不变。

发送交易

用户将钱包连接到应用程序，这样应用程序就可以读取用户的公钥。私钥则保持加密，并在与应用程序分离的安全环境中得到保护。

应用程序根据用户的操作构建交易消息参数。例如，如果用户想要交换两个代币，他们需要指定要购买的代币数量、要出售的对应代币，以及可接受的交易滑点。

交易消息准备好后，它会被发送到钱包进行用户私钥签名。此时，用户会弹出确认交易的窗口。该窗口可能会包含交易结果的模拟。一旦签名完成，交易消息和签名将返回给应用程序，应用程序可以将交易转发给其选择的 RPC 提供商，无论是其自有的还是使用钱包提供商的服务。

RPC（远程过程调用）提供商充当应用程序与构建区块的验证者之间的中介。他们是一个重要服务，使应用程序能够提交或模拟签名交易，并高效地检索链上数据。希望与网络交互的应用程序通过 JSON-RPC 或 WebSocket 端点进行（参阅文档）。

请记住
在 Solana 上，“失败交易”这一术语可能会引起误解并造成相当大的混乱。这些交易会产生费用，并且由运行时根据签署者的意图成功执行。它们之所以“失败”，是由于交易本身的逻辑要求这样做。超过 80% 的“失败”交易来自错误代码 0x1771，即超出滑点金额的代码（数据）。值得注意的是，这些交易中有 95% 是由仅占活跃 Solana 地址的 0.1% 提交的，主要是自动化的机器人，试图利用时间敏感的价格套利机会。

Gulf Stream

“Solana 的目标字面上是让交易的速度与新闻传播的速度一样快——就像光速通过光纤一样。我们的竞争对手是 NASDAQ 和纽约证券交易所。”—— Anatoly Yakovenko，Solana 联合创始人

RPC（远程过程调用）指的是 RPC 节点。这些节点可以被视为与网络交互和读取数据的网关。它们运行与完整验证者相同的软件，但设置不同，使其能够准确地模拟交易并保持对当前状态的最新视图。截至目前，Solana 网络上已有超过 4,000 个 RPC 节点。

与完整验证者节点不同，RPC 节点在网络中没有持有任何权益。没有权益，它们就无法进行投票或构建区块。这一设置与大多数其他区块链不同，因为在那些区块链中，验证者和 RPC 节点通常是相同的。由于 RPC 节点不接收质押奖励，因此运行 RPC 节点的经济模式与验证者不同，许多 RPC 节点作为开发者运行 Solana 应用程序的付费服务存在。

Solana 的独特之处在于它从一开始就设计为不使用内存池（mempool）。与传统区块链通过八卦（Gossip）协议随机和广泛传播交易不同，Solana 将所有交易转发到一个预定的主要验证者（即领导者）处，该验证者在每个时隙中负责处理这些交易。

重点提示
Solana 运营着四个集群：Localnet、Testnet、Devnet 和 Mainnet-Beta。当人们提到 Solana 或 Solana 网络时，他们几乎总是指 Mainnet-Beta。Mainnet-Beta 是唯一一个代币具有实际价值的集群，而其他集群仅用于测试目的。

一旦 RPC 接收到要包含在区块中的交易消息，它必须转发给领导者（leader）。在每个 epoch（大约每两天）之前，会生成一个领导者计划。即将到来的纪元被划分为若干个时隙，每个时隙固定为 400 毫秒，并为每个时隙选择一个领导者。拥有更多权益的验证者将更频繁地被选择为每个纪元的领导者。在每个时隙中，交易消息被转发给领导者，领导者有机会生成一个区块。当轮到某个验证者时，他们会切换到“领导者模式”，开始积极处理交易并向网络广播区块。

权益加权服务质量（SWQoS）

在 2024 年初，Solana 引入了一种新的机制，旨在防止垃圾信息和增强女巫抵抗能力，这一机制被称为“权益加权服务质量”（SWQoS）。该系统使领导者能够优先处理通过其他已质押验证者代理的交易消息。在这种机制下，持有更高权益的验证者获得相应更高的能力，将交易消息数据包传送给领导者。这种方法有效地缓解了来自未质押节点的女巫攻击。

在这一模型下，验证者还可以与 RPC 节点达成协议，将其按权益加权的容量租赁给 RPC 节点。作为回报，RPC 节点获得了更大的带宽，从而提高了在区块中交易的包含率。值得注意的是，领导者的 80% 能力（2000 个连接）被保留用于 SWQoS，剩余的 20%（500 个连接）则用于来自未质押节点的交易消息。这种分配策略类似于高速公路上的优先车道，驾驶者可通过支付通行费来避开交通拥堵。

SWQoS 对 Solana 生态系统产生了影响，通过提高将交易转发给领导者的要求并减少垃圾信息攻击的有效性。此变化鼓励高流量应用程序进行纵向整合。通过运行自己的验证者节点或访问已质押的连接，应用程序可以确保对领导者的优先访问，从而提升其交易处理能力。

QUIC 说明

在 2022 年底，Solana 采用了 QUIC 网络协议来管理交易消息的传输。这一转变是由于网络中由于机器人刷链上 NFT 发行导致的干扰。QUIC 使得快速、异步的通信成为可能。

QUIC 最初由 Google 于 2012 年开发，旨在结合两者的优势。它提供类似于 UDP 的快速异步通信，同时具备 TCP 的安全会话和先进的流量控制策略。这使得可以对单个流量源设置限制，从而使网络能够集中处理真实的交易。QUIC 还引入了独立流的概念，因此如果某一交易丢失，不会阻塞其他交易。简而言之，QUIC 可以被视为试图结合 TCP 和 UDP 的最佳特性。

请注意

权益加权是 Solana 系统中的一个反复出现的原则，涵盖了投票奖励、涡轮树、领导者调度、Gulf Stream 和 Gossip 网络。持有更多权益的验证者在网络中获得更高的信任和优先级角色。

区块构建

“我们认为 SVM（Solana 虚拟机）在当前虚拟机技术中是最好的。” — Andre Cronje，Fantom Foundation

许多区块链网络在广播之前先构建完整的区块，这种方法称为离散区块构建。与此不同，Solana 采用的是连续区块构建，即在分配的时间槽内动态地组装和流式传输区块，从而显著降低延迟。

每个时间槽持续 400 毫秒，每个领导者被分配四个连续的时间槽（1.6 秒），然后轮换到下一个领导者。为了获得接受，一个区块中的所有交易必须有效且可被其他节点重现。

在承担领导者角色的前两个时间槽，验证者会停止交易转发，以准备即将到来的工作负载。在此期间，入站流量激增，达到每秒超过十亿字节，因为整个网络将数据包发送到即将到来的领导者。

在接收后，交易消息进入交易处理单元（TPU），这是验证者的核心逻辑，负责区块生产。在这里，交易处理过程开始于获取阶段（Fetch Stage），在该阶段交易通过 QUIC 接收。随后，交易进入签名验证阶段（SigVerify Stage），进行严格的验证检查。在此阶段，验证者会验证签名的有效性、检查签名数量是否正确，并排除重复的交易

银行阶段

银行阶段可以描述为区块构建阶段。它是 TPU 的最重要阶段，得名于“银行”。银行实际上是某一特定区块的状态。对于每个区块，Solana 有一个银行，用于访问该区块的状态。当一个区块在足够多的验证者投票后变得最终确定时，他们会将银行中的账户更新写入磁盘，使其成为永久性的。链的最终状态是所有已确认交易的结果。这个状态总是可以从区块链历史中确定性地重建。

交易以并行方式处理，并打包成分类账“条目”，每个条目包含 64 个不冲突的交易。Solana 上的并行交易处理变得简单，因为每笔交易必须包含将要读取和写入的所有账户的完整列表。这个设计选择虽然增加了开发者的负担，但允许验证者通过轻松选择仅包含不冲突交易的条目来避免竞争条件。如果两个交易尝试写入同一账户（两个写操作），或者一个交易尝试读取而另一个交易写入同一账户（读取 + 写入），这些交易就会发生冲突。因此，冲突的交易会分配到不同的条目中并按顺序执行，而不冲突的交易则会并行执行。

有六个线程并行处理交易，其中四个专门处理普通交易，两个专门处理投票交易，后者对于 Solana 的共识机制至关重要。所有的并行处理都是通过多个 CPU 核心实现的；验证者没有 GPU 要求（参阅文档）。

一旦交易被分组为条目，它们就准备由 Solana 虚拟机（SVM）执行。交易所需的账户被锁定；进行检查以确认交易是最新的但尚未处理。账户被加载，交易逻辑被执行，账户状态被更新。条目的哈希将被发送到历史证明服务进行记录（更多内容将在下一部分讨论）。如果记录过程成功，所有更改将提交到银行中，并解除第一步中对每个账户施加的锁定。执行由 SVM 完成，SVM 是使用 Solana 的 rBPF 分支构建的虚拟机，rBPF 是一个用于 JIT 编译和 eBPF 程序虚拟机的库。值得注意的是，Solana 不规定验证者如何选择在区块内排序交易。这种灵活性是一个关键点，我们将在本报告的经济学 + Jito 部分进一步探讨。

请注意

术语 SVM 可能会引起歧义，因为它可能指代“Solana 虚拟机”或“Sealevel 虚拟机”。这两个术语描述的是相同的概念，其中 Sealevel 是 Solana 的运行时环境的名称。尽管最近有努力精确定义其使用范围，但 SVM 这个术语仍然未得到严格使用。

客户端

Solana 网络由数千个独立操作的节点组成，这些节点协作维护一个统一的账本。每个节点都是运行相同开源软件的高性能机器，这些软件被称为“客户端”。

Solana 最初推出了一个单一的验证节点客户端软件——最初是 Solana Labs 客户端，现在称为 Agave 客户端——使用 Rust 编写。扩展客户端的多样性一直是优先事项，并且这一目标将随着 Firedancer 客户端的推出而真正实现。Firedancer 是对原始客户端的全面重写，使用 C 语言构建。由高频交易公司 Jump 的经验丰富团队开发，其致力于成为任何区块链上性能最优的验证客户端。

历史证明

“我喝了两杯咖啡和一杯啤酒，一直熬到凌晨 4 点。我突然有了一个灵光一现的时刻，这个谜题类似于工作量证明，使用相同的 SHA-256 抗预映像哈希函数……我知道我掌握了时间的流向。” — Anatoly Yakovenko，Solana 联合创始人

历史证明（PoH）是 Solana 的秘密武器，像每个验证节点上的特殊时钟一样，促进了网络的同步。PoH 为事件的顺序和时间的流逝建立了一个可靠的真实来源。最关键的是，它确保遵循领导者计划。尽管名称类似，但历史证明并不是像工作量证明这样的共识算法。

节点之间的通信开销通常会随着网络的扩展而增加，协调变得越来越复杂。Solana 通过用 PoH 本地计算替代节点间的通信来缓解这一问题。这意味着验证者可以通过一次投票来提交一个区块。消息中的受信时间戳确保验证者无法相互干扰并提前开始生成区块。

PoH 基于哈希算法的独特属性，具体来说是 SHA256：

确定性：相同的输入总是会产生相同的哈希值。
固定大小：无论输入大小如何，输出哈希值总是 256 位。
高效：非常迅速地计算任何给定输入的哈希值。
抗预映像性：从哈希输出中找到原始输入在计算上不可行。
雪崩效应：输入的微小变化（甚至一个比特）会导致哈希值显著不同，这种属性被称为雪崩效应。
抗碰撞性：找到两个不同的输入生成相同的哈希值几乎不可能。

在每个验证客户端中，一个专用的“历史证明服务”不断运行 SHA256 哈希算法，创建哈希链。每个哈希的输入是前一个哈希的输出。这条链充当可验证延迟函数，因为哈希工作必须按顺序完成，未来哈希的结果不能提前知道。如果 PoH 服务创建了一个包含一千个哈希的链，我们知道在计算每个哈希时时间已经过去——这可以被看作是“微型工作量证明”。然而，其他验证者可以并行验证这千个哈希的正确性，速度远快于它们生成的速度，因为每个哈希的输入和输出已被广播到网络中。因此，PoH 难以生成但易于验证。

不同 CPU 上计算 SHA-256 的性能范围出奇地窄，最快的机器之间的差异很小。尽管在优化这一功能上投入了大量时间和精力，但一个常见的上限已经被达到，这主要是由于比特币对其的依赖。

在领导者的时间槽中，PoH 服务将接收来自银行阶段的新处理条目。当前的 PoH 哈希与条目中所有交易的哈希结合生成下一个 PoH 哈希。这作为时间戳，将条目插入哈希链中，证明交易处理的顺序。这个过程不仅确认了时间的流逝，还作为交易的加密记录。

在一个区块中，有 800,000 个哈希。PoH 流还包括“滴答”，这些是空的条目，表示领导者的存活性和时间的流逝，时间约为几分之一秒。每 6.25 毫秒发生一次滴答，每个区块包含 64 次滴答，总区块时间为 400 毫秒。

即使在不是领导者的时候，验证者也会不断运行 PoH 时钟，因为它在节点之间的同步过程中发挥着关键作用。

请记住

PoH 的关键好处是确保即使在区块生产者离线——即所谓的“失职”状态下——也必须遵循正确的领导者计划。PoH 防止恶意验证者在未轮到他们之前生成区块。

账户模型

“在 SVM 中分离代码和状态是最好的设计决策。嵌入式系统开发人员有福了，他们虔诚地将这个概念灌输到我的大脑中。” ——Solana 联合创始人阿纳托利·雅科文科 (Anatoly Yakovenko)

在 Solana 验证者中，全局状态保存在称为 AccountsDB 的帐户数据库中。该数据库负责在内存和磁盘上存储所有帐户。帐户索引中的主要数据结构是哈希图，这使得 AccountsDB 本质上是一个巨大的key-value存贮库。这里，key是账户地址，value是账户数据。

随着时间的推移，Solana 账户的数量已激增至数亿。如此大的数字部分是因为，正如 Solana 开发人员喜欢说的那样，“Solana 上的一切都是一个帐户！”

Solana 账户

账户是一个持久存储数据的容器，类似于计算机上的文件。账户有多种形式：

用户账户：这些账户具有私钥，通常由钱包软件为用户生成。
数据账户：这些账户存储状态信息，例如用户持有的特定代币数量。
程序账户：这些账户较大，包含可执行的字节码，类似于 Windows 上的 .exe 文件或 Mac 上的 .app 文件。
本地程序账户：这些是特殊的预部署程序账户，执行网络的各种核心功能。例如，Vote Program 和 BPF Loader。

所有账户都有以下字段：

程序

Solana 的程序账户仅包含可执行逻辑。这意味着当程序运行时，它会改变其他账户的状态，但自身不会发生变化。代码和状态的分离使 Solana 与其他区块链不同，并支持其许多优化。开发者主要使用 Rust 编写这些程序，Rust 是一种因注重以安全性和性能而闻名的通用编程语言。此外，还有多种 TypeScript 和 Python 的 SDK 可用于创建应用程序前端并实现与网络的程序化交互。

许多常见功能由本地程序提供开箱即用的服务。例如，Solana 不要求开发者部署代码来创建代币。相反，指令被发送到预部署的本地程序，该程序将设置一个账户来存储代币的元数据，从而有效地创建了一个新的代币。

租金

租金是一种机制，旨在激励用户关闭账户，减少状态膨胀。要创建一个新账户，账户必须持有一定数量的 SOL，称为“免租金”金额。这可以看作是为了保持账户在验证者内存中活跃而产生的存储成本。如果账户数据的大小增加，最低余额的租金要求也会相应增加。当账户不再需要时，可以关闭账户，租金将返还给账户所有者。

例如，如果用户持有一个以美元计价的稳定币，这个状态会存储在一个代币账户中。目前，代币账户的免租金金额为 0.002 SOL。如果用户将其全部稳定币余额转移给朋友，该代币账户可以关闭，用户将会收回 0.002 SOL。程序通常会自动为用户处理账户的关闭。还有几个应用程序可以帮助用户清理旧的、未使用的账户，并回收存储在这些账户中的少量 SOL。

所有权

尽管读取账户数据通常是允许的，但 Solana 的所有权模型通过限制谁可以修改（写入）账户的数据来增强安全性。这个概念对于在 Solana 区块链上执行规则和权限至关重要。每个账户都有一个程序“所有者”。账户的所有者负责管理该账户，确保只有授权的程序可以更改账户的数据。一个显著的例外是 Lamports（SOL 的最小单位）的转移——增加账户的 Lamports 余额通常是允许的，无论所有权如何。

状态存储

Solana 程序作为只读可执行文件，必须使用“程序派生地址”（PDAs）来存储状态。PDA 是与程序关联并由程序而非特定用户拥有的特殊类型账户。虽然普通 Solana 用户地址是从 Ed25519 密钥对的公钥派生的，但 PDA 没有私钥。相反，它们的公钥是从一组参数（通常是关键字或其他账户地址）和拥有程序的程序 ID（地址）组合中派生出来的。

PDA 地址存在于“曲线外”，意味着它们不像普通地址那样在 Ed25519 曲线上。只有拥有 PDA 的程序才能以编程方式生成签名，确保它是唯一可以修改 PDA 状态的程序。

上图：Solana 代币账户是程序派生地址（PDA）的具体实例。它们用于存储代币，并且“离线”存在。关联代币账户（ATA）程序确保每个钱包对每种代币类型只有一个关联代币账户，提供了管理代币账户的标准化方式。

涡轮（Turbine）

“Solana 最有趣的部分不是并行化、SVM 或 Toly 的推文，而是你可能没听说过的东西：Turbine。” — Mert Mumtaz, Helius

在银行阶段，交易被组织成条目并发送到历史证明流（Proof of History，PoH）进行时间戳标记。区块的银行被更新，条目现在准备进入下一个阶段——涡轮（Turbine）。

涡轮是领导者将其区块传播到网络其他部分的过程。受到 BitTorrent 的启发，它被设计为快速而高效，可减少通信开销，最小化领导者需要发送的数据量。

涡轮通过一种叫做“切片”（shredding）的过程，将交易数据拆分成“切片”（shreds）。切片是小的数据包，最大为 1280 字节，类似于视频流中的单独帧。重新组合这些切片后，验证者可以重放整个区块。这些切片通过互联网在验证者之间使用 UDP 发送，并利用纠删编码处理数据包丢失或恶意丢包。纠删编码是一种基于多项式的错误检测和修正方案，确保数据完整性。即使某些切片丢失，区块仍然可以被重建。

切片被分组为称为前向纠错（FEC）批次的集合。默认情况下，这些批次由 64 个切片组成（32 个数据切片 + 32 个恢复切片）。数据恢复在每个 FEC 批次内进行，这意味着批次中最多可以丢失或损坏一半的数据包，所有数据仍然可以恢复。每个 64 切片的批次经过 Merkle 化，根由领导者签名，并链式连接到前一个批次。这个过程确保切片可以从网络中任何拥有它们的节点安全获取，因为 Merkle 根链提供了可验证的真实性和完整性路径。

领导者最初向一个根节点广播，该节点将切片传播到所有其他验证者节点。这个根节点会随着每个切片的变化而变化。验证者被组织成层级，形成“涡轮树”。持有较多权益的验证者通常位于树的顶部，而权益较少的则位于底部。

树通常跨越两到三跳，具体取决于活跃验证者的数量。为了视觉简化，上面展示了一个 3 跳的示例，但 Solana 当前的实际扩展值设置为 200。出于安全原因，树的顺序会为每个新的切片批次进行旋转。

这种系统的主要目标是减轻领导者和根节点的出站数据压力。通过利用传输和重传系统，负载在领导者和重传节点之间分配，减少了对单个节点的压力。

共识

“一些聪明的人告诉我，在 Solana 中有一个认真聪明的开发者社区……我希望这个社区能有机会蓬勃发展。” — Vitalik Buterin, Ethereum 共同创始人

一旦验证者通过涡轮从领导者那里接收到新区块，它必须验证每个条目中的所有交易。这包括重放整个区块、并行验证 PoH 哈希、按照 PoH 规定的顺序重建交易，以及更新本地银行。

这个过程由交易验证单元（Transaction Validation Unit，TVU）处理，它类似于领导者的交易处理单元（Transaction Processing Unit，TPU），作为处理切片和区块验证的核心逻辑。与 TPU 类似，TVU 的流程被分为几个阶段，从切片获取阶段开始，接收通过涡轮传输的切片。在随后的切片验证领导者签名阶段，切片经过多次一致性检查，最重要的是验证领导者的签名，以确保接收到的切片来源于领导者。

在“重传阶段”（Retransmit Stage），验证者根据其在涡轮树（Turbine tree）中的位置，将数据片段转发给适当的下游验证者。在“重放阶段”（Replay Stage），验证者精确地重建每个事务，并以正确的顺序进行，同时更新其本地的银行状态。

重放阶段类似于TPU中的银行阶段（banking stage）；这是最重要的阶段，可以更直接地描述为区块验证阶段。重放是一个单线程的过程循环，协调许多关键操作，包括投票、重置PoH时钟以及切换银行。

上图：重放阶段负责将验证者切换到领导者模式并开始区块生产。原始图像来源：Justin Starry, Anza

共识

为了实现共识，Solana 使用了 Tower BFT（TBFT），这是一个自定义实现的实际拜占庭容错（PBFT）算法，PBFT 是大多数区块链用来达成链状态一致的算法。像所有区块链一样，Solana 假设网络中存在恶意节点，因此系统必须承受不仅仅是节点故障，还要抵御一定程度的攻击。

Tower BFT 与其他链的不同之处在于利用了由历史证明（Proof of History，PoH）提供的同步时钟。传统的 PBFT 需要多轮通信来达成交易顺序的共识，而 Solana 节点利用预先建立的事件顺序，大大减少了消息开销。

投票

为了参与共识并获得奖励，验证者需要对他们认为有效（即没有双花或不正确签名等问题）的区块进行投票，并将这些区块视为规范性区块。验证者为这些投票支付交易费用，这些费用由领导者处理并与常规用户交易一起包含在区块中。这就是为什么 Solana 的交易通常分为投票交易和非投票交易。当验证者提交正确且成功的投票时，他们会获得信用。这一机制激励验证者投票支持他们认为最有可能被包含的分叉，即“最重”的分叉。

‍分叉

Solana 的部分部分使其速度如此之快，即网络在生成下一个区块之前并不会等待所有验证者对新生成的区块达成一致。因此，两个不同的区块链接到同一个父区块，从而产生分叉，这并不罕见。

Solana 验证者必须对这些分叉进行投票，并使用共识算法来确定采用哪个分叉。当存在竞争的分叉时，最终只有一个分叉会被网络确认，而其他分叉中的区块则会被弃用。

每个时隙都有一个预定的领导者，只有该领导者的区块会被接受；一个时隙不能有两个提议的区块。因此，潜在的分叉数量被限制在一个“有/没有”跳跃列表中，这些分叉可以在领导者轮换时出现。一旦验证者选择了一个分叉，它会被承诺于这个分叉，直到锁定时间过期，这意味着它必须在最小期限内坚持其选择。

Solana 的“跳过率”——即一个区块未生成的时隙百分比——在 2% 到 10% 之间，分叉是导致这些跳过时隙的主要原因。其他可能导致跳过时隙的原因包括新纪元的开始、领导者离线或生成无效区块。

请记住

Solana 上交易的状态根据其在共识过程中的当前阶段而有所不同：

处理（Processed）：交易已被包含在区块中。
确认（Confirmed）：交易所在的区块已被三分之二的绝大多数投票确认。
最终确认（Finalized）：超过 31 个区块已建立在交易区块之上。

截至目前，Solana 的历史上从未出现过（乐观地）确认的区块没有最终确认的情况。

对于每个区块，Solana 使用一个银行来访问该区块的状态。当一个银行被最终确认时，该银行及其前置账户更新会被刷新到磁盘上。此外，任何来自早期银行但不是最终确认银行的前置的账户更新会被修剪。这一过程使 Solana 能够有效地维护多个潜在的状态。

八卦网络与归档

“一条区块链需要巧妙地结合密码学、分布式系统、操作系统和编程语言。Solana 的超级能力就是愿意逃离每个学科中最有趣的问题。” — Greg Fitzgerald, Solana 共同创始人

八卦网络

八卦网络可以被视为 Solana 网络的控制平面。与处理交易流的数据平面不同，控制平面传播关于区块链状态的关键元数据，如联系信息、账本高度和投票信息。如果没有八卦网络，验证者和 RPC 将不知道哪些地址和端口可以用于跨各种服务的通信。新节点也依赖八卦来加入网络。

Solana 的八卦协议使用非正式的对等通信，采用基于修改过的 PlumTree 算法的树广播方法。这种方法在不依赖任何中央来源的情况下高效传播信息。

八卦操作有点像一个独立的系统，与大多数其他验证者组件相对独立。验证者和 RPC 每 0.1 秒通过 UDP 使用八卦共享签名数据对象，确保信息在网络中的可用性。所有八卦消息必须小于或等于 1280 字节的最大传输单元（MTU），在代码库中称为“数据包结构”（packet struct）。

八卦记录是节点之间共享的实际数据对象。大约有 10 种不同类型的记录，每种记录都有不同的用途。八卦记录是经签名的、版本化的，并有时间戳的，以确保完整性和时效性。

八卦消息有四种类型：

推送（Push）：最常见的消息，与一部分“推送对等体”共享信息。
拉取与拉取响应（Pull & Pull Response）：定期检查遗漏的消息，拉取响应会发送回节点没有的信息。
修剪（Prune）：允许节点选择性地减少维护的连接数量。
Ping 和 Pong：节点的健康检查——如果发送了 ping，则期望收到 pong，表示对等节点仍然活跃。

八卦数据存储在集群复制数据存储（CrdsTable）中。这个数据结构可能会变得非常大，需要定期修剪。

归档

Solana 在区块链领域的独特之处在于不需要完整的历史记录来确定账户的当前状态。Solana 的账户模型确保了在任何给定时隙的状态都是已知的，使得验证者可以存储每个账户的当前状态，而无需处理所有历史区块。RPC 和验证者在设计上不会保留完整的历史账本。相反，他们通常只存储 1 或 2 个纪元（2-4 天）的交易数据，这足以验证链的末端状态。

归档目前由“仓库节点”管理，这些节点由专业 RPC 服务提供商、Solana 基金会及其他希望确保交易历史可用的生态系统参与者运营。仓库节点通常维护以下一个或两个内容：

账本归档：上传原始账本和适合从头开始重播的 AccountsDB 快照。
Google Bigtable 实例：存储从创世区块开始的区块数据，并以适合 RPC 请求的格式提供。

经济学与 Jito

“人们逐渐认识到，Solana 是今天唯一能够支持主流消费应用的区块链。” — Ted Livingston, 创始人

Solana 采用通货膨胀机制来分发质押奖励，每个纪元生成新的 SOL 代币。这一过程导致非质押者在网络中的份额相对于质押者减少，从而使财富从非质押者转移到质押者。通货膨胀从 2021 年初开始，初始年率为 8%，每年减少 15%，直到稳定在长期的 1.5%。

任何 SOL 代币持有者都可以通过将代币质押给一个或多个验证者来获得奖励并帮助保护网络。将代币分配给验证者称为委托。委托代币给验证者表示对该验证者的信任，但并不会赋予验证者对代币的所有权或控制权。所有质押、解质押和委托操作都在下一个新纪元的开始时执行。

投票奖励

当验证者提交投票时，如果投票准确且成功，他们会获得信用。投票交易费用为 0.000005 SOL，并免除优先费用。投票费用大约为每个验证者每天 1 SOL，使其成为运行验证者的主要运营成本。在一个纪元内，验证者通过投票积累信用，这些信用可以在纪元结束时兑换成通货膨胀奖励的一部分。

表现最佳的验证者能够成功投票大约 90% 的时隙。请注意，无区块的时隙百分比（跳过时隙率）从 2% 到超过 10% 不等，这些时隙无法进行投票。平均而言，验证者在大约 80% 的时隙上成功投票，在一个 432,000 时隙的纪元中，获得 345,600 个信用。

总通货膨胀奖励池首先根据纪元内获得的信用进行分配。验证者在总信用中的份额（其信用除以所有验证者信用之和）决定了他们的相应奖励。这一奖励进一步根据质押量进行加权。

因此，拥有总质押 1% 的验证者如果获得平均数量的信用，其通货膨胀奖励应该大约为总奖励的 1%。如果他们的信用高于或低于平均水平，其奖励将相应波动。

投票表现差异是验证者提供的回报（以年化收益率APY衡量）变化的一个原因。另一个因素是验证者收取的佣金率，这是指向他们验证者的总通货膨胀奖励的百分比。此外，验证者离线或与区块链不同步（称为失职）也会显著影响回报。

区块奖励

被指定为特定区块的领导者的验证者将获得额外的区块奖励。这些奖励包括该区块内所有交易的基础费用和优先费用的 50%，其余费用则被销毁。只有生成区块的验证者才能获得这些奖励。与每个纪元分发的质押奖励不同，区块奖励在区块生成时会立即记入验证者的身份账户。

流动性质押

流动性质押已成为原生质押的热门替代方案。参与者将SOL质押到一个质押池中，并获得一种称为流动性质押代币（LST）或流动性质押衍生品（LSD）的代币。这些LST代币代表了用户质押SOL的份额。尽管质押者仍在获得质押奖励，这些代币可以进行交易、用于各种应用程序，或转移给他人。该系统的主要优势在于显著提高了资本效率。

LST的价格 = （质押池中的总SOL * SOL的价格）/ 铸造的总LST数量

与传统的原生质押不同，随着时间的推移，质押者会直接增加更多的SOL。而在流动性质押中，奖励被重新投资到池中，从而提高LST的公允价值。只要存在机制可以用LST赎回底层质押的SOL，套利交易者将确保代币价格保持合理。

Jito

截至撰写本文时，超过80%的Solana质押量（来源）使用了Jito客户端验证软件。该客户端是原Agave客户端的一个分支，引入了一种协议外的区块空间拍卖，为验证者提供额外的经济激励。这个额外的激励是Jito客户端在验证者中广泛采用的主要因素。

当领导者使用Jito验证客户端时，他们的交易会首先被定向到Jito-Relayer。这个开源软件充当交易代理路由器。其他网络节点并不知道Jito-Relayer的存在，因为它们只是将交易发送到领导者通过八卦网络公布的地址和端口配置，即他们的入口套接字（ingress_socket），假设这是领导者的。

中继节点在将所有交易转发给领导者之前，会将其保存200毫秒。这一“速度缓冲”机制延迟了交易消息的传递，提供了一个简短的拍卖窗口。200毫秒后，无论拍卖结果如何，中继节点会乐观地释放这些交易。

区块空间拍卖通过Jito区块引擎在链外进行，允许搜索者和应用程序提交一组原子执行的交易，称为“交易捆绑包”。这些捆绑包通常包含时间敏感的交易，如套利或清算。Jito对所有小费收取5%的费用，最低小费为10,000 lamports。小费完全在协议外操作，与协议内的优先费和基本费分开。此前，Jito运行了一个规范的协议外内存池服务，但该服务现已被弃用。