最近有许多“ZK-EVM”项目高调发布公告,但并不是每一个项目的“等效性”都相同。这篇文章将测验描述EVM等价性的不同“类型”的分类,以及测验完结每种类型的长处和本钱。

V神:分析当前4种不同类型ZK-EVM的优缺点及未来展望

作者:VitalikButerin(V神)

转自:《V神:不同类型 ZK-EVM 的未来》by 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等价性的不同“类型”的分类,以及测验完结每种类型的长处和本钱。

概述(图表办法)

V神:分析当前4种不同类型ZK-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类型的未来

这些类型并不是明确地比其他类型“更好”或“更差”。相反,它们在权衡空间上是不同的点:编码难度较低的类型与现有基础设施更兼容,但速度较慢;编码难度较高的类型与现有基础设施不太兼容,但速度更快。总体而言,一切这些类型的人都在探究,这对这个范畴是健康的。

- ZK-EVM能够从类型3 开端,决定不包含一些特别难ZK-证明的功用。稍后,他们能够跟着时刻的推移增加这些功用,并转移到类型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-汇总的不同途径上看到许多立异。

作者:PA荐读

来源:panewslab

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注