SolanaVM 详解：Solana 虚拟机

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

SolanaVM（也称为 Solana 虚拟机或 SVM）是 Solana 区块链的执行环境：处理和运行链上程序的软件层。 它负责计算、强制执行程序逻辑并将结果提交回网络。SolanaVM 不是一个独立的产品或代币；它是内置于 Solana 协议的核心执行引擎。

术语说明： 在区块链上下文中，SVM 表示 Solana 虚拟机。SVM 也缩写为支持向量机（Support Vector Machine），一种与区块链无关的机器学习算法。在本文中，SVM 仅指 Solana 虚拟机。

目录： SolanaVM 如何工作 | SolanaVM 与 EVM | 在 SolanaVM 上构建 | 多链采用 | SolanaVM 的采用如何发展 | 常见问题解答

区块链是一种分布式账本，它在无需中心化机构的情况下，在计算机网络上记录交易。现代区块链的功能不仅仅是记录价值转移。它们运行程序：处理借贷、交易、治理以及数千种其他链上功能的软件。要运行程序，区块链需要一个执行环境，这是一个接收指令、根据定义规则处理指令并将结果写上链的可控软件层。每个智能合约区块链都需要一个执行环境。在 Solana 上，这个环境就是 SolanaVM。

Solana 是一个 Layer 1 (L1) 区块链，一个拥有自己共识机制和名为 SOL 的原生代币的基础层网络。SolanaVM 与 Solana 不同。它们的关系类似于汽车发动机和汽车本身：SolanaVM 是发动机；Solana 是完整的汽车。SOL 是支付执行费用的燃料。这三个是独立的实体，混淆它们会在评估 Solana 的架构时造成真正的困惑。

SolanaVM 的构建围绕着一种吞吐量优先的设计理念，这直接源于 Solana 的联合创始人兼前高通工程师 Anatoly Yakovenko，他认为交易排序开销是现有区块链设计中的主要瓶颈。

SolanaVM 如何工作：架构和执行模型

SolanaVM 通过一个五阶段的流水线在网络的分布式验证者基础设施上执行 Solana 程序，并行处理非冲突交易，而不是串行处理。

在 SolanaVM 上，智能合约被称为Solana 程序（SolanaVM 对智能合约的术语）。这是官方 Solana 基金会的术语，并非风格上的变体。命名差异反映了真实的架构区别。EVM 智能合约将程序逻辑和状态数据存储在同一个合约对象内。Solana 程序是无状态的：程序代码存在于一个链上账户中，它操作的数据存在于单独的数据账户中。这种分离是实现大规模并行执行的关键。

SolanaVM 执行流水线遵循五个阶段：

1. 开发者用 Rust 编写 Solana 程序
2. Rust 代码编译成 sBPF 字节码
3. 编译后的字节码被部署为链上程序账户
4. 用户提交一个包含指令数据的交易来调用程序
5. Solana 验证者（运行 SolanaVM 的网络节点）执行 sBPF 字节码，消耗计算单元，并将结果提交到账本

Solana 验证者在专用硬件上运行 SolanaVM，并通过两个独立的机制达成共识：用于交易排序的“历史证明”（PoH），以及用于验证结果的“权益证明”共识机制——Tower BFT。Solana 的验证者网络由 Tower BFT 保护。PoH 对交易进行排序，而 Tower BFT 则决定其有效性的共识。这两个角色是独立的，绝不能混淆。

历史证明（Proof of History）是由 Anatoly Yakovenko 发明的加密排序机制，在 Solana 历史证明白皮书. 中有详细介绍。PoH 类似于一个同步时钟，让所有验证者无需相互询问即可就每笔交易的发生时间达成一致，消除了主要的协调瓶颈。通过加密方式预先排序交易，PoH 为 SolanaVM 提供了同时处理多笔交易所需的时间基础。PoH 不是共识机制；它是一个时间戳和排序协议，为 Tower BFT 共识提供输入。

