PSE Trading：Rollup浪潮之下，VM还有故事要讲

原文作者： PSE Trading Analyst @cryptohawk

TL;DR

1. 虚拟机是一个软件仿真的计算机系统，为程序提供执行环境。它可以模拟各种硬件设备，使程序在受控且兼容的环境中运行。

2. 以太坊虚拟机（EVM）是一种基于栈的虚拟机，用于执行以太坊智能合约；zkEVM 在 EVM 等效/兼容上做了一定的 zk-proof 生成效率优化；

   zkVM 则舍弃 EVM 等效/兼容性，将 zk 友好化的优先级提高；

   privacy zkVM 则是在 zkVM 上叠加了原生隐私特性；

   SVM、FuelVM、MoveVM 共性是通过并行执行追求性能极致，但在设计细节上有各自的特点；

   ESC VM、BitVM 分别在 ETH 和 BTC 链上进行了一定创新性的计算层实验，但目前环境下真实落地需求较低。

3. EVM 庞大的用户生态决定了任何放弃它的区块链网络短期内都难以与其抗衡，因此非 EVM 生态通过转译器/编译器/字节码解释器甚至 VM 兼容层引入 EVM 生态用户，利用非 EVM 的虚拟机特性构建新的生态叙事，或是一条必备的成功之路。

1.1 什么是 VM？

虚拟机（VM）是虚拟化计算资源的构建块，它具有与计算机几乎相同的功能，包括运行应用程序和操作系统。虚拟机的这个概念并不新颖，该技术被广泛应用于众多技术生态系统中。

在区块链的背景下，虚拟机（VM）是一种运行程序的软件，通常被称为执行区块链智能合约的运行时环境。虚拟机通常通过模拟不同的硬件设备来提供一个虚拟的计算机环境。不同的虚拟机可以模拟的硬件设备有所不同，但通常包括 CPU、内存、硬盘、网络接口等。当一笔链上交易被提交时，虚拟机负责处理该交易并更新受该交易执行影响的区块链状态（整个网络的当前全局状态）。改变网络状态的具体规则由 VM 定义。处理交易时，VM 将智能合约代码转换为节点/验证器硬件可以执行的格式。

VM 当中最为重要的内核便是 LLVM（low-level-virtual-machine），他可以看作是编译器最重要的内核。图中是原始 EVM 的运作方案，智能合约通过 LLVM IR 的中间代码进行转化，转化成 Bytecode。这些 Bytecode 会存储在区块链上，当智能合约被调用的时候，便会将 Bytecode 转化成对应的 Opcode，再由 EVM 和节点硬件来执行。

1.2 主流 VM

1.2.1 EVM——区块链 VM 共一石，EVM 独占八斗，其余共分两斗

代表项目： Optimism 、 Arbitrum

作为目前行业内开发者&用户活跃度最高的区块链生态，以太坊虚拟机 EVM 是一种基于堆栈的虚拟机，它通过模拟 CPU、内存、存储器和栈等硬件设备来提供一个虚拟的计算机环境，以此执行智能合约的指令并存储智能合约的状态和数据。EVM 的指令集包括各种操作码 Opcode，例如算术操作、逻辑操作、存储操作、跳转操作等。

EVM 模拟的内存和存储器是用于存储智能合约的状态和数据的设备。EVM 将内存和存储器视为两个不同的区域，它可以通过读取和写入内存和存储器来访问智能合约的状态和数据。

EVM 模拟的栈用于存储指令的操作数和结果。EVM 的指令集中的大多数指令都是基于堆栈的，它们从栈中读取操作数并将结果推回栈中。

EVM 的设计过程，显然是自下而上的，先敲定了模拟的硬件环境（堆栈、内存），再根据对应的环境设计了自己的一套汇编指令集（Opcode）与字节码（Bytecode）。以太坊社区为了 EVM 执行效率设计了两种编译型的高级语言——Solidity 和 Vyper。Solidity 自不必强调，Vyper 是 Vitalik 针对 Solidity 中存在的部分缺陷进行改进后设计的 EVM 高级语言，但是在社区没有获得很高的采用度，于是渐渐淡出历史舞台。

1.2.2 zkEVM——我全都要：兼容 EVM 环境+支持全局状态根转换生成 zk-proof

代表项目： Taiko 、 Scroll 、 Polygon zkEVM

由于 EVM 在构建时并未考虑 zk-proof 计算，因此它具有对证明电路不友好的特性，特别是在特殊的操作码、基于堆栈的架构、存储开销以及证明成本等方面。而 zkEVM 是一种以兼容 zk-proof 计算的方式执行智能合约的虚拟机，让 EVM 的执行过程可以通过 zk-proof/validity-proof 来更高效、低成本地验证。相比起 OP Rollup 执行层只需照搬 EVM，而构建 EVM 的 ZK 友好化是 ZK Rollup 的额外挑战。

