tp钱包app官网下载|PSE Trading：Rollup浪潮之下，VM还有故事要讲

原文作者：PSE Trading Analyst@cryptohawk

TL;DR

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.2zkEVM——我全都要：兼容EVM环境+支持全局状态根转换生成zk-proof

代表项目：Taiko、Scroll、PolygonzkEVM

由于EVM 在构建时并未考虑zk-proof 计算，因此它具有对证明电路不友好的特性，特别是在特殊的操作码、基于堆栈的架构、存储开销以及证明成本等方面。而zkEVM是一种以兼容zk-proof计算的方式执行智能合约的虚拟机，让EVM的执行过程可以通过zk-proof/validity-proof来更高效、低成本地验证。相比起OPRollup执行层只需照搬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.3zkVM——鱼和熊掌不能兼得：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.4Privacy zkVM——zk友好+原生隐私支持尝试点燃生态新火花

代表项目：Aleo、Ola、PolygonMiden

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

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

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

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

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

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

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

1.2.6FuelVM——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.7ESCVM——Ordinal/Smartweave的继承者：以太坊之上的计算层

代表项目：Ethscriptions Protocol

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

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

代表项目：Aptos、Sui

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

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

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

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.2VM后端兼容

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拥堵时对整个网络用户体验、安全性或流动性造成的破坏。

参考资料：

1.“Kakarot：探索Starknet的EVM兼容之路”，by Cynic & Starknet Astro

2.“BitVM 引热议，比特币网络可以实现图灵完备？”，by Haotian

3.https://ethereum.org/en/developers/docs/evm/

4.“Starkware技术架构与生态梳理”，by Maxlion

5.https://twitter.com/muneeb/status/1712461799327416491

6.“项目调研丨模块化高速执行层Fuel研究报告”，from Web3CN

7.https://www.fuel.network/

8.https://docs.ethscriptions.com/overview/introducing-ethscriptions

9. “Analysis of the First Critical Vulnerability of Aptos Move VM”，by Numen Cyber Labs

10.https://ethereum.org/en/developers/docs/evm/

11.“What Is SVM - The Solana Virtual Machine”，by Squads

12.“Introducing Eclipse Mainnet: The Ethereum SVM L2”，by Eclipse

13.https://john-hol.gitbook.io/bitvm/

14.https://bitvm.org/bitvm.pdf

15.“The different types of ZK-EVMs”，by Vitalik Buterin

16. “Cipholio 调研报告：漫谈 ZkVM 的方案及未来”，by YOLO SHEN，Cipholio Ventures