不同的ZK-EVM类型

不同的 ZK-EVM 类型

不同的 ZK-EVM 类型

对 PSE、Polygon Hermez、Zksync、Scroll、Matter Labs 和 Starkware 团队的辩论和审查，特别感谢 eren 的翻译。

最近看到许多“ZK-EVM”项目发布了引人注目的公告。Polygon 将 ZK-EVM 项目开源，ZKSync 发布了 ZKSync 2.0 的计划，以及相对较新的参与者 Scroll 公布了其 ZK-EVM。此外，Privacy and Scaling Explorations 团队与 Nicolas Liochon 及其同事 的团队，也正在致力于将 EVM 转向 Starkware 的 ZK 友好语言 Cairo 的 alpha 编译器，还有一些我遗漏的持续努力的团队。

所有这些项目的基本目标是相同的：利用 ZK-SNARK 技术生成以 Ethereum 为基础的交易的加密执行证明，从而使得验证这些证明变得更加容易，或被用来构建与 Ethereum 提供的（几乎）等效但更加可扩展的 ZK-rollup。然而，在这些项目之间存在微妙的差异，这些差异决定了它们在实用性与速度之间的权衡。本文将尝试阐明 EVM 对应的不同“类型”的分类法，以及尝试实现每种类型的好处和成本。

概览（图形形式）

类型 1 （完全 Ethereum 等效）

类型 1 ZK-EVM 努力成为完全且不妥协的 Ethereum 等效。它们不改变 Ethereum 系统的任何部分，以便简化生成证明。无论 hash、状态树、交易树、预编译，还是其他任何共识中包含的逻辑，它们都不进行更改。

优势：完美的兼容性

目标是能够验证当前状态下的 Ethereum 块——或者至少能够验证执行层（因此，信标链共识逻辑不包括在内，但所有交易执行和智能合约及账户逻辑都包括在内）。

类型 1 ZK-EVM 是我们最终需要的东西，以使 Ethereum Layer1 更加可扩展。从长远来看，已在类型 2 或类型 3 ZK-EVM 中测试过的对 Ethereum 的修改可能会适当地引入 Ethereum，但这样的重新设计自有其复杂性。

类型 1 ZK-EVM 也非常适合用于 rollup，因为它们允许 rollup 复用许多基础设施。例如，Ethereum 执行客户端可以像创建和处理 rollup 块一样被使用（或至少在 提现实现时，这个功能可以再被利用来支持向 rollup 存入 ETH），因此区块浏览器、区块生成等工具非常容易重复使用。

劣势：证明时间

Ethereum 最初并未设计为 ZK 友好，因此 Ethereum 协议有很多部分需要大量计算才能进行 ZK 证明。类型 1 的目标是完全复制 Ethereum，因此没有能够减轻这些低效的途径。目前，生成 Ethereum 块的证明需要数小时。通过非常巧妙的工程技术将证明过程大规模并行化或者从长远来看使用 ZK-SNARK ASIC，这种情况可能会有所缓解。

谁在构建？

ZK-EVM 社区版本（由 Privacy and Scaling Explorations、Scroll 团队、Taiko 等人的社区贡献发起）是一个类型 1 的 ZK-EVM。

类型 2 （完全 EVM 等效）

类型 2 ZK-EVM 努力完美地成为 EVM 等效，但不完全是 Ethereum 等效。也就是说，从“内部”看起来完全像 Ethereum，但在“外部”存在一些差异，特别是在区块结构和 状态树 等数据结构中。

目标是与现有应用程序完全兼容，但在 Ethereum 中进行一些小改动以简化开发，让证明的生成更快。

优势：VM 层面上的完美对应

类型 2 ZK-EVM 会对持有数据（如 Ethereum 状态）的数据结构进行更改。幸运的是，由于这些是 EVM 无法直接访问的结构，因此在 Ethereum 上运行的应用程序几乎总是可以继续在类型 2 ZK-EVM rollup 上运行。虽然你不能像使用 Ethereum 执行客户端那样直接使用，但可以通过一些修改继续使用，且仍然能够使用 EVM 调试工具和大多数其他开发者基础设施。

有少数例外。例如，在验证 历史 Ethereum 块 的 Merkle 证明的应用程序中，历史交易、回执或状态索赔可能会出现不兼容情况（例如，桥接有时会这样做）。一个用不同哈希函数替代 Keccak 的 ZK-EVM 可能会破坏这些证明。然而，通常我不建议应用程序以这种方式构建，因为未来的 Ethereum 修改（例如 Verkle 树）甚至会破坏这种应用程序。更好的替代方法则是在 Ethereum 中增加 未来可兼容的历史访问预编译。

