ZK-EVM类型：以太坊等效、EVM等效、Type 1、Type …

ZK-EVM 类型：Ethereum-equivalent（以太坊等效），EVM-equivalent（EVM 等效），Type 1，Type 4 以及其他神秘的流行语

TL;DR（太长不看）

一年前，相当多的 ZK-EVM 宣布即将推出测试网。社区想知道所有这些项目之间的区别是什么，以及 Ethereum-equivalence，EVM-equivalence 和其他突然出现的流行语是什么意思。为了明确起见，Vitalik 写了一篇文章“不同类型的 ZK-EVM”，为不同类型的 ZK-EVM 提供了分类并解释了差异。

核心思想是：Type 1（例如，Taiko）是完全 Ethereum-equivalent 的，而 Type 4（例如，zkSync）产生证明的效率最高。所有其他类型（Type 2，Type 2.5，Type 3）都介于这两个极端情况之间。

大多数 ZK-EVM 最初是 Type 3 或 Type 2.5，发布了一些转向 Type 1 甚至至少 Type 2 的意图，但没有提供任何具体的时间或承诺。

在本文中，我们将重点介绍 Type 1 和 Type 2/2.5 之间差异的细节，解释了打破 Ethereum-equivalence 的实际差异和可能造成的后果。我们还将简要介绍其他类型。但是，这超出了本文的范围。

免责声明：在本文中，我们提供了一些定义，以确保每个人都可以理解解释。如果你是专业人士，请随时跳过这些定义。😎

但是，如果你不熟悉 ZK-EVM 是什么，最好在阅读本文之前查看 PSE 的这篇详细的系列 文章 文章 或者这篇简短的解释 “Proof of Meow: how ZK-VM works”。

ZK-EVM 的主要目标是扩展以太坊。也就是说，在保留所有其他属性（安全性，开发者体验等）不变的情况下，提高以太坊的吞吐量。在理想情况下，为了模拟以太坊，ZK-EVM：

• 根据黄皮书中指定的以太坊 VM 规范，证明未更改的本机字节码的执行（即，涵盖 100％ 的以太坊 opcodes）；

• 以低成本快速生成证明；

• 允许重用为以太坊开发的 100％ 的工具和基础设施；

• 允许在 ZK-EVM 上“按原样”重新部署任何以太坊 dapp（“按原样”意味着不妥协，并且无需任何更改）。

Type 1/2/2.5/3/4 ZK-EVM 彼此有何不同

TL;DR（太长不看）

ZK-EVM 的类型因 Ethereum/EVM-equivalence 水平和 zk-unfriendly 元素（影响证明生成成本和速度）的数量以及电路实现的简易性（例如，VM 构建或状态树）而异。在下面，我们探讨了不同类型之间的差异，特别关注区分 Type 1 和 Type 2/2.5。 我们还将介绍与特定类型最相关的用例。

通常，在尝试在演讲或演示文稿中比较不同类型时，会使用类似于下面的图表：

对于那些不是 24/7 全天候从事 ZK-EVM 工作的人来说，此表可能看起来有些神秘。为了使其更清晰，并将不同类型之间的差异引入到更广泛的社区中，让我们以简单的英语仔细研究一下此差异对开发人员和用户的意义：

感觉好多了，但仍然很神秘。在本文的后面，我们将解释技术特征的每个差异以及这些技术问题的每个后果。

让我们连接点并立即填补 ZK-EVM 飞机中的空白！

Type 1 – Ethereum-equivalent（以太坊等效）

“Type 1 ZK-EVM 是我们最终需要使以太坊 Layer 1 本身更具可扩展性的工具” – Vitalik.

Type 1 意味着不更改以太坊系统的任何部分，以使其更容易生成证明。不更改以太坊意味着不妥协的安全性，因为大多数加密原语（例如，哈希函数），开发人员基础架构（例如，调试器）或链基础架构（例如，执行客户端）已经过 9 年多的实战测试：

Type 1 ZK-EVM 不会替换任何内容：哈希、状态树、交易树、预编译或任何其他共识逻辑。一切都与 EVM 中的完全一样。