什么是 sBPF？SolanaVM 的字节码格式

sBPF（Solana Berkeley Packet Filter）是 SolanaVM 执行的字节码格式：Solana 对 Berkeley Packet Filter 指令集进行的修改版本，专门为区块链程序执行进行了适配。

当开发者用 Rust 编写 Solana 程序时，该 Rust 代码不会直接在链上运行。Rust 编译器将其翻译成 sBPF 字节码，这是一种紧凑的低级指令格式，SolanaVM 的执行引擎可以高效地处理。验证者直接执行 sBPF 字节码；计算就在这里实际发生在网络上。

sBPF 不同于原始的 BPF（Berkeley Packet Filter），后者是操作系统内核中用于数据包过滤的网络技术。Solana 的 sBPF 是一个修改过的分叉版本，适配了区块链虚拟机执行的限制。在指代 Solana 的字节码格式时，请始终使用“sBPF”，而不是单独使用“BPF”。

对于来自 EVM 生态系统的开发者来说，sBPF 在功能上相当于 EVM 的操作码（opcodes）：它是虚拟机解释和运行的低级指令集。

并行执行：SolanaVM 如何同时处理多笔交易

SolanaVM 同时处理非冲突交易，而不是一次处理一笔，这与 EVM 的顺序执行模型有着根本区别。

想象一下银行，每个柜员同时服务不同的客户，而不是只有一个窗口提供排队服务。SolanaVM 的并行执行对于不触及同一账户的交易来说，工作方式是类似的。

该机制是 Sealevel，SolanaVM 的并行执行引擎。在执行任何交易之前，Sealevel 会分析每笔交易的账户依赖关系：这笔交易从哪些账户读取，向哪些账户写入？如果两笔交易访问的账户完全不同，它们就没有冲突，可以在多个 CPU 核心上并行运行。共享账户的交易会针对那些特定账户进行顺序排队，而所有不相关的交易则继续并行处理。

其结果是吞吐量上限随验证者硬件性能提升而扩展，而非受限于固定的串行瓶颈。在理想条件下，Solana 的理论最大吞吐量可达约 65,000 TPS（每秒交易处理量），而以太坊主网约为 15 至 30 TPS（来源：Solana 基金会，solana.com；ethereum.org，截至 2025 年第一季度）。在负载情况下，两个网络的实际吞吐量都会较低，而基于以太坊构建的 EVM 兼容 Layer 2 (L2) 链所实现的吞吐量远高于以太坊主网本身。

SolanaVM 对比 EVM：两种执行环境的比较

SolanaVM 和以太坊虚拟机 (EVM) 代表了区块链程序执行的两种截然不同的架构方案，各自的权衡取舍适用于不同的使用场景。第三种虚拟机标准 WebAssembly (WASM) 则被 NEAR Protocol 和 Polkadot 等链采用，代表了与 EVM 和 SolanaVM 均不同的架构选择。

以太坊虚拟机 (EVM)：既定标准

以太坊虚拟机 (EVM) 最初由 Vitalik Buterin 和以太坊团队设计，是跨以太坊及所有 EVM 兼容链共享的执行环境。完整的 以太坊虚拟机文档可在 ethereum.org 查看.

EVM 串行处理交易：严格按顺序逐一处理。区块中的每笔交易都在前一笔交易完成后才执行。程序使用 Solidity 或 Vyper 编写，并编译为 EVM 操作码。这种串行模型建立了一个与区块时间而非硬件能力挂钩的吞吐量上限，但也简化了状态推理。在执行的任何时间点，整个状态都是确定且完全一致的。

EVM 最持久的竞争优势在于其网络效应。包括 Polygon、Arbitrum、Avalanche C-Chain 和 BNB Chain 在内的 100 多条 EVM 兼容链都共享相同的执行标准。学习了 Solidity 的开发者无需重写代码即可在任何 EVM 兼容链上进行部署。这种便携性经过十年的积累，创建了一个工具生态系统（Hardhat、Foundry、Remix、OpenZeppelin）和开发者社区，其规模是 SolanaVM 尚未企及的。

