Solana 架构：SOL 速度背后的 8 项创新

准确性说明：网络性能、验证者数量、费用、协议功能、钱包支持和第三方集成会随时间变化。请将过往数据视为历史快照，并验证当前的原始资料文档。

Solana 架构通常通过其早期技术材料中的八个设计理念来解释。其中一些仍处于核心地位，而另一些则是历史提案或已经演变，因此本文将原始模型与当前的实现声明区分开来。

早期的 Solana 材料将架构分为八个旨在支持高吞吐量执行的想法。当前的性能、实现归属、软件组件和组织角色都在不断演变，因此本文将“八项创新”框架视为历史解释模型，而非完整的当前规范。

关键要点

Solana 的架构建立在八个支柱之上，每个支柱都解决了一个特定的性能瓶颈：

1. 历史证明 (PoH)：在共识运行前为事件标记时间戳的加密时钟
2. Tower BFT：在投票中使用 PoH 时间戳的共识机制
3. Turbine：将区块分解为更小数据包的区块传播技术
4. Gulf Stream：基于预定领导者的交易转发
5. Sealevel：并行智能合约执行运行时
6. 流水线：分阶段交易处理
7. Cloudbreak：专为并发访问设计的账户数据库
8. Archivers：历史性的分布式存储提案

性能说明： 历史理论 TPS、目标槽位时间 (slot time)、确认、最终性、基础费用和优先费用是不同的衡量指标。请验证当前的日期指标及其背后的方法论。

诚实的权衡： 自 2020 年 3 月主网启动以来，Solana 经历过有记录的网络中断，且其验证者硬件要求（建议 128GB 以上内存）造成了去中心化压力。这些是已知的架构权衡，而非偶然问题。

Solana 旨在解决的问题

传统区块链面临着一个根本性约束：区块链三元悖论。这一概念由 Vitalik Buterin 推广，指出一个网络最多只能同时实现三个属性中的两个。这些属性是可扩展性（高吞吐量）、安全性（抗攻击能力）和去中心化（分布式控制）。可以把它想象成一个三角形，推向其中一个角总是会把另外两个角向内拉。比特币的 TPS 约为 7，出块时间为 10 分钟，以牺牲吞吐量为代价优先考虑安全性和去中心化。以太坊在加入扩容方案之前，其基础层处理的 TPS 约为 15–30，同样优先考虑安全性和去中心化。

Anatoly Yakovenko 曾是高通（Qualcomm）的分布式系统工程师，他以不同的方式处理这一约束。2017 年 11 月，他发表了一篇题为《历史证明：区块链的时钟》的白皮书，描述了一种加密计时机制，可以大幅减少共识算法中的通信开销。Greg Fitzgerald 以联合创始人兼首席技术官（CTO）的身份加入，他们共同构建了后来成为 Solana 的协议。他们共同创立的营利性公司 Solana Labs 领导核心协议开发。Solana 基金会是一家总部位于日内瓦的独立非营利实体，负责资助生态系统赠款、验证者去中心化计划和教育倡议。

Solana 的八大支柱架构旨在这些三元悖论的限制内尽可能地突破可扩展性边界。该设计刻意接受了较高的验证者硬件要求，以此作为实现高吞吐量的成本。Solana 并没有解决三元悖论；它在可扩展性轴上占据了一个异常激进的仓位。这些权衡是有实际成本的，详见下文的架构权衡章节。

Solana 的八大架构支柱：概述

历史上的八部分框架涵盖了历史证明、Tower BFT、Turbine、Gulf Stream、Sealevel、流水线、Cloudbreak 和 Archivers。不应假设每一项目前仍是独立部署的子系统，特别是 Archivers 提案。

