从Type1到Type4，各类型ZK-EVM间差异何在？

编者按：作者根据Vitalik此前撰写的ZK-EVM介绍文章进行整理，并详细介绍了各类ZK-EVM和它们之间的差异。

大约一年前，一群ZK-EVM宣布即将推出测试网。这些举措激起了以太坊社区的好奇心，并引发了人们对以太坊等效和EVM等效等术语背后的细微差别的讨论。

为了明确起见，Vitalik撰写了一篇重要的文章，题为《不同类型的ZK-EVMs》，将各种ZK-EVM分类为四种类型，并解释了它们的区别。

其核心思想是：Type 1（例如Taiko）与以太坊完全等效，而Type 4（例如zkSync）在高效的证明生成方面表现出色。所有其他类型，Type 2、Type 2.5和Type 3，介于这两者之间（例如PolygonzkEVM、Scroll、Linea）。

大多数ZK-EVM最初都是Type 2.5和Type 3，并透露了一些朝Type 1或Type 2发展的意图，尽管这些项目没有为此提供具体的时间表或承诺。

本文主要关注Type 1和Type 2/Type 2.5之间的差异，并描述了破坏以太坊等效性可能带来的后果。我们还将简要介绍其他类型。

ZK-EVM的主要目标是扩展以太坊，即提高以太坊的吞吐量，同时保留其其他特性（安全性、开发者体验等）。在理想情况下，ZK-EVM应该能够：

• 根据黄皮书中以太坊虚拟机规范，证明未经修改的原生字节码的执行情况（覆盖100%的以太坊操作码）。
• 以低成本快速生成证明。
• 允许100%重用为以太坊开发的工具和基础设施。
• 允许将任何以太坊dApp“按原样”重新部署在ZK-EVM上（“原样”意味着不需要任何更改，毫不妥协）。

ZK-EVM 类型之间的区别

在ZK-EVM领域，区别主要来自以太坊/EVM等效性水平、ZK不友好元素对证明生成成本和速度的影响，以及电路实现的复杂性（如VM构建或状态树）。

让我们分析这些差异，特别是将Type 1与Type 2/Type 2.5区分开来。我们还将涉及到与每种类型最相关的使用案例。

在比较各种类型时，通常使用下面的图表：

对于那些不在 ZK-EVM 领域全职工作的人来说，这张表可能看起来一头雾水，所以让我们将这些术语翻译成通俗易懂的话再看看：

这个图表更清晰地展示了每种类型的实际情况，但它仍然可能有些晦涩难懂，接下来让我们通过分别解释每种Type，全面探索ZK-EVM领域。

Type 1：等效于以太坊

Vitalik Buterin：

“Type 1 ZK-EVM 是我们最终需要的，使以太坊第 1 层本身更具可扩展性。”

Type 1 表示不更改以太坊系统的任何部分，以便更轻松地生成证明。对以太坊的不改变意味着安全性上的不妥协，因为大多数密码学原语（例如哈希函数）、开发者基础设施（例如调试器）或链基础设施（例如执行客户端）已经经过了9年的实战测试。

Type 1 ZK-EVM 不会替换任何东西：哈希、状态树、事务树、预编译或任何其他共识逻辑，一切都与主网的EVM完全相同。

• Type 1 是唯一能够验证以太坊链本身的类型——从整个区块到交易执行、智能合约和账户逻辑。

Type 2：等效于 EVM

Type 2通过去除一些不利于ZK的部分，使得证明生成更快、电路开发更容易。然而，由于这一点的后果，它可能会使得ZK-rollup的其他部分（例如节点软件）的开发更加复杂。这些复杂性可能是由于已经确立的最佳实践和测试工具与实施的更改（例如改变的状态树）不兼容所导致的。

注意：等效于以太坊和等效于EVM并不相同。虽然等效于以太坊意味着没有改变以太坊的任何部分，也就是说与所有以太坊dApp完全兼容，但是等效于EVM允许改变数据结构（例如块结构或状态树）。

尽管这些调整可能看起来很小，但它们会影响以太坊的兼容性。改变数据结构可能导致以太坊dApp与Type 2 ZK-EVM不兼容，特别是在验证关于过去交易、收据或状态的Merkle证明时（例如跨链桥）。

删除 ZK 不友好的元素

对以太坊进行的修改旨在简化开发并提高证明生成速度。目标是修剪依赖于不友好的零知识密码学的以太坊部分。用更专业的术语来说，由于非本地域（例如哈希函数）而需要大量门电路（加法和乘法操作）的部分；大量的多标量乘法和/或快速傅里叶变换（FFT）；或者只是需要大量操作的部分。

Type 2 ZK-EVM可能修改的不友好的零知识元素的具体示例：

• 哈希函数：虽然以太坊使用Keccak哈希函数，但许多ZK-EVM使用Poseidon哈希函数，它需要的门电路数量显著较少。例如，让我们估计每种类型的哈希函数可以每秒计算多少个（即证明生成速度的比较）。