ZK-rollups 不容易与以太坊虚拟机（EVM）兼容。 在电路中证明通用 EVM 计算比证明简单计算（如前面描述的代币传输）更困难且更耗费资源。

然而，零知识技术的进步（在新选项卡中打开）重新点燃了人们对将 EVM 计算包装在零知识证明中的兴趣。 这些努力旨在创建一个零知识 EVM (zkEVM) 实现，可以有效地验证程序执行的正确性。。

与 EVM 一样，zkEVM 在对某些输入执行计算后在状态之间转换。 不同的是，zkEVM 还创建零知识证明来验证程序执行中每一步的正确性。 有效性证明可以验证涉及虚拟机状态（内存、堆栈、存储）和计算本身的操作的正确性（即，该操作是否调用了正确的操作码并正确执行了它们？）。

想法很美好，现实很骨感，目前 Rollup 在实现 ZK 友好化和 EVM 兼容（甚至等效）上难以两全，即要么尽可能完整复制以太坊L1执行层，包括哈希、状态树、事务树、预编译等，使得以太坊L1执行客户端可以按原样使用来处理 Rollup 区块；要么舍弃 EVM 兼容性，重新创建现有的 Opcode，用于在电路中进行证明/验证，从而允许执行智能合约。

1.2.3 zkVM——鱼和熊掌不能兼得：zk-proof 效率导向的非 evm 虚拟机

代表项目： Starknet 、Zksync、RISC ZERO

zkVM 舍弃了 EVM 兼容性，以数据证明与状态更新为核心目标，在密码学和高级语言之间找到了一层公约数，来为各类应用提供一个通用的框架。

Starkware 由于在整个 ZK 领域起步较早，技术积累较为充分，拥有一定的技术领先。他是代表性的 ZK 中心主义的技术架构，围绕 ZK 构建了 Cairo VM 和 Cairo 的语言。其缺点在于 Cairo 的学习成本较高。

ZKsync 的框架兼容了 EVM 和 ZK 两方面的特点，将 Solidity 和其自主开发的电路语言 Zinc 做了一个融合，在编译器内部将两者在 IR 层面上做了统一。其优点在于编译器内核的 LLVM 可以兼容多种语言。

RISC Zero 使用 RISC-V 架构搭建模拟器允许程序员用 Rust、C/C++ 和 Go 等通用语言为 zkVM 编写程序，这意味着应用逻辑不需要局限于可以用 Solidity 表达的内容，允许写出与链无关的代码。

1.2.4 Privacy zkVM——zk 友好+原生隐私支持尝试点燃生态新火花

代表项目： Aleo 、Ola、Polygon Miden

区块链作为一个公共账本系统，所有交易都在链上进行，这意味着包含与地址或账户相关的资产信息的状态变化是公开透明的。因此，在致力于扩容解决方案之外，一些区块链团队相信下一个要实现的关键功能是隐私。

Privacy zkVM 除去 zk 友好支持扩容的特性外，由于其本身的编程语言原生支持的隐私特性，使其上层应用开发者能开出基于隐私相关的 dapp，这将带来新的应用场景和宏大叙事，比如彻底解决 MEV 问题、保障用户数据所有权等。当然，Privacy zkVM 设计上的复杂程度需要更庞大的技术团队实现落地，或许需要还等待几年时间才能实现。

1.2.5 SVM——退潮之后，仍有余烬：性能设计已达极致的执行环境

代表项目： Eclipse Mainnet、Nitro、 MakerDAO Chain (maybe)

SVM，即 Solana 虚拟机，主打高性能执行环境，智能合约主要使用 Rust 语言编写。相比单线程计算的 EVM 和 EOS WASM 执行环境，通过要求 Solana 事务描述事务在执行时将读取或写入的所有状态， SVM 实现了非重叠事务和仅读取相同状态的事务并发执行。

另外，为了实现快速验证/广播大量交易块，Solana 网络上的事务验证过程广泛使用了 CPU 设计中常见的流水线优化。以满足一系列步骤处理的输入数据流并且每个步骤都有不同的硬件负责的情况。一个典型比喻是洗衣机和烘干机，它按顺序洗涤/烘干/折叠多批衣物。 清洗必须在干燥之前进行，干燥之前必须进行折叠，但这三个操作中的每一个都由单独的单元执行。

另外，SVM 基于寄存器，并且具有比 EVM 小得多的指令集，使得 SVM 的执行更容易在 ZK 中证明。对于乐观 Rollup，基于寄存器的设计可以更轻松地设置检查点。

