Solana Sealevel：并行处理引擎

Solana Sealevel 并行处理允许运行时在那些交易声明它们将读取和写入的账户时，同时执行不冲突的交易。因此，Sealevel 是一个执行模型，而不是一个独立的共识机制或对所有工作负载都将并行运行的保证。

本文中的性能数据需要背景信息。被广泛引用的 65,000 TPS 数据是理论上的或受控测试的基准，并非保证的主网吞吐量。大约 400 毫秒的区块目标不等于交易最终性，费用因签名、计算使用量、优先级设置和网络条件而异。

以太坊在其基础层上每秒处理大约 15 笔交易。Solana 的文档过去曾引用过理论或受控条件下高达 65,000 TPS 的数据；实际面向用户的吞吐量各不相同。这种差距并非偶然。其背后的引擎被称为 Sealevel。

Sealevel 是 Solana 的并行智能合约运行时：一个同时处理数千笔独立交易而不是一次处理一笔交易的执行引擎。它由 Anatoly Yakovenko 构思，他曾是以太Qualcomm工程师，Solana Labs（Solana 核心协议开发背后的公司）的创始人，并于 2017 年撰写了 Solana 的基础白皮书。

想象一下高峰时段的主要高速公路。Solana（一种区块链，或分布式防篡改数字账本）使用 Sealevel 构建数百条车道，并按目的地对进站交通进行分类。以太坊上的每辆车都必须使用一条车道。汽车前后排队，一次只移动一辆。Sealevel 按目的地对汽车进行分类：前往不同地址的汽车同时行驶，无需等待。只有前往完全相同地址的汽车才需要排队。这种分类机制是 Solana 速度优势背后的架构洞察。

本解释涵盖了 Sealevel 是什么，其基于账户的并行性如何机械地工作，它与以太坊的执行环境相比如何，其不足之处，以及这些功能对于评估 Solana 的开发人员和投资者意味着什么。

Solana Sealevel 并行处理：快速概览

• Sealevel 是 Solana 的并行智能合约运行时，可同时处理数千笔交易。
• 工作原理： 交易预先声明账户依赖关系；Sealevel 并行运行不冲突的交易。
• 吞吐量： 理论最大值约为 65,000 TPS；实际非投票交易通常达到 2,000–4,000 TPS。
• 对比以太坊： 以太坊的 EVM 一次处理一笔交易；Sealevel 同时处理独立的交易。
• 诚实的局限性： Solana 在 2021 年和 2022 年经历了由于 Sealevel 上游的摄入故障导致的网络中断。

顺序执行 vs. 并行执行：Sealevel 解决的核心问题

顺序执行和并行执行是处理区块链交易的两种根本不同的方法，而这种区别解释了 Solana 和以太坊之间大部分的性能差距。

顺序执行意味着一笔交易在下一笔开始之前完全完成。交易到达，区块链锁定相关状态，运行计算，写入结果，解锁状态，然后才开始下一笔交易。每一步都会阻止其后面的步骤。没有重叠，没有并发，没有独立工作的同时处理。

由此产生的吞吐量上限是真实的。根据以太坊基金会的文档，以太坊的以太坊虚拟机 (EVM) 在其 Layer-1 (L1) 基础链上（不使用 Layer-2 (L2) Rollup）大约每秒处理 15–30 笔交易。这个数字多年来基本保持不变，因为瓶颈在于架构。

更广泛的挑战体现在被广泛引用的可扩展性三难困境中，即区块链在历史上难以同时最大化去中心化和安全性，同时实现高可扩展性。顺序执行是主要的性能瓶颈。添加更快的硬件并不能解决它，因为执行模型本身将所有工作串行化通过单个管道。

并行处理提供了不同的答案。与其说只有一个收银员服务所有顾客，不如想象一个拥有 500 个结账通道的超市。购买完全不同商品的顾客（没有共享支付终端，没有共享会员账户）可以同时在所有通道结账。只有真正需要共享终端的顾客才需要排队。商店的总吞吐量会呈数量级增长，不是因为任何一个收银员变得更快，而是因为独立的交易不再相互阻塞。

