imtoken钱包安卓下载 | Vitalik 解释了 5 种不同的类型

注：原作者为以太坊联合创始人Vitalik Buterin。

特别感谢 PSE、Polygon Hermez、Zksync、Scroll、Matter Labs 和 Starkware 团队的讨论和审查。

最近有很多“ZK-EVM”项目发布了华丽的公告，例如 Polygon 开源了他们的 ZK-EVM 项目，ZKSync 发布了他们的 ZKSync 2.0 计划，以及相对较新的 Scroll 最近宣布了他们的 ZK-EVM 项目。 EVM。 隐私和扩展探索团队（Privacy and Scaling Explorations），Nicolas Liochon 等人的团队，从 EVM 到 Starkware 的 Cairo 语言的 alpha 编译器也在努力工作，当然也有一些我错过的。

所有这些项目的核心目标都是相同的：使用 ZK-SNARK 技术来制作类似于以太坊交易执行的密码学证明，或者更容易验证以太坊区块链本身以太坊状态树，或者构建可与以太坊提供的功能相媲美（更接近）但更具可扩展性的 ZK-rollup。 但这些项目之间存在细微差别，以及它们在效用和速度之间做出的权衡。 本文将尝试描述不同“类型”的 EVM 等效性的分类，以及尝试实施每种类型系统的收益和成本。

ZK-EVM 概览图

Type 1（完全等同于以太坊）

Type 1 ZK-EVM 力求完全且毫不妥协地等同于以太坊，它们不会更改以太坊系统的任何部分以使其更容易生成证明。 它们不会取代哈希、状态树、交易树、预编译或任何其他共识逻辑，无论多么微小。

优点：完美兼容

目标是能够像今天一样验证以太坊区块，或者至少在执行层端（因此，不包括信标链共识逻辑，但包括所有交易执行和智能合约和账户逻辑）。

Type 1 ZK-EVM 是我们最终需要使以太坊 L1 层本身更具可扩展性的东西。 从长远来看，在 Type 2 或 Type 3 ZK-EVM 中测试的以太坊修改可能会引入以太坊本身，但这种重新架构有其自身的复杂性。

Type 1 ZK-EVM 也是 rollup 的理想选择，因为它们允许 rollup 重用大量基础设施。 例如，以太坊执行客户端可以按原样使用来生成和处理汇总块（或者至少，一旦实现取款，他们可以使用和重用该功能来支持将 ETH 存入汇总），例如区块浏览器等工具和块生产非常容易重用。

缺点：证明时间

以太坊最初并不是围绕 ZK 友好性设计的，因此以太坊协议的许多部分都需要大量的 ZK 证明计算。 Type 1 ZK-EVM 旨在精确复制以太坊，因此它无法缓解这些低效率问题。 目前，以太坊区块的证明需要很长时间才能生成。 这可以通过巧妙地设计大规模并行化的证明者来缓解，从长远来看，可以通过 ZK-SNARK ASIC 来缓解。

那么谁在构建 Type 1 ZK-EVM？

Privacy and Scaling Explorations 团队正在构建 Type 1 ZK-EVM。 （译者注：Privacy and Scaling Explorations team是更名appliedzkp）

类型 2（完全等效的 EVM）

Type 2 ZK-EVM 力求完全等同于 EVM，但不等同于以太坊。 也就是说，它们“从内部看”与以太坊一模一样，但在外部却有一些差异，尤其是在块结构和状态树等数据结构方面。

目标是与现有应用程序完全兼容，但对以太坊进行一些小的修改，以使开发更容易并更快地生成证明。

优点：VM 级别的完美等价

类型 2 ZK-EVM 对保存以太坊状态等内容的数据结构进行更改。 幸运的是，EVM 本身不能直接访问这些结构，因此在以太坊上运行的应用程序几乎总是在 Type 2 上运行。在 ZK-EVM rollup 上运行。 您将无法按原样使用以太坊执行客户端，但您可以通过一些修改来使用它们，并且您仍然可以访问 EVM 调试工具和大多数其他开发人员基础设施。

当然，也有少数例外。 验证以太坊历史区块的 Merkle 证明以验证历史交易、收据或状态声明的应用程序会出现不兼容性（例如，桥有时会这样做）。 用不同的哈希函数替换 Keccak 的 ZK-EVM 会破坏这些证明。 但是，我通常建议不要以这种方式构建应用程序，因为未来的以太坊更改（例如 Verkle 树）可能会破坏以太坊本身的此类应用程序。 一个更好的选择是以太坊本身添加面向未来的历史访问预编译。