SolanaVM 对比 EVM：侧重对比

SolanaVM 和 EVM 最根本的区别在于处理交易的方式：SolanaVM 并行运行非冲突交易，而 EVM 则串行处理交易。下表从六个核心维度对比了这些架构差异。

TPS 数据代表理想条件下的理论最大值，在实际网络负载下会有显著变化。EVM 兼容的 L2 链实现的吞吐量远高于以太坊主网。最后更新时间：2025 年第一季度。来源：Solana 基金会 (solana.com)，ethereum.org。

EVM 在 100 多条链上的网络效应是其持久的竞争优势。SolanaVM 的并行执行架构为特定的高频用例提供了明显的吞吐量优势，但原生速度只是开发或投资决策的其中一个维度。

Solana 程序对比以太坊智能合约：有何区别？

Solana 程序（Solana 基金会对 SolanaVM 上的智能合约的正式称呼）与 EVM 智能合约的区别不仅在于名称，还在于结构架构。

Solana 程序是无状态的。程序逻辑存储在某个链上账户中；程序操作的数据则存储在程序读取和写入的独立数据账户中。相比之下，EVM 智能合约将逻辑和状态打包在单个合约对象中。合约拥有自己的存储空间。Solana 模型中的这种分离使得 Sealevel 能够在执行前确定账户依赖关系：任何交易涉及的账户都会预先明确声明，从而为执行引擎提供安全调度并行执行所需的信息。

SolanaVM 与 EVM 不兼容。来源援引 Neon EVM 作为与 Solana 相关的独立第三方 EVM 环境。它并不会使 SVM 本身变得兼容，且其当前的架构、部署状态、工具支持和局限性必须进行独立评估。

在 SolanaVM 上构建：语言、工具与入门攻略

Solana 程序主要使用 Rust 编写，Rust 是一种系统编程语言，因其内存安全保证和性能特性而被选中，并在部署到 SolanaVM 之前被编译为 sBPF 字节码。

Rust 通过所有权模型在编译时强制执行内存安全，消除了整类错误：空指针解引用、数据竞争和缓冲区溢出，且无需依赖垃圾回收器。这些属性符合链上执行的安全性及性能要求，因为链上程序在部署后无法修补，且执行成本在指令层面都至关重要。SolanaVM 在技术上也支持 C 和 C++，但 Rust 是 Solana 开发者生态系统中的事实标准。

用于 Solana 开发的 Anchor 框架 抽象了大部分底层 Rust 和 sBPF 的复杂性，其功能类似于 EVM 生态系统中的 Hardhat 或 Foundry。Anchor 提供结构化的账户验证、错误处理和程序接口定义，显著减少了编写正确 Solana 程序所需的样板代码。请注意，用于 Solana 的 Anchor 框架与 Anchor Protocol（2022 年崩盘的 Terra/Luna DeFi 借贷协议）无关。

SolanaVM 的并行执行架构使其特别适用于需要高吞吐量的 DeFi 应用：链上订单簿、强制平仓引擎以及对低延迟和高交易密度有要求的收益优化程序。主要的 SolanaVM 原生 DeFi 协议包括 Raydium（自动做市商）、Jupiter（DEX 聚合器）和 Kamino（收益优化）。SOL 可在主要的加密货币交易所购买，并在与 SolanaVM 程序交互时用于支付计算单元费用。

有关完整的开发者快速入门，请访问 官方 Solana 开发者文档。

计算单元：SolanaVM 如何计量程序执行

计算单元 (CU) 是 SolanaVM 中对应以太坊 Gas 的概念：它是衡量 Solana 程序执行所消耗的计算资源的单位。