智能合约运行时是执行区块链上智能合约代码的软件环境。它是获取程序代码并实际运行它的那一层。在 Solana 上，智能合约被称为“程序”（Solana 文档中的规范术语，尽管“智能合约”仍然被广泛理解并在此处互换使用）。Sealevel 是 Solana 的运行时：它从头开始构建，旨在同时运行数千个这样的程序，而不是顺序运行。

理解 Sealevel 如何安全地实现这一点，没有竞态条件或状态损坏，需要理解使并行化安全的架构机制。该机制是 Solana 的账户模型。

Sealevel 如何工作：账户模型和预先声明状态

Sealevel 通过两种协同工作的架构功能安全地实现并行执行：Solana 的账户模型和通过历史证明 (PoH) 提供的交易预排序，PoH 是一种加密时钟机制，为 Solana 网络上的每个事件创建可验证的时间戳。本节将对此进行解释。

Solana 账户模型：代码与状态分离

Sealevel 可以并行执行交易，因为 Solana 的账户模型在执行开始前就为它提供了安全执行所需的信息。

在 Solana 上，程序仅包含可执行代码，不存储任何数据本身。这些是无状态程序：它们携带指令，但不拥有自己的状态。数据存在于独立的账户对象中，程序可以读取或写入这些账户。这种设计在架构层面将代码与状态分离开来。这与以太坊模型不同，在以太坊模型中，一个智能合约在其单一的合约地址中存储其可执行代码及其状态。

每个 Solana 交易在执行开始前都必须预先声明它将读取和写入的账户。Sealevel 读取这些声明来调度执行。跳过此步骤的交易将被运行时拒绝。这不是可选的簿记：这是实现安全并行性的结构性先决条件。

想象一下在有六个炉灶的厨房里工作的两位厨师。厨师 A 正在做意大利面，需要炉灶一和二。厨师 B 正在做炒菜，需要炉灶四和五。由于他们的工作台不重叠，他们可以同时工作而无需任何协调。他们不需要等待对方。只有当两位厨师同时需要炉灶三时，其中一位才需要等待。Sealevel 将相同的逻辑应用于交易：使用不同账户的交易并行运行；共享写入账户的交易按顺序运行。

开发者备注： 运行时将拒绝访问未声明账户的交易。账户访问必须在构建交易时确定，而不是在执行期间。这种约束是实现下文所述并行调度的设计机制。

Sealevel 如何调度并行执行

当交易到达 Sealevel 时，调度过程遵循四个不同的步骤。

1. 交易到达时携带一份清单：它将读取的账户和它将写入的账户的完整列表。
2. Sealevel 通过同时比较所有待处理交易的清单，构建一个依赖关系图（共享账户的交易地图）。
3. 不共享任何写入账户的交易是相互独立的。Sealevel 将它们同时分发到不同的处理器内核，在所有可用的 CPU 和 GPU 内核上并行运行。
4. 声明对同一账户具有写入依赖关系的交易则存在冲突。Sealevel 会将这些特定交易序列化，按照 PoH 确立的顺序依次执行，而所有其他非冲突交易则继续并行运行。

这种方法是确定性并行：Sealevel 在执行开始前识别冲突，而不是在事后解决冲突。它不会投机性地执行交易并回滚失败。这使其区别于乐观并发方法（如 Aptos Block-STM），后者先投机性地执行交易，并在发生冲突时重新运行。

Sealevel 还可以将签名验证任务路由到 GPU 内核，类似于 GPU 在游戏或 AI 工作负载中同时运行数千个着色器计算的方式。Solana 的交易处理单元 (TPU) 使用流水线技术在硬件单元上同时运行交易验证阶段，而 Sealevel 则负责该流水线的执行阶段。

Sealevel 与以太坊 EVM：直接的架构对比