1.2.6 Fuel VM——buff 叠满：UTXO 框架下的并行虚拟机

代表项目：Fuel

Fuel VM 是基于 EVM、Solana、WASM、BTC & Cosmos 技术框架下的改良，跟 EVM 相比有以下特点：

最为独特的是，Fuel 不仅类似 SVM 设置访问列表（access lists），具有非重叠事务并行执行交易的能力，还采用 UTXO 模型，分代币 UTXO 和合约 UTXO，进一步提高了访问效率和计算吞吐量。

另外，Fuel VM 通过自己的领域特定语言 Sway 和支持工具链 Forc 提供了强大且流畅的开发人员体验，其开发环境保留了 Solidity 等智能合约语言的优点，同时采用 Rust 工具生态系统中引入的范例。

未来 Fuel VM 还将实现 Sway 语言升级内容，包括字节码大小方面的编译器优化、Sway 将支持更多后端（EVM 后端已经在开发中）、抽象将更加具有经济性、更多应用程序将从 Solidity/Vyper 迁移到 Sway、改进编译器级别的重入分析等。

1.2.7 ESC VM——Ordinal/Smartweave 的继承者：以太坊之上的计算层

代表项目： Ethscriptions Protocol

ESC VM，即 Ethscriptions Virtual Machine，是 Ethscriptions Protocol 提出的一种智能合约方案。Ethscriptions Protocol 本身是以太坊链上类似于 BTC Ordinal 的协议，专注于探索不同于智能合约和L2的低成本替代方案。

Ethscriptions 允许用户以极低的成本绕过智能合约存储和执行，通过提前约定的协议规则，应用于 Tx 中的 calldata 进行计算。简单来说，只要一笔成功的以太坊交易，其 calldata 符合规定有效的数据规范&唯一&“to”地址不为 0 ，即可认为合法创建了一个 Ethscription，“from”地址为创建者，“to”地址为拥有者。

设计之初，每个 Ethscription 更偏向于 NFT 的形式，比如图片 NFT，直接将图片内容通过 Base 64 格式写入 calldata 中：

最近比较火的 eths 则是参考了 brc-20 的协议规范进行创建的 Ethscription：

ESC VM 引入的智能合约，被称为"哑合约"(Dumb Contract)，作为一个逻辑合约公示，但本身不以 EVM 形式进行链上交互。另外，ESC VM 还增加了一种特殊格式"计算机命令"，使用这种格式创建的 ethscriptions 会被 ESC VM 识别与哑合约交互，比如 Deploy - 部署哑合约，Call - 调用哑合约。

该方案存在一些局限性，一是 "哑合约"的函数不是 payable 的，也就是说如果你想通过哑合约来发送 ETH，必须通过一个“桥合约”，而“桥合约”本身存在控制权滥用&资产盗用风险；二是生态存在准入门槛，不允许任意创建哑合约，其代码需要通过 Ethscriptions Protocol 治理提案进行定义。

总结下来，ESC VM 是将以太坊L1作为数据存储层，在此之上建立的一个计算层，通过将合约逻辑、合约调用、合约调用等数据内容放在以太坊 tx 的 calldata 内实现，ESC VM 的全局状态共识是 ESC VM 客户端共识，近似于 Arweave 的 SmartWeave 实现逻辑，只不过 SmartWeave 的数据存储层是 Arweave。

1.2.8 Bit VM——一个有趣的研究实验：BTC 之上的点对点执行通道

代表项目：ZeroSync

ZeroSync 创始人 Robin Linus 于 10 月 9 日发布了一篇白皮书“BitVM：Compute Anything On Bitcoin ”，准确来说它不是一个 VM，而是试图创建一个图灵完备的计算空间，其合约存储在比特币链上，但是合约的逻辑执行在链下。如果认为对方违约，己方可以在链上发起挑战，如果对方无法作出正确回应，则己方可以拿走合约中的所有资金。

其优点在于，可以赋予比特币图灵完备性而不需要对比特币协议进行任何修改，不需要新的操作码，不需要软分叉，随时可以应用。

其缺陷也很明显，一是只支持两方之间的交易（一方证明、一方验证），二是创建一个合约需要创建大量数据以及预签署大量交易，链下信息存储成本巨大。

下面是对技术逻辑的简单介绍：

（1）点输入承诺

点输入承诺允许证明者为逻辑门设置输入值 0 或 1 ，在这个承诺里存在两个哈希值 H（A 0）、H（A 1），证明者需要揭示一个哈希原像，例如 A 0 ，则将输入值设置为 0 ，若揭示 A 1 ，则将输入值设置为 1 。

（2）逻辑门承诺

有了输入值之后，通过组合比特币的与、非等操作码，可以在比特币脚本中组合任意逻辑门。

