引言

预计于 2023 年秋冬实施的以太坊重大升级——坎昆升级（Cancun-Deneb Upgrade），核心目标是增强以太坊网络的可扩展性、安全性和可用性，同时极大程度降低二层网络的 Gas 费。因此，如若成功实施，将直接利好太坊二层扩容（L2 Rollups）生态，甚至有望带动整个 L2 赛道的爆发。

在 L2 扩容赛道中，具有极佳数据压缩性能的零知识证明扩容方案（ZK Rollups）已然被认为是以太坊的中长期核心方案。以太坊创始人 Vitalik 于 2022 年根据各家 ZK Rollups 与 EVM（Ethereum Virtual Machine）以太坊虚拟机的兼容性将其分为 4 种不同的类型，为 zkEVM 类型确立了基础标准。

这篇文章深受上述 Vitalik 的开创性分类标准的启发。经过一年的发展，该领域已取得重大进展。本文旨在以清晰的逻辑和简洁的语言，以 Vitalik 见解为基础，提供赛道更新和更详细的诠释（技术小白友好）。

什么是 EVM？

EVM（Ethereum Virtual Machine）以太坊虚拟机，是第一个图灵完备的区块链虚拟机。可以理解为是以太坊上的代码运行环境，专门用以执行部署在以太坊网络上的智能合约。通过 EVM，智能合约能够在去中心化网络上实现自动化的功能。

作为 2015 年发布的、迄今为止最久经考验的区块链虚拟机，EVM 绝对是以太坊非常重要的基础设施。甚至在评判其他区块链时，EVM 兼容与否已是一个重要的考量维度，因为 EVM 兼容的背后代表的不仅仅是智能合约执行环境、可用的以太坊工具集，更代表着巨大的网络效应和成熟复杂的生态。

不过，EVM 在设计之初，并未想象到有朝一日 ZK Rollup L2 会成为以太坊扩容的核心方案，因此 EVM 的设计并没有考虑要对零知识证明友好。这就使得构建零知识证明友好的 EVM（zkEVM）变得非常困难。

什么是 zkEVM？

正因为零知识证明（Zero Knowledge Proof）和以太坊虚拟机（EVM）兼容方面的难度之高，早期的 ZK Rollup 是不支持 EVM 的。它们普遍缺乏执行智能合约的能力（或者支持特别的虚拟机），因此受限于相对简单的特定场景：比如 代币兑换（swap）和支付（payment）。

为了解决这个问题，许多组织和研究人员专注于创建 zkEVM（Zero Knowledge Ethereum Virtual Machine），顾名思义，它就是为智能合约在 EVM 中的执行（过程和结果）生成零知识证明的。

随着 ZK Rollup 扩容方案确定性的增加和技术的进展，各家 zk 扩容项目根据在兼容性 Compatibility 和性能 Performance（生成零知识证明的时间 Proving Time）之间做衡量和取舍，开创了不同的将 EVM 执行与零知识证明计算结合的方法。

不同类型的 zkEVM：

（来源：Vitalik 博客《The different types of ZK-EVMs》）

2022 年 Vitalik 曾发文阐述「不同类型的 zkEVM」，并将市面上的 zk 扩容项目做了大致的分类和对比。

接下来让我们用浅显的语言和清晰的逻辑梳理一下 zkEVM 的类型、技术架构、以及各自的优缺点。

Type1 类 zkEVM ：完全等效于以太坊

Type2 类 zkEVM ：完全兼容 EVM 以太坊虚拟机（曾经还有 Type2.5 类，如今看来基本与 Type2 类融合了）

Type3 类 zkEVM ：几乎兼容 EVM 以太坊虚拟机

Type4 类 zkEVM ：兼容高级语言

Type1 类 zkEVM——完全等效于以太坊

架构：

· 完全等同于以太坊且无需改变以太坊系统环境的任何部分。

· 无需取代哈希（Hashes）、状态树（State Trie）、交易树（Transactions Trie）、预编译的合约（Precompiles)，和任何其他共识逻辑（In-consensus Logic）。

· 其目标是与现有的应用程序完全兼容，开发者可以将应用程序丝滑地照搬过去。

优点：