Solana 在基础层比以太坊更快，主要是因为 Sealevel，即它的并行智能合约运行时。以太坊的 EVM 按照严格顺序一次处理一笔交易，而 Sealevel 则在多个处理器内核上同时处理数千笔独立的交易。

Sealevel 与 EVM 对比

EVM 一次处理一笔交易，是因为其有状态的合约架构使得在架构上很难提前确定哪些交易可以安全地并行化。以太坊上的智能合约存储自己的状态。理论上任何两个合约都可以共享状态，如果在不知道哪些交易是独立的情况下就进行并行化，会有损坏状态的风险。这并非以太坊设计的缺陷，而是其架构的结果。

Solana 将程序编译为 Solana 修改后的 eBPF（扩展伯克利数据包过滤器）字节码：一种适配自成熟 Linux 原生格式的紧凑指令集。Sealevel 以接近原生的速度执行此字节码。相比之下，EVM 字节码在自定义软件模拟的虚拟机上运行。BPF 方法提供了 EVM 自定义格式所不具备的硬件级优化路径，从而增强了 Sealevel 在指令执行层面的吞吐量优势。

Solana 在架构上与以太坊的不同之处在于：

• 执行模型： 并行确定性 (Sealevel) 对比 串行 (EVM)
• 状态架构： 无状态程序和独立的账户数据 对比 有状态合约
• 扩容方案： L1 并行执行 对比 L2 Rollup 和分片
• 开发语言： Rust 对比 Solidity

关于账户模型在不同第 1 层区块链架构中的差异，Solana 的预先声明方法与其他链上存储设计之间的对比具有启发意义。

Sealevel 对比 Aptos Block-STM 和 Monad：并行执行方法的差异

Sealevel 并不是唯一投产的并行执行架构。将其方法与 Aptos Block-STM、Monad 以及 Sui 进行对比，可以揭示每种设计所做的独特权衡。

Aptos 使用 Block-STM（软件事务内存），这是一种乐观并发方法。它在不需要预先声明账户的情况下，投机性地并行执行交易，然后验证结果并重新执行任何产生冲突的交易。对开发者的好处是：无需在构建时声明账户依赖关系。权衡是：高冲突的工作负载会触发重新执行，这会耗费时间。Sealevel 完全避免了重新执行，因为它在运行前就识别了冲突。

Monad 旨在实现并行 EVM 执行并兼容以太坊 Solidity。它对执行阶段进行流水线处理，并在 EVM 模型之上应用乐观并行。Monad 的赌注是 EVM 兼容性值得付出架构上的开销。Sealevel 做了相反的选择：采用全新的账户模型，拥有更高的原始并行度，但要求开发者采用新的编程范式。

Sui 使用基于对象的所有权作为其并行单位。触及独立对象的交易在定义上就是并行运行的，不需要显式声明。根据目前的文档，每种方法（Sealevel 的确定性模型、Block-STM 的乐观模型、Sui 的对象所有权模型）都代表了对同一个问题的不同回答：如何实现安全的大规模并行。

没有哪种方法是绝对优越的。Sealevel 的预先声明增加了开发者的负担。Block-STM 的乐观模型在重冲突负载下会产生重新执行成本。Monad 为了 Solidity 兼容性权衡了原始性能空间。正确的选择取决于用例需求以及团队已经在运行的开发者生态系统。

Sealevel 在 Solana 八大创新架构中的作用

Sealevel 的并行性之所以安全，是因为历史证明 (PoH) 在执行开始前已经建立了一个可信的交易顺序。理解这种依赖关系可以揭示 Sealevel 如何融入 Solana 更广泛的八大创新架构，以及为什么这些组件不能被孤立评估。

Solana 的架构基于八项共同设计的创新：PoH、Tower BFT、Turbine、Gulf Stream、Sealevel、Pipelining、Cloudbreak、Archivers。每一项都处理交易生命周期的不同阶段。Sealevel 是执行层：运行程序的引擎。

