EVM：以太坊的核心

EVM（Ethereum Virtual Machine, 以太坊虚拟机）是以太坊的核心，负责运行智能合约和处理交易。

虚拟机通常用于真实计算机的虚拟化，通常由“虚拟机管理程序”（如 VirtualBox）或整个操作系统实例（如 Linux 的 KVM）进行虚拟化。它们必须分别提供实际硬件、系统调用和其他内核功能的软件抽象。

EVM 在一个更有限的领域中运行：它只是一个计算引擎，因此提供了计算和存储的抽象，例如类似于 Java 虚拟机 （JVM） 规范。从高层次的角度来看，JVM 旨在提供与底层主机操作系统或硬件无关的运行时环境，从而实现跨各种系统的兼容性。同样，EVM 执行自己的字节码指令集，这些指令集通常由 Solidity 编译而成。

EVM 是一个准图灵完备的状态机，"准 "是因为所有执行步骤都会消耗有限的资源 Gas，因此任何给定的智能合约执行都会限制在有限的计算步数内，避免了执行过程可能的死循环，从而导致整个以太坊平台停止的情况。

EVM 没有调度功能，以太坊的执行模块从区块中取出一个个交易，EVM 负责依次去执行。执行的过程中会修改最新的世界状态，一笔交易执行完成后进行状态累加，到达区块完成后的最新的世界状态。下一区块的的执行时又严格依赖上一个区块执行后的世界状态，所以以太坊的交易线性执行过程无法很好的进行并行执行优化。

从这个意义上说，以太坊协议约定交易按照顺序执行。虽然顺序执行确保了交易和智能合约能够以确定性顺序执行，保障了安全性，但在面临高负载的情况下，可能会导致网络拥堵和延迟，这也是为什么以太坊有极大的性能瓶颈，需要 Layer2 Rollup 扩容的原因。

高性能 Layer1 的并行之道

大多数高性能 Layer1 都是基于以太坊不能并行处理的缺陷去设计自己的优化方案，这里只聊执行层的优化，也就是虚拟机和并行执行。

虚拟机

EVM 设计成一台256位的虚拟机，目的是为了更易于处理以太坊的哈希算法，它会明确产生256位的输出。然而，实际运行 EVM 的计算机则需要把256位的字节映射到本地架构来执行智能合约，从而使得整个系统变得非常低效和不实用。因此从虚拟机的选择上，高性能 Layer1 更多采用的是基于 WASM， eBPF 字节码或 Move 字节码的虚拟机，而非 EVM。

WASM 是一种体积小、加载快、可移植且基于沙盒安全机制的字节码格式，开发人员可以使用多种编程语言（C/C++、Rust、Go、AssemblyScript、JavaScript等）编写智能合约，然后编译成 WASM 字节码并执行。WASM 已经被许多区块链项目接纳为标准，包括 EOS，Dfinity，Polkadot（Gear），Cosmos（CosmWasm），Near等，以太坊未来也会集成 WASM，从而保证以太坊的执行层更加高效、简单，适合作为完全的去中心化计算平台。

eBPF 前身是 BPF（Berkeley Packet Filter ，伯克利包过滤器），原本是用于网络数据包的高效过滤，后经过演化形成了 eBPF ，提供更丰富的指令集，允许在不改动源码的情况下对操作系统内核进行动态干预和修改其行为。后来这项技术从内核中走出来，发展出了用户态 eBPF 运行时，其具有高性能、安全和可移植性。Solana 上执行的智能合约都会编译成 SBF（基于 eBPF） 字节码并在其区块链网络上运行。

Move是 Diem 设计的一种新的智能合约编程语言，注重灵活性、安全和可验证性。Move语言旨在解决资产和交易中的安全性问题，使得资产和交易能够被严格定义和控制。Move 的字节码验证器是一个静态分析工具，分析 Move 字节码并确定是否遵守所需的类型、内存和资源安全规则，不需要在智能合约级别实现并在运行时检查。Aptos 继承了 Diem Move，Sui 则通过自身定制版本的Sui Move来编写其智能合约。

