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

最近有很多“ZK-EVM”项目发布了华而不实的公告。Polygon开源了他们的ZK-EVM项目,ZKSync发布了他们的ZKSync 2.0计划,相对较新的Scroll最近宣布了他们的ZK-EVM。隐私和扩展探索团队Nicolas Liochon等人的团队,从EVM到Starkware的ZK友好语言Cairoalpha编译器,当然还有至少我错过的其他一些。

所有这些项目的核心目标是相同的:使用ZK-SNARK技术来制作执行类似以太坊交易的加密证明,要么使验证以太坊链本身变得更加容易,要么构建ZK汇总,这些ZK汇总(接近)等同于以太坊提供的功能,但更具可扩展性。但是这些项目之间存在细微的区别,以及它们在实用性和速度之间做出的权衡。这篇文章将尝试描述不同“类型”的EVM等价分类,以及尝试实现每种类型的好处和成本是什么。

概述(图表形式)

类型 1(完全等效于以太坊)

类型 1 ZK-EVM 努力做到完全且毫不妥协地等同于以太坊。它们不会更改以太坊系统的任何部分,以使其更容易生成证明。它们不会替换哈希、状态树、事务树、预编译或任何其他共识逻辑,无论外围如何。

优点:完美兼容性

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

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

类型 1 ZK-EVM 也是汇总的理想选择,因为它们允许汇总重用大量基础架构。例如,以太坊执行客户端可以按原样用于生成和处理汇总块(或者至少,一旦实现提款,并且该功能可以重用于支持将 ETH 存入汇总),因此块浏览器、块生产等工具非常容易重用。

缺点:证明时间

以太坊最初并不是围绕 ZK 友好性设计的,因此以太坊协议的许多部分需要大量的计算来证明 ZK。类型 1 旨在完全复制以太坊,因此它无法减轻这些低效率。目前,以太坊区块的证明需要很多小时才能产生。这可以通过巧妙的工程来大规模并行化证明器,或者从长远来看,可以通过ZK-SNARK ASIC来缓解。

谁在建造它?

ZK-EVM 社区版(由社区贡献者引导,包括隐私和扩展探索、Scroll 团队、Taiko 等)是第 1 层 ZK-EVM。

类型 2(完全等效于 EVM)

类型 2 ZK-EVM 力求与 EVM 完全等效,但不完全等同于以太坊。也就是说,它们“从内部”看起来与以太坊一模一样,但它们在外部有一些差异,特别是在块结构和状态树等数据结构方面。

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

优势:虚拟机级别的完美等效性

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

有少数例外。对于验证历史以太坊区块的Merkle证明以验证有关历史交易,收据或状态的声明的应用程序(例如,桥有时会这样做)的应用程序会出现一个不兼容。用不同的哈希函数替换 Keccak 的 ZK-EVM 会破坏这些证明。但是,我通常建议无论如何都不要以这种方式构建应用程序,因为未来的以太坊会发生变化(例如。弗克尔树)即使在以太坊本身上也会破坏此类应用程序。更好的选择是以太坊本身添加面向未来的历史访问预编译

缺点:改进但仍然缓慢的证明时间

类型 2 ZK-EVM 提供比类型 1 更快的证明时间,主要是通过删除依赖于不必要的复杂和 ZK 不友好的加密的以太坊堆栈部分。特别是,他们可能会改变以太坊的Keccak和基于RLP的Merkle Patricia树,也许还会改变区块和收据结构。类型 2 ZK-EVM 可能会使用不同的哈希函数,例如。波塞冬。另一个自然修改是修改状态树以存储代码哈希和 keccak,无需验证哈希来处理 和 操作码。EXTCODEHASHEXTCODECOPY

这些修改显著缩短了证明时间,但它们并不能解决所有问题。必须按原样证明 EVM 的缓慢,以及 EVM 固有的所有低效率和 ZK 不友好,仍然存在。一个简单的例子是内存:因为 an 可以读取任何 32 个字节,包括“未对齐”的块(其中开始和结束不是 32 的倍数),所以 MLOAD 不能简单地解释为读取一个块;相反,它可能需要读取两个连续的块并执行位操作来组合结果。MLOAD

谁在建造它?

