Vitalik：分别典型的 ZK-EVM

稀奇报答 PSE、Polygon Hermez、Zksync、Scroll、Matter Labs 以及 Starkware 团队的琢磨与校阅。

迩来，良多“ZK-EVM”项目很快相继发出通告。Polygon 开源了他们的 ZK-EVM 的项目，ZKSync 揭晓了 ZKSync 2.0 的讨论，而 Scroll 算作相对于的新人，迩来也发布了他们的 ZK-EVM 项目。还有 Privacy and Scaling Explorations（隐私以及扩容研究）团队、Nicolas Liochon et al 的团队，和 Nethermind 团队努力于将 EVM 的 Solidity 语言转译为 StarkWare 的 ZK 友爱语言 Cairo 的一个 Alpha 编译器，这些团队都正在为此不停尽力，固然，还有一些项目我没有例举进去。

这些项想法当中目的是统一的：运用 ZK-SNARK 本领对于以太坊类买卖的施行天生加密证实，没有是让证实更易于验证以太坊链自己，便是构建（凑近）异常于以太坊所供给的一些功能，但比它更拥有可扩充性的 ZK-rollups。但这些项目之间也有些轻微区分，并且他们正在有用性以及速率之间所做的衡量也有分裂。这篇文章将形容分歧 EVM 等效“类别”的分类学，和每品种型的劣势以及支出。

概览（图表大局）

类别 1：全面以太坊等效的 ZK-EVM

第一类 ZK-EVM 力争成为全面失当协的以太坊等效 ZK-EVM 。他们没有会退换以太坊系统的一切全体来让它更轻易天生证实：没有会更换哈希、状态树、买卖树、预编译或是共鸣中的其他逻辑，没有管这些全体何等次要。

劣势：完善的兼容性

ZK-EVM 的目的正在于，恐怕像今朝以太坊验证区块那样 —— 大概至多，验证施行层下面的区块（所以，虽然信标链的共鸣逻辑没有包罗出去，不过一切施行的买卖、智能合约以及账户逻辑都蕴含正在内）。

第一类的 ZK-EVM 正是咱们最终所须要的，能让以太坊 L1 自己更拥有可扩充性。永恒来看，正在第二类以及第三类的 ZK-EVM 中考察得出的对于以太坊的改动，大概会被正当引入至以太坊上，不过这种从新架构自己拥有繁复性。

第一类 ZK-EVM 对于 Rollup 来讲也是巴望的，由于它们让 Rollup 也许反复运用根底办法。例如，以太坊施行层客户端也许像原本那样天生以及处置 Rollup 的区块（至多，一旦完结支款功能，它们也许从新利用该功能来支柱 ETH 存入 Rollup），因而区块欣赏器、区块天生等器械也许轻便从新利用。

劣势：证实天生时光慢

以太坊底本的妄图并没有是 ZK 友爱的，所以，以太坊协议中的许多全体都须要破费大度的算计来天生 ZK 证实。第一类 ZK-EVM 旨正在全面复制以太坊的境况，所以，它没法减缓这些算计低效性课题。今朝，以太坊区块证实须要破费多个小时才华天生。这也许经过精巧的工程（如大领域并行天生证实），或从深化来看，经过 ZK-SNARK ASIC 来减缓低效性课题。

谁正在构建第一类 ZK-EVM？

Privacy and Scaling Explorations 团队在尽力构建第一类 ZK-EVM。

类别 2：全面 EVM 等效的 ZK-EVM

第二类 ZK-EVM 力图成为全面 EVM 等效但也没有那么以太坊等效的 ZK-EVM。也便是说，“从内部来看”，他们全面就像以太坊一律，不过正在外部与以太坊有一些区分，尤为是区块组织以及状态树等数据组织。

它的目的正在于，与现有的利用全面兼容，但它会对于以太坊做一些较小的改动，闪开发更轻易，也让证实天生得更快。

劣势：正在假造机层面全面等效

第二类 ZK-EVM 会改革保存着如以太坊状态的数据组织。运气的是，由于 EVM 自己就没有能直接拜候这些数据组织，因而对于底本正在以太坊上运行的利用法式没甚么作用，它们仍能正在第二类的 ZK-EVM rollup 上运行。你大概没法像原本那样利用以太坊施行层客户端，但你也许经过一些改动来利用客户端，并且仍然能利用 EVM 调试器械以及大全体其他开垦者根底办法。

还生存小量例外状况。当验证以太坊史乘区块的默克尔树证实来验证史乘买卖、收条或状态的证实（例如，桥接有时分也会这么做）时，利用法式呈现了没有兼容。假设 ZK-EVM 用分歧的哈希函数来更换 Keccak，那就会摧毁这些证实。而且，我时常提议没有要这样构建利用法式，由于他日的以太坊更新（如 Verkle tree）以至会作用以太坊上的利用。更好的挑选是以太坊自身推广没有会过时的 (future-proof) 史乘拜候预编译。

