近期有几个 ZK-Rollup 项目相继宣布支持 ZK-EVM 的主网或测试网的上线计划，而在2022年8月初，以太坊创始人 Vitalik 发表了一篇博文对比了不同类型的 ZK-EVM。ZK-EVM，这个ZK-Rollup 的圣杯，又一次引起市场的关注，它在未来可能会是以太坊扩容的利器。

以太坊扩容是一个老生常谈的话题，也是众多用户期望的事情。不少人可能会有一个认识误区，即计划在9月底升级的以太坊合并会把共识机制从 PoW 转为 PoS 将能够改善以太坊性能。但实际上，合并没有改变区块大小，出块时间也仅仅是从平均13秒变为12秒，所以届时以太坊性能提升预计有限。因而，以太坊短期内扩容的希望还在二层网络（Rollup）。在 Rollup 两种主流方向 Optimisic Rollup 和 ZK-Rollup 里，相当一部分人更期待后者，因为 ZK-Rollup不仅同样可以通过将打包多笔链下交易来降低网络手续费，更重要的是它能够通过零知识证明计算出一个有效性证明并提交到以太坊网络来继承以太坊的安全性，无需像 Optimistic Rollup 那样设置一个挑战期。

只能支付的 ZK-Rollup

但ZK-Rollup早期为人诟病的地方是不能兼容 EVM，不能支持智能合约功能，例如 Gitcoin 捐赠主要支付途径的 zkSync 1.0 仅能支持转账等基本功能。目前市场上的 ZK 应用如 dYdX，是专门定制的应用无法通用，开发难度大，改动麻烦。同时，由于不同 ZK 应用有各种专用电路，无法相互调用，可组合性差。因此市场急需能够支持以太坊智能合约的ZK-Rollup，而其中关键门槛就是能够支持零知识证明的虚拟机。幸运的是，近期有几个 ZK-Rollup 项目相继宣布支持 ZK-EVM 的主网或测试网的上线计划。本文将介绍 EVM、ZK-EVM 以及主要的 ZK-EVM 项目和它们的区别。

什么是 EVM?

EVM 指的是以太坊虚拟机（Ethereum Virtual Machine），它相当于执行引擎，是以太坊智能合约的运行时环境（Runtime）。开发者通过高级编程语言如 Solidity 编写业务逻辑，然后编译器把代码编译成低级编程语言字节码（bytecode)，EVM 再把字节码解析成机器可读指令即操作码（opcode）并执行相应指令修改系统状态。EVM 是基于堆栈结构的虚拟机（stack machine），在执行opcode的时候需要和stack、memory、storage交互。

对于以太坊、各种扩容协议和竞争公链而言，EVM 几乎成为以太坊生态的代名词，代表以太坊生态的开发者、应用和工具。如果某个公链不支持 EVM，那么它需要重新培育自己生态内的开发者，而开发者也需要重新开发应用和工具。有人曾对比 Optimisic Rollup 的两大巨头 Optimism 和 Arbitrum，指出其中一个协议仅 99% 兼容 EVM 而另一个协议可以 100% 兼容 EVM，就算 1% 的区别也会产生以太坊生态竞争的劣势。由此可见，兼容 EVM 直接关乎对以太坊生态的兼容性，只有兼容 EVM，开发者才可以无缝迁移现有的以太坊合约，以太坊生态的各种工具才能顺利接入。

即将到来的 ZK-EVM

尽管 EVM 在以太坊生态发挥着关键作用，但 ZK-EVM 的开发相当复杂。ZK-EVM 是指能够支持生成零知识证明并兼容 EVM，以太坊智能合约可以无需修改而直接部署运行，同时程序的运行可以通过零知识证明其计算的有效性。EVM 在设计之初并没有考虑到 ZK，这也因为当时 ZK 尚未取到突破性进展还没有被主流采用，直到 2016 年才第一次有零知识证明算法 zk-SNARK 被 Zcash 采用。EVM 里有一些操作对零知识不友好，即很难生成零知识证明，或生成证明的效率低，或生成的证明太大。

很多人知道 ZK 开发门槛很高，不仅涉及密码学、数学也涉及到硬件知识，而 ZK-EVM 开发更属于难上加难的级别，它既要能够兼容 EVM，又要对零知识友好。幸运的是，在过去的几年时间里，ZK 领域取得了越来越多的重大突破。ZK-EVM 赛道几位选手包括 Starkware、zkSync 2.0、Polygon 和 Scroll 等都在加紧研发 ZK-EVM，其中后面三个项目在近期陆续宣布了测试网上线的消息。