PoH 是一种加密时钟机制，它为 Solana 网络上的每个事件创建一个可验证的时间戳。每个验证者都同意这个时间戳序列。当交易到达 Sealevel 时，排序问题已经解决。Sealevel 不负责协调。它负责调度。

把它想象成一条装配线。PoH 是传送带，按验证后的顺序交付预先分类的工作项目。Sealevel 是生产线上的工人团队，他们同时提取并处理不冲突的项目。工人们不需要协商下一步处理哪个项目，因为传送带已经确定了顺序。如果没有传送带，工人们就会不断停下来进行协调，从而完全消除并行化带来的好处。

由于 PoH 预先排序交易，并且账户模型需要预先声明状态，Sealevel 在执行开始前就能识别出哪些交易会发生冲突。冲突是前瞻性地解决的，而不是事后解决，这与先执行后在发生冲突时重新运行的乐观并发模型不同。

其余的创新各自扮演支持角色。Tower BFT（Solana 的共识机制，是 Practical Byzantine Fault Tolerance 的 PoH 优化版本）验证 Sealevel 生成的区块。Gulf Stream（无内存池的交易转发协议）在区块确认前将交易推送到验证者，因此 Sealevel 可以在当前区块最终确定的同时开始处理下一批交易。Cloudbreak（账户数据库）与 Sealevel 协同设计，以支持跨越数千个并行执行线程的并发读写。

实际性能：Sealevel 实际带来了什么（以及它的不足之处）

Sealevel 在顺序执行的区块链上实现了实际吞吐量提升，但其真实世界性能远低于理论最大值，并且网络曾发生过重大宕机。为了诚实评估，这两个事实都很重要。

理论吞吐量与实际吞吐量

Solana 的吞吐量数据需要仔细解读，因为通常引用的数字，即每秒约 65,000 笔交易 (TPS)，描述的是理论架构上限，而非主网的典型性能。

已发布的 TPS 数据通常包含内部验证者投票交易，这会夸大报告的数字。非投票 TPS 反映了实际面向用户的交易吞吐量。

约 65,000 TPS 的数据作为架构设计上限是真实的。它描述了 Sealevel 在理想条件下和最佳交易配置文件下可以处理的内容。真实世界的数据较低有几个已记录的原因：交易复杂性、热门程序中的账户争用以及 Sealevel 本身上游的网络级限制。即便如此，Solana 的主网吞吐量仍远超以太坊的底层，后者约为 15–30 TPS（以太坊基金会文档）。

Sealevel 的并行执行能力是已记录的架构现实，而非营销宣传。理论 TPS 数据反映了运行时的设计；真实世界的数据反映了其周围的运行环境。

Solana 在 2021 年和 2022 年经历了几次重大的网络宕机，对 Sealevel 的任何诚实描述都必须解释为什么在运行时具有并行处理能力的情况下仍然会发生这些宕机。

2021 年 9 月的一次事件持续了约 17 小时。一个试图在代币发行中获得优势的机器人网络，用垃圾信息淹没了网络的交易接收层，导致其不堪重负。2022 年 1 月以及 2022 年全年的多个时间点也发生了其他重大宕机。这些都是已记录的历史事件，并有已发布的事件事后报告。

宕机并非 Sealevel 并行执行逻辑的失败。它们是 Sealevel 上游交易接收基础设施的失败。Sealevel 的约 65,000 TPS 容量描述了它可以处理的有效交易数量；它不能使网络免受交易洪水的影响。一条有 100 个车道的公路，当十亿辆汽车试图同时进入匝道时，仍然会发生交通堵塞。处理上限和垃圾信息抵抗是独立工程问题。

非同质化代币 (NFT) 的铸造活动，数千名用户同时尝试铸造，造成了网络面临的一些最剧烈的负载峰值，并暴露了相同的接收层瓶颈。