1. 历史证明 (Proof of History)：一种顺序 SHA-256 哈希链，在共识运行前创建可验证的时间戳记录
2. Tower BFT：一种经过 PoH 增强的拜占庭容错共识机制，利用 PoH 时间戳进行高效投票
3. Turbine：一种受 BitTorrent 启发的区块传播协议，将区块分解为称为 shreds 的小型纠删码数据包
4. Gulf Stream：一种无内存池的交易转发协议，将交易直接路由到即将上任的验证者领导者
5. Sealevel：一种并行智能合约执行运行时，可同时运行数千个非冲突程序
6. 流水线 (Pipelining)：一种交易验证优化 (TVO) 系统，通过四个并发硬件阶段处理交易
7. Cloudbreak：一种水平扩展的账户数据库，使用内存映射文件支持并发读写
8. Archivers：一种关于使用复制证明概念进行分布式账本存储的历史提案

下面的章节将深入介绍每个支柱。

历史证明 (PoH)：Solana 的计时引擎

历史证明 (PoH) 是一种顺序 SHA-256 哈希链，在共识运行之前创建可验证的、按时间排序的事件记录，充当整个网络的共享加密时钟。PoH 不是 Solana 的共识机制；该角色属于 Tower BFT。PoH 是让 Tower BFT 变快的计时层。

将 PoH 想象成一个加密秒表，它证明了事件之间经过了多少时间，而无需网络上的每个验证者先检查彼此的时钟。在传统的区块链网络中，验证者必须在每一轮共识期间彼此交换时间戳消息，这增加了随验证者集合规模增长的通信开销。PoH 完全消除了这种交换。

从技术上讲，PoH 是一个顺序 SHA-256 哈希链，其中每个输出都成为下一次计算的输入。由于 SHA-256 在这种链式形式下无法并行化，因此链的长度就是经过时间的防篡改记录。生成 N 个哈希链的验证者可以证明花费了计算 N 个顺序哈希操作所需的时间。不存在捷径。Anatoly Yakovenko 在他 2017 年 11 月的白皮书《历史证明：区块链的时钟.)》中首次描述了这一机制。

PoH 的作用类似于可验证延迟函数 (VDF)：这是一种计算过程，需要可预测的序列化时间来计算，但几乎可以瞬间完成验证。计算时间与验证时间之间的这种不对称性正是 PoH 具有实际意义的原因。验证者可以广播 PoH 输出，任何观察者都可以在微秒内验证其真实性，尽管生成该输出需要实际经过的时间。学术研究人员和协议分析师将这一特性视为 PoH 安全属性的理论基础。

通过建立可验证的排序参考，PoH 可以减少一些时间协调工作。它并不会消除共识消息，也不会直接保证特定的插槽 (Slot)、确认或最终确定时间。

一个关键的澄清：Solana 有时被描述为“历史证明区块链”，暗示 PoH 取代了权益证明 (PoS)。这是不正确的。Solana 在其经济安全层是一个权益证明区块链。验证者质押 SOL 作为抵押品，并因不诚实行为面临罚没 (Slashing)。PoH 是一种加密时钟，它使通过 Tower BFT 实现的 Solana PoS 共识变得更快、更高效。这两个层级都是必要的，互不替代。

Tower BFT：Solana 的共识机制

Tower BFT 是 Solana 的共识机制：它是实用拜占庭容错 (pBFT) 的 PoH 增强变体，使用 PoH 时间戳记录作为共享时钟，允许验证者在不交换时钟同步消息的情况下对账本状态进行投票。

拜占庭容错 (BFT) 描述了分布式系统的一种特性，即即使某些参与者的行为具有恶意或不可预测性，系统也能正确达成共识，其名称源于分布式计算中的拜占庭将军问题。传统的 pBFT 算法要求节点之间进行大量的消息传递以建立共同的时间视图，这使得它们在规模化时变得不切实际。Tower BFT 用 PoH 记录替代了这种消息传递。验证者已经共享了 PoH 时钟；他们不需要协商时间戳。

验证者是质押 SOL、验证交易、在被选为领导者时生产区块并对账本状态进行投票的网络参与者。他们对分叉投出时间锁定的选票，且选票权重随时间指数级增长。验证者在特定分叉上投票的时间越长，如果该分叉被放弃，它面临通过罚没（针对不诚实或不一致行为移除质押代币的惩罚机制）失去更多 SOL 的风险就越大。这种投票锁定机制为诚实参与创造了强大的经济激励，而无需额外的通信轮次。

