从Type1到Type4，各类型ZK-EVM间差异何在？
在 ZK-EVM 领域，区别主要来自以太坊/EVM 等效性水平、ZK 不友好元素对证明生成成本和速度的影响，以及电路实现的复杂性（如 VM 构建或状态树）。
原文作者：Lisa Akselrod
原文来源：X
编译：0xAyA，Odaily 星球日报
编者按：作者根据 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 ，介于这两者之间（例如 Polygon zkEVM、 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）；或者只是需要大量操作的部分。
关于【从Type1到Type4，各类型ZK-EVM间差异何在？】的延伸阅读
Movement的公链新解：“将 Move 引入 EVM”如何重塑以太坊与 Move？
LFG Labs推出基于Move语言的以太坊L2，旨在将Move系智能合约的安全性和高性能与EVM系的流动性和用户群结合。Movement SDK提供了模块化的MoveVM虚拟机、编译器和自定义适配器，解决了Move生态系统的破碎化问题。M1和M2公链架构集成了以太坊虚拟机，允许开发者在M2上启动并引入EVM系的DApp。M2使用零知识证明提高隐私和安全性，同时支持EVM和Move语言编写的智能合约。顶级VC机构已开始布局，为新的场景用例和生态增长奠定基础。
比特币与以太坊——根植于基本原则的文化之战
比特币和以太坊是推动加密货币和区块链技术发展的双重力量，但基于不同信念而相互对立。加密货币世界还有其他选择，如门罗币和Solana。跨链连接是解决不同加密货币互操作性的方式，但也存在安全和中心化风险。比特币和以太坊可能通过引入去中心化的EVM侧链来共存。
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 限制（30 M gas），增加每个操作码的 gas 成本会导致每个区块的操作码减少。因此，一个区块中可以包含较少复杂的操作码。较简单的操作码使电路变得更小，并且生成证明的速度更快。
- gas 是工作量的度量单位。
- 操作码的价格是以 gas 计算的。
- 操作码指定了机器语言指令中的操作。
- 一个程序是操作码的静态列表。程序执行是执行跟踪。
- 执行跟踪是程序执行的特定有序操作码列表。
难以进行 ZK 证明的部分包括：
- Keccak 操作码和一些依赖于 Keccak 的其他操作码。
- 预编译：对 EVM 可访问的函数。其中一些提供复杂或数学上复杂的任务，例如密码学函数（例如 blake 2 f 或 sha 256）。它们不在 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 可能会添加以太坊等效选项。
免责声明：本文仅代表作者个人观点，不代表链观CHAINLOOK立场，不承担法律责任。文章及观点也不构成投资意见。请用户理性看待市场风险，以及遵守所在国家和地区的相关法律法规。
图文来源：Lisa Akselrod，如有侵权请联系删除。转载或引用请注明文章出处！