Scroll的ZK-EVM项目正在朝着Type 2 ZK-EVM的方向发展,Polygon Hermez也是如此。也就是说,这两个项目都还没有完全实现;特别是,许多更复杂的预编译尚未实现。因此,目前这两个项目都最好被认为是第3类

类型 2.5(EVM 当量,汽油成本除外)

显著缩短最坏情况证明时间的一种方法是大大增加 EVM 中难以证明的特定操作的气体成本。这可能涉及预编译、KECCAK 操作码,以及可能调用合约或访问内存、存储或还原的特定模式。

改变 gas 成本可能会降低开发人员工具的兼容性并破坏一些应用程序,但通常认为它比“更深入”的 EVM 更改风险更小。开发人员应该注意交易中不需要超过区块容量的gas,永远不要使用硬编码的gas量进行调用(这已经成为开发人员长期以来的标准建议)。

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

类型 3(几乎等效于 EVM)

类型 3 ZK-EVM 几乎等效于 EVM,但为了精确等效而做出一些牺牲,以进一步缩短证明时间并使 EVM 更易于开发。

优点:更易于构建,证明时间更快

类型 3 ZK-EVM 可能会删除一些在 ZK-EVM 实现中特别难以实现的功能。预编译通常位于此处列表的顶部;此外,Type 3 ZK-EVM 有时在处理合约代码、内存或堆栈的方式上也存在细微差异。

缺点:更不兼容

类型 3 ZK-EVM 的目标是与大多数应用程序兼容,并且只需要对其余应用程序进行最少的重写。也就是说,有些应用程序需要重写,因为它们使用Type 3 ZK-EVM删除的预编译,或者因为虚拟机处理不同的边缘情况的微妙依赖性。

谁在建造它?

滚动和多边形都是当前形式的类型 3,尽管随着时间的推移,它们有望提高兼容性。Polygon有一个独特的设计,他们用ZK验证自己的内部语言zkASM,并使用zkASM实现解释ZK-EVM代码。尽管有这些实现细节,我仍然称其为真正的 Type 3 ZK-EVM;它仍然可以验证 EVM 代码,它只是使用一些不同的内部逻辑来做到这一点。

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

类型 4(相当于高级语言)

类型 4 系统的工作原理是获取用高级语言编写的智能合约源代码(例如。SolidityVyper或一些都编译为的中间体),并将其编译为某种明确设计为ZK-SNARK友好的语言。

优点:证明时间非常快

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

在这篇文章中,我只用一句话来描述这个优势(与下面的兼容性相关缺点的大项目符号列表相比),但这不应该被解释为价值判断!直接从高级语言编译确实可以大大降低成本,并通过更容易成为证明者来帮助去中心化。

缺点:更不兼容

用 Vyper 或 Solidity 编写的“普通”应用程序可以编译下来,它会“正常工作”,但是有一些重要的方式,其中许多应用程序不是“正常的”:

  • 合约在类型 4 系统中的地址可能与在 EVM 中的地址不同,因为 CREATE2 合约地址取决于确切的字节码。这破坏了依赖于尚未部署的“反事实合约”、ERC-4337 钱包、EIP-2470 单例和许多其他应用程序的应用程序。
  • 手写 EVM 字节码更难使用。为了提高效率,许多应用程序在某些部分使用手写 EVM 字节码。类型 4 系统可能不支持它,尽管有一些方法可以实现有限的 EVM 字节码支持来满足这些用例,而无需努力成为全面的类型 3 ZK-EVM。
  • 许多调试基础结构无法转移,因为此类基础结构在 EVM 字节码上运行。也就是说,通过“传统”高级或中间语言(例如。LLVM)。

开发人员应注意这些问题。

谁在建造它?

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

ZK-EVM 类型的未来

这些类型并不比其他类型明确“更好”或“更差”。相反,它们是权衡空间上的不同点:编号较低的类型与现有基础结构更兼容,但速度较慢,编号较高的类型与现有基础结构的兼容性较低,但速度更快。总的来说,对于正在探索所有这些类型的空间来说,这是健康的。

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

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

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

然而,在我们达到这样的未来之前,还需要相当长的时间。与此同时,我们将在扩展以太坊和基于以太坊的ZK汇总的不同途径中看到许多创新。