Tower BFT 最多可容忍三分之一的验证者集表现出拜占庭行为。如果恶意验证者少于三分之一，网络就能达成正确的共识。这一阈值遵循拜占庭将军问题的数学要求，最初由 Lamport、Shostak 和 Pease 在 1982 年正式提出。研究者的共识演进路线：pBFT (Castro 和 Liskov, 1999) 奠定了基础算法；随后的变体包括 HotStuff 和 Tendermint 对其进行了改进；Tower BFT (2017) 则通过 PoH 进一步消除了时钟同步的开销。

目标插槽时间绝不能被视为最终性保证。应用程序应区分“已处理”、“已确认”和“已最终确定”的承诺级别，并根据其风险模型选择确认规则。

Turbine：规模化区块传输

在理论 TPS 达到 65,000 的情况下向每位验证者广播完整区块，将产生随网络规模线性增长的带宽瓶颈。Turbine 解决这一问题的方式与 BitTorrent 解决大型文件分发的方式相同：通过将数据分解为小块并在整个网络中分摊传播负载。

Turbine 是 Solana 的区块传播协议，灵感来自 BitTorrent 的基于碎片的分发模型。Turbine 不是由一位领导者同时向每位验证者广播一个完整的区块，而是将区块分解为称为“Shreds”的小型纠删码数据包，并通过树状结构的验证者网络进行分发。

Shreds 经过纠删码处理以实现冗余。传播树中的每个节点接收一部分 Shreds，将其转发到下一层，并从接收到的子集中重构完整区块。纠删码意味着即使某些 Shreds 在传输中丢失，仍可以从剩余的数据包中重构区块。带宽需求随网络规模对数级增长而非线性增长，因为每位验证者仅处理总区块数据的一小部分。

扩大验证者集不会按比例增加每个节点的带宽需求。拥有 2,000 个验证者的网络并不要求每个验证者处理中心化系统 2,000 倍的带宽。传播树分摊了负载。对于验证者运营商在规划数据接收和区块重构能力时，Turbine 的 Shred 结构具有参考意义。

Gulf Stream：无内存池交易转发

Gulf Stream 使用感知领导者的转发机制，而非传统的共享全局内存池。这改变了排队模型，但并没有消除拥堵或交易排序激励。

在以太坊上，未确认的交易在内存池（等待包含在区块中的未确认交易的共享池）中等待。在需求高峰期，这个池子会成为拥堵、费用上涨和最大可提取价值 (MEV) 的源头，MEV 是指通过在交易最终确定前重新排序、插入或审查内存池内的交易来提取的利润。以太坊用户通过支付更高的买价（Gas 费）来优先处理他们的交易，这就是为什么在高峰使用期间，费用历史上曾达到 5 至 50 美元以上。

该设计利用 Solana 已知的领导者调度计划，将交易转发给即将到来的领导者，而不是广播到传统的全局池。验证者可以在轮到他们生产区块之前对交易进行暂存，这可能会减少排队延迟，但拥堵、费用竞争、掉线和 MEV 仍是需要独立关注的问题。

感知领导者的交易转发改变了交易到达预定领导者的方式，但它并不能消除拥堵、优先费竞争、MEV、掉线交易或验证者的资源压力。当前的基准费用和优先费用应直接测量，而不是转换为固定的美元金额。

内存池的缺失改变了在 Solana 上构建的开发者的交易提交模式。交易具有可预测的转发路径，从而能够在达到完整最终性之前实现乐观确认。Solana 上的 MEV 空间虽然不是零，但实质上比以太坊小得多；质押加权的交易排序创造了其自身的动态平衡，dApp 设计者在构建前应予以研究。

Sealevel：并行智能合约执行

Sealevel 是 Solana 的并行智能合约执行运行时，是运行链上程序（Solana 对以太坊所谓智能合约的称呼）的引擎。与以太坊每次按顺序执行一个合约的 EVM 不同，Sealevel 在可用的 GPU 和 CPU 核心上同时执行数千个非冲突程序。