劣势：复杂但仍然慢的证明时间

类型 2 ZK-EVM 通过消除 Ethereum 堆栈中不必要地复杂且对 ZK 不友好的加密部分，比类型 1 提供更快的证明时间。特别是它们可以改变 Ethereum 的 Keccak 和基于 RLP 的 Merkle Patricia 树，甚至可能改变区块和回执结构。类型 2 ZK-EVM 可以使用不同的哈希函数，例如 Poseidon。另一个自然而然的改动是，将状态树改为存储代码哈希和 keccak，从而消除处理 EXTCODEHASH 和 EXTCODECOPY 操作码的哈希验证需求。

这些变化极大改善了证明时间，但并没有解决所有问题。由于证明 EVM 的必要性带来的慢速，EVM 的所有低效以及对 ZK 不友好的情况仍然存在。这的一个简单例子是内存：一个 MLOAD 可以读取任意 32 字节，包括“未对齐”的部分（开头和结尾未能对齐到 32 的倍数），因此，MLOAD 不能简单地被视为读取一部分；相反，它可能需要读取两个相邻部分，以合并结果并进行位运算。

谁在构建？

Scroll 的 ZK-EVM 项目正朝着类型 2 ZK-EVM 发展，类似于 Polygon Hermez。然而，目前这两个项目都尚未完全达到目标；尤其是大多数更复杂的预编译尚未实现。因此，目前将这两个项目更好地视为 类型 3 更为妥当。

类型 2.5 （EVM 等效，除 gás 费用外）

在最坏的情况下，通过大幅增加在 EVM 中 ZK 证明极其困难的特定操作的 gás 费用，从而显著提高证明时间。这可能包括对预编译、KECCAK 操作码，以及某些合约调用模式或对内存/存储的访问或回溯进行额外िथ。

改变 gas 费用可能会降低开发者工具的兼容性，并可能会破坏若干应用程序，但通常被认为比“深层” EVM 变更风险更小。开发者应注意，不要在一次操作中要求过多的 gás 以至于装不下进一个块，也不要使用硬编码的气体量进行调用（这对于开发者来说早已是标准建议）。

管理资源限制的另一种方法是对每个操作可调用次数设定严格限制。虽然在电路中实施时更容易，但在 EVM 安全假设下的兼容性较低。我称之为类型 2.5，而非类型 3 的方法。

类型 3 （几乎 EVM 等效）

类型 3 ZK-EVM 几乎 是 EVM 等效的，但在速度上有所妥协，以进一步改善证明时间，方便 EVM 的升级。

优势：更容易构建且提供更快的证明时间。

类型 3 ZK-EVM 可以移除一些在 ZK-EVM 实现中实施极其困难的特性。通常， 预编译 排在此列表的顶部。此外，类型 3 ZK-EVM 在对合约代码、内存或栈的处理上可能也会有细微差别。

劣势：更多的不兼容性。

类型 3 ZK-EVM 的目标是与大多数应用兼容，对于其余的仅需要少量重写。然而，由于依赖于去除的预编译或虚拟机在某些细微之处的不同操作方式，仍然会有一些应用需要重写。

谁在构建？

Scroll 和 Polygon 都以现有形式作为类型 3，但随着时间的推移，预期它们会提高兼容性。Polygon 拥有其独特的设计，称为 zkASM，通过此设计来 ZK 验证其 ZK-EVM 代码。尽管由于实现细节，我仍将其称为真正的类型 3 ZK-EVM；因为它仍然能够验证 EVM 代码，只是为执行而采用了不同的内部逻辑。

今天，没有 ZK-EVM 团队主动想成为类型 3；类型 3 是在处理如预编译的复杂工作完成并且项目转向类型 2.5 之前的过渡阶段。然而，未来类型 1 或类型 2 的 ZK-EVM 可以自愿通过增加允许较低证明时间和 gas 费用的 新 ZK-SNARK 友好的预编译而转变为类型 3 ZK-EVM。

类型 4 （高级语言等效）

一个类型 4 系统通过接收用高级语言编写的智能合约源代码（例如 Solidity、Vyper 或二者编译的中间语言），并明确地在专为 ZK-SNARK友好而设计的语言中进行编译。