缺点：尽管有所改进以太坊状态树，但证明时间仍然很慢

类型 2 ZK-EVM 提供比类型 1 ZK-EVM 更快的证明时间，主要是通过消除对以太坊堆栈中不必要的复杂和 ZK 不友好的加密部分的依赖。 特别是，他们可能会更改以太坊的 Keccak 和基于 RLP 的 Merkle-Patricia 树，并可能更改区块和接收结构。 类型 2 可能对 ZK-EVM 使用不同的哈希函数，例如 Poseidon‌。 另一个自然的修改是修改状态树以存储代码哈希和 keccak，以便在不验证哈希的情况下处理 EXTCODEHASH 和 EXTCODECOPY 操作码。

这些修改显着缩短了证明时间，但并未解决所有问题。 由于 EVM 固有的所有低效和 ZK 不友好，证明 EVM 仍然很慢。 一个简单的例子是内存：因为 MLOAD 可以读取任何 32 个字节，包括“未对齐”的块块（其中开始和结束不是 32 的倍数），所以 MLOAD 不能简单地解释为读取块； 相反，它可能需要读取两个连续的块并执行位操作来组合结果。

那么谁在构建 Type 2 ZK-EVM？

Scroll 的 ZK-EVM‌ 项目正朝着 Type 2 ZK-EVM 方向发展，Polygon Hermez‌ 也是如此。 当然，这两个项目都还没有完成。 特别是，尚未实现更复杂的预编译。 因此，目前这两个项目最好归类为Type 3 ZK-EVM。

类型 2.5（EVM 等效，gas 成本除外）

显着改善最坏情况证明时间的一种方法是大大增加 EVM 中某些难以 ZK 证明的操作的气体成本。 这可能涉及预编译、KECCAK 操作码，以及可能涉及调用合约或访问内存或存储或恢复的特定模式。

更改 gas 成本可能会降低开发人员工具的兼容性并破坏某些应用程序，但通常我们认为它比“更深层次的”EVM 更改风险更小。 开发人员应注意不要在一笔交易中请求超过一个区块的 gas，并且永远不要使用硬编码的 gas 数量进行调用（这一直是标准建议）。

管理资源约束的另一种方法是简单地对每个操作的调用次数设置硬限制。 这在电路中更容易实现，但在 EVM 安全假设下性能更差。 我将这种方法称为类型 3 而不是类型 2.5。

类型 3（几乎等同于 EVM）

Type 3 ZK-EVM 几乎等同于 EVM，但需要在精确等价方面做出一些牺牲，以进一步缩短证明时间并使 EVM 更易于开发。

优点：易于构建，证明时间更快

Type 3 ZK-EVM 可能会移除一些在 ZK-EVM 实现中非常难以实现的特性，而预编译通常位于此列表的顶部，此外，Type 3 ZK-EVM 有时在处理合约代码、内存方面或 stack 也有细微差别。

缺点：不兼容的地方会相对多一些

Type 3 ZK-EVM 旨在与大多数应用兼容，同时对其余部分的重写最少。 也就是说，某些应用程序需要重写，因为它们使用了 Type 3 ZK-EVM 删除的预编译，或者因为对 VM 以不同方式处理的边缘情况的微妙依赖。

那么谁在构建类型 3 ZK-EVM？

Scroll 和 Polygon 都是当前 ZK-EVM 构建中的 Type 3，尽管它们有望随着时间的推移提高兼容性。 Polygon 具有独特的设计，他们使用自己的内部语言 zkASM‌ 进行 ZK 验证，并使用 zkASM 实现来解释 ZK-EVM 代码。 尽管有这个实现细节，我仍然称它为真正的 Type 3 ZK-EVM，它仍然可以验证 EVM 代码，它只是使用一些不同的内部逻辑来做到这一点。

今天，没有一个 ZK-EVM 团队的目标是成为 Type 3 ZK-EVM，Type 3 只是一个过渡阶段，直到完成添加预编译的复杂工作，然后项目才能转移到 Type 2.5 ZK-EVM。 然而，在未来，Type 1 或 Type 2 ZK-EVM 可能会通过添加新的 ZK-SNARK 友好预编译自动成为 Type 3 ZK-EVM，为开发人员提供低证明时间和 gas 成本的函数。

类型 4（相当于高级语言）

Type 4 系统通过将用高级语言（例如 Solidity、Vyper 或中间语言）编写的智能合约源代码编译成某种明确设计为 ZK-SNARK 友好的语言来工作。

