最近有许多“ZK-EVM”项目发布他们的计划。Polygon开源了他们的ZK-EVM 项目，consensys开始了他们的zk-EVM的测试，ZKSync发布了他们的 ZKSync 2.0 计划，而相对较近的Scroll最近宣布了他们的 ZK-EVM。

所有这些项目的核心目标都是相同的：使用ZK-SNARK技术为以太坊系的执行交易提供加密证明，以便更容易的验证以太坊链上信息；构建ZK- rollups 可以做到共享以太坊的安全性，同时更具可扩展性。这些项目之间存在细微差别，它们在实用性和交易速度之间做出选择。下面将尝试描述EVM不同“类型”的分类，以及每种类型实现的回报和成本。

Type 1 ZK-EVM 力求完全和以太坊等效。不会更改以太坊系统的任何部分来达到更容易生成证明的效果。不会替换hashes、状态树、交易树、预编译、共识逻辑或任何功能。

目的是达成以太坊区块验证一样的效果——或者至少验证执行层（因此，不包括信标链共识逻辑，但包括所有交易执行和智能合约和账户逻辑）。Type 1 ZK-EVM 是使以太坊第 1 层本身更具可扩展性的东西。从长远来看，在 Type 2 或 Type 3 ZK-EVM 的测试中，对以太坊的修改可能会被引入以太坊本身，但是这种重新架构其自身又具备复杂性。

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

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

Type 1 项目

ZK-EVM 社区版（由 Privacy and Scaling Explorations、Scroll 团队、Taiko 等社区贡献者主导）是第一级的ZK-EVM。

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

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

Type 2 ZK-EVM 对数据结构进行更改同时保持以太坊状态不改变。幸运的是，这些是 EVM 本身无法直接访问的结构，因此在以太坊上运行的应用程序完全可以在 Type 2 ZK-EVM rollup 上运行。这样将无法按原样使用以太坊执行客户端，但通过一些修改来运行它们，仍然可以使用 EVM 调试工具和大多数开发者工具。

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

Type 2 ZK-EVM 提供比类型Type 1 ZK-EVM 更快的证明时间，主要是通过删除不必要且复杂和 ZK 不友好部分的以太坊堆栈。特别是，他们可能会改变以太坊的算法和基于 RLP 的默克尔树，或许还有区块和账本结构。Type 2 ZK-EVM 可能会使用不同的哈希函数，例如，Poseidon。修改状态树以存储代码哈希和 keccak，从而无需验证哈希来处理EXTCODEHASH和EXTCODECOPY操作码。

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

Type 2 项目

Scroll和Polygon HermezScroll都正在构建Type 2 ZK-EVM。也就是说，这两个项目都还没有完成。特别是，许多更复杂的预编译尚未实现。目前这两个项目都被认为比Type 3 ZK-EVM更好。

显著改善最坏情况证明时间的一种方法是在EVM中大大增加特定操作的gas成本，对于ZK-EVM来说很难。特定模式可能涉及预编译、算法，以及调用合约或访问内存或存储。

更改gas成本可能会降低开发者工具的兼容性并破坏一些应用程序，但通常我们认为它比“更深层次的”EVM的改变风险更小。约束管理资源的另一种方法是简单地对每个操作的调用次数设置上限限制。这个更容易实现，但在EVM安全性能假设下效果不佳。这种方法称为Type 3 而不是Type 2.5。

Type 3 ZK-EVM几乎是EVM 等效的，但为了进一步缩短证明时间并使 EVM 更易于开发，牺牲了准确性。

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

Type 3 ZK-EVM 的目标是与大多数应用程序兼容，其余应用程序只需要进行最少的重写。因为它们使用了 Type 3 ZK-EVM 删除的预编译部分，或者是因为不同EVM处理的情况的不同。

Type 3 项目

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

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

Type 4 系统的工作原理是获取高级语言（例如Solidity、Vyper或两者都编译成的中间体）编写的智能合约源代码，并将其编译为明确设计向ZK-SNARK 友好的一种语言。

通过不用单独对每个EVM执行步骤的所有不同部分进行ZK证明，直接从更高级别的代码开始，避免很多冗余操作。

不过这不应该作为价值判断！直接从高级语言编译确实可以大大降低成本，并通过验证者更简单的参与验证来帮助去中心化的愿景。

一个用 Vyper 或 Solidity 编写的“正常”应用程序可以被编译下来并且它“可以正常工作”，但是有一些重要的方式使很多应用程序不“正常”：

· 合约在Type 4系统中的地址可能与它们在EVM中的地址不同，因为 CREATE2合约地址取决于确切的字节码。这会破坏依赖于尚未部署的“反事实合约”、ERC-4337 钱包、EIP-2470序列和其他应用程序。

· 手写的EVM代码更难使用。许多应用程序为了提高效率在某些部分使用手写的EVM代码。Type 4 系统不支持它，尽管可以实现有限的EVM 代码支持来满足这些功能，而无需成为一个完整的Type 3 ZK-EVM。

· 很多调试基础设施不能调用，因为这样的基础设施运行在 EVM代码之上。也就是说，通过从“传统”高级或中间语言（例如LLVM）更多地访问调试基础结构，可以减轻这种缺点。

Type 4 项目

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

这些类型的ZK-EVM并没有明确地比其他类型“更好”或“更差”。相反，它们是权衡空间上的不同版本：有的类型与现有基础设施的兼容性更高但速度较慢，有的则与现有基础设施的兼容性较低但速度更快。总的来说，探索这些类型对于整个区块链世界是积极正向的。

· ZK-EVM 可以从Type 3 开始，不包括一些特别难以ZK证明的特性。他们可以随着时间的推移添加这些功能，并转移到Type 2。

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

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

· 也可以是以太坊自身修改变得对ZK更加友好，则Type 2或Type 3 ZK-EVM 可以成为Type 1 ZK-EVM。

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

希望随着时间推移，通过 ZK-EVM 的改进和以太坊本身的改进相结合，一切都变成 Type 1型，使其对 ZK-SNARK 更加友好。在未来，我们将有多个 ZK-EVM 实现，它们既可以用于 ZK 汇总，也可以用于验证以太坊链本身。从理论上讲，以太坊无需为L1使用标准化而针对单个 ZK-EVM 去实现改变；不同类型的ZK-EVM可以使用不同的证明，我们将受益于这种代码冗余。

总的来说，更多的资本在ZK+EVM赛道进行投资，目的也很明确，实现对自己的EVM原生资产进行隐匿，从而避免三箭资本的类似遭遇。然而，要实现这样的未来还需要相当长的时间。我们将在扩展以太坊和基于以太坊的ZK-rollup的不同技术方案上看到更多的创新。