劣势：一经革新过了但依然证实时光太慢

第二类 ZK-EVM 能比第一类供给更快的证实天生时光，它主要经过移除全体以太坊客栈，这全体客栈依附于拥有没有须要繁复性以及 ZK 没有友爱的加密学。稀奇是，这些客栈大概会退换以太坊的 Keccak 以及基于 RPL 的 Merkle patricia tree，只怕还会退换区块以及收条组织。第二类 ZK-EVM 则是会利用分歧的哈希函数，如 Poseidon。当然而然地，它会改动状态树以储藏哈希码以及 Keccak，没有须要验证哈希以处置 EXTCODEHASH 以及 EXTCODECOPY 操作码。

这些改动极小地改善了证实天生的时光，但它们没有束缚一切课题。这类 ZK-EVM 承继了 EVM 自己带来的低效性以及 ZK 没有友爱课题，因而像底本那样基于 EVM 天生证实的低效状况照旧币安官网入口生存。内存便是最简捷的例子：由于 MLOAD 也许读取一切 32 字节，席卷“无序的”代码段（其初步以及末尾都没有是 32 的倍数）， MLOAD 也没有能单纯领会为对于一段代码的读取；确凿地说，它大概须要读取两个陆续的代码段以及施行位操作来贯串运行了局。

谁正在构建第二类 ZK-EVM？

Scroll 的 ZK-EVM 项目在构建第二类 ZK-EVM，Polygon Hermez 也是。即使如许，还没有项目真的成为第二类 ZK-EVM；尤为是良多尤其繁复的预编译还没完结。因而，今朝来讲，这两个项目应该说属于第三类 ZK-EVM。

类别 2.5：EVM 等效，除了 gas 支出

正在最糟了的状况下，有一种恐怕极小地改善证实天生时光慢的办法是，大大进步那些难以正在 EVM 中天生 ZK 证实的施行所花的 gas 支出。这些施行大概触及预编译、KECCAK 操作码，还大概触及挪用合约的一定模式、拜候内存/保存或是回滚。

退换 gas 支出大概会升高开垦者器械的兼容性，摧毁一些利用，但总体上，它的告急比“更深切地”变化 EVM 来讲更少。开垦者须要留神，没有要消费超越一个区块所包容的 gas 下限，也永久都没有要用硬编码 gas 数来施行挪用（这一经是永恒以后对于开垦者的规范提议了）。

另一种办理资源限制的办法是，只有对于每个操作能被挪用的次数设定硬限制就好了。这正在电路中的完结很简捷，不过对于 EVM 的安全假定就没有太好了。我更承诺将这种方式称作第三类 ZK-EVM，而没有是类别 2.5。

类别 3：多少乎是 EVM 等效的

第三类 ZK-EVM 多少乎是 EVM 等效的，但须要对于全面等效性做一些埋葬，以进一步改善证实天生时光，并匆匆进 EVM 更易于开垦。

劣势：易于构建，证实天生时光更快

第三类 ZK-EVM 只怕会取缔一些特殊难以正在 ZK-EVM 完结中完结的功能。预编译常常会是这类功能中最难完结的；其余，这类 ZK-EVM 有时也正在处置合约代码、内存以及客栈方面有些许分歧。

劣势：兼容性更差

第三类 ZK-EVM 的目的是与大全体利用法式兼容，它只须要对于剩下的利用施行少少的改写。即使是这样，也须要对于一些利用施行改写，由于这些利用会利用第三类 ZK-EVM 一经取缔的预编译，或是由于它们对于边缘状况有着奥秘依附性，而 VM 会以分歧的办法处置。

谁来构建第三类 ZK-EVM？

Scroll 以及 Polygon 而今的大局都属于第三类 ZK-EVM，即使他们瞻望会随着时光改善兼容性。Polygon 的妄图很特殊，他们用着自身的内部语言 zkASM 验证 ZK，并且他们会利用 zkASM 的完结来转译 ZK-EVM 代码。虽然本来现细节是这样的，但我依然承诺把它称为真正的第三类 ZK-EVM。它仍然恐怕验证 EVM 代码，仅仅用着一些分歧的内部逻辑而已。

而今，还没有 ZK-EVM 团队想要成为第三类 ZK-EVM；该类别仅仅是告竣预编译推广这一繁复处事以及项目恐怕转为类别 2.5 以前的过渡阶段。然而，经过推广新的 ZK-SNARK 友爱的预编译，为开垦者供给证实天生时光短、gas 支出低的功能，第一类以及第二类 ZK-EVM 正在币安官网登录他日大概会自觉成为第三类 ZK-EVM。

类别 4：高等语言（high-level-language）等效

第四类 ZK-EVM 系统的处事原理是，选择高等语言编写智能合约源码（如 Solidity、Vyper，或一些由二者编译而成的中间语言（intermediate）），并将这些源码编译为一些清爽妄图成 ZK-SNARK 友爱的其他语言。

劣势：极快的证实天生时光