每笔 SolanaVM 交易都在计算单元预算内运行。根据 Solana 基金会文档（来源：docs.solana.com，截至 2025 年第一季度），当前每笔交易的最大限制为 140 万 CU。执行中途超过 CU 预算的程序将被中止，交易失败。开发者为每笔交易请求特定的 CU 限制；请求过多会浪费潜在的储蓄费用，而请求过少则会导致可避免的失败。

Solana 上的交易费用以 SOL 支付，并部分由 CU 消耗量决定。基础费用适用于所有交易；可选的优先费用市场允许用户在需求高峰期支付更多费用，以在 slot 调度中提前。计算单元 (Compute units) 的功能类似于以太坊的 Gas，因为两者都衡量计算成本，但 Solana 的 CU 系统使用固定价格的基础费用，而不是完全动态的拍卖，并在此基础上叠加优先费用。

您能否将 EVM 合约移植到 SolanaVM？

如果不进行重写，直接将 EVM 合约移植到 SolanaVM 是不可能的。Solana 程序需要 Rust 和 sBPF 字节码，而不是 Solidity 和 EVM 操作码。两者的执行模型在架构上差异很大，不存在逐行转换的可能。

EVM 合约和 Solana 程序使用不同的状态和账户模型，因此原生迁移通常需要架构上的更改。独立的 EVM 环境可能会保留部分 Solidity 工作流，而原生 SVM 开发则使用不同的工具链。请根据兼容性、性能、审计、操作依赖项和当前支持情况进行比较，而不是将任何一种路径视为默认选择。

SolanaVM 的超越：多链采用与 SVM 生态系统

SolanaVM 的运行范围已超出 Solana 主网，Layer 2 项目正将其作为独立的执行环境部署在其他底层区块链上。

虽然 SolanaVM 最初是作为 Layer 1 执行环境设计的，但它被 Layer 2 项目所采用标志着重大的架构演进。这种便携性论点，即 SolanaVM 可以像 EVM 那样作为跨多条链的共享执行标准发挥作用，正在从理论走向生产。

下表按类型和状态列出了当前的 SVM 链：

最近更新：2025 年第一季度。在重新发布前请核实当前项目状态。来源：eclipse.xyz、Solana 基金会文档。其他 SVM Rollup 项目正在开发中；随着生态系统的演变，此表需要定期更新。

在所有 SVM 链中，DeFi 应用（尤其是 DEX、借贷协议和收益优化程序）代表了 SolanaVM 并行执行能力的主要用例。Neon EVM 代表了 SVM 生态系统增长的另一个维度，使 EVM 兼容的合约能够在 Solana 的 SolanaVM 上运行，并桥接了两个最大的智能合约生态系统。

Eclipse：作为以太坊 Layer 2 的 SolanaVM

该来源引用 Eclipse 作为在 Solana 之外使用 SVM 技术的示例。其当前的架构、结算模型、数据可用性、安全假设和实测性能应通过有日期的主要来源进行验证，而不是简单地总结为继承了全面的安全保证。

该架构分离了大多数区块链捆绑在一起的两个功能。SolanaVM 处理执行：它接收交易，使用 Sealevel 并行处理 Solana 程序，并高速生成状态输出。以太坊处理结算：Eclipse 将交易数据传回以太坊，继承其安全模型和终局性。Eclipse 将执行速度从底层链的安全模型中解耦，分别独立访问两者。

这种架构证明了 SolanaVM 可以作为 Solana 网络之外的便携式执行标准运行。它遵循了允许 EVM 扩展到数十条链的相同架构便携性。Eclipse 的部署是目前 SVM 便携性论点最清晰的证据。

有关完整的架构细节，请访问 Eclipse 官方文档 eclipse.xyz。

SVM Rollup：SolanaVM 采用的下一个前沿

SVM Rollup（一种由 SolanaVM 提供动力的 Layer 2 解决方案）是一种使用 SolanaVM 作为其执行环境，同时将交易数据发布到底层链进行结算和数据可用性的区块链。

