Bupt3分享18-ZK-EVMs 对比拆解

Dora Dōjo
1

Dora Dōjo Workshop
资助金额：100 USDT
分享者：北邮在读硕士 Syshems
本项目由Dora Dōjo资助，文章转载请联系
Telegram: @DoraDojo0
WeChat: @DoraDojo0

所有 zk-Rollups 项目都使用类似 ZK-SNARK 技术对以太坊进行扩容，目的要么是让以太坊链本身的验证变简单，要么是在提供更好的拓展性的同时实现更好的 EVM 兼容。不同项目模型之间基于不同的 trade-off 考量，所设计的 ZK-EVM 模型也不同。本课题旨在探究不同 ZK-EVM 的架构设计倾向和考量，以及不同方案实现获得的好处和成本。

一、五种类型的 ZK-EVMs

正因为零知识证明和以太坊虚拟机（EVM）兼容方面的难度之高，早期的 ZK Rollup 是不支持 EVM 的。它们普遍缺乏执行智能合约的能力（或者支持特别的虚拟机），因此受限于相对简单的特定场景，比如 swap 和 payment 。为了解决这个问题，许多组织和研究人员专注于创建 zkEVM（Zero Knowledge Ethereum Virtual Machine），顾名思义，它就是为智能合约在 EVM 中的执行（过程和结果）生成零知识证明的。

随着 ZK Rollup 扩容方案确定性的增加和技术的进展，各家 zk 扩容项目根据在兼容性 Compatibility 和性能 Performance（生成零知识证明的时间 Proving Time）之间做衡量和取舍，开创了不同的将 EVM 执行与零知识证明计算结合的方法。过去一年，许多的 ZK-EVM 项目纷纷宣告上线。 Polygon 开源了他们的 ZK-EVM 项目，ZKSync 发布了他们的 ZKSync 2.0 计划，华人之光的 Scroll 也上线了。还有 Github 上的 privacy-scaling-explorations 团队，Nicolas Liochon 等人的团队，以及 Cairo 编程语言等。

这些项目的核心目标都是一样的：使用 ZK-SNARK 技术，对以太坊二层的交易执行提供密码学证明，要么使以太坊本身的验证变得更加容易，要么构建功能上等效于以太坊但更加扩容的 zk-rollup 。但项目之间存在着细微的差别，在实用性和速度方面存在着取舍。Vitalik 在博客中曾将 zk-EVM 进行了分类，并分析了各个 EVM 等效类型的收益和成本。

image
image1920×1415 153 KB

1、Type 1 (fully Ethereum-equivalent)

类型一试图构建完全等同于以太坊，没有为了「更容易生成证明」而改变以太坊的任何部分。没有替换哈希（Hashes）、状态树（State Trie）、交易树（Transactions Trie）、预编译的合约（Precompiles)，和任何其他共识逻辑（In-consensus Logic），目标是与现有的应用程序完全兼容，开发者可以将应用程序丝滑地照搬过去。

1.1 优点：完美的兼容性

  • 兼容程度最高，对开发者最友好。允许开发者将现有代码「无需修改」地部署到 L2 上运行。例如可以照搬现有的海量以太坊基础设施，以太坊执行客户端可以按原来的方式用于生成和处理 Rollup 区块、现有的区块浏览器和区块生成等工具也可以丝滑地部署到 L2 等。
  • 和以太坊本身探索扩容的方向高度一致，未来可以被无摩擦地引入到 Ethereum 本身，扩容以太坊 L1 本身。
  • 能够如同现在的以太坊一样验证以太坊区块，或者更确切来说是验证执行层端（包括所有交易执行、智能合约和账户逻辑，但目前还不包括信标链共识逻辑）。
  • 总的来说，完全等价以太坊的价值便是可以借助以太坊现有的巨大网络效应和成熟复杂的生态。