• Type 1 是唯一可以验证以太坊链本身的类型（整个区块的当前状态，或仅执行端（即，交易执行、智能合约和帐户逻辑））。

• 最近显示的另一种可行方法是在 zkVM 内部运行现有的以太坊实现（如 revm、geth 甚至以太坊可执行规范本身）。这种方法的最大好处是不需要电路，除了非常通用的 zkVM 电路本身，尽管在实践中，仍然使用额外的电路来加速难以证明的部分（因此范围仍然更有限）。缺点是在 zkVM 内部运行以太坊而不是专门的 zkEVM 会产生大量的开销，但随着证明者变得越来越快，这可能是一个值得的权衡。

Type 2 – EVM-equivalent（EVM 等效）

Type 2 删除了一些 ZK-unfriendly 的部分，以加快证明生成速度并简化电路开发。但是，由于后者的结果，它可能会使 ZK-rollup 的其他部分的开发（例如，节点软件）更加复杂。因为这可能取决于众所周知的良好实践和测试工具，这些工具可能与已实现的更改不兼容（例如，已更改状态树）。

免责声明：Ethereum-equivalent 和 EVM-equivalent 并不相同。 Ethereum-equivalent 意味着没有更改以太坊的任何部分，即与所有以太坊 dapp 完全兼容，而 EVM-equivalent 允许更改数据结构（例如，区块结构或状态树）。

即使这些更改看起来很小，它们也会影响以太坊的兼容性：通过更改数据结构，如果 dapp 需要验证历史以太坊区块的 Merkle 证明，才能验证有关历史交易、收据或状态的声明（例如，网桥有时会这样做），则以太坊应用程序将与 Type 2 ZK-EVM 不兼容。

删除 ZK-unfriendly 的部分

对以太坊的修改是为了使开发更容易并加快证明生成速度。目标是删除以太坊堆栈中依赖于 ZK-unfriendly 加密的部分。通过 ZK-unfriendly，我们指的是由于使用非原生字段（例如，哈希函数）、大量的多标量乘法和/或 FFT，或者只是大量所需的操作，而需要很多门（加法和乘法运算）的那些。

让我们看一下 Type 2 ZK-EVM 可能更改的 ZK-unfriendly 元素的具体示例

• 哈希函数：虽然以太坊使用 Keccak 哈希函数，但许多 ZK-EVM 使用 Poseidon 哈希函数，该函数需要的门数量明显更少。

• 为了提供说明，让我们估计每秒可以计算多少个哈希函数（即，证明生成速度比较）。

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

但是，（i）较新的密码学原语不如较旧的密码学原语受欢迎，并且（ii）由不同行业中的广大社区经过实战测试的那些加密原语比由小范围社区使用的密码学原语更受欢迎。这就是为什么 Keccak 既旧又是被更广泛社区（不仅在区块链中，而且在其他行业中，例如，安全系统或智能设备中的传感器）采用的标准，可以被认为比 Poseidon （一种由 ZK 社区创建和使用的新哈希函数）更经过实战测试，因此也更强大和安全。

• 用于数据存储的状态树：例如，虽然以太坊使用 Merkle Patricia Trees（具有大量复杂编码要求的 Keccak 哈希函数），但 Polygon zkEVM 使用 Sparse Merkle Tree（使用 Poseidon 哈希）。更改状态树可能会导致一些不兼容，如本节开头所述。例如，以太坊 Merkle 树具有不同的节点类型，并使用 RLP 对数据进行编码，这在 ZK 中是一件非常疯狂的事情。

• 区块结构 区块包含大量信息。但是，在探索 L2 时，我们只关心 execution_payload_header（即，区块哈希）。

即使仅更改上述组件之一也会破坏以太坊的等效性。

Type 2.5 ZK-EVM（EVM 等效，但 Gas 成本除外）

Type 2.5 ZK-EVM 增加了 EVM 中特定操作的 Gas 成本，这些操作难以进行 ZK 证明。

虽然以太坊对每个区块的 Gas 有限制（30M Gas），但增加每个操作码的 Gas 成本会减少每个区块的操作码数量。因此，可以将不太复杂的操作码包含在一个区块中。不太复杂的操作码使它们的电路更小，并且证明生成速度更快。

