Subscribe to KuiKuaiLian
<100 subscribers
Share Dialog
Share Dialog
原文标题：《The different types of ZK-EVMs》 原文来源：Vitalik Buterin 个人主页 原文作者：Vitalik Buterin 原文编译：Block unicorn
最近有许多「ZK-EVM」项目高调发布公告。Polygon 开放了他们的 ZK-EVM 项目，ZKSync 发布了他们的 ZKSync 2.0 计划，相对较新的 Scroll 最近也发布了他们的 ZK-EVM。还有来自隐私和拓展探索的团队、Nicolas Liochon 等人的团队的持续努力，从 EVM 到 Starkware 的 zk 友好语言 Cairo 的 alpha 编译器，当然有一些项目我会错过。
所有这些项目的核心目标都是相同的：使用 ZK-SNARK 技术来对类似以太坊的交易执行进行加密证明，要么让验证以太坊链本身变得更容易，要么构建与以太坊提供的内容 (接近) 相同但可扩展性更强的 zk rollup。但这些项目之间存在着微妙的差异，以及它们在实用性和速度之间的权衡。这篇文章将尝试描述 EVM 等价性的不同「类型」的分类，以及尝试实现每种类型的好处和成本。
概述 (图表形式)
类型 1（完全等效于以太坊）
类型 1 ZK - EVM 力求完全和毫不妥协的等效于以太坊。它们不改变以太坊系统的任何部分，以使生成证明更容易。它们不会取代哈希、状态树、事务树、预编译或任何其他共识逻辑，无论它有多么外围。
优势:完美的兼容性
我们的目标是能够像现在一样验证以太坊区块，或者至少验证执行层 (因此，信标链共识逻辑不包括在内，但包括所有的交易执行和智能合约和账户逻辑)。
类型 1 ZK-EVM 是我们最终需要的，使以太网第 1 层本身更具可扩展性。从长远来看，在类型 2 或类型 3 ZK-EVM 中测试出的对以太的修改可能会被引入到以太本身，但这样的重新设计伴随着它自己的复杂性。
类型 1 ZK-EVM 也是汇总的理想选择，因为它们允许汇总重复使用大量基础设施。例如，Etherum Execution 客户端可以按原样使用来生成和处理 ROLLUP 块 (或者至少，一旦实现提取，它们就可以被重新使用，并且该功能可以被重用以支持存放到 ROLLUP 中的 ETH)，因此块资源管理器、块生产等工具非常容易重用。
劣势: 验证时间
以太坊最初并不是围绕 zk 友好性设计的，所以以太坊协议的许多部分需要进行大量的计算来验证 zk。类型 1 的目标是完全复制以太坊，所以它没有办法缓解这些低效率。目前，以太坊区块的证明需要许多小时来产生。这种情况可以通过巧妙的工程来大规模并行化验证器，或者从长远来看，可以通过 ZK-SNARK 专用集成电路来缓解。
构建者是谁?
隐私和扩展探索团队 ZK-EVM 正在构建类型 1 ZK-EVM。
类型 2 (完全等效 EVM)
类型 2 ZK - EVM 力求完全等价于 EVM，但不完全等价于以太坊。也就是说，它们「从内部」看起来完全像以太坊，但它们在外部有一些不同，特别是在数据结构上，如块结构和状态树。
其目标是与现有应用程序完全兼容，但对以太坊进行一些小的修改，以使开发更容易，并更快地生成证明。
优势：在虚拟机级实现完全对等
类型 2 ZK-EVM 对保存以太状态等内容的数据结构进行更改。幸运的是，这些结构是 EVM 本身不能直接访问的，因此在 Etherum 上工作的应用程序几乎总是在类型 2 ZK-EVM 汇总上工作。您将不能按原样使用 Etherum Execution 客户端，但您可以通过一些修改使用它们，并且您仍然可以使用 EVM 调试工具和大多数其他开发人员基础设施。
但也有少数例外。对于验证历史以太块的 Merkle 证明以验证关于历史交易、收据或状态的声明的应用程序，出现了一种不兼容性 (例如，桥梁有时会这样做)。用不同的散列函数取代 Keccak 的 ZK-EVM 将打破这些证明。然而，我通常建议不要以这种方式构建应用程序，因为未来的以太更改 (例如。Verkle Trees) 甚至在以太本身上也会破坏这样的应用。对以太坊本身来说，一个更好的替代方案是添加未来可靠的历史访问预编译。
缺点：改进了验证时间，但仍然很慢
类型 2 ZK-EVM 提供比类型 1 更快的验证时间，主要是通过移除依赖于不必要的复杂和不友好的 ZK 加密的以太堆栈的部分。特别是，它们可能会改变 Etherum 的 Keccak 和基于 RLP 的 Merkle Patricia 树，可能还会改变区块和接收结构。类型 2 ZK-EVM 可能会使用不同的哈希函数，例如，Poseidon。另一个自然的修改是修改状态树以存储代码散列和 keccak，从而不再需要验证散列来处理 EXTCODEHASH 和 EXTCODECOPY 操作码。
这些修改显著提高了验证时间，但它们不能解决所有问题。由于 EVM 固有的低效性和对 zk 的不友好性，证明 EVM 原样的过程仍然很缓慢。一个简单的例子是内存:因为 MLOAD 可以读取任何 32 字节，包括「未对齐」的块 (其中开始和结束不是 32 的倍数)，MLOAD 不能简单地解释为读取一个块;相反，它可能需要读取两个连续的块，并执行位操作来合并结果。
构建者是谁？
Scroll 的 ZK-EVM 项目正朝着 2 型 ZK-EVM 的方向发展，正如 Polygon Hermez 一样。也就是说，这两个项目都还没有完成（没有完成 ZKEVM 工作）;特别是，许多更复杂的预编译还没有实现。因此，目前两个项目都最好考虑类型 3。
2.5 类型 (与 evm 相当，不包括 gas 费用)
显著改善最坏情况验证时间的一种方法是大幅增加 EVM 中很难证明的特定操作的费用成本。这可能涉及预编译、KECCAK 操作码，还可能涉及调用约定或访问内存、存储或恢复的特定模式。
不断变化的 gas 费用成本可能会降低开发人员工具的兼容性，并破坏了一些应用程序，但通常认为这比「更深层次的」EVM 更改风险更小。开发人员应该注意，在交易中需要的 gas 费用不要超过区块的容量，不要使用硬编码的 gas 费用数量进行调用 (这已经是很长时间以来对开发人员的标准建议)。
类型 3 (几乎等同于 EVM)
第 3 型 zk -EVM 几乎同等于 EVM，但为了实现完全相同，需要做出一些牺牲，以进一步提高验证时间并使 EVM 更容易开发。
优点：更容易构建，验证时间更快
类型 3 ZK-EVM 可能会删除一些在 ZK-EVM 实现中特别难实现的功能。在这里，预编译通常位于列表的顶部；此外，类型 3 ZK-EVM 在处理合约代码、内存或堆栈的方式上有时也有细微的差异。
缺点：更多的不兼容
类型 3 ZK-EVM 的目标是与大多数应用程序兼容，其余部分只需要最少的重写。也就是说，有些应用程序需要重写，要么是因为它们使用了类型 3 ZK-EVM 删除的预编译，要么是因为对边缘情况的微妙依赖，而这些边缘情况是由 EVM 以不同的方式处理的。
构建者是谁？
Scroll 和 Polygon 目前形式都是类型 3，尽管随着时间的推移，他们有望改善兼容性。Polygon 有一个独特的设计，他们用 ZK 验证自己的内部语言 zkASM，并使用 zkASM 实现解释 ZK-EVM 代码。尽管有这样的实现细节，我仍然将其称为真正的 Type3ZK-EVM；它仍然可以验证 EVM 代码，只是使用了一些不同的内部逻辑来完成。
今天，没有 ZK-EVM 团队想要成为类型 3；类型 3 只是一个过渡阶段，直到添加预编译的复杂工作完成，项目可以转移到类型 2.5。然而，在未来，类型 1 或类型 2 ZK-EVM 可能会自愿成为类型 3 ZK-EVM，方法是添加新的 ZK-SNARK 友好预编译器，为开发人员提供低验证时间和 gas 费用成本的功能。
类型 4 (相当于高级语言)
类型 4 系统的工作方式是采用用高级语言编写的智能合同源代码 (例如，SOLIDITY、VYPER 或某种两者都编译为的中间语言)，并将其编译成某种明确设计为 ZK-snark 友好的语言。
优点:验证时间非常快
通过不使用 ZK 来证明每个 EVM 执行步骤的所有不同部分，并直接从更高级别的代码开始，可以避免很多开销。
我在这篇文章中只用一句话描述了这一优点 (与下面与兼容性相关的缺点的大项目符号列表相比)，但这不应被解释为价值判断！直接从高级语言编译确实可以极大地降低成本，并通过使其更容易成为证明者来帮助分散。
缺点：更多的不兼容
一个用 Vyper 或 Solidity 编写的「正常」应用程序可以被编译下来，它会「正常工作」，但有一些重要的方面，很多应用程序不是「正常工作」的:
合约在类型 4 系统中的地址可能不同于它们在 EVM 中的地址，因为 CREATE2 协定地址取决于确切的字节码。这打破了依赖于尚未部署的「反事实合同」、ERC-4337 钱包、EIP-2470 单例和许多其他应用程序的应用程序。
手写的 EVM 字节码更难使用。为了提高效率，许多应用程序在某些部分使用手写 EVM 字节码。类型 4 系统可能不支持它，尽管有一些方法可以实现有限的 EVM 字节码支持来满足这些用例，而不需要努力成为一个完整的 Type3ZK-EVM。
许多调试基础设施不能继续，因为这些基础设施运行在 EVM 字节码上。也就是说，通过更多地从「传统」高级或中间语言访问调试基础设施，这一缺点得到了缓解 (例如，LLVM)。
开发人员应该注意这些问题。
构建者是谁？
ZKSync 是一个类型 4 的系统，尽管随着时间的推移，它可能会增加对 EVM 字节码的兼容性。NetherMind 的 Warp 项目正在构建一个从 Solidity 到 Starkware 的 Cairo 编译器，这将把 StarkNet 变成事实上的类型 4 系统。
ZK-EVM 类型的未来
这些类型并不是明确地比其他类型「更好」或「更差」。相反，它们在权衡空间上是不同的点：编码难度较低的类型与现有基础设施更兼容，但速度较慢；编码难度较高的类型与现有基础设施不太兼容，但速度更快。总体而言，所有这些类型的人都在探索，这对这个领域是健康的。
1.ZK-EVM 可以从类型 3 开始，决定不包括一些特别难 ZK-证明的功能。稍后，他们可以随着时间的推移添加这些功能，并转移到类型 2。
2.ZK-EVM 可以从类型 2 开始，然后通过提供在全以太兼容模式下运行或使用可以更快证明的经修改的状态树的可能性而变成混合型 2/类型 1 ZK-EVM。Sroll 正在考虑朝这个方向发展。
从类型 4 开始的系统可能会随着时间的推移而变成类型 3，因为后来添加了处理 EVM 代码的能力 (尽管仍鼓励开发人员直接从高级语言编译，以减少费用和验证时间)。
如果 Etherum 本身采用其修改以努力变得对 ZK 更友好，则类型 2 或类型 3 ZK-EVM 可以成为类型 1 ZK-EVM。
类型 1 或类型 2 的 ZK-EVM 可以通过添加预编译器来验证 ZK-SNARK 友好语言中的代码，从而成为类型 3 ZK-EVM。这将让开发人员在以太兼容性和速度之间做出选择，这将是类型 3，因为它打破了完美 EVM 的同等性，但从实际目的和目的来看，它将具有类型 1 和类型 2 的许多好处。主要缺点可能是一些开发人员工具不理解 ZK-EVM 的定制预编译，尽管这是可以修复的：开发人员工具可以通过支持包括预编译的 EVM 代码等价实现的配置格式来添加通用预编译支持。
就我个人而言，我希望随着时间的推移，所有的东西都会变成类型 1，通过改进 ZK-EVM 和改进以太坊本身来使其更适合 ZK-Snark。在这样的未来，我们将有多个 ZK-EVM 实现，既可以用于 ZK 汇总，也可以用于验证以太链本身。从理论上讲，以太坊没有必要为 L1 使用的单个 ZK-EVM 实现进行标准化；不同的客户端可以使用不同的证明，因此我们继续受益于代码冗余。
然而，我们需要相当长的时间才能达到这样的未来。与此同时，我们将在扩展以太坊和基于以太坊的 ZK-汇总的不同途径上看到许多创新。
原文标题：《The different types of ZK-EVMs》 原文来源：Vitalik Buterin 个人主页 原文作者：Vitalik Buterin 原文编译：Block unicorn
最近有许多「ZK-EVM」项目高调发布公告。Polygon 开放了他们的 ZK-EVM 项目，ZKSync 发布了他们的 ZKSync 2.0 计划，相对较新的 Scroll 最近也发布了他们的 ZK-EVM。还有来自隐私和拓展探索的团队、Nicolas Liochon 等人的团队的持续努力，从 EVM 到 Starkware 的 zk 友好语言 Cairo 的 alpha 编译器，当然有一些项目我会错过。
所有这些项目的核心目标都是相同的：使用 ZK-SNARK 技术来对类似以太坊的交易执行进行加密证明，要么让验证以太坊链本身变得更容易，要么构建与以太坊提供的内容 (接近) 相同但可扩展性更强的 zk rollup。但这些项目之间存在着微妙的差异，以及它们在实用性和速度之间的权衡。这篇文章将尝试描述 EVM 等价性的不同「类型」的分类，以及尝试实现每种类型的好处和成本。
概述 (图表形式)
类型 1（完全等效于以太坊）
类型 1 ZK - EVM 力求完全和毫不妥协的等效于以太坊。它们不改变以太坊系统的任何部分，以使生成证明更容易。它们不会取代哈希、状态树、事务树、预编译或任何其他共识逻辑，无论它有多么外围。
优势:完美的兼容性
我们的目标是能够像现在一样验证以太坊区块，或者至少验证执行层 (因此，信标链共识逻辑不包括在内，但包括所有的交易执行和智能合约和账户逻辑)。
类型 1 ZK-EVM 是我们最终需要的，使以太网第 1 层本身更具可扩展性。从长远来看，在类型 2 或类型 3 ZK-EVM 中测试出的对以太的修改可能会被引入到以太本身，但这样的重新设计伴随着它自己的复杂性。
类型 1 ZK-EVM 也是汇总的理想选择，因为它们允许汇总重复使用大量基础设施。例如，Etherum Execution 客户端可以按原样使用来生成和处理 ROLLUP 块 (或者至少，一旦实现提取，它们就可以被重新使用，并且该功能可以被重用以支持存放到 ROLLUP 中的 ETH)，因此块资源管理器、块生产等工具非常容易重用。
劣势: 验证时间
以太坊最初并不是围绕 zk 友好性设计的，所以以太坊协议的许多部分需要进行大量的计算来验证 zk。类型 1 的目标是完全复制以太坊，所以它没有办法缓解这些低效率。目前，以太坊区块的证明需要许多小时来产生。这种情况可以通过巧妙的工程来大规模并行化验证器，或者从长远来看，可以通过 ZK-SNARK 专用集成电路来缓解。
构建者是谁?
隐私和扩展探索团队 ZK-EVM 正在构建类型 1 ZK-EVM。
类型 2 (完全等效 EVM)
类型 2 ZK - EVM 力求完全等价于 EVM，但不完全等价于以太坊。也就是说，它们「从内部」看起来完全像以太坊，但它们在外部有一些不同，特别是在数据结构上，如块结构和状态树。
其目标是与现有应用程序完全兼容，但对以太坊进行一些小的修改，以使开发更容易，并更快地生成证明。
优势：在虚拟机级实现完全对等
类型 2 ZK-EVM 对保存以太状态等内容的数据结构进行更改。幸运的是，这些结构是 EVM 本身不能直接访问的，因此在 Etherum 上工作的应用程序几乎总是在类型 2 ZK-EVM 汇总上工作。您将不能按原样使用 Etherum Execution 客户端，但您可以通过一些修改使用它们，并且您仍然可以使用 EVM 调试工具和大多数其他开发人员基础设施。
但也有少数例外。对于验证历史以太块的 Merkle 证明以验证关于历史交易、收据或状态的声明的应用程序，出现了一种不兼容性 (例如，桥梁有时会这样做)。用不同的散列函数取代 Keccak 的 ZK-EVM 将打破这些证明。然而，我通常建议不要以这种方式构建应用程序，因为未来的以太更改 (例如。Verkle Trees) 甚至在以太本身上也会破坏这样的应用。对以太坊本身来说，一个更好的替代方案是添加未来可靠的历史访问预编译。
缺点：改进了验证时间，但仍然很慢
类型 2 ZK-EVM 提供比类型 1 更快的验证时间，主要是通过移除依赖于不必要的复杂和不友好的 ZK 加密的以太堆栈的部分。特别是，它们可能会改变 Etherum 的 Keccak 和基于 RLP 的 Merkle Patricia 树，可能还会改变区块和接收结构。类型 2 ZK-EVM 可能会使用不同的哈希函数，例如，Poseidon。另一个自然的修改是修改状态树以存储代码散列和 keccak，从而不再需要验证散列来处理 EXTCODEHASH 和 EXTCODECOPY 操作码。
这些修改显著提高了验证时间，但它们不能解决所有问题。由于 EVM 固有的低效性和对 zk 的不友好性，证明 EVM 原样的过程仍然很缓慢。一个简单的例子是内存:因为 MLOAD 可以读取任何 32 字节，包括「未对齐」的块 (其中开始和结束不是 32 的倍数)，MLOAD 不能简单地解释为读取一个块;相反，它可能需要读取两个连续的块，并执行位操作来合并结果。
构建者是谁？
Scroll 的 ZK-EVM 项目正朝着 2 型 ZK-EVM 的方向发展，正如 Polygon Hermez 一样。也就是说，这两个项目都还没有完成（没有完成 ZKEVM 工作）;特别是，许多更复杂的预编译还没有实现。因此，目前两个项目都最好考虑类型 3。
2.5 类型 (与 evm 相当，不包括 gas 费用)
显著改善最坏情况验证时间的一种方法是大幅增加 EVM 中很难证明的特定操作的费用成本。这可能涉及预编译、KECCAK 操作码，还可能涉及调用约定或访问内存、存储或恢复的特定模式。
不断变化的 gas 费用成本可能会降低开发人员工具的兼容性，并破坏了一些应用程序，但通常认为这比「更深层次的」EVM 更改风险更小。开发人员应该注意，在交易中需要的 gas 费用不要超过区块的容量，不要使用硬编码的 gas 费用数量进行调用 (这已经是很长时间以来对开发人员的标准建议)。
类型 3 (几乎等同于 EVM)
第 3 型 zk -EVM 几乎同等于 EVM，但为了实现完全相同，需要做出一些牺牲，以进一步提高验证时间并使 EVM 更容易开发。
优点：更容易构建，验证时间更快
类型 3 ZK-EVM 可能会删除一些在 ZK-EVM 实现中特别难实现的功能。在这里，预编译通常位于列表的顶部；此外，类型 3 ZK-EVM 在处理合约代码、内存或堆栈的方式上有时也有细微的差异。
缺点：更多的不兼容
类型 3 ZK-EVM 的目标是与大多数应用程序兼容，其余部分只需要最少的重写。也就是说，有些应用程序需要重写，要么是因为它们使用了类型 3 ZK-EVM 删除的预编译，要么是因为对边缘情况的微妙依赖，而这些边缘情况是由 EVM 以不同的方式处理的。
构建者是谁？
Scroll 和 Polygon 目前形式都是类型 3，尽管随着时间的推移，他们有望改善兼容性。Polygon 有一个独特的设计，他们用 ZK 验证自己的内部语言 zkASM，并使用 zkASM 实现解释 ZK-EVM 代码。尽管有这样的实现细节，我仍然将其称为真正的 Type3ZK-EVM；它仍然可以验证 EVM 代码，只是使用了一些不同的内部逻辑来完成。
今天，没有 ZK-EVM 团队想要成为类型 3；类型 3 只是一个过渡阶段，直到添加预编译的复杂工作完成，项目可以转移到类型 2.5。然而，在未来，类型 1 或类型 2 ZK-EVM 可能会自愿成为类型 3 ZK-EVM，方法是添加新的 ZK-SNARK 友好预编译器，为开发人员提供低验证时间和 gas 费用成本的功能。
类型 4 (相当于高级语言)
类型 4 系统的工作方式是采用用高级语言编写的智能合同源代码 (例如，SOLIDITY、VYPER 或某种两者都编译为的中间语言)，并将其编译成某种明确设计为 ZK-snark 友好的语言。
优点:验证时间非常快
通过不使用 ZK 来证明每个 EVM 执行步骤的所有不同部分，并直接从更高级别的代码开始，可以避免很多开销。
我在这篇文章中只用一句话描述了这一优点 (与下面与兼容性相关的缺点的大项目符号列表相比)，但这不应被解释为价值判断！直接从高级语言编译确实可以极大地降低成本，并通过使其更容易成为证明者来帮助分散。
缺点：更多的不兼容
一个用 Vyper 或 Solidity 编写的「正常」应用程序可以被编译下来，它会「正常工作」，但有一些重要的方面，很多应用程序不是「正常工作」的:
合约在类型 4 系统中的地址可能不同于它们在 EVM 中的地址，因为 CREATE2 协定地址取决于确切的字节码。这打破了依赖于尚未部署的「反事实合同」、ERC-4337 钱包、EIP-2470 单例和许多其他应用程序的应用程序。
手写的 EVM 字节码更难使用。为了提高效率，许多应用程序在某些部分使用手写 EVM 字节码。类型 4 系统可能不支持它，尽管有一些方法可以实现有限的 EVM 字节码支持来满足这些用例，而不需要努力成为一个完整的 Type3ZK-EVM。
许多调试基础设施不能继续，因为这些基础设施运行在 EVM 字节码上。也就是说，通过更多地从「传统」高级或中间语言访问调试基础设施，这一缺点得到了缓解 (例如，LLVM)。
开发人员应该注意这些问题。
构建者是谁？
ZKSync 是一个类型 4 的系统，尽管随着时间的推移，它可能会增加对 EVM 字节码的兼容性。NetherMind 的 Warp 项目正在构建一个从 Solidity 到 Starkware 的 Cairo 编译器，这将把 StarkNet 变成事实上的类型 4 系统。
ZK-EVM 类型的未来
这些类型并不是明确地比其他类型「更好」或「更差」。相反，它们在权衡空间上是不同的点：编码难度较低的类型与现有基础设施更兼容，但速度较慢；编码难度较高的类型与现有基础设施不太兼容，但速度更快。总体而言，所有这些类型的人都在探索，这对这个领域是健康的。
1.ZK-EVM 可以从类型 3 开始，决定不包括一些特别难 ZK-证明的功能。稍后，他们可以随着时间的推移添加这些功能，并转移到类型 2。
2.ZK-EVM 可以从类型 2 开始，然后通过提供在全以太兼容模式下运行或使用可以更快证明的经修改的状态树的可能性而变成混合型 2/类型 1 ZK-EVM。Sroll 正在考虑朝这个方向发展。
从类型 4 开始的系统可能会随着时间的推移而变成类型 3，因为后来添加了处理 EVM 代码的能力 (尽管仍鼓励开发人员直接从高级语言编译，以减少费用和验证时间)。
如果 Etherum 本身采用其修改以努力变得对 ZK 更友好，则类型 2 或类型 3 ZK-EVM 可以成为类型 1 ZK-EVM。
类型 1 或类型 2 的 ZK-EVM 可以通过添加预编译器来验证 ZK-SNARK 友好语言中的代码，从而成为类型 3 ZK-EVM。这将让开发人员在以太兼容性和速度之间做出选择，这将是类型 3，因为它打破了完美 EVM 的同等性，但从实际目的和目的来看，它将具有类型 1 和类型 2 的许多好处。主要缺点可能是一些开发人员工具不理解 ZK-EVM 的定制预编译，尽管这是可以修复的：开发人员工具可以通过支持包括预编译的 EVM 代码等价实现的配置格式来添加通用预编译支持。
就我个人而言，我希望随着时间的推移，所有的东西都会变成类型 1，通过改进 ZK-EVM 和改进以太坊本身来使其更适合 ZK-Snark。在这样的未来，我们将有多个 ZK-EVM 实现，既可以用于 ZK 汇总，也可以用于验证以太链本身。从理论上讲，以太坊没有必要为 L1 使用的单个 ZK-EVM 实现进行标准化；不同的客户端可以使用不同的证明，因此我们继续受益于代码冗余。
然而，我们需要相当长的时间才能达到这样的未来。与此同时，我们将在扩展以太坊和基于以太坊的 ZK-汇总的不同途径上看到许多创新。
No comments yet