并行执行

区块链中的并行执行意味着同时处理不相关的交易。把不相关的交易看作互不影响的事件。例如，如果两个人在不同的交易平台上交易代币，他们的交易可以同时处理。但是，如果它们在同一平台上交易，则可能需要按照特定的顺序执行交易。

实现并行执行的主要挑战是确定哪些交易是不相关的，哪些是独立的，大多数高性能 Layer1 依赖于两种方法：状态访问方法和乐观并行模型。

状态访问方法需要预先知道每个交易可以访问区块链状态的哪一部分，从而分析出哪些交易是独立的。代表方案是 Solana 和 Sui。

在 Solana 中，程序（智能合约）是无状态的，因为它们不能自行访问（读取或写入）在整个交易过程中持续存在的任何状态， 要访问或保持状态，程序需要使用帐户。Solana 的每个交易必须指定在交易执行期间将访问哪些帐户，这样交易处理运行时可以调度非重叠交易并行执行，同时保证数据一致性。

在 Sui Move 中，每个智能合约都是一个模块，由函数和结构定义组成。结构在函数中实例化，可以通过函数调用传递给其他模块。运行时存储的结构实例作为对象，Sui 中存在三种不同类型的对象，分别是拥有者对象，共享对象和不可更改对象。Sui 的并行化策略与 Solana 相似，交易也需要指定操作哪些对象。

乐观并行模型在所有交易都是独立的假设下运行，只是回顾性地验证这一假设并在必要时进行调整。代表方案是 Aptos。

Aptos 使用 Block-STM （区块软件事务内存，Block Software Transactional Memory）的方法来应用乐观并行执行。在 Block-STM 中，交易首先在区块内按照一定的顺序进行设置，然后在不同的处理线程之间进行拆分，以便同时执行。在处理这些交易时，系统会跟踪每个交易更改的内存位置。在每一轮处理之后，系统检查所有的交易结果。如果它发现某个交易触及了由早期交易更改的内存位置，则擦除其结果并再次运行。这一过程一直持续到区块中的每个交易都被处理完毕。

并行 EVM

并行 EVM（Parallel EVM）早在 2021 年就被提起，那时候指的还是支持同时处理多个交易的 EVM，旨在改进现有 EVM 性能和效率，代表方案有 Polygon 基于 Block-STM 实现的并行 EVM，BSC 和 NodeReal 合作开发的并行 EVM。

但在2023 年底，Paradigm 的 CTO Georgios Konstantopoulos 和 Dragonfly 的 Haseeb Qureshi 不约而同在展望 2024 年趋势时又提到了并行 EVM，带火了一波采用了并行执行技术的 EVM 兼容 Layer1，包括 Monand 和 Sei V2。

现如今，Solana 上的 EVM 兼容方案 Neon，以太坊 SVM（Solana 虚拟机）的 Layer2 Rollup Eclipse，以太坊 Move 虚拟机的 Layer2 Rollup Lumio，模块化执行层 Layer1 Fuel 都纷纷贴上了并行 EVM 的标签，令人眼花缭乱。

我认为合理的能定义成并行 EVM 的只有以下三类：

1. 没有采用并行执行技术的 EVM 兼容的 Layer1 的并行执行升级，例如 BSC，Polygon；
2. 采用了并行执行技术的 EVM 兼容的 Layer1，例如 Monand，Sei V2 以及 Artela；
3. 采用了并行执行技术的非 EVM 兼容的 Layer1 的 EVM 兼容方案，例如 Solana Neon。

BSC 和 Polygon 作为最主流的兼容 EVM 的 Layer1 自不必多说，这里简单介绍下 Monand，Sei V2，Artela 和 Solana Neon。