• Gas 是衡量工作量的指标。

• 操作码以 Gas 定价。

• 操作码是机器语言指令的一部分，用于指定要执行的操作。

• 程序是操作码的静态列表。程序执行是执行跟踪。

• 执行跟踪是专门为特定程序执行而执行的特定有序操作码列表。

难以进行 ZK 证明的部分：

• Keccak 操作码和一些其他取决于 Keccak 的操作码。

• 预编译——暴露给 EVM 的函数。有些提供了复杂或数学上复杂的任务，例如加密函数（例如，blake2f 或 sha256）。它们不在 EVM 内部执行。相反，它们是在执行客户端中硬编码的函数，并使用对特殊地址的 CALL 将其暴露给 EVM。

• 访问内存：例如，增加内存插槽大小（例如，虽然以太坊使用字节对齐的内存，但 Polygon zkEVM 使用 32 字节的 mrmoty 插槽）。为了使此更改成为可能，必须更改某些操作码（例如，MLOAD）的内部逻辑。

• 存储（即，如上所述更改哈希函数或状态树）。

更改 Gas 成本可能会降低开发人员工具的兼容性并破坏某些应用程序。例如，如果有一个智能合约需要执行具有增加的 Gas 成本的特定操作码次数，则将超过区块 Gas 限制。

Type 3（几乎 EVM 等效）

删除难以进行 ZK 证明的预编译，并可能对访问内存、存储或恢复进行一些更改。

使用已删除的预编译的 Dapp 需要重写。Type 3 ZK-EVM 和原始 EVM 处理边缘情况（即，在不常见的情况下）的方式的差异可能也会导致 Dapp 的重写。

Type 4（高级语言等效）

以高级语言（例如，Solidity、Zinc 等）编写的智能合约源代码被编译为中间表示形式，并为 ZK-friendly VM 生成操作码。这使我们可以避免为每个 EVM 执行步骤的所有不同部分生成 ZK 证明，从而大大减少了证明者的工作。

Type 4 已经离 EVM 很远了。

即使可以编译合约，如果 Dapp 使用 EVM 手写字节码，则还需要进一步的工作。

Type 4 ZK-EVM 也需要自己的开发人员工具（仅那些在操作码级别工作的工具），例如调试器和跟踪器。

在证明执行跟踪的 ZK 电路中，所有约束都针对每个步骤实现，因此每个步骤的成本都是所有操作码的总和。这就是为什么 Type 4 ZK-EVM 尝试使用尽可能少的复杂操作码来优化效率。

自定义操作码（即，以太坊未涵盖的操作码）还允许实现默认情况下以太坊上不可用的新功能。例如，用于帐户抽象功能的多个调用执行或使用开箱即用解决方案（例如，Argent）启动智能合约钱包。

结论

不同类型的 ZK-EVM 专注于不同的目标并优先考虑不同的特征（Type 1 – Ethereum-equivalence，而 Type 4 –高效的证明生成），而其他类型则介于这两个极端情况之间，声明了他们将来朝着 Ethereum-equivalence 迈进的意图。

可能的情况是，四种类型的分类法不是 ZK-Rollup 的最终目标，将来可能会发生进一步的修改。 Taiko 并不声称永远保持 Type 1。但它确实声称不妥协地并最终与以太坊保持一致。也就是说，无论以太坊引入什么规范或新的路线图目标，Taiko 都将一路支持它。

加入我们 💗

在我们的 招聘版块 上探索空缺职位。

关注我们 🥁

从 Taiko 处获取最新消息：

• 网站：https://taiko.xyz.

• Discord：https://discord.gg/taikoxyz.

• GitHub：https://github.com/taikoxyz.

• Twitter：https://twitter.com/taikoxyz.

• 社区论坛：https://community.taiko.xyz.

贡献 🤓

在 GitHub 上为 Taiko 做出贡献，并获得 GitPOAP！你还将在我们的 README 中被列为贡献者。从 贡献手册 开始。

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