Rollup 架构将 SolanaVM 的执行速度与任何单一链的安全模型解耦。SVM Rollup 不需要新的独立链，而是可以插入现有的底层（以太坊、Celestia 或 Solana 本身）以获得数据可用性和终局性。SolanaVM 的并行执行性能在更广泛的区块链生态系统中变得触手可及，而不仅仅局限于 Solana 自己的网络。

Eclipse 的主网部署代表了目前生产中最先进的 SVM Rollup 架构。其他 SVM Rollup 项目正在开发中，尽管它们的状态经常变化。如果 SVM Rollup 的采用继续保持目前的轨迹，SolanaVM 的多链存在感可能会接近 EVM 采用的广度，尽管开发者生态系统规模仍然是关键的差异化变量。

本节涵盖了前瞻性的生态系统发展。项目状态需要定期验证。最近更新：2025 年第一季度。

SolanaVM 在 Solana 之外的采用如何发展

SolanaVM 正显示出多链采用的早期迹象，Eclipse 等项目将其部署为 Solana 网络之外的执行层。SolanaVM 是否能实现类似 EVM 的多链标准化，取决于开发者的采用率、工具的成熟度以及 SVM Rollup 项目的成功。

SolanaVM 影响力不断扩大的证据是具体的。Eclipse 在以太坊上运行着一个使用 SolanaVM 作为执行环境的实时主网。SVM Rollup 项目正从宣布阶段走向活跃阶段。Anchor 框架已经成熟到使 SolanaVM 开发比两年前更容易实现的程度。Solana 上的 DeFi 协议（Raydium、Jupiter、Kamino）证明了 SolanaVM 的并行执行架构产生了真实的经济活动，而不仅仅是理论上的吞吐量数字。

障碍同样也是具体的。EVM 在开发者采用、工具成熟度和多链部署方面拥有十年的领先优势。今天，掌握 Solidity 的开发者可以在 100 多条链上进行部署；而掌握 Rust 和 Anchor 框架的开发者可以在 Solana 主网和 Eclipse 上部署，更多的 SVM 链也在逐渐增加。EVM 的网络效应代表了真正的竞争护城河，而不是 SolanaVM 会自动取代的遗留负担。SolanaVM 的并行执行架构为高吞吐量的 DeFi 用例提供了可衡量的优势，但在一个维度上的技术优越性并不会自动转化为生态系统的广泛采用。

SolanaVM 在 Solana 原生网络上日益增长的采用增加了对 SOL 作为计算单元支付费用代币的需求。在其他网络上结算的 SVM 链（例如在以太坊上结算的 Eclipse）可能会使用不同的费用结构；SOL 的需求关系因链架构而异。

此内容仅供参考，不构成财务或投资建议。SolanaVM 和 SOL（Solana 的原生加密货币）具有区块链技术和数字资产固有的风险。读者在做出任何投资决定前应进行独立研究。

SolanaVM 在 Solana 主网、Eclipse 和新兴 SVM Rollup 中的采用轨迹，将同样取决于开发者社区的增长和架构优势。SolanaVM 的架构优势已确立。生态系统的案例仍在构建中。

在 Bybit 上探索 SOL

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

常见问题解答：SolanaVM 解析

什么是 SolanaVM？

SolanaVM（也称为 Solana 虚拟机或 SVM）是 Solana 区块链的执行环境：处理 Solana 程序并将其结果提交到网络的软件层。SolanaVM 不是一个单独的代币或产品；它是 Solana 的核心架构组件。在区块链领域，SVM 指的是 Solana 虚拟机，而不是支持向量机。

SolanaVM 与 EVM 有何不同？

SolanaVM 与以太坊虚拟机 (EVM) 在三个主要的架构维度上有所不同。第一，SolanaVM 使用 Sealevel 引擎并行处理不冲突的交易；而 EVM 按顺序处理交易。第二，SolanaVM 执行从 Rust 编译的 sBPF 字节码；EVM 执行从 Solidity 或 Vyper 编译的操作码。第三，SolanaVM 以计算单位 (CU) 衡量执行成本；EVM 使用 Gas。EVM 拥有一个规模大得多的多链生态系统。