Poseidon哈希函数在证明生成方面具有显著的速度优势。

然而，需要注意的是，相对于广泛社区认可的已建立的密码学原语，较新的密码学原语并不那么受青睐。尽管Poseidon可能提供速度，但Keccak经过实战检验的特性使其更具鲁棒性和安全，因为它被广泛采用。

这就是为什么Keccak尽管更古老且被更广泛的社区采用（在其他行业，例如安全系统或智能设备中的传感器），但可以被认为比Poseidon更更经得起考验，毕竟Poseidon是在ZK社区内创建和使用的新哈希函数。

• 用于数据存储的状态树：例如，虽然以太坊使用Merkle Patricia树（使用Keccak哈希），但一些Type 2 ZK-EVM选择稀疏Merkle树（使用Poseidon哈希）。更改状态树可能会导致一些不兼容性。例如，以太坊的Merkle树具有不同的节点类型，并使用RLP对数据进行编码，这在ZK中是一件困难的事情。
• 块结构： 块包含大量信息。然而，在探索L2时，我们只关心execution_payload_header（即块哈希）。在下图中，有execution_payload_header中包含的所有数据的结构（块哈希）。

请注意：更改这些组件任意之一都会破坏以太坊等效性。

Type 2.5：等效于 EVM，考虑gas成本

Type 2.5 ZK-EVM增加了在EVM中使用ZK技术难以证明的特定操作的gas成本。

鉴于以太坊每个区块的gas限制（30M gas），增加每个操作码的gas成本会导致每个区块的操作码减少。因此，一个区块中可以包含较少复杂的操作码。较简单的操作码使电路变得更小，并且生成证明的速度更快。

• gas是工作量的度量单位。
• 操作码的价格是以gas计算的。
• 操作码指定了机器语言指令中的操作。
• 一个程序是操作码的静态列表。程序执行是执行跟踪。
• 执行跟踪是程序执行的特定有序操作码列表。

难以进行ZK证明的部分包括：

• Keccak操作码和一些依赖于Keccak的其他操作码。
• 预编译：对EVM可访问的函数。其中一些提供复杂或数学上复杂的任务，例如密码学函数（例如blake2f或sha256）。它们不在EVM内执行，而是作为在执行客户端中硬编码的函数，并使用对特殊地址的 CALL 向 EVM 公开。
• 内存访问：例如，增加内存插槽大小（例如，以太坊使用字节对齐的内存，而Polygon zkEVM使用32字节的内存插槽）。为了使这种更改成为可能，必须更改某些操作码（例如MLOAD）的内部逻辑。
• 存储（即如上所述更改哈希函数或状态树）。

改变 gas 成本可能会降低开发人员工具的兼容性并破坏某些 dApp。例如，经常执行 gas 成本增加的操作码的智能合约可能会超过区块 gas 限制并且无法执行。

Type 3：几乎等效于 EVM

Type 3 ZK-EVM省略了不适用于ZK的预编译，并可能调整内存和存储访问。

依赖已删除的预编译的dApp需要进行重写。在不常见的情况下，Type 3 ZK-EVM和原始EVM处理边缘情况的方式的差异可能需要对dApp进行调整。

Type 4（相当于高级语言）

Type 4 离 EVM 已经很远了。

用高级语言（例如Solidity，Zinc）编写的智能合约源代码被编译为中间表现形式，生成适用于ZK友好的虚拟机的操作码。

• 这种方法避免了为每个 EVM 执行步骤生成 ZK 证明，从而大大减少了证明工作。
• 即使合约可以编译，如果 dApp 使用 EVM 手写字节码，也需要进一步的工作。
• Type 4 ZK-EVM 还需要自己的开发人员工具（（仅适用于操作码级别），例如调试器和跟踪器。

在证明执行轨迹的ZK电路中，每个步骤都实现了约束，每个步骤的成本是所有操作码的总和。因此，Type 4 ZK-EVM 旨在使用尽可能少的复杂操作码来优化效率。

值得一提的是，自定义操作码（不在以太坊中涵盖的操作码）使得可以通过默认情况下在以太坊上无法实现的新功能。例如，通过帐户抽象功能进行多次调用执行，或使用像Argent这样的开箱即用解决方案启动智能合约钱包。

总结

不同的 ZK-EVM 类型优先考虑不同的目标和特征。Type 1 侧重于以太坊等效性，而Type 4 优先考虑高效的证明生成。其他类型介于这些极端之间，许多 Type 2 和 3 ZK-EVM 协议已宣布他们打算转向以太坊等效。

这四种类型的分类可能不是 ZK 汇总的最终状态，将来可能会进行进一步的修改。例如，一些 ZK-EVM 可能会成为混合型，Type 1/2 可能会开发Type 4 解决方案（具有尽可能高的效率）并为 dApp 提供两种选择，而Type 3 和 4 ZK-EVM 可能会添加以太坊等效选项。