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，直接将图片内容通过 Base64 格式写入 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（A0）、H（A1），证明者需要揭示一个哈希原像，例如 A0，则将输入值设置为 0，若揭示 A1，则将输入值设置为 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 进行操作。