以太坊的 EVM 处理智能合约就像杂货店里的单个结账通道：一次处理一笔交易，每位购物者都在前一位购物者后面等待。Sealevel 同时开启了二十个结账通道，并行运行非冲突交易。这是 Solana 的吞吐量在基础层超过以太坊的主要架构原因。

Parallelism is possible because Solana's programming model requires every transaction to declare, at submission time, which accounts (the state objects that store data on Solana) it will read and write. Sealevel analyzes these account access lists to identify non-conflicting transactions: those that touch completely different accounts can run simultaneously without producing conflicting state changes. Transactions that share accounts must execute sequentially. The Sealevel runtime uses this declaration to schedule parallel or sequential execution across available hardware cores.

链上 programs are primarily written in Rust, compiled to Berkeley Packet Filter (BPF) bytecode, and executed by the Sealevel runtime. Parallel execution across GPU and CPU cores is what makes 65,000 theoretical TPS physically achievable at the hardware level.

对开发者而言意味着什么

When you deploy a program on Solana, you must declare all accounts your program will read and write at transaction submission time. This account access list is not optional; it is the mechanism Sealevel uses to schedule parallel execution. Omitting or incorrectly declaring accounts causes transaction failures.

Programs that share state with other programs (writing to the same accounts) cannot benefit from parallelism and will always execute sequentially. Design your program's account structure to minimize shared state wherever possible. Programs with narrow, non-overlapping account access patterns extract the most benefit from Sealevel's parallel scheduler.

The Anchor framework, a Rust-based toolkit that provides macros and abstractions that simplify common program patterns, is the most widely used development toolkit for Solana programs. For full documentation on the accounts model, program-derived addresses, and the Sealevel runtime, see the Solana developer documentation.

流水线：交易验证作为装配线

An automobile assembly line does not build one car completely before starting the next. Each station (welding, painting, interior fitting) works on a different car simultaneously. Solana applies this same logic to transaction validation through Transaction Validation Optimization (TVO).

Pipelining in Solana refers to TVO, an application of CPU pipeline architecture to blockchain transaction processing. The transaction validation process is divided into four discrete stages, each handled by a separate hardware unit operating concurrently. While one batch of transactions moves through one stage, the next batch is already in the preceding stage.

The four stages are:

1. Fetch: a kernel-space unit retrieves incoming transaction data from the network
2. Signature Verification (SigVerify): the GPU verifies cryptographic signatures across the batch in parallel
3. Banking: the CPU processes transaction logic, checks account balances, and updates account state
4. Write Confirmation: the disk writes the finalized state changes

While batch A is in Banking, batch B is in SigVerify, and batch C is being fetched. No hardware sits idle waiting for the previous batch to finish. This continuous staging eliminates the CPU idle time between processing stages that would otherwise cap throughput.

Pipelining is one of three pillars, alongside Sealevel and Gulf Stream, that together produce Solana's total transaction processing capacity. Solana extracts more throughput from the same hardware by keeping every processing component working at all times, rather than letting any stage sit idle between batches.

Cloudbreak: Horizontally Scaled Account Database

Cloudbreak is the filing system that lets Solana's parallel processors read and write account data simultaneously without queuing. Without it, the storage layer would serialize all account reads and writes, and Sealevel's parallelism gains would evaporate at the database boundary.

Cloudbreak is Solana's horizontally scaled accounts database: the data structure that stores the state of every account on the network. It uses memory-mapped files and SSD-tuned data structures to support concurrent reads and writes across multiple threads simultaneously.

Accounts are distributed across multiple data structures accessible in parallel. The operating system's memory-mapped I/O allows Cloudbreak to treat disk-resident account data as if it were in RAM, eliminating seek latency and enabling thread-level concurrent access. When Sealevel schedules 10,000 parallel transactions, Cloudbreak serves 10,000 simultaneous account reads and writes without serializing the requests into a queue.