1.2 缺点：证明生成时间特别长

  • 以太坊在融合零知识证明方面所面临的问题，Type1 类方案也同样面临。毕竟它是以太坊等价，而以太坊最初并非为了 zk 功能设计的。
  • 最大的问题就是生成证明所需时间久。针对这个问题，目前行业里主要的解决方案主要是：通过巧妙的工程大规模并行化证明，或通过硬件优化来加速。

1.3 主流项目

  • 以太坊基金会 PSE（Privacy and Scaling Explorations 隐私和扩容）团队，并由 Scroll、Taiko 社区支持贡献。
  • Taiko：今年 7 月已更新至 Alpha-4 测试网，预计 2024 年年初上线主网。Taiko 项目从最初就优先考虑去中心化和兼容性，是目前第一家且唯一一家实现去中心化提议者（proposer）的 ZK Rollup。

2、Type 2 (fully EVM-equivalent)

类型二力求完全兼容 EVM 以太坊虚拟机，但不等效于以太坊，目标是尽可能与绝大部分现有应用程序兼容，少数应用需进行一些改动。

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

2.1 优点：在虚拟机级别完全等价

  • 通过对 gas fee 的重新定价（越 zk 不友好的 op code 价格越贵，反之亦然），和删除部分对 ZK 不友好的以太坊堆栈，来提供比 Type1 类更快的验证时间。
  • Type2 类型可以做到与极大部分现有的以太坊应用程序兼容，因此绝大多数开发者和用户层面基本感受不到摩擦。
  • 虽无法零修改地直接使用以太坊执行客户端，但通过一些调试仍可以支持现有的 EVM 调试工具和其他开发基础设施。因此仍在极大程度上可以借力于以太坊现有的繁荣生态。

2.2 缺点：证明生成时间缩短但仍较长

  • 更改执行环境的影响范围虽小，但中长期依旧存在潜在的开发问题。比如将以太坊常用哈希（Keccak）替换为其他 zk 友好的哈希值（例如 Poseidon ），有可能会导致那些依赖于 Keccak 哈希值（涉及到历史数据）的 dapp 在迁移到 Type2 类型项目后出现不兼容问题（无法使用、或者跑出不同结果）。
  • 对于未来 gas fee 定价规则的更改，现有合约和 gas fee 优化工具可能出现不兼容的问题。 gas fee 定价规则的更改，本意是通过重新根据对 zk 友好程度来定价 op code，来「引导」开发者减少使用 zk 不友好的 op code。但可能反而对已经做了 gas fee 优化的项目产生不兼容。
  • 这些修改虽然和 Type1 类 zkEVM 相比，进一步提高了证明者的效率，但和 Type4 类 zkEVM 相比，证明时间依旧是一个相对缺点。

2.3 主流项目

  • Scroll ：2022 年 9 月上线 Pre-Alpha 测试网，2023 年 2 月上线 Alpha 测试网，2023 年 10 月上线主网。测试网上线时属于 Type3 类 zkEVM，但正在逐步增强 EVM 兼容性并向 Type2 类 zkEVM 过渡。
  • Polygon zkEVM：2023 年 3 月上线了主网 Beta 版本。上线时属于 Type3 类 zkEVM，但目前在向 Type2 类 zkEVM 过渡。

3、Type 2.5 (EVM-equivalent, except for gas costs)

曾经还有 Type2.5 类，现在基本与 Type2 类融合了。长期以来， Gas fee 规则已经成为开发人员遵守的标准。

要想显着缩短证明生成时间的一个办法是大幅增加证明生成特定环节的 Gas fee。尽管更改 Gas fee 规则可能会降低开发人员工具的兼容性并破坏一些应用程序，但通常认为它比其他“更深层次”的改动风险要小。 开发的过程需要确保，交易所需要的 Gas 量不要超过区块所能容纳的 Gas 量，也不要使用硬编码的 Gas 量进行调用。

管理资源约束的另一种方法是简单地对每个操作可以调用的次数设置硬性限制。 这在电路中更容易实现，但与 EVM 安全假设的配合却不太好。 我将这种方法称为类型 3，而不是类型 2.5。

4、Type 3 (almost EVM-equivalent)