· 是所有类型 ZK Rollup 中兼容程度最高的方案。因此也是开发者最友好对方案——允许开发者将现有代码零摩擦（无需修改）地部署到 L2 上运行，因为所有的共识逻辑和系统环境完全等同于以太坊。

· 和以太坊本身探索扩容的方向高度一致，因为在 Type1 类 zkEVM 上的探索，未来是可以被无摩擦地引入到 Ethereum 本身，从而使得以太坊 L1 本身更具可扩展性。

· 它可以让 Rollup 无摩擦地照搬现有的海量以太坊基础设施（例如：以太坊执行客户端可以按原来的方式用于生成和处理 Rollup 区块、现有的区块浏览器和区块生成等工具也可以丝滑地部署到 L2）。

· 能够如同现在的以太坊一样验证以太坊区块，或者更确切来说是验证执行层端（包括所有交易执行、智能合约和账户逻辑，但目前还不包括信标链共识逻辑）。

· 正如先前提到的，完全等价以太坊的一大价值，便是可以借助以太坊现有的巨大网络效应和成熟复杂的生态。

缺点：

· 以太坊在融合零知识证明方面所面临的问题，Type1 类方案也同样面临（毕竟它是以太坊等价，而以太坊最初并非为了 zk 功能设计的）。

· 最大的问题就是生成证明所需时间久。针对这个问题，目前行业里主要的解决方案主要是：通过巧妙的工程大规模并行化证明，或通过 硬件优化来加速。

主流项目：

· 以太坊基金会 PSE（Privacy and Scaling Explorations 隐私和扩容）团队

· Taiko：今年 7 月已更新至 Alpha-4 测试网，预计 2024 年年初上线主网。Taiko 项目从最初就优先考虑去中心化和兼容性，是目前第一家且唯一一家实现去中心化提议者（proposer）的 ZK Rollup。

Type2 类 zkEVM——完全兼容 EVM 以太坊虚拟机

架构：

· 力求完全兼容 EVM 以太坊虚拟机，但不等效于以太坊。

· 与以太坊自身的运行环境相比，此类型 zkEVM 主要对区块结构、状态树的数据结构、gas fee 的定价逻辑（根据 zk 友好度重新定价）和数据存储等方面进行了一些修改，使 zk 验证证明生成得更快更便宜。

· 其目标是尽可能与绝大部分现有应用程序兼容，少数应用需进行一些改动。

优点：

· 通过对 gas fee 的重新定价（越 zk 不友好的 op code 价格越贵，反之亦然），和删除部分对 ZK 不友好的以太坊堆栈，来提供比 Type1 类更快的验证时间。

· Type2 类型可以做到与极大部分现有的以太坊应用程序兼容，因此绝大多数开发者和用户层面基本感受不到摩擦。

· 虽无法零修改地直接使用以太坊执行客户端，但通过一些调试仍可以支持现有的 EVM 调试工具和其他开发基础设施。因此仍在极大程度上可以借力于以太坊现有的繁荣生态。

缺点：

· 更改执行环境的影响范围虽小，但中长期依旧存在潜在的开发问题。比如将以太坊常用哈希（Keccak）替换为其他 zk 友好的哈希值（例如 Poseidon ），有可能会导致那些依赖于 Keccak 哈希值（涉及到历史数据）的程序应用（比如：跨链桥。大致原理：跨链桥不是实时通讯，通常是你在 A 链做了一个行为——比如已经 burn 了什么；要在 B 链做相互对应行为——要铸造什么…那本质就是你在 B 链上需要去证明 A 链的历史数据，因此会涉及到使用 Keccak 来证明历史数据）在迁移到 Type2 类型项目后出现不兼容问题（无法使用、或者跑出不同结果）。

· 对 gas fee 定价规则的更改（本意是通过重新根据对 zk 友好程度来定价 op code，来「引导」开发者减少使用 zk 不友好的 op code），对于已经在以太坊上已经进行过 gas fee 优化的合约、甚至是以太坊上的 gas fee 优化工具就会带来问题。

· 这些修改虽然和 Type1 类 zkEVM 相比，进一步提高了证明者的效率，但和 Type4 类 zkEVM 相比，证明时间依旧是一个相对缺点。

主流项目：