The database architecture and the execution runtime are interdependent: neither delivers throughput without the other. Cloudbreak's I/O patterns require high-performance NVMe SSDs. Standard spinning disk drives cannot sustain the random read/write throughput that Cloudbreak's concurrent access model demands. Understanding Cloudbreak's account model is foundational for Solana program design: all state lives in discrete account objects, programs operate statelessly on those accounts, and account layout decisions directly affect runtime read/write performance.

Archivers: A Historical Storage Proposal

The Archivers concept appears in early Solana architecture materials but should not be presented as a currently deployed production subsystem without current primary-source evidence.

Early design materials proposed Archivers, also called Replicators in some descriptions, as lightweight participants storing portions of historical ledger data and proving storage. This explains the original approach to ledger growth, but it should not be described as an active reward-bearing production network without current primary-source confirmation. Current ledger retention and archival infrastructure must be documented separately.

With all eight architectural pillars in place, the combined system produces performance benchmarks that separate Solana from most other public blockchains, which the next section quantifies.

Solana Performance Benchmarks: TPS, Fees, and Block Finality

~65,000 TPS in historical theoretical benchmarks is Solana's theoretical maximum under optimal lab conditions, not a sustained real-world figure. The distinction matters for anyone using these numbers in investment analysis or system design.

Use current primary sources and a consistent measurement methodology for performance comparisons.

Real-world mainnet throughput runs below the theoretical maximum for several reasons. Not all transaction slots fill completely during normal demand. Spam-filtering mechanisms reject low-quality transactions before they reach the banking stage. Network conditions affect propagation timing. Approaching the theoretical ceiling requires sustained peak demand combined with full hardware utilization across the validator set, conditions that occur during specific high-traffic events rather than continuously.

Solana 的吞吐量配置源于多个协同工作的架构来源。PoH 提供了一个可验证的排序参考，可以减少时间协调开销。Sealevel 并行执行不冲突的工作。Leader-aware forwarding 可以在区块槽位开放前暂存交易，减少一些传统的内存池排队，但不会消除网络延迟。

以太坊的 Layer-2 生态系统（包括 Arbitrum 和 Optimism）以及未来的分片升级，使其有效吞吐量远超其基础层数据。在评估两个平台用于特定用例时，任何完整的比较都应考虑到其扩展的容量。

从架构到应用：Solana 的设计如何实现实际用例

Solana 的架构选择为其之上的应用产生了具体、可衡量的结果，而非抽象的性能数字。

NFT： Solana 通常较低的费用和并行执行能力可以支持高吞吐量的铸造，但优先费用、应用成本、拥堵、失败和资产标准仍然很重要。Gulf Stream 并未消除费用竞争。

DeFi： Solana 的运行时可以并行处理不冲突的交易，而通常较低的费用也可以支持频繁的交互。实际的兑换延迟和成本包括路由、滑点、优先费用、失败的交易、程序计算和市场状况。Gulf Stream 并未消除 MEV 或抢跑风险。

GameFi 和微交易： 通常较低的费用可以支持小额价值的操作，但总的应用成本和失败的交易仍然很重要。应使用当前数据单独比较以太坊 L1 和 L2 的成本。

支付： 基于 Solana 的支付应用可以以快速的用户反馈为目标，但钱包批准、乐观确认、根最终性、商户风险承受能力和链下操作是独立的阶段。信用卡授权不等同于公链结算。

促成这些应用实现的相同架构选择也伴随着已记录的权衡，下一节将不加修饰地进行审视。

架构权衡：网络可靠性、去中心化和速度

自 2020 年 3 月主网上线以来，Solana 经历了已记录的网络中断，主要原因是机器人生成的交易洪潮淹没了验证器的内存，导致验证器退出共识。

网络中断

Solana 的高吞吐量设计以最小的预过滤处理交易，这造成了特定的漏洞。当机器人用垃圾邮件交易淹没网络时，验证器可能会在交易到达过滤阶段之前耗尽可用内存，导致共识停滞。重大的已记录中断包括 2021 年 9 月一次持续约 17 小时中断，由机器人驱动的 IDO 事件交易量激增引发；以及 2022 年 1 月一次与验证器过度重复交易相关中断。2022 年和 2023 年还发生了其他较短的中断。