Monad 是一个采用 PoS 机制的兼容 EVM 的高性能 Layer1，旨在通过并行执行显着增强可扩展性和交易速度。Monad Labs 由 Jump Trading 前研究负责人 Keone Hon 创立。Monad 允许在区块内并行执行交易以提高效率。它使用乐观并行模型，在上一步的执行完成之前就开始执行新交易。为了应对不正确的结果，Monad 跟踪输入 / 输出并重新执行不一致的交易。静态代码解析器可以预测依赖关系，避免无效的并行性，并在不确定时恢复到简单模式。这种并行执行增加了吞吐量，同时减少了交易失败的可能性。

Sei是基于 Cosmos SDK 开发的 Layer1，专门为 DeFI 设计的公链。Sei 团队成员兼具科技和传统金融背景，曾就职于 Robinhood、Databricks、Airbnb 及高盛等公司。Sei V2 是对 Sei 网络的大范围升级，旨在成为第一个完全并行的 EVM。与 Monad 一样，Sei V2 将使用 乐观并行化。这允许区块链同时执行交易，而不需要开发人员定义任何依赖项。当发生冲突时，区块链将跟踪每个交易触及的存储部分并按顺序重新运行这些交易。这个过程将递归地持续下去，直到所有未解决的冲突都得到解决。

Artela 是一个可扩展的区块链网络，使开发人员能够构建功能丰富的去中心化应用程序（dApps），核心成员来自于蚂蚁链。Artela 推出的 EVM++ 代表着高扩展性 + 高性能的并行 EVM，分为两个阶段实现，第一阶段将围绕并行执行进行设计，在并行执行的基础上，通过弹性计算保证网络节点算力可扩展，最终实现弹性区块空间。其中并行执行会根据交易依赖冲突分析对交易进行分组以支持并行执行。

Solana Neon 是 Neon Labs 开发的解决方案，用于在 Solana 之上执行 EVM 交易。Neon EVM 实际上是 Solana 上的一个智能合约，该合约内实现了一个 EVM 解释器，编译为 SBF 字节码。Neon EVM 内部实现了一套以太坊交易模型和账户模型，用户只需要支付 EVM GAS 费用即可发送交易。Solana 网络的费用是由 Neon Proxy 支付的。Solana 强制要求交易提供账户列表，包装交易也不例外，所以 Neon Proxy 的职责包括生成这个账户列表，同时也获得了 Solana 的交易并行执行能力。

这里补充一点，类似 Solana Neon 将 EVM 作为智能合约运行以实现 EVM 兼容的方案还有 Near Aurora 和 EOS EVM+，理论上 Aptos 和 Sui 上也可以采用此方案来实现无侵入性的 EVM 兼容，但我没有找到相关资料（或许 Pontem 在做这个事情？），如果有正在进行中的项目可以联系我补充。EVM 兼容使得开发者可以轻松将他们的以太坊应用迁移到链上，而无需进行大规模修改，是一个很好建设 Aptos 和 Sui 生态的方向。

写在最后

笔者来自蚂蚁链，也是一名以太坊上的开发者（最近也在学习 Solana 开发和 Sui 开发），平时喜欢看书和写作，所以也运营了一个 Web3 的公众号（公众号名：小猪Web3），主要聚焦 Web3 前沿技术和发展历程，所以在这里还是小小打一个广告，希望能在登链认识更多志同道合的朋友交流学习。

这一篇也是我公众号最新的一篇发表，探讨了区块链并行技术，并行 EVM 叙事每隔一段时间就会抬一次头，但是目前主要都是对以 Aptos 的 Block-STM 机制 为代表的乐观执行模型的改造和模仿，没有实质性的突破，所以热度难以持续。展望未来，还会有更多的新兴的 Layer1 项目加入并行 EVM 的竞争，而对于一些旧的 Layer1 也会实现 EVM 并行升级 或 EVM 兼容的方案，两个方向殊途同归，还会诞生更多与性能提升有关的新叙事。