· Scroll：2022 年 9 月上线 Pre-Alpha 测试网，2023 年 2 月上线 Alpha 测试网，预计于 2023 年 8 月上线主网。测试网上线时属于 Type3 类 zkEVM，但正在逐步增强 EVM 兼容性并向 Type2 类 zkEVM 过渡。

· Polygon zkEVM（Polygon 团队的 ZK Rollup 方案）：2023 年 3 月上线了主网 Beta 版本。上线时属于 Type3 类 zkEVM，但目前在向 Type2 类 zkEVM 过渡。

Type3 类 zkEVM——几乎兼容 EVM 以太坊虚拟机

架构：

· Vitalik 在其 2022 年的 blog 文章中称，Type3 类 zkEVM 更像是一个过渡（通过提高兼容程度过渡为 Type2/1 类；或者通过降低兼容程度、提升 zk 友好度，过渡为 Type4 类)。

· 近乎兼容 EVM 以太坊虚拟机。通过在兼容性方面进一步牺牲，使其 zkEVM 更易于开发、zk 证明生成速度更快。

· 删除了更多在 zkEVM 中难以实现的功能（比如预编译功能）。

· 在处理合约代码（contract code）、内存（memory）或堆栈（stack）方面存在更大差异。

· 目标是与大多数现有应用程序兼容。

优点：

· 相比起 Type1 和 Type2 类 zkEVM，此类型更加 zk 友好，运算 zk 证明时间更短。

· 相比起 Type4 类 zkEVM 可以兼容的现有以太坊应用程序更多。

缺点：

· 相比起 Type1 和 Type2 类 zkEVM，此类存在更高的不兼容性和更多元素的牺牲（对以太坊开发者更加不友好）。这也是为什么 Type3 类更像是一个过渡，处于此类的方案大概率会通过提升兼容度，过渡到 type2 类 zkEVM。

· 相比起 Type4 类 zkEVM 证明速度更慢。

主流项目：

· Scroll：2022 年 9 月上线 Pre-Alpha 测试网，2023 年 2 月上线 Alpha 测试网，预计于 2023 年 8 月上线主网。一年前 Scroll 属于此类型，但目前通过提升以太坊兼容度，在向 Type2 类 zkEVM 发展。

· Polygon zkEVM（Polygon 团队的 ZK Rollup 方案）：2023 年 3 月上线了主网 Beta 版本。上线时属于 Type3 类 zkEVM，但目前在向 Type2 类 zkEVM 过渡。

Type4 类 zkEVM——兼容高级语言

架构：

· 此类实际上属于 zkVM（零知识证明虚拟机，而非零知识证明以太坊虚拟机）。

· 可以理解为编程语言层面的兼容。大致逻辑是：开发者可以继续使用他们在以太坊上习惯使用的编程语言（比如 Solidity）编写智能合约。此类型项目会用编译器将此编程语言转换为它们自定义的可读代码（比如 Starkware 使用 Warp 编译器将 Solidity 代码转换为 Cairo 字节码；zkSync 通过 LLVM 编译器将 Solidity 代码转换为其自定义的虚拟机可执行的代码 LLVM-IR）进行编译，并在它们自定义的环境中（比如 Starknet 的 Cairo VM 和 zkSync 的 Sync VM）执行。

· 目标是低成本、高效率、最大化零知识证明友好性。

优点：

· 非常快的验证时间。

· 直接从高级语言编译可以大大降低成本（时间、金钱和计算工作量）。

· 降低成为证明者的技术门槛，提高去中心化程度。

· 此类 zkEVM 可以通过使用其自定义的虚拟机原生支持帐户抽象（Account Abstraction）。因为 EVM 等效的链无法原生支持账户抽象，需要通过以太坊的 ERC-4337 来实现。

缺点：

· 大量现有的以太坊应用程序无法被复制到这类 zkVM 中，或者在复制过程中会出现问题：比如 合约在 Type 4 类 zkVM 系统中的地址可能与 EVM 中的地址不一样；Type4 类 zkEVM 不支持手写的 EVM 字节码（而目前许多应用程序都会使用手写的 EVM 字节码以节省 gas fee）；（先前提到了此类型是通过编译器达到 Solidity 代码语言层面的兼容）其编译器并不支持 Solidity 的一些功能。