Solana Labs 实施了两项主要的架构缓解措施。QUIC 网络协议取代了 UDP 用于交易接收，提供了连接级别的流量控制，限制了任何单一来源可以提交的交易数量。基于质押权重的服务质量 (QoS) 优先转发来自拥有更多 SOL 质押的验证器的交易，使得低质押来源的垃圾邮件洪潮效果不佳。计算单元的费用市场在高吞吐量下形成了针对垃圾邮件的经济摩擦。自从部署了这些缓解措施以来，中断频率有所下降。对于需要持续高可用性的应用而言，中断历史仍然是一个已知的风险因素。

验证器中心化担忧

Solana 验证器需要大量的硬件。根据 Solana 基金会验证器文档,)，推荐的配置包括 128GB 以上的 RAM、高性能 NVMe SSD 和高带宽互联网连接。请在阅读时核实当前配置，因为随着协议升级，需求也在不断变化。这些要求远远超过了以太坊验证器参与 PoS 共识所需的条件。

硬件门槛将潜在的验证器池限制在有大量资本投资的运营商。硬件要求服务于真实的工程目的：它们是当前吞吐量目标所依赖的。它们也是更广泛的验证器参与的真正障碍。Solana 基金会资助验证器去中心化计划和小运营商的拨款，但性能目标与硬件成本之间的紧张关系是设计的结构性特征，而非偶然的政策问题。

区块链三元悖论定位

Solana 并未消除区块链三元悖论。其架构代表了优先考虑可扩展性和维护安全性，同时接受更高的验证器硬件要求，从而给去中心化带来压力。以太坊优先考虑去中心化和安全性，通过 Layer-2 解决方案解决可扩展性问题。比特币则以最小的吞吐量为代价，优先考虑安全性和去中心化。每个链在相同的悖论中占据不同的工程位置，没有任何一种配置可以同时最大化所有三个维度。

中断历史、验证器硬件要求带来的中心化压力以及三元悖论定位，都是任何严格技术评估 Solana 网络时必须考虑的重要因素。

Solana 与以太坊与比特币：架构对比

历史基准测试显示 Solana 的基础层吞吐量配置高于以太坊主网，但测量方式并非完全相同。PoH 提供预共识排序，Sealevel 并行运行不冲突的工作，而 leader-aware forwarding 改变了交易路由。常被引用的约 65,000 TPS 和 15-30 TPS 数字是过时、依赖于方法的参考点，而非永久的网络属性。

吞吐量和执行模型

以太坊的 EVM 顺序执行合约，每个区块一次一个。Sealevel 同时执行数千个不冲突的合约。这是 TPS 差距的主要来源。以太坊通过 Layer-2 扩展来解决吞吐量问题：包括 Arbitrum 和 Optimism 在内的 Rollup 在链下处理交易，并在以太坊基础层结算压缩批次，大幅提高了有效容量。Solana 的方法是在 Layer-1 进行横向扩展，避免了 Layer-2 架构为开发者和用户带来的额外复杂性。

开发者平台对比

以太坊的开发者生态系统（Solidity、EVM 工具、拥有多年审计代码的成熟 DeFi 协议）比 Solana 的更大、更成熟。Solana 的 Rust 和 Sealevel 模型提供了更高的基础层吞吐量和更低的费用，但需要理解账户模型和账户访问声明要求，这在以太坊上没有直接等价物。吞吐量和费用是限制因素的应用非常适合 Solana 的架构。优先考虑 EVM 兼容性、最广泛的开发者人才库或最大化基础层去中心化的应用，则更适合以太坊的基础层或其 L2 生态系统。

比特币作为第三个参考点

比特币的架构优先考虑安全性与去中心化，而非吞吐量。以约 7 TPS 和 10 分钟的区块时间，比特币并非为高频应用而设计。其工作量证明 (Proof of Work) 共识在设计上是计算密集型的：通过能源消耗而非经济质押来实现安全。Solana 和以太坊都提供比特币原初不支持的可编程智能合约平台。比特币的架构定位使其成为一类不同系统的参考，而非应用部署的直接竞争者。