此后，Solana 实施了几项工程响应：QUIC 协议取代 UDP 用于交易接收（提供更好的拥塞控制），本地费用市场允许应用程序在负载下设置优先费用，Jump Crypto 开发的 Firedancer 验证者客户端预计将进一步提高吞吐量和弹性。这些响应表明了迭代改进，但没有一个升级能消除开放访问交易提交和有限处理能力之间固有的紧张关系。

Sealevel 的多核并行执行还要求验证者运行高规格硬件：快速的多核处理器、大量的 RAM 分配和高带宽网络连接。这为验证者参与设置了实质性的障碍，并代表了去中心化权衡，而 Solana 架构的批评者正确地指出了这一点。

Sealevel 是 Solana (SOL) 持久的竞争壁垒吗？

Sealevel 在底层为 Solana 提供了实际的吞吐量优势。这种优势是否构成持久的竞争壁垒，需要将架构事实与生态系统变量区分开来。

持久性的论点始于集成深度。Sealevel 的架构与其 Solana 的其他协同设计的组件紧密耦合。PoH 在交易到达 Sealevel 之前对其进行预排序。Cloudbreak 处理 Sealevel 并行线程所需的并发存储读取。Gulf Stream 减少了 Sealevel 必须处理的交易积压。在没有完整堆栈的情况下，单独复制 Sealevel 的性能无法重现其优势。这种集成是一个真正的复制障碍：并非绝对，但非微不足道。

账户模型还为围绕 Sealevel 范式构建了生产应用的开发者创建了实际的切换成本。围绕预先账户声明、PDA 模式和 Anchor 开发框架设计的程序架构，如果不进行大规模的重新架构，就无法移植到 EVM 链。不断增长的 Rust 工具库、Anchor 资源、审计服务和参考实现增加了进一步的惯性。

反对永久持久性的论点同样真实。Aptos 和 Monad 表明，并行执行架构可以构建在不同的技术基础上。以太坊的 L2 生态系统 (Arbitrum, Optimism, Base) 通过链下执行和链上结算实现了高吞吐量，这是另一种实现可扩展性的方法，完全绕过了 Sealevel 的限制。对于许多去中心化金融 (DeFi) 用例（包括自动做市商 AMM 和去中心化交易所 DEX，如 Orca 和 Raydium），L2 卷轴的吞吐量已经足够，无需 Sealevel 的范式转变。

Sealevel 的优势在结构上最可辩护的用例是需要高频、同时链上状态更新的场景：链上订单簿、强制平仓引擎以及数千个独立交易必须同时结算的大规模 NFT 铸造活动。对于这些用例，即使有 L2 解决方案，在 EVM 链上仍然具有架构上的难度，因为 L2 结算仍需要与 L1 层协调才能最终确定。

Sealevel 在底层代表了真实且已记录的架构差异化因素。它的竞争壁垒是真实的，但并非永久的。它面临着新兴的并行链和以太坊不断扩展的 L2 生态系统的压力。Solana 地位的持久性，在很大程度上取决于网络效应（开发者采用、DeFi 总锁仓价值、机构基础设施），以及运行时本身的原始技术架构。

关于区块链网络间的 Layer-1 竞争定位以及架构权衡在不同 L1 设计中的体现，Sealevel 的设计选择及其带来的借鉴意义是值得研究的。

本节内容仅供信息参考和教育目的，不构成财务、投资或交易建议。加密货币投资具有重大风险，包括全额亏损的风险。在做出投资决策前，请咨询合格的财务顾问。

相关 Solana 架构资源

Sealevel 依赖于 Solana 账户模型，是 Solana 更广泛的速度架构 的一部分。市场读者可以参考 SOL 价格页面. SOLUSDT 永续合约 是一种杠杆衍生品，具有强平风险；它不是衡量 Sealevel 技术性能的指标。

常见问题解答：Solana Sealevel 并行处理

这些常见问题解答旨在解决有关 Sealevel 并行执行模型、吞吐量数据以及与其他区块链架构关系的最常见困惑。

什么是 Solana 中的 Sealevel？