Vitalik 认为，Type3 类 zkEVM 更像是一个过渡（通过提高兼容程度过渡为 Type2/Type1 类；或者通过降低兼容程度、提升 zk 友好度过渡为 Type4 类)。

  • 近乎兼容 EVM 以太坊虚拟机。通过在兼容性方面进一步牺牲，使其 zkEVM 更易于开发、zk 证明生成速度更快。
  • 删除了更多在 zkEVM 中难以实现的功能（比如预编译功能）。
  • 在处理合约代码（contract code）、内存（memory）或堆栈（stack）方面存在更大差异。
  • 目标是与大多数现有应用程序兼容。

4.1 特点：高不成低不就 / 优势兼具

  • 相比起 Type1 和 Type2 类 zkEVM，此类型更加 zk 友好，运算 zk 证明时间更短。但存在更高的不兼容性和更多元素的牺牲（对以太坊开发者更加不友好）
  • 相比起 Type4 类 zkEVM 可以兼容的现有以太坊应用程序更多，证明速度更慢。
  • 这也是为什么 Type3 类更像是一个过渡，处于此类的方案大概率会通过提升兼容度，过渡到 type2 类 zkEVM。

4.2 主流项目：

  • Scroll：一年前 Scroll 属于此类型，但目前通过提升以太坊兼容度，在向 Type2 类 zkEVM 发展。
  • Polygon zkEVM（Polygon 团队的 ZK Rollup 方案）：2023 年 3 月上线了主网 Beta 版本。上线时属于 Type3 类 zkEVM。

5、Type 4 (high-level-language equivalent)

此类实际上属于 zkVM（零知识证明虚拟机，而非 zk-EVM ）。可以理解为编程语言层面的兼容。目标是低成本、高效率、最大化零知识证明友好性。开发者可以继续使用他们在以太坊上习惯使用的编程语言（比如 Solidity）编写智能合约。此类型项目会用编译器将此编程语言转换为它们自定义的可读代码进行编译，并在它们自定义的环境中（和 ）执行。

  • 比如 Starkware 使用 Warp 编译器将 Solidity 代码转换为 Cairo 字节码；执行环境 Starknet 的 Cairo VM
  • zkSync 通过 LLVM 编译器将 Solidity 代码转换为其自定义的虚拟机可执行的代码 LLVM-IR，执行环境 zkSync 的 Sync VM

5.1 优点：非常快的证明时间

  • 非常快的验证时间。
  • 直接从高级语言编译可以大大降低成本（时间、金钱和计算工作量），降低成为证明者的技术门槛，提高去中心化程度。
  • 此类 zkEVM 可以通过使用其自定义的虚拟机**「原生支持帐户抽象（AA）」**，而 EVM 等效的链无法原生支持账户抽象，需要通过以太坊的 ERC-4337 来实现。

5.2 缺点：更多的 EVM 不兼容

  • 大量现有的以太坊应用程序无法被复制到这类 zkVM 中，或者在复制过程中会出现问题，需要进行更复杂的的调整。
    • 比如合约在 Type 4 类 zkVM 系统中的地址可能与 EVM 中的地址不一样；
    • Type4 类 zkEVM 不支持手写的 EVM 字节码（而目前许多应用程序都会使用手写的 EVM 字节码以节省 gas fee）；
    • 编译器不完全支持 Solidity 的一些功能，尚不成熟。
  • 对现有 EVM 项目的开发者友好度相对低，有可能影响生态的发展和技术的迭代速度。极难借力于以太坊现有的复杂繁荣的生态和网络效应。

5.3 主流项目：

  • zkSync Era ：2020 年 6 月上线 zkSync Lite（zkSync 1.0），主要支持简单的支付（payment）和资产兑换（swap）场景，并不支持 EVM 兼容的智能合约；2023 年 3 月上线 zkSync Era（zkSync 2.0），通过上述架构可以实现在高级语言层面的兼容。zkSync 的目标本就不是 EVM 兼容，而是提高零知识证明生成速度。
  • Starknet ：2021 年 11 月上线主网，今年 7 月已更新至 v0.12.0 版本。其自身属于 Type4 类 zkEVM，目标不是 EVM 兼容。但目前它上面也有像 Kakarot 这样的项目，旨在使 Starknet 也能达到类似 Type 2.5-3 类 zkEVM 的兼容程度。