没有将 EVM 的每个施行方法的一切关节天生 ZK 证实，而是直接结束证实高等语言编写的代码，这样你也许避免失落良多支出。

正在本文，虽然我只用了一句话来形容这种劣势（对于比以下兼容性相干的劣势重点列表来讲），但这句话没有应该被解读为价值判别！从高等语言直接编译真的也许极小地削减支出，并经过让证实历程变得轻易而驱策去焦点化。

劣势：兼容性更差

一个用 Vyper 或 Solidity 编写的“一般”利用法式恐怕被编译进去，并且它“也许运行”，但正在良多主要状况下，良多利用会变得没有“一般”：

第四类 ZK-EVM 的系统中的合约地方与 EVM 中的大概没有一律，由于 CREATE2 合约地方取决于全部的字节码。这损坏了依附于尚未摆设的“反真相合约”的利用、ERC-4337 钱包、EIP-2470 单例以及许多其他利用法式。

手动编写的 EVM 字节码更难参预利用。良多利用法式为了效用，会利用手动编写全体 EVM 字节码。即使有良多种办法也许完结对于这类有限制的 EVM 字节码的支柱，也许正在无需全面成为第三类 ZK-EVM 的状况下将这些用例利用起来，但第四类 ZK-EVM 的系统大概没有会支柱这种手动编写的字节码。

良多调试根底办法没法连续存在，由于这种根底办法都基于 EVM 字节码运行。即使如许，但咱们也许经过“传统”高等语言或中间语言更轻便地拜候调试根底办法，以加重这种劣势（例如 LLVM）。

开垦者应该留心这些课题。

谁正在构建第四类 ZK-EVM？

ZKSync 系统便是第四类 ZK-EVM，虽然它大概会随着时光进步 EVM 字节码的兼容性。Nethermind 的 Warp 项目在构建从 Solidity 语言转译为 StarkWare Cairo 语言的编译器，这个编译器将会把 StarkNet 变为真正的第四类 ZK-EVM 系统。

各个 ZK-EVM 类别的他日

并没有是说这些类别比其余类别“更好”或“更差”。相反，相较之下他们各有分歧：从类别 1 至类别 4，编号较低的 ZK-EVM 类别以及现有的根底办法尤其兼容，但运行得更慢；而编号较高的 ZK-EVM 类别则以及现有的根底办法没有那么兼容，但运行得更快。总之，对于一切 ZK-EVM 类别的研究有益于该范畴的强健繁华。

其它，ZK-EVM 项目也许随着时光的推移，轻便地从编号高的 ZK-EVM 结束，然后转为编号低的类别（反之亦然）。比如：

ZK-EVM 也许正在一结束算作第三类 ZK-EVM 参预利用，没有去参加一些稀奇难以天生 ZK 证实的功能。之后，他们也许随着时光的推移而参加那些功能，既而变化为第二类。

一结束算作第二类型的 ZK-EVM，经过正在全面兼容以太坊的模式下运行，或利用正在改动后能更快天生证实的状态树，这类 ZK-EVM 也许正在之后变为第二类以及第一类 ZK-EVM 的混杂类别。Scroll 就在思虑向这个方向繁华。

一些一结束属于第四类系统的 ZK-EVM 项目，也许经过之后推广 EVM 代码处置的功能，既而随着时光变为第三类 ZK-EVM（即使开垦币安登录地址者依然会被激动直接从高等语言编译，以此削减用度以及证实天生的时光）。

假设以太坊自身为了变得尤其 ZK 友爱而选择一些改动，那么第二类以及第三类也许成为第一类 ZK-EVM。

第一类或第二类 ZK-EVM 也许经过推广验证 ZK-SNARK 友爱语言代码的预编译，变为第三类 ZK-EVM。这为开垦者正在以太坊兼容性以及运行速率之间供给了一个挑选。这也许算是第三类 ZK-EVM，由于它会损坏完善的 EVM 等效，但出于理论计划以及想法，它大概还会拥有良多第一类以及第二类 ZK-EVM 的劣势。它没有好的地点大概是，一些开垦者器械没法领会 ZK-EVM 的自编译，虽然这点也也许建设：开垦者器械也许经过支柱席卷 EVM 代码等效的预编译完结正在内的配置花样，以此推广通用的预编译支柱。

就集体而言，经过贯串 ZK-EVM 中的革新与让以太坊变得尤其 ZK-SNARK 友爱的革新，我指望这些项目全数徐徐变为第一类 ZK-EVM。正在这样的他日里，咱们也会有多种 ZK-EVM 完结，也许用于 ZK rollup，也能用来验证以太坊链自己。外貌上，以太坊没有须要规范化单个 ZK-EVM 的完结来供 L1 利用；分歧客户端也许利用分歧的证实，咱们才华连续从代码冗余中获益。

没有论若何，咱们还须要一些时光来迎接这种他日。同时，咱们也会正在扩容以太坊以及开垦基于以太坊 ZK rollup 的分歧赛道上看到大度改革。