优点：非常快的证明时间

通过不对每个 EVM 执行步骤的所有不同部分进行 ZK 证明，并直接从更高级别的代码开始，您可以避免大量开销。

我在本文中只用了一句话来描述Type 4系统的这一优势（与下面列出的与兼容性相关的劣势相比），但这不应被解释为价值判断！ 直接从高级语言编译确实可以大大降低成本，并通过更容易成为证明者来帮助去中心化。

缺点：兼容性会差一些

用 Vyper 或 Solidity 编写的“正常”应用程序可以编译为“正常工作”，但有一些重要的方式使许多应用程序无法“正常工作”。

类型 4 系统中的合约地址可能与 EVM 中的地址不同，因为 CREATE2 合约地址取决于确切的字节码。 这打破了依赖“反事实合约”、ERC-4337 钱包、EIP-2470 单例和许多其他尚未部署的应用程序的应用程序。 手写EVM字节码比较难用，很多应用在某些地方使用手写EVM字节码来提高效率。 Type 4 系统可能不支持它，尽管有一些方法可以实现有限的 EVM 字节码支持来满足这些用例，而无需尝试成为完整的 Type 3 ZK-EVM。 许多调试基础设施是不兼容的，因为此类基础设施运行在 EVM 字节码上。 也就是说，可以通过从“传统”高级或中间语言（如 LLVM）更多地访问调试基础设施来缓解这一缺点。

开发人员应该意识到这些问题。

那么谁在构建 Type 4 系统？

ZKSync 是类型 4 系统的一个示例，尽管随着时间的推移它可能会增加与 EVM 字节码的兼容性。 Nethermind 的 Warp 项目正在构建一个从 Solidity 到 Starkware 的 Cairo 语言的编译器，这将把 StarkNet 变成事实上的 Type 4 系统。

ZK-EVM 类型的未来

本文并未明确判断上述各种类型的 ZK-EVM 中哪一种“更好”或“更差”，相反，它们只是在不同点上进行权衡：编号较低的类型与现有基础设施更兼容，但它会速度较慢，并且编号较高的类型与现有基础设施的兼容性较差，但它们会更快。 总的来说，探索所有类型的 ZK-EVM 都是有益的。

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

ZK-EVM 可以从类型 3 开始，它决定不包含一些特别难以 ZK 证明的特性。 稍后，他们可以随着时间的推移添加这些功能并迁移到 Type 2 ZK-EVM。 ZK-EVM 也可以从类型 2 开始，然后成为混合类型 2/类型 1 ZK-EVM，提供在完全与以太坊兼容的模式下运行的可能性，或者提供可以更快证明的修改状态树，例如Scroll 正在考虑朝这个方向发展。 随着时间的推移，通过添加处理 EVM 代码的能力，最初为 Type 4 的系统可能会变成 Type 3（尽管仍然鼓励开发人员直接从高级语言编译以减少费用和证明时间）。 如果以太坊本身采用修改变得更加 ZK 友好，则 Type 2 或 Type 3 ZK-EVM 可以成为 Type 1 ZK-EVM。 通过添加预编译以验证 ZK-SNARK 友好语言的代码，Type 1 或 Type 2 ZK-EVM 可以成为 Type 3 ZK-EVM。 这将使开发人员在以太坊兼容性和速度之间做出选择，而 Type 3 就是这样的选择，因为它打破了完美的 EVM 等价性，但出于实用目的，它将具有 Type 1 和 Type 3 2 ZK-EVM 的许多好处。 主要缺点可能是某些开发人员工具不理解 ZK-EVM 的自定义预编译，尽管这可以修复：开发人员工具可以通过支持包含预编译 EVM 代码的等效实现的配置格式来添加通用预编译支持。

就个人而言，我希望随着时间的推移，通过 ZK-EVM 的改进以及以太坊本身的改进（使其对 ZK-SNARK 更加友好），一切都变成 Type 1 ZK-EVM。 在这样的未来，我们将有多个 ZK-EVM 实现，可用于 ZK rollup 和验证以太坊区块链本身。 理论上，以太坊不需要为 L1 使用标准化单个 ZK-EVM 实现。 不同的客户可以使用不同的证明，因此我们继续受益于代码冗余。

然而，要实现这样的未来还需要相当长的时间。 同时，我们将在扩展以太坊和基于以太坊的 ZK-rollup 的不同路径上看到很多创新。