Vitalik详解5种类型的ZK-EVM

最近有许多“ZK-EVM”项目发布了公告。Polygon开源了他们的ZK-EVM项目，发布了他们的ZKSync 2.0 计划，相对较新的Scroll最近也宣布了他们的ZK-EVM。Privacy and Scaling Explorations团队、Nicolas Liochon等人的团队也在不断努力，从EVM到Starkware的ZK友好语言Cairo的alpha编译器，当然还有一些我不知道

所有这些项目的核心目标都是相同的：使用ZK-SNARK技术来制作类似以太坊交易执行的加密证明，或者更容易验证以太坊链本身，或者构建 （接近）相当于以太坊提供的，但更具可扩展性的ZK-rollup。但是这些项目之间存在细微的差异，以及它们在实用性和速度之间做出的权衡

这篇文章将尝试分类不同“类型”ZK-EVM的EVM等效性，以及尝试实现每种类型的好处和成本

（完全等效于以太坊）

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

优点：完美兼容

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

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

1型ZK-EVM也是Rollup的理想选择，因为它们允许Rollup重用大量基础架构。例如，以太坊执行客户端可以按原样使用来生成和处理rollup区块（或者至少，它们可以在实现提款后使用，并且可以重新使用该功能来支持将存入rollup中），因此工具例如区块浏览器、区块生产等非常容易重用

缺点：证明时间

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

谁在建造它？

Privacy and Scaling Explorations团队ZK -EVM正在构建1型ZK-EVM。

类型2（完全等效于 EVM）

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

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

优点：VM级别的完美等效

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

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

缺点：改进但仍然很慢证明时间

2型ZK-EVM提供比1型更快的证明时间，主要是通过删除依赖于不必要的复杂和ZK不友好密码学部分的以太坊堆栈。特别是，他们可能会改变以太坊的Keccak和基于RLP的Merkle Patricia 树，可能还会改变区块和收据结构。2型ZK-EVM可能会使用不同的哈希函数，

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

谁在建造它？

Scroll的ZK-EVM项目正朝着Type 2 ZK-EVM方向发展，Polygon Hermez也是如此。也就是说，这两个项目都还没有完成。特别是，许多更复杂的预编译还没有实现。因此，目前这两个项目都被更好地考虑为Type 3

谁在建造它？

Scroll和Polygon在其当前形式中都是3型ZK-EVM，尽管它们有望随着时间的推移提高兼容性。Polygon有一个独特的设计，他们正在ZK验证他们自己的称为zkASM的内部语言，并且他们使用zkASM实现来解释ZK-EVM代码。尽管有这个实现细节，但我仍将其称为真正的Type 3 ZK-EVM；它仍然可以验证EVM代码，它只是使用一些不同的内部逻辑来完成它

ZK-EVM类型的未来

一些类型并不比其他类型明确地“更好”或“更差”。相反，它们权衡空间上的不同点：编号较小的类型与现有基础架构的兼容性更高，但速度较慢，编号较高的类型与现有基础架构的兼容性较差，但速度更快。一般来说，探索所有这些类型的空间是健康的

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

ZK-EVM可以从类型3开始，决定不包含一些特别难以ZK证明的功能。之后，他们可以随着时间的推移添加这些功能，并转向类型2

ZK-EVM可以从类型2开始，后来成为混合类型2/类型1的ZK-EVM，通过提供在完全以太坊兼容模式下运行的可能性或使用可以更快证明的修改状态树的可能性。Scroll正在考虑朝这个方向发展

通过添加处理EVM代码的能力，从类型4开始的系统可能会随着时间的推移变成类型3（尽管仍然鼓励开发人员直接从高级语言编译以减少费用和验证时间）

如果以太坊本身采用其修改以变得更加ZK友好，那么类型2或类型3ZK-EVM可以成为类型1 ZK-EVM

1型或2型ZK-EVM可以通过添加预编译来验证ZK-SNARK友好语言中的代码，从而成为3型 ZK-EVM。这将使开发人员在以太坊兼容性和速度之间做出选择。这将是类型3，因为它打破了完美的EVM等效性，但出于实际目的和目的，它将具有类型1和2的很多好处。主要缺点可能是某些开发人员工具无法理解ZK-EVM的自定义预编译，尽管这可以修复：开发人员工具可以通过支持包含预编译的EVM代码等效实现的配置格式来添加通用预编译支持

就我个人而言，我希望随着时间的推移，通过ZK-EVM的改进和以太坊本身的改进相结合，使其对ZK-SNARK更加友好，一切都将成为 类型1。在这样的未来，我们将有多个ZK-EVM实现，它们既可用于ZK Rollup，也可用于验证以太坊链本身。

从理论上讲，以太坊不需要为L1 使用单一的ZK-EVM实现进行标准化；不同的客户端可以使用不同的证明，因此我们继续从代码冗余中受益。

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

在加密行业你想抓住下一波牛市机会你得有一个优质圈子，大家就能抱团取暖，保持洞察力。如果只是你一个人，四顾茫然，发现一个人都没有，想在这个行业里面坚持下来其实是很难的。

想抱团取暖，或者有疑惑的，欢迎加入我们——所有资讯平台均为：Crypto悟饭

感谢阅读，喜欢的朋友可以点个赞关注哦，我们下期再见！