有关五个维度的完整数据对比，请参阅上方的性能基准测试表（TPS、费用和区块最终性）。

关于 Solana 架构的常见问题解答

什么是 Solana 中的 Proof of History？

Proof of History (PoH) 是一个连续的 SHA-256 哈希链，在共识运行之前创建可验证的时间顺序事件记录。它充当整个验证者网络中的共享加密时钟，允许验证者在不交换时间戳消息的情况下处理交易。PoH 不是 Solana 的共识机制。Tower BFT 负责处理共识，并使用 PoH 时间戳作为其共享的时间参考。

Solana 每秒可以处理多少笔交易？

历史资料引用了理论和观察到的 TPS 范围，但实时吞吐量取决于交易组合、投票记账、过滤、拥堵、验证者软件和衡量方法。请使用当前的原始来源数据并明确所统计的内容。

谁创建了 Solana？

Solana 由 Anatoly Yakovenko 和 Greg Fitzgerald 共同创立。Yakovenko 曾是高通工程师，从事分布式系统和时钟同步工作，他于 2017 年 11 月的白皮书中首次描述了 Proof of History 机制。Solana Labs 是他们共同创立的营利性开发公司，负责领导协议工程。Solana Foundation 是一家总部位于日内瓦的独立非营利机构，负责支持生态系统的发展。

为什么 Solana 比以太坊快？

多个架构层共同导致了性能差异。PoH 提供了一个可验证的排序参考，可以减少一些协调开销；Sealevel 并行运行非冲突的工作；而感知领导者的转发机制改变了交易到达预定验证者的方式。历史 TPS 数据取决于方法论，不应被视为任何一个网络的永久属性。

Solana 的 8 大核心创新是什么？

早期的资料将该架构归纳为 Proof of History、Tower BFT、Turbine、Gulf Stream、Sealevel、Pipelining、Cloudbreak 和 Archivers。这是一个历史性的解释框架，并不证明每个命名的项目（尤其是 Archivers）在今天仍然是独立部署的子系统。

什么是 Solana 中的 Tower BFT？

Tower BFT 是 Solana 的权益加权投票和分叉选择机制，围绕 PoH 插槽和增加投票锁定而构建。不要假设存在特定的自动削减（slashing）实现，也不要平等地计算验证者：拜占庭阈值是根据质押权重计算的，安全性和活跃度假设需要更精确的处理。

什么是 Solana 中的 Gulf Stream？

Gulf Stream 描述的是感知领导者的交易转发，而不是传统的全局内存池。它可能会减少一些排队情况，但并不能消除优先费用竞争、拥堵、交易丢失、MEV 或抢跑风险。当前的联网行为应根据实现文档进行验证。

什么是 Sealevel 运行时？

Sealevel 是 Solana 的并行智能合约执行运行时。与以太坊每次执行一个合约的 EVM 不同，Sealevel 在可用的 CPU 和 GPU 内核上同时运行数千个非冲突程序。并行性是通过要求每笔交易在提交时声明其将访问的账户来实现的，这样运行时就可以识别非冲突操作并同时调度它们。

Solana 是权益证明区块链吗？

是的。Solana 使用权益证明 (PoS) 作为其经济安全层。验证者质押 SOL 作为抵押品，并因不诚实或不一致的行为面临削减处罚。Proof of History 是一种独立的加密计时机制，可使 Solana 的 PoS 共识机制更快。PoH 并不取代 PoS；它增强了基于 PoS 的共识机制 Tower BFT 的效率。

为什么 Solana 会出现网络宕机？

Solana 已记录的宕机主要由机器人生成的交易洪流引起，这些交易淹没了验证者内存，导致验证者脱离共识。该架构的高吞吐量设计在处理交易时预过滤极少，从而在大量垃圾邮件攻击面前显得脆弱。Solana Labs 实施了 QUIC 网络协议和权益加权 QoS 作为架构缓解措施，从而减少了宕机频率。有关特定的已记录事件，请参阅架构权衡部分。

