从比特币的工坊到 Solana 的厨房

比特币有一门脚本语言 Script，它的能力是被刻意限制的。它不是图灵完备的，不支持循环，只允许一些基础操作：签名校验、时间锁（timelock）与多签（multisig）。这种简单性让比特币的行为可预测，也压缩了执行面——尽管网络安全还取决于协议的许多其他部分。

以太坊走了另一条路：引入 EVM（以太坊虚拟机），一个可以运行智能合约的图灵完备环境。在协议层面，状态转换遵循串行模型，尽管某些实现可以对内部任务做部分并行化。

面对可扩展性难题，Solana 给出的是一套完全不同的架构：SVM（Solana 虚拟机）与运行环境 Sealevel.

Solana（以及 SVM）的账户模型

在以太坊上，状态“属于”智能合约——数据就存放在合约内部。在 SVM 中，这两者是解耦的：

- 代码存放在程序账户中；能否升级取决于部署方式，以及被指定为 authority 的主体
- 数据（即状态）存放在由程序控制的独立账户中

因此 Sealevel 可以预先分析交易：如果交易 A 涉及账户 {X, Y}，交易 B 涉及账户 {Z, W}，两者就可以并行执行，互不冲突。

这一模型使不涉及相同账户的交易得以并行执行。这有望提升吞吐能力，但单凭它并不足以得出“在同等硬件条件下相对 EVM 有多大量化优势”的结论。就 Bitcoin Hyper 而言，迄今尚未公布任何具体的性能测试。

这对开发者意味着什么

SVM 程序以 Rust（或 C/C++）编写，编译为 eBPF 字节码。最常用的框架是 Anchor，它通过宏与约定简化了开发流程。

Bitcoin Hyper 的文档提出与 Solana 生态直接兼容，并将其称为“drop-in compatibility”。据项目方说明，现有程序只需少量改动即可运行——例如更换 RPC 端点与若干网络参数。文档还假定其与 Solana CLI、Anchor 或 IDE 插件等工具兼容。实际兼容到什么程度，仍有待独立核实。

如果真能达到这种兼容程度，熟悉 Solana 的开发者上手门槛确实会降低。但两条网络同样基于 SVM，并不等于程序、API、系统程序、工具链或运行环境行为就一定兼容。就目前而言，这更像是一个设计目标，而非经过独立验证的结果。

仍需澄清的几点

不过，有几点值得说清楚：

完全兼容尚未经过独立验证：开发网为限定开放，公开测试也很有限
手续费模型存在差异：据项目文档，Bitcoin Hyper 以 $HYPER 而非 SOL 收取手续费，这意味着部分抽象层并不相同
对 Solana 系统程序的依赖：部分 Solana 应用依赖系统程序（例如官方 Token Program），而这些程序未必以完全相同的形式提供

关于“drop-in”兼容性的说法仍有待验证。要作出判断，需要有公开的技术文档、足够的开发网访问权限，以及覆盖程序、工具链与系统依赖的可复现测试。

一个连锁餐厅的比喻

不妨把 SVM 想象成连锁餐厅的厨房。菜谱相当于代码，门店则相当于代码运行其上的网络。Bitcoin Hyper 提出要提供与 Solana 兼容的工具；但迄今为止，既没有证明所有组件完全一致，也没有证明在任何情况下出品都一样。

区别在主料上：这间厨房的“燃料”不是 SOL，而是 $HYPER。

写给比特币用户的 Solana 虚拟机