（3）二进制电路承诺

将数以亿计的逻辑门组成一个二进制电路，就可以实现图灵完备性。为了将这个二进制电路承诺到比特币网络中，需要将所有逻辑门放进一个 Taproot 地址的叶节点里。

（4）挑战-响应环节

只是将电路承诺在链上还不够，交易双方需要一种有效的方式来验证合约的计算结果是否正确。在理想情况下，合约在链下运行，双方都很合作且对结果无争议则皆大欢喜。但如果交易双方存在争议，则需要进入挑战-响应环节验证计算结果，并通过比特币脚本强制分配通道余额。

因此，BitVM 远非某种 Bitcoin Rollup 或 L2，不具有完整的虚拟机执行环境、全局状态、用于发布复杂智能合约的高级语言，也无法允许任意数量的用户轻松与这些合约进行交互。用个很通俗的例子来形象说明：BitVM 像是在人人可以用移动终端的时代里，构建了一台比房间还大的巨型计算机。

1.2.9 MoveVM——Facebook Web2基因传承下的产物

代表项目： Aptos 、 Sui

Move 是一种用于编写安全智能合约的编程语言，最初由 Facebook 开发，为 Diem 区块链提供支持，在 Diem 区块链项目中止后，以 Aptos、Sui 为代表的项目延续了 Move 语言的运用。Move 区块链最大特点是数据存储采用全局存储，由以账户地址为根的树组成，每个地址可以存储资源数据和模块代码。

Move 有两种不同类型的程序：模块和脚本。模块是定义结构类型以及对这些类型进行操作的函数的库。结构类型定义了 Move 的全局存储模式，模块函数定义了更新存储的规则。模块本身也存储在全局存储中。而脚本是可执行文件的入口点，类似于传统语言中的 main 函数，是未在全局存储中发布的临时代码片段。

总结，Move 模块类似于系统可执行文件运行时加载的动态库模块，而脚本类似于主程序。 用户可以编写自己的脚本来访问全局存储，包括调用模块，而发布模块或执行脚本通过 Move VM 进行操作。

1.3 生态发展趋势

在 EVM 网络效应如此强大的现在，EVM 用户向非 EVM 链生态迁移已成为新兴区块链项目的最大增长点，这将带来更多的 Dapp 可组合性，更大的连接性可能会在未来几年引发更快的用户增长。

1.3.1 钱包前端兼容

将 EVM 用户引入非 EVM 链历来都是一个主要障碍，但最近推出的 Metamask Snap 将打破这一障碍。 EVM 用户可以继续使用 MetaMask ，无需切换钱包。 得益于 Drift 的开源贡献构建了出色的 MetaMask Snap 实现，UX 相当于与任何 EVM 链交互。 Eclipse 主网用户将能够与 MetaMask 中的原生应用程序交互，或使用 Solana 原生钱包（如 Salmon ）。

1.3.2 VM 后端兼容

1.3.2.1 转译器/编译器

代表项目：Wrap

Warp 是一个 Solidity-Cairo 转译器，目前已经由以太坊著名基础设施团队 Nethermind 开发完成。Warp 可以把 Solidity 代码转译为 Cairo，但转译后的 Cairo 程序往往需要修改并增添 Cairo 特性（如调用内置函数，优化内存等）才能最大化执行效率。

1.3.2.2 字节码解释器/VM 兼容层

代表项目： Kakarot 、Neon EVM

Kakarot 是一个部署在 Starknet 上以 Cairo 编写的、以智能合约形式实现的 EVM 字节码解释器，它以 Cairo 智能合约的形式模拟了 EVM 的堆栈、内存、执行等方面。相比起代码转译，Kakarot 实现了 EVM 背后 Opcode 与 Pre-compile 的逐条实现，并搭建了 Account Registry、Blockhash Registry 等组件针对账户地址映射、 Block 信息获取等方面进行了额外处理，让 kakarot 拥有了更高原生的兼容性。

Neon EVM 是一种作为智能合约运行的 EVM，可以部署在任何 SVM 链上。Eclipse 主网本身采用了 SVM 作为执行环境，但通过 Neon EVM 带来了完全的 EVM 兼容性（包括 EVM 字节码支持和以太坊 JSON-RPC），并且吞吐量比单线程 EVM 更高。另外每个 Neon EVM 实例都有自己的本地费用市场，即一个区块高度上单合约账户交互相关的计算单元存在上限（区块计算单元的 1/4），因此用户只需要在特定热点合约交互或区块塞满时需要付出 priority fee。在这个意义上来说，应用程序部署自己的合约即可获得近似应用程序链的优势，以此降低因某一特定合约交互 tx 拥堵时对整个网络用户体验、安全性或流动性造成的破坏。