Solana 与以太坊有何不同？

核心架构差异在于执行模型（并行 Sealevel 与顺序 EVM）、交易路由（无内存池的 Gulf Stream 与全局内存池）、编程语言（Rust 与 Solidity）以及基础层吞吐量（约 65,000 理论 TPS 与约 15–30 TPS）。两个区块链都使用权益证明来保证经济安全。以太坊庞大的开发者生态系统和二层网络（Layer-2）方案非常适合 EVM 兼容项目；Solana 的基础层吞吐量和费用结构则适用于将交易量和成本作为主要约束条件的应用程序。

什么是 Solana 的区块链三元悖论解决方案？

区块链三元悖论没有完美的解决方案；Solana 选择了权衡。该架构优先考虑可扩展性并维护安全性，同时接受较高的验证者硬件要求，这给去中心化带来了可衡量的压力。这是在三元悖论中的一种特定工程立场，而不是消除了它。与其他主流区块链相比，Solana 在可扩展性轴上的立场异常激进。

Solana 使用什么编程语言？

Solana 链上程序主要使用 Rust 编写，编译为伯克利数据包过滤器 (BPF) 字节码，并由 Sealevel 运行时执行。同时也支持 C 和 C++。Anchor 框架是一个基于 Rust 的工具包，提供宏和抽象来简化常见的程序模式，是目前使用最广泛的开发工具包。有关当前的生态系统工具，请参阅 Solana 开发者文档。

Solana 交易的成本是多少？

Solana 交易成本包括基础费用，并可能包括优先级和计算相关的费用。美元价值随 SOL 价格变化，而拥堵和应用程序行为会影响总执行成本。Gulf Stream 并没有消除费用竞争。

Solana 有多少个验证者？

截至撰稿时，Solana 拥有超过 1,000 个活跃验证者。请通过 Solana Foundation 验证者统计数据. 验证当前的计数和分布情况。验证者需要大量的硬件投资，包括 128 GB 以上的内存和高性能 NVMe SSD，这比大多数其他权益证明链的准入门槛更高，也是持续存在的去中心化疑虑的主要来源。

在 Bybit 上探索 SOL

读者可以查看 最新的 SOL 市场信息 或 SOL/USDT 现货市场.。这些链接提供市场准入渠道，并不证明 Solana、钱包或第三方协议适合每一位读者。

底线：Solana 的架构对 Web3 生态系统意味着什么

Solana 的架构结合了多项相互关联的设计决策。PoH 提供排序参考，Sealevel 并行化非冲突执行，感知领导者的转发机制改变交易路由，而 Pipelining、Cloudbreak 和 Turbine 则解决了处理、存储和传播问题。已记录的宕机历史和验证者资源要求与性能优势一样，都属于同一技术评估范畴。

对于选择平台的开发者来说，Solana 提供了任何主要生产区块链中最高的底层吞吐量和最低的交易费用之一。与以太坊的 EVM 相比，账户模型和 Rust 要求增加了设计复杂性。账户访问声明要求改变了程序状态的结构方式，而并行执行模型则奖励那些最小化共享状态的程序设计。

对于研究人员来说，Anatoly Yakovenko 的原始著作 历史证明：区块链的时钟 (2017年11月) 仍然是 PoH 设计的基础主要来源。Solana Labs 在 docs.solana.com 上维护着最新的架构文档。Solana 基金会在 solana.org/validators 上发布验证器网络统计信息。可通过 Solana Beach 获取实时网络数据。

通过理解 Solana 的八个架构支柱，您现在可以根据自己的判断来评估该网络的性能声明、权衡及其长期发展轨迹。

免责声明： 本文仅用于提供信息和教育目的。它不构成财务建议、投资建议或购买、出售或持有 SOL 或任何其他加密货币的推荐。所有业绩数据均可能发生变化。在做出投资决定前，请咨询合格的财务顾问。

相关阅读

• Solana 历史证明
• Solana 共识机制
• SolanaVM
• Solana 速度