Sealevel 是 Solana 的并行智能合约运行环境：它是处理引擎，可同时处理数千笔独立的交易，而非一次处理一笔。通过 Solana 的账户模型识别哪些交易不共享数据依赖关系，Sealevel 将它们同时调度到不同的处理器内核，从而实现顺序执行无法企及的吞吐量。

Sealevel 如何实现并行交易处理？

Sealevel 要求每笔交易预先声明将读取和写入哪些账户。它利用这些声明构建依赖图，识别出哪些交易没有重叠的账户。这些独立的交易可以在多个处理器内核上同时运行。共享写入账户的交易会被序列化并按顺序执行，而所有其他非冲突交易则继续并行处理。

Solana 的 Sealevel 与以太坊 EVM 有何不同？

以太坊虚拟机 (EVM) 按顺序一次处理一笔交易，因为以太坊的有状态合约架构使得在架构上很难提前确定哪些交易可以安全地进行并行化。Sealevel 则同时处理非冲突交易，因为 Solana 的账户模型要求交易预先声明其状态依赖关系，从而在执行开始前为 Sealevel 提供安全并行化所需的信息。

借助 Sealevel，Solana 每秒可以处理多少笔交易？

根据 Solana Labs 的文档，在理想条件下，Solana 的理论处理量最高可达约 65,000 TPS。在实践中，非投票交易的真实主网吞吐量通常在 2,000–4,000 TPS 之间，具体取决于交易复杂度、账户竞争和网络状况。这仍然大大高于以太坊基础层约 15–30 TPS 的吞吐量。

在 Sealevel 上构建使用什么编程语言？

Solana 程序主要使用 Rust 编程语言编写，但也支持 C 和 C++。所有程序在部署到链上之前，都会被编译为 Solana 修改后的 eBPF (extended Berkeley Packet Filter) 字节码格式。Anchor 框架是一个广泛使用的基于 Rust 的开发工具，它抽象了账户管理并减少了 Solana 程序开发中的模板代码。

如果 Sealevel 速度这么快，为什么 Solana 还会经历网络中断？

Solana 2021 年和 2022 年的网络中断并非由 Sealevel 的并行执行逻辑故障引起。它们是由大量垃圾邮件和畸形交易淹没了网络的交易摄取层（位于 Sealevel 上游的一个独立系统）造成的。Sealevel 的 TPS 上限描述的是它可以处理多少笔有效交易；它并不能使网络免受摄取层交易洪水攻击的影响。

历史证明 (Proof of History) 与 Sealevel 之间有什么关系？

历史证明 (PoH) 通过在执行开始前建立受信任的交易顺序来赋能 Sealevel。PoH 是一种加密时钟机制，可生成每个验证者都同意的可验证时间戳序列。由于交易排序在 Sealevel 接收交易之前就已确定，Sealevel 无需暂停与验证者协调，而是可以立即将非冲突交易调度到各个并行处理线程中。

结论：Sealevel 对 Solana 的未来意味着什么

Sealevel 是 Solana 对每个区块链面临问题的最清晰回答：如何在不牺牲安全性或去中心化的情况下处理更多交易？

Sealevel 的并行执行是一种架构上真实且有案可查的能力，它将 Solana 的执行模型与所有在第 1 层进行顺序执行的区块链区分开来。其实际吞吐量意义重大，远高于以太坊的基础层，但仍低于理论最大值，并且仍受制于曾导致网络中断的摄取层限制。它作为竞争优势的持久性取决于生态系统的发展和竞争性并行执行架构的步伐，以及运行环境自身的设计。

Firedancer 验证者客户端的推出以及 Monad 等竞争性并行链的成熟，将在未来几年使竞争格局更加明朗。相关的问题不再是基础层的并行执行是否可行，而是哪种架构方法最能为大规模的各种用例提供服务。

相关阅读

• 以太坊智能合约执行：5 步交易框架
• 账户模型如何在不同区块链架构中运作
• 第 1 层区块链架构对比：Near Protocol 对比 FetchAI

来源