以太坊创始人 Vitalik Buterin 最新的这篇文章将为你论述不同类型 ZK-EVM 的未来，并为当下 Zk 类项目进行归类。
原文：The different types of ZK-EVMs
作者：Vitalik Buterin
编译：Web3Caff
特别感谢 PSE、Polygon Hermez、Zksync、Scroll、Matter Labs 和 Starkware 团队的讨论和审查。
最近有许多 “ZK-EVM” 项目陆续高调发布了公告，Polygon 开源了他们的 ZK-EVM 项目，ZKSync 发布了他们的 ZKSync 2.0 计划，而相对较新的 Scroll 最近也宣布了他们的 ZK-EVM。还有来自隐私和扩展解决方案研究团队，Nicolas Liochon 等人团队的持续努力，推出了从 EVM 到 Starkware 的 ZK 友好语言 Cairo 的 alpha 编译器，当然至少还有其他一些我错过的。
所有这些项目的核心目标都是一样的：使用 ZK-SNARK 技术对类似以太坊交易的执行进行加密证明，或者使验证以太坊链本身更容易，或者构建（或接近）以太坊但扩展性更强的 ZK-rollup。但这些项目之间存在着微妙的差异，以及他们在实用性和速度之间的权衡设计。这篇文章将试图描述 EVM 等价的不同 "类型 "的分类法，以及试图证明每种类型的好处和成本是什么。
概览（图表形式）
Type 1（完全等效于以太坊）
Type 1 ZK-EVM 力求完全且毫不妥协地与以太坊等效。他们不改变以太坊系统的任何部分，使其更容易产生证明。它们不会取代哈希、状态树、事务树、预编译或任何其他共识逻辑，无论它有多么边缘化。
优势：完美兼容
我们的目标是能够如同现在一样验证以太坊区块，或者至少验证执行层方面（因此，信标链的共识逻辑不包括在内，但所有的交易执行和智能合约和账户逻辑都包括在内）。
Type1 ZK-EVM 是我们最终需要的，它使得以太坊第 1 层本身更具可扩展性。从长远来看，在 Type 2 或 Type 3 ZK-EVM 中测试出来的对以太坊的修改可能会被引入以太坊本身，但这种重新架构也有其自身的复杂性。
Type1 ZK-EVM 也是 rollups 的理想选择，因为它们允许 rollups 重新使用大量的基础设施。例如，以太坊执行客户端可以按原来的方式用于生成和处理 rollup 区块（或者至少一旦实现提款，他们可以重新使用该功能来支持 ETH 存入 rollup），因此区块浏览器、区块生成等工具非常容易重用。
弊端：证明时间
以太坊最初并不是围绕 ZK 友好性设计的，所以以太坊协议的许多部分都需要大量的计算来进行 ZK 证明。Type1 的目标是完全复制以太坊，所以它没有办法减轻这些低效率的问题。目前，以太坊区块的证明需要许多小时才能产生。这种情况可以通过巧妙的工程来大规模并行验证，从来长远来看可通过 ZK-SNARK ASIC 来缓解。
谁在构建？
隐私和扩展探索团队 ZK -EVM 正在构建 Type 1 ZK-EVM。
Type 2（完全 EVM 等效）
Type 2 ZK-EVM 努力做到完全 EVM 等效，但不完全等同于以太坊。也就是说，它们 "从内部 "看起来与以太坊完全一样，但它们在外部有一些差异，特别是在数据结构方面，如块结构和状态树。
其目标是与现有的应用程序完全兼容，但对以太坊做一些小的修改，以使其开发更容易，并使更快生成证明。
优势：VM 级别的完美等价
Type 2 ZK-EVM 会对保存诸如以太坊状态之类的数据结构进行更改。幸运的是，这些结构是 EVM 本身不能直接访问的，因此在以太坊上运行的应用程序几乎总是可以在 Type 2 ZK-EVM rollup 上运行。你将无法按原样使用以太坊执行客户端，但你可以通过一些修改来使用它们，而且你仍然能够使用 EVM 调试工具和大多数其他开发者基础设施。
不过有少数例外。对于验证历史以太坊区块的 Merkle 证明以验证有关历史交易、收据或状态的声明的应用程序出现了一种不兼容（例如，桥梁有时会这样做）。用不同的哈希函数替换 Keccak 的 ZK-EVM 会破坏这些证明。但是，我通常建议不要以这种方式构建应用程序，因为未来的以太坊变化（如 Verkle 树）将打破这样的应用程序，甚至在以太坊本身。更好的选择则是让以太坊本身添加面向未来的历史访问预编译。
弊端：改进验证时间，但仍然很慢
Type 2 ZK-EVM 提供比 Type 1 更快的验证器时间，主要是通过移除以太坊堆栈中依赖于不必要的复杂和 ZK 不友好的密码学的部分。特别是，他们可能会改变以太坊的 Keccak 和基于 RLP 的 Merkle Patricia 树，也许还有区块和接收结构。Type 2 ZK-EVM 可能会改用不同的哈希函数，例如 Poseidon。另一种较为自然的修改是修改状态树以存储代码哈希和 keccak，进而消除验证哈希的需要以处理 EXTCODEHASH 和 EXTCODECOPY 操作码。
这些修改显着提高了证明者的时间，但它们并不能解决所有问题。由于 EVM 固有的低效性和对 zk 的不友好性，因此证明 EVM 原样的过程仍很缓慢。一个简单的例子是内存：因为 MLOAD 可以读取任何 32 个字节，包括 “未对齐” 块（开始和结束不是 32 的倍数），所以不能简单地将 MLOAD 解释为读取一个块；相反，它可能需要读取两个连续的块并执行位操作来合并结果。
谁在构建？
Scroll 的 ZK-EVM 项目正朝着 Type 2 ZK-EVM 方向发展，Polygon Hermez 也是如此。也就是说，这两个项目都还没有完成。特别是，许多更复杂的预编译还没有实现。因此，目前这两个项目最好被认为是第三类。
Type 2.5（等同于 EVM，除 Gas 成本）
显着改善最坏情况证明者时间的一种方法是大大增加 EVM 中很难进行 ZK 证明的特定操作的 gas 成本。这可能涉及预编译、KECCAK 操作码，以及可能涉及到调用合约或访问内存或存储或还原的特定模式。
改变 gas 成本可能会降低开发者工具的兼容性，并破坏一些应用程序，但一般认为它比 "更深层次 "的 EVM 变化风险要小。开发者应该注意不要在一个事务中要求更多的气体，不要用硬编码的气体量进行调用（这已经是对开发者的标准建议了很久）。
更改 gas 成本可能会降低开发人员工具的兼容性并破坏一些应用程序，但通常认为它比 “更深层次” 的 EVM 更改风险更小。开发人员应该注意，在交易中需要的 gas 费用不要超过区块的容量，永远不要使用硬编码的 gas 量进行调用 (这已经是很长时间以来对开发人员的标准建议)。
管理资源约束的另一种方法是简单地对每个操作可以调用的次数设置硬限制。这在电路中更容易实现，但在 EVM 安全假设下的表现要差得多。我将这种方法称为 Type 3 而不是 Type 2.5。
Type 3（几乎等效于 EVM）
Type 3 ZK-EVM 几乎与 EVM 等效，但在精确等效性方面做出了一些牺牲，以进一步改善验证器的时间，使 EVM 更容易开发。
优势：更容易构建，更快的验证时间
Type 3 ZK-EVM 可能会删除一些在 ZK-EVM 实现中极难实现的功能。预编译通常位于此处列表的顶部；此外，Type 3 ZK-EVM 有时在处理合约代码、内存或堆栈方面也存在细微差别。
弊端：更多的不兼容性
Type 3 ZK-EVM 的目标是与大多数应用程序兼容，并且只需要对其余的应用程序进行最小的重写。也就是说，会有一些应用程序需要重写，要么是因为它们使用了 Type 3 ZK-EVM 所删除的预编译，要么是因为对边缘情况的微妙依赖，而虚拟机的处理方式不同。
谁在构建？
Scroll 和 Polygon 在目前的形式下都是 Type 3，尽管他们预计会随着时间的推移提高兼容性。Polygon 有一个独特的设计，他们对自己的内部语言 zkASM 进行 ZK 验证，并使用 zkASM 实现来解释 ZK-EVM 代码。尽管有这样的实现细节，我仍然会把它称为真正的第三类 ZK-EVM；它仍然可以验证 EVM 代码，只是使用一些不同的内部逻辑来完成。
今天，没有一个 ZK-EVM 团队想成为第 3 类；第 3 类只是一个过渡阶段，直到添加预编译的复杂工作完成，项目可以转移到第 2.5 类。然而，在未来，Type 1 或 Type 2 ZK-EVM 可能会自愿成为 Type 3 ZK-EVM，通过添加新的对 ZK-SNARK 友好的预编译，为开发者提供功能，并降低验证器时间和 gas 成本。
Type 4（相当于高级语言）
Type 4 系统的工作原理是，将用高级语言（如 Solidity、Vyper 或一些两者都能编译的中间语言）编写的智能合约源代码，编译成一些明确设计为 ZK-SNARK 友好的语言。
优势：验证器时间非常快
如果不对每个 EVM 执行步骤的所有不同部分进行 ZK 验证，而直接从高级别的代码开始，就可以避免大量的开销。
在这篇文章中，我只用了一句话来描述这个优点（相比之下，下面有一个很大的与兼容性有关的缺点列表），但这不应该被解释为一种价值判断！直接从高级语言编译确实可以大大降低成本，并通过使其更容易成为验证者来帮助去中心化。
弊端：更多的不兼容性
一个用 Vyper 或 Solidity 编写的 "正常 "的应用程序可以被编译下来，它可以 "正常工作"，但在一些重要的方面，很多应用程序都会不 "正常"工作。
合约在 Type 4 系统中的地址可能与 EVM 中的地址不一样，因为 CREATE2 合约地址取决于确切的字节码。这打破了依赖尚未部署的 "反事实合约"、ERC-4337 钱包、EIP-2470 单子和许多其他应用程序。
手写的 EVM 字节码更难使用。许多应用程序在某些部分使用手写的 EVM 字节码以提高效率。 Type 4 系统可能不支持它，尽管有办法实现有限的 EVM 字节码支持来满足这些用例，而不需要经过努力成为一个完整的 Type 3 ZK-EVM。
大量的调试基础设施不能被带过去，因为这些基础设施在 EVM 字节码上运行。也就是说，这个缺点被 "传统 "高级语言或中间语言（如 LLVM）的调试基础设施的更大访问量所缓解。
开发者应注意这些问题。
谁在构建？
ZKSync 是一个 Type 4 系统，尽管它可能随着时间的推移增加对 EVM 字节码的兼容性。Nethermind 的 Warp 项目正在建立一个从 Solidity 到 Starkware 的 Cairo 的编译器，这将使 StarkNet 成为一个事实上的 Type 4 系统。
ZK-EVM 类型的未来
这些类型并不明确地比其他类型 "更好 "或 "更差"。相反，它们是权衡空间的不同点：编号难度较小的类型与现有的基础设施更兼容，但速度较慢，而编号难度较大的类型与现有的基础设施不兼容，但速度较快。总的来说，所有这些类型都在探索，这对这个领域来说是健康的。
此外，ZK-EVM 项目可以很容易地从编号难度较大的类型开始，并随着时间的推移跳到编号难度较小的类型（或相反）。例如：
- ZK-EVM 可以从 Type 3 开始，决定不包括一些特别难于 ZK 证明的功能。之后，他们可以随着时间的推移增加这些功能，并转移到 Type 2
- ZK-EVM 可以从 Type 2 开始，然后成为第 2 类/第 1 类 ZK-EVM 的混合体，通过提供在完全以太坊兼容模式下运行的可能性，或者使用可以更快地证明的修改后的状态树，Scroll 正在考虑往这个方向发展。
- 从 Type 4 开始的系统随着时间的推移，通过增加处理 EVM 代码的能力，可能会变成 Type 3 系统，（为了减少费用和验证器时间，因此鼓励开发人员直接从高级语言编译）。
- 如果以太坊本身采用其修改以变得更加 ZK 友好，则 Type 2 或 Type 3 ZK-EVM 可以成为 Type 1 ZK-EVM。
- Type 1 或 Type 2 ZK-EVM 可以通过添加预编译来验证 ZK-SNARK 友好语言中的代码，从而成为 Type 3 ZK-EVM，这将使开发人员在以太坊兼容性和速度之间做出选择。这将是 Type 3，因为它打破了完美的 EVM 等效性，但出于实际目的和目的，它将具有 Type 1 和 2 的很多好处。主要缺点可能是某些开发人员工具无法理解 ZK-EVM 的自定义预编译，尽管这可以修复：开发人员工具可以通过支持包含预编译的 EVM 代码等效实现的配置格式来添加通用预编译支持。
我个人希望，随着时间的推移，通过对 ZK-EVM 的改进和对以太坊本身的改进，使其对 ZK-SNARK 更加友好，一切都会变成第一类（Type 1）。在这样的未来，我们将有多个 ZK-EVM 实现，既可用于 ZK rollups，又可用于验证以太坊链本身。理论上，以太坊没有必要为 L1 使用的单一 ZK-EVM 实现进行标准化；不同的客户可以使用不同的证明，所以我们继续从代码冗余中受益。
然而，在我们达到这样的未来之前，还需要相当长的时间。在此期间，我们将看到在扩展以太坊和基于以太坊的 ZK-rollup 的不同路径上有很多创新。
免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。本文内容仅用于信息分享，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。