· 以太坊开发者如果想将应用部署到此类项目上，需要进行更复杂的的调整。因此，和前几类 zkEVM 相比，此类项目的开发者友好度相对低，有可能影响生态的发展和技术的迭代速度。

· 极难借力于以太坊现有的复杂繁荣的生态和网络效应。

主流项目：

· zkSync Era（Matter Labs 团队构建的 ZK Rollup 方案）：2020 年 6 月上线 zkSync Lite（zkSync 1.0），主要支持简单的支付（payment）和资产兑换（swap）场景，并不支持 EVM 兼容的智能合约；2023 年 3 月上线 zkSync Era（zkSync 2.0），通过上述架构可以实现在高级语言层面的兼容。zkSync 的目标本就不是 EVM 兼容，而是提高零知识证明生成速度。

· Starknet（Starkware 团队构建的 ZK Rollup 方案）：2021 年 11 月上线主网，今年 7 月已更新至 v0.12.0 版本。其自身属于 Type4 类 zkEVM，目标本就不是 EVM 兼容。但目前它上面也有像 Kakarot 这样的项目，旨在使 Starknet 也能达到类似 Type 2.5-3 类 zkEVM 的兼容程度）

基于 Vitalik 2022 年对于不同 zkEVM 的分类，再结合各家项目的进展（截止 2023 年 8 月），我们可以用下图简单地总结：

（各家主流 ZK Rollup 项目分类）

各类 zkEVM 主流项目

(各家主流 ZK Rollup 项目对比图）

Vitalik 在其文末总结称：「就我个人而言，我希望随着时间的推移，通过 zkEVM 的改进和以太坊本身的改进相结合，使其（以太坊）对 ZK-SNARK 更加友好，最终一切都将成为 Type1 类。

在这样的未来，我们将有多个 zkEVM 实现，它们既可以用于 ZK Rollup（零知识扩容），也可以用于验证以太坊链本身。从理论上讲，以太坊没必要为 L1（第一层）使用制定单一的、标准化的 zkEVM 规范；不同的客户端可以选择使用不同的证明方式，这样我们就可以继续受益于代码层面的冗余。

但是，要实现这样的未来，还需要相当长的时间。与此同时，在以太坊（自身）扩容和基于以太坊的 ZK Rollup 的不同路径方面，我们也将会看到大量的创新。」

同时，需要强调的是，虽然市面上主流的 zkEVM 分类方式是 Vitalik 2022 年推出的分类（本文引用的），但同时也存在其他的分类标准。且无论如何分类，这些 zkEVM 类型并没有绝对的优劣之分。它们只是在兼容性与速度之间有所取舍：Type1 类 zkEVM 与以太坊的兼容性最高，但证明速度较慢（在 ZK Rollup 赛道中属于）；Type4 类 zkEVM 与以太坊的兼容性较差，但验证速度更快。

当然，zkEVM 的兼容性和速度实际上并不是开发者考量应该基于哪个 ZK Rollup 去部署应用的唯一指标。还有许多其他的因素会影响他们的选择，比如：

· L2 交易排序的去中心化程度：sequencer/proposer 是否是去中心化的，这直接影响到生态参与者的复杂程度，以及整个网络的安全性；

· 费用：以哪些代币支付费用、一条公链的代币经济模型如何；

· 生成证明的规则：对于 prover 的激励机制、加速生成证明的硬件标准；

· 自托管：是否有明确的机制来确保 L2 发生事故的时候仍然能够在 L1 恢复用户资产；

· 数据可用性：完整的数据可用性成本自然要高些，是否可接受有些 ZK Rollup 采用的较低成本的数据可用性模式。

但由于多数通用 ZK Rollup 项目目前还处于测试网阶段，以上诸多因素尚无法做横向对比。

最后，任何 zkEVM 项目所属的类型也并非是静态不变的。随着各家方案在 zkEVM 方面的探索、甚至是以太坊本身的改进，有可能所有方案最终都能达到 Type 1 类 zkEVM的效果。届时我们将有多个 zkEVM 实现——既可用于 ZK Rollups，又可用于验证以太坊链本身。

而在那之前，让我们期待看到在扩展以太坊和 ZK Rollup 不同路径上的持续创新。