6、总结

上述的分类方式，并不明确地意味着一些类型要比其他类型“更好”或“更差”，相反，它们代表了不同的 trade-off ：编号较低的类型与现有基础设施更兼容，但速度较慢；编号较高的类型与现有基础设施的兼容性较差，但速度较快。总的来说，所有这些类型正在探索的空间都是健康的。

image
image2000×598 106 KB

image
image2000×1127 100 KB

二、未来的 ZK-EVM 什么样

尽管不同类型的 ZK-EVM 不意味着好坏，但 Vitalik 在博客文章最后给出了他对未来的看法：

  • 目标：就我个人而言，我希望随着时间的推移，通过 zkEVM 的改进和以太坊本身的改进相结合，使其（以太坊）对 ZK-SNARK 更加友好，最终一切都将成为 Type1 类。在这样的未来，将有多个 zkEVM 实现方式，它们既可以用于 ZK Rollup（零知识扩容），也可以用于验证以太坊链本身。
  • 实现：从理论上讲，以太坊没必要为 L1（第一层）使用制定单一的、标准化的 zkEVM 规范；不同的客户端可以选择使用不同的证明方式，这样我们就可以继续受益于代码层面的冗余。但是，要实现这样的未来，还需要相当长的时间。与此同时，在以太坊（自身）扩容和基于以太坊的 ZK Rollup 的不同路径方面，我们也将会看到大量的创新。

任何 zkEVM 项目所属的类型也并非是静态不变的。随着各家方案在 zkEVM 方面的探索、甚至是以太坊本身的改进，有可能所有方案最终都能达到 Type 1 类 zkEVM的效果。例如：

  • ZK-EVM 可能从 Type 3 入手，随着时间的推移，他们可以添加一些更加 EVM 兼容、同时让 ZK-prove 变得困难的功能，并转向 Type 2。
  • ZK-EVM 可能从 Type 2 入手，尝试在完全以太坊兼容的模式下，运行可以更快地证明状态树修改的可能性，成为 Type1 和 Type2 混合的状态。Scroll 正在考虑向这个方向移动。
  • 随着时间的推移，通过添加处理 EVM 代码的能力，开始作为 Type4 的系统可能会变成 Type3 系统（尽管开发人员仍然被鼓励直接从高级语言编译，以减少费用和证明时间）。
  • 如果以太坊自身变得更加 zk-friendly，Type2 或 Type3 可以很容易成为 Type1 。
  • 一个 Type1 或 Type2 的 ZK-EVM 可以通过添加一个预编译器来变成 Type3 ，通过 ZK-SNARK-friendly 的语言实现验证代码。

三、写在最后

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

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

  • L2 交易排序的去中心化程度：sequencer/proposer 是否是去中心化的，这直接影响到生态参与者的复杂程度，以及整个网络的安全性；
  • 费用：以哪些代币支付费用、一条公链的代币经济模型如何；
  • 生成证明的规则：对于 prover 的激励机制、加速生成证明的硬件标准；
  • 是否自托管：是否有明确的机制来确保 L2 发生事故的时候仍然能够在 L1 恢复用户资产；
  • 数据可用性：完整的数据可用性成本自然要高些，是否可接受有些 ZK Rollup 采用的较低成本的数据可用性模式。
  • 项目进度：由于多数通用 ZK Rollup 目前还处于测试网阶段，项目本身的进度也成为开发者选择的重要因素。

参考

Vitalik Blog：https://vitalik.ca/general/2022/08/04/zkevm.html

MirrorSite：The different types of ZK-EVMs

Blockbeats：L2赛道爆发前夕，浅析各类zkEVM - BlockBeats