7 月 19 日，Scroll 发布了 pre-alpha 测试网，用户可以体验一些演示程序例如 Uniswap fork 版本以及 Metamask 钱包。7 月 20 日，Matter Labs 宣布兼容 EVM 的 zkSync 2.0 将在 11 月左右上线主网并公布路线图。同样在 7 月 20 日，Polygon 宣布其 ZK-EVM 测试网也即将上线。

各家 ZK-EVM 对比

由于 ZK-EVM 并没有统一的设计规格或者标准，所以每个项目方基于不同角度在兼容 EVM 和支持 ZK 之间权衡设计出各自方案，目前基本分为两种思路：

1. 编程语言层面支持，自定义 EVM 操作码，把 ZK 友好的操作抽出来重新设计新的、架构不同的虚拟机，通过编译器将 Soilidity 编译成新的虚拟机操作码

2. 字节码层面支持，支持原生 EVM 操作码

第一种思路的项目包括有 Starkware 的 StarkNet 和 zkSync 2.0。Starkware 的 ZK-Rollup 通用解决方案 StarkNet 可以运行任意的以太坊 dApp。开发者可以通过编译器将 Solidity 编译成 StarkNet 的智能合约语言 Cairo，再部署到其 ZK 友好的 VM。类似 Starkware，zkSync 2.0 通过开发编译器前端 Yul 和 Zinc 来实现 ZK-EVM 功能。Yul 是一种中间 Solidity 表示，可以编译为不同后端的字节码。Zinc 是用于智能合约和通用零知识证明电路的基于 Rust 的语言。它们都是基于开源框架 LLVM，能够实现最高效的 ZK-EVM 字节码。

这一类项目在语言层面兼容 Solidity，开发者可以把用 Solidity 写的智能合约通过转移的方式来部署运行，但是底层 VM 架构并非是 EVM，严格来说是一种 zkVM。而且由于底层的虚拟机指令集的不同，有一些现有开发工具不能直接使用，但是对 ZK 友好，能更有效生成零知识证明。

而第二种思路的项目包括有 Polygon ZK-EVM 和 Scroll。Polygon ZK-EVM 叫做 uVM，zkCircuit 优化的 VM 具有定制的操作码以优化 EVM 操作，EVM 字节码先被编译成“微操作码”（Micro opcode）再在 uVM 执行。Polygon ZK-EVM 计划支持全部 EVM 操作码，是一个与以太坊完全兼容的零知识 (ZK) 扩展解决方案：所有现有的智能合约、开发人员工具和钱包都可以无缝运行。Scroll 也和 Polygon 的类似，会为每个字节码设计电路，包括验证 EVM 执行的每一个步骤，包括加载 bytecode，执行 opcode，更新 storage 等。

而在 Vitalik 的博文里，他将 ZK-EVM 分为几种类型。其中，类型 1 是直接在以太坊上面直接开发 ZK-EVM，这个开发过于复杂而且目前效率太低，以太坊基金正在研究中。类型 2、类型 2.5 和类型 3 是 EVM 等效的 ZK-EVM，Scroll 和 Polygon Hermez 目前处于类型 3 这个阶段，朝着类型 2.5 乃至类型 2 努力。类型 4 是高级语言兼容的 ZK-EVM，包括 Starkware 和 zkSync。这些类型并无好坏之分，而且 ZK-EVM 也没有统一的标准。正如 Vitalik 所说，“从理论上讲，以太坊不需要为 L1 使用单一的 ZK-EVM 实现进行标准化；不同的客户可以使用不同的证明，因此我们继续从代码冗余中受益。”（Theoretically, there is no need for Ethereum to standardize on a single ZK-EVM implementation for L1 use; different clients could use different proofs, so we continue to benefit from code redundancy.）

总结

各家的 ZK-EVM 方案设计并无绝对的好坏，因为目前大家代码尚未开源也无法比较效率。以太坊作为最大的智能合约平台，拥有强大的生态系统和网络效应，ZK-EVM 是 ZK-Rollup 的圣杯，只有通过 ZK-EVM，ZK-Rollup 才能依托以太坊的生态和网络效应，在继承以太坊安全性、降低手续费的同时更容易获得充满活力的开发者生态、经过时间考验的代码库和工具。2021 年初，Vitalik 曾在其博客称，短期内，Optimisic Rollup 可能会在通用 EVM 计算方面胜出，而 ZK-Rollup 可能会在简单的支付、交易和其他特定于应用程序的用例中胜出，但在随着 ZK-SNARK 技术的改进，中长期 ZK-Rollup 将在所有用例中胜出。随着各个 ZK-EVM 项目的测试网/主网陆续上线，相信在不久的将来，以太坊二层扩容将会精彩纷呈。