优势：非常快速的证明时间

通过直接高效得 ZK 进行所有 EVM 执行的不同部分，可以降低 大量 的额外负担。

我在这里用只有一句话的论述来解释这个优势（与后面关于兼容性劣势的大列表相比），但这不应该被解读为一个价值判断！直接从高级语言进行编译可以显著减少成本，同时让证明更加简单，从而帮助去中心化。

劣势：更多的不兼容性

用 Vyper 或 Solidity 编写的“普通”应用程序可以编译并“正常工作”，但在许多方面，许多应用并不“普通”：

• 合约在类型 4 的系统中可能与 EVM 唯一地址不同，因为 CREATE2 合约地址完全依赖于字节码。这会破坏依赖尚未部署的“对偶合约”、ERC-4337 钱包、EIP-2470 单例 及其他许多应用程序。
• 直接使用手写 EVM 字节码更为复杂。许多应用出于效率考虑在某些部分使用手写的 EVM 字节码。类型 4 系统可能不支持此功能，但可以通过不完全是类型 3 ZK-EVM 而满足这些使用案例的有限 EVM 字节码支持。
• 许多调试基础设施不可转移，因为这类基础设施是在 EVM 字节码之上运行的。然而，这种不利影响会通过“传统”的高级或中间语言（例如 LLVM）提供的调试基础设施的 更大 可获取性而缓解。

开发者应该牢记这些问题。

谁在构建？

ZKSync 是一个类型 4 的系统，但随着时间的推移，可能会增加对 EVM 字节码的兼容性。Nethermind 的 Warp 项目正在构建从 Solidity 到 Starkware 的 Cairo 的编译器，这将使 StarkNet 成为事实上的类型 4 系统。

ZK-EVM 类型的未来

各个类型并没有明显的“更好”或“更差”。相反，它们是在权衡领域中的不同点：较低编号的类型与现有基础设施更兼容，但更慢，而较高编号的类型与现有基础设施的兼容性较差，但更快。总体来说，这些类型的探索在领域上都是健康的。

此外，ZK-EVM 项目可以轻松地从高编号的类型开始，随着时间的推移跳转到低编号的类型（或反之亦然）。例如：

• 一个 ZK-EVM 可以选择不包含某些特别需要 ZK 证明的特性，从而作为类型 3 开始。随后随着时间推移，它们可以添加这些特性并转换为类型 2。
• 一个 ZK-EVM 可以作为类型 2 开始，随后通过完全与 Ethereum 的兼容模式或可更快证明的修改过的状态树提供功能，转变为混合的类型 2 / 类型 1 ZK-EVM。Scroll 正在考虑这个方向。
• 一个最初作为类型 4 的系统，随后可以随着具有处理 EVM 代码能力的功能的加入，转变为类型 3（尽管开发者仍然会倾向于用直接从高级语言编译来降低费用和证明时间）。
• 类型 2 或类型 3 ZK-EVM 可能在 Ethereum 实施更为 ZK 友好的修改时，转变为类型 1 ZK-EVM。
• 一个类型 1 或类型 2 ZK-EVM，可以通过增加一个预编译以验证使用 ZK-SNARK 友好的语言编写的代码，转变为类型 3 ZK-EVM。这将为开发者提供 Ethereum 兼容性和速度之间的选择。虽然这将是类型 3，因为这会破坏完美的 EVM 等效性，但在实际目的和意图上却具有类型 1 和 2 的许多优势。主要劣势是某些开发者工具可能无法理解 ZK-EVM 的专用预编译，但这个问题是可以解决的：开发者工具可以通过支持包含 EVM 字节码等效实现的配置格式来增加通用预编译支持。

就我个人而言，我希望 ZK-EVM 的改进和 Ethereum 自身变得更加 ZK-SNARK 友好的改进，能够共同实现所有事物最终化为类型 1 的目标。在这样的未来中，我们将拥有多个可以用于验证 ZK rollup 以及 Ethereum 链本身的 ZK-EVM 实现。从理论上讲，Ethereum L1 的使用者不需仅依赖一个统一的 ZK-EVM 实现；不同的客户端可以使用不同的证明，因此让代码重复利用。

然而，达到这样的未来是需要时间的。在此期间，我们将见证许多关于扩展 Ethereum 和基于 Ethereum 的 ZK-rollup 的创新。

• 原文链接： vitalik.eth.limo/general...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～