揭秘区块链中的速度之王——Solana

一份性能报告

CoinGecko 于 5 月 17 日发布的 《Fastest Chains》报告中显示，Solana 是大型区块链中速度最快的，最高日均真实 TPS 达到 1, 054 （已经去除了投票交易），Sui 是第二快的区块链，最高日均真实 TPS 达到 854 ，BSC 排名第三，但达到的真实 TPS 还不到 Sui 的一半。

从这份报告可以看出，性能最好的 Solana 和 Sui 都是非 EVM 兼容的区块链，更进一步， 8 个非 EVM 兼容区块链的平均真实 TPS 为 284 ， 17 个 EVM 兼容区块链和以太坊 Layer 2 的平均 TPS 仅为 74 ，非 EVM 兼容区块链的性能是 EVM 兼容区块链的 4 倍左右。

本文将会探讨 EVM 兼容区块链的性能瓶颈，并揭开 Solana 的性能之道。

EVM 兼容区块链的性能瓶颈

首先，我们泛化 EVM 区块链到一般区块链。一般区块链想要提升 TPS，一般有如下几种做法：

提升节点性能：通过堆硬件资源去提升节点性能，节点的硬件要求会影响去中心化程度，例如以太坊推荐配置，Cpu 4 核，内存 16 G，网络带宽 25 Mbps，普通用户级设备都能达到，去中心化程度较高；Solana 推荐配置相对更高 Cpu 32 核，内存 128 G，网络带宽 1 Gbps，专业级设备才能达到，去中心化程度一般；

改进底层协议：包括网络协议、密码学、存储等，改进区块链底层协议不改变区块链自身的属性，也不影响区块链的运行规则，可以直接提升区块链的性能，但底层技术关注度低，目前研究领域没有重大突破；

扩大区块：增加区块的大小可以包含更多的交易，进而提高区块链的交易吞吐量，例如比特币现金（BCH）将区块从 1 MB 扩大到 8 MB，之后扩展到 32 MB。但扩大区块的同时也会增大传播延迟引发安全威胁, 比如导致分叉可能性增大和 DDoS 攻击；

共识协议：共识协议保证了区块链各个节点对于区块链的状态更新达成一致，是区块链最重要的一重安全门，已经用于区块链的共识机制有 PoW、PoS、PBFT 等。为了满足可扩展性的需求，一般高性能公链都会改进共识协议，并结合自身特殊机制，例如 Solana 基于 PoH 的共识机制，Avalanche 基于雪崩的共识机制；

交易执行：交易执行只关心单位时间内处理的交易或计算任务数量，以太坊等区块链采用串行方式执行区块中的智能合约交易，在串行执行中，CPU 的性能瓶颈是非常明显的，严重制约了区块链的吞吐量。一般高性能公链都会采用并行执行的方式，有的还会提出更利于并行的语言模型来构建智能合约，例如 Sui Move。

对于 EVM 区块链而言，由于限定了虚拟机，即交易的执行环境，因此最大的挑战在于交易执行。EVM 主要有两个性能问题：

256 位：EVM 设计成一台 256 位的虚拟机，目的是为了更易于处理以太坊的哈希算法，它会明确产生 256 位的输出。然而，实际运行 EVM 的计算机则需要把 256 位的字节映射到本地架构来执行，一个 EVM 操作码会对应多个本地操作码，从而使得整个系统变得非常低效和不实用；

缺少标准库：Solidity 中没有标准库，必须自己用 Solidity 代码实现，虽然 OpenZeppelin 使这一情况得到一定改善，他们提供了一个 Solidity 实现的标准库（通过将代码包含在合约中或是以 delegatecall 的形式调用部署好的合约），但是 EVM 字节码的执行速度远不如预编译好的标准库。

如果站在执行优化的角度，EVM 还存在两大不足：

难以做静态分析：区块链中的并行执行意味着同时处理不相关的交易，把不相关的交易看作互不影响的事件。实现并行执行主要挑战是确定哪些交易是不相关的，哪些是独立的，目前部分高性能公链会预先对交易做静态分析，EVM 的动态跳转（dynamic jumps）机制导致代码很难被静态分析；

JIT 编译器不成熟：JIT 编译器（Just In Time Compiler）是现代虚拟机常用的优化手段，JIT 最主要的目标是把解释执行变成编译执行。在运行时，虚拟机将热点代码编译成与本地平台相关的机器码，并进行各种层次的优化。目前虽然有 EVM JIT 的项目，但还处于实验阶段，不够成熟。

因此从虚拟机的选择上，高性能公链更多采用的是基于 WASM， eBPF 字节码或 Move 字节码的虚拟机，而非 EVM。例如 Solana 使用自己独特的虚拟机 SVM 和基于 eBPF 的字节码 SBF。

Fastest Chains：Solana

Solana 因其 PoH（Proof of History ）机制以及低延迟高吞吐量而闻名，是最著名的“以太坊杀手”之一。