SolanaVM 使用什么编程语言？

Solana 程序主要用 Rust 编写，这是一种系统编程语言，因其内存安全保证和性能而备受推崇。Rust 代码在链上部署前会编译成 sBPF 字节码。Solana 的 Anchor Framework 通过处理样板化的账户验证和程序结构来简化 Rust 开发。C 和 C++ 在技术上也受支持，但 Rust 是事实上的标准。

SolanaVM 比 EVM 快吗？

在理想条件下，SolanaVM 的理论最大吞吐量可达约 65,000 TPS；而以太坊主网按顺序处理约 15 到 30 TPS（来源：Solana 基金会，ethereum.org，截至 2025 年第一季度）。SolanaVM 的并行执行使其在不冲突的交易工作负载方面具有可衡量的速度优势。像 Arbitrum 和 Optimism 这样的 EVM 兼容 L2 链在实践中实现了显著缩小这一差距的吞吐量。

Solana 中的 sBPF 是什么？

sBPF（Solana Berkeley Packet Filter）是 SolanaVM 执行的字节码格式：它是 Berkeley Packet Filter 指令集的 Solana 修改版本，已适应区块链程序的执行。当开发人员用 Rust 编写 Solana 程序时，Rust 编译器会在部署前将其翻译成 sBPF 字节码。然后验证者直接执行该 sBPF 字节码。sBPF 与操作系统内核中使用的原始 BPF 网络技术不同。

可以在 SolanaVM 上运行 EVM 合约吗？

EVM 字节码无法在 SolanaVM 中原生运行，因为它们的执行模型和账户模型不同。独立的第三方 EVM 环境可能支持 Solidity 工作流的部分功能，而原生的 SVM 实现则需要兼容的语言和架构。在选择路径之前，请验证当前的工具支持并对实际工作负载进行基准测试。

什么是 Eclipse 区块链及其如何使用 SolanaVM？

Eclipse 是一个以太坊 Layer 2 区块链，它使用 SolanaVM 作为其执行环境，同时在以太坊上进行交易结算。Eclipse 使用 SolanaVM 的 Sealevel 并行执行引擎处理交易，从而达到 Solana 级别的吞吐量。结算和数据可用性由以太坊处理，继承其安全模型。Eclipse 表明 SolanaVM 可以作为 Solana 网络之外的可移植执行标准。

什么是 Solana 程序？

Solana 程序是 SolanaVM 对智能合约的官方称呼：一种由 SolanaVM 在被交易调用时处理的自执行链上代码。与存储逻辑和状态在同一合约对象中的 EVM 智能合约不同，Solana 程序是无状态的。程序逻辑存在于程序账户中；它操作的数据存在于单独的数据账户中。这种无状态设计使得 SolanaVM 的并行执行引擎能够安全地同时运行多个程序。

Solana 中的计算单位是什么？

计算单位 (CU) 是 SolanaVM 中相当于以太坊 Gas 的概念：衡量执行 Solana 程序所消耗计算资源的单位。每个 SolanaVM 交易都在一个 CU 预算内运行，该预算上限为每笔交易 140 万 CU（来源：Solana 基金会文档，docs.solana.com，截至 2025 年第一季度）。超出 CU 预算的程序将被中止。Solana 上的交易费用以 SOL 支付，部分由 CU 消耗决定，并设有优先级费用市场以应对高需求时期。

SolanaVM 会成为新的区块链标准吗？

来源指出，早期 SVM 已被 Solana 以外的其他项目采用，包括 Eclipse 和其他已公布的项目。必须验证当前的部署和活动。SVM 技术是否会广泛标准化仍不确定，不应被视为预测。

相关阅读

• Solana Architecture
• Is Solana EVM Compatible?
• Solana Token Standards