不同类型的 ZK-EVM

不同类型的 ZK-EVM

不同类型的 ZK-EVM

特别感谢 PSE, Polygon Hermez, Zksync, Scroll, Matter Labs 和 Starkware 团队参与讨论和协助校稿

最近各家 ZK-EVM 纷纷登场。Polygon 的 ZK-EVM 以开源的方式释出，ZKSync 公布了 ZKSync 2.0 的规划，相对晚进场的 Scroll 也推出了他们的 ZK-EVM。正在开发 ZK-EVM 的，还有 PSE, Nicholas Liochon 等人，以及 Starkware 正在开发的 alpha compiler（能把 EVM 编译成 Starkware 所开发的 Cairo），族繁不及备载。

上述项目有一个共同的目标：利用 ZK-SNARK 进行密码学证明，验证以太坊生态（Ethereum-like）交易的执行。这更好地验证以太坊 L1 链上的交易与状态，也建立（接近）与以太等价且扩展性更好的 ZK-rollups。但这几个项目之间的些微的差异，反映在实用性和速度之间的取舍。本文试图提出分类不同 EVM 的方法，并说明其中的利弊得失。

懒人包（以图表呈现）

zkevm

第 1 类：等价以太坊（fully Ethereum-equivalent）的 ZK-EVM

第 1 类 ZK-EVM 志在完整、毫无妥协地达到以太坊等价。它没有改动以太坊生态任何部分的设计以让证明更简单，也没有换掉哈希运算（hashes）、状态树（state trees）、交易树（transaction trees）、预编译的合约（precompiles），而且再怎么边陲的共识逻辑（in-consensus logic），都没有换掉。

优点：完美的相容性

一切的用意在于用现况下的以太链——至少，要验证执行层（也因此不包含信标链（Beacon Chain）的共识逻辑，但是所有交易执行和智能合约、账户的概念，都有涵盖）。

第 1 类的 ZK-EVM 是以太坊 L1 更有扩展性的最终解。长远来看，对以太坊的修正，可能会在第 2 类或第 3 类测试之后，引入到正规以太坊。然后，要作架构的重规划，则会有其复杂之处。

第 1 类的 ZK-EVM 也对 rollups 很理想，因为 rollups 能够重复利用许多的基础设施。举例来说，以太坊的执行端可以被用来生成和处理 rollup blocks（退一步来说，等到解除质押存款生效后，这个功能可以被重新用在 rollup 的以太质押存款），所以比如区块链浏览器、block production 等工具，都很容易重复利用。

缺点：证明者运算时间（prover time)

以太坊原生不以零知识证明基础构建，所以有 许多 以太坊固有元件，若要作零知识验证，需要消耗庞大的运算时间。第 1 类 ZK-EVM 为求完全复制以太坊运作，因此没有避开低效率的证明流程。目前而言，从以太坊既有区块产生零知识证明，要花上好几个小时。然而，这个障碍可以通过巧妙的工程设计，大幅提升验证者平行化产生零知识证明的能力，或建构出 ZK-SNARK ASIC 等方式，缓解其缺点。

实例

PSE 正在盖的 ZK-EVM 属于第 1 类。

第 2 类：等价以太坊虚拟机（fully EVM-equivalent）的 ZK-EVM

第 2 类 ZK-EVM 试作到跟 EVM 等价，但又不完全跟以太坊等价。也就是说，他们“内部”跟以太坊一样，但是从外面看上去会有些差异，尤其是区块结构（block structure）、状态树（state tree）等数据结构。

一切的用意在于要跟既有的应用软件完全相容，但是针对以太坊作一些微调，让开发更容易、生成证明更快速。

优点：等价于虚拟机

第 2 类 ZK-EVM 改动了储存诸如 Ethereum state 的数据结构。幸运的是，这些都是 EVM 本身无法直接存取的结构，所以在 Ethereum 之上执行的应用程式几乎都可以在第 2 类 ZK-EVM rollup 上使用。你无法直接利用以太的执行端，但经过微调之后可以，EVM 的除错工具和多数的开发设施，也都能照常使用。

也有少数的例外的情况。对于使用以太坊历史区块（historical Ethereum blocks）的哈希数验证（Merkle proofs） 来验证对历史交易、交易明细、或状态（claims about historical transactions, receipts, or state）（例如：跨链桥有时候会这么做）就会有不相容的情况发生。如果有 ZK-EVM 用其他哈希函数取代 Keccak，这些证明会失效。然而，我本来就不建议这样设计应用程序，因为未来以太坊会引用的改变（例如 Verkle trees）会让这些应用程序连在以太坊上都不能使用。比较好的替代方案，是以太坊本身应该要新增不容易被未来科技淘汰的历史取用预编译合约（future-proof history access precompiles）。

缺点：证明者运算时间稍有改善到仍然很慢

第 2 类 ZK-EVM 的证明者运算速度，比第 1 类更快，主要的原因，是因为不再使用某些以太坊上，对零知识技术毫无意义地不友善的密码学。尤其，他们可能会改变 Ethereum 的 Keccak 和基于 RLP 的 Merkle Patricia tree，还有或许区块及交易明细的结构。第 2 类 ZK-EVM 可能会使用不同的哈希函数，例如 Poseidon。也很自然发生的改变是修正状态树，以储存合约码哈希值（code hash）和 keccak，免除对于执行EXTCODEHASH和EXTCODECOPY所需要的哈希验证。

这些改动大幅改善证明者运算时间，但不会完全解决所有问题。证明现阶段的 EVM 的缓慢效率，以及源自于 EVM 的其他不效率、对 zk 的不友善，都还留着。举一个简单例子：内存。因为一个MLOAD只能一次读 32 bytes，包含“没有对齐的”字节（起始端和终端都不是32的倍数），一个 MLOAD 无法被直接读取为一个 chunk，它可能需要读超过两个连续的 chunk，并做一些运算，合并结果。

实例

Scroll 的 ZK-EVM 以及 Polygon Hermez 都属于第 2 类。然而，两项目距离到位都还早。尤其因为还没加入比较复杂的预编译，因此，以目前来说，两项目都更应该被分类在第 3 类。

第 2.5 类：跟以太坊虚拟机结构一样，但是 gas 定价例外

想要大幅减少最坏可能的证明者运算时间（worst-case prover times）的方法，就是针对 EVM 内很难的零知识证明运算，大幅提升所需的 gas 定价。这会牵扯到预编译、KECCAK 操作码、以及或许呼叫合约的特殊模式（specific patterns of calling contracts）、存取内存（accessing memory）、储存空间（storage）或还原（reverting）。

改善 gas 定价可能会降低开发者工具的相容性，并会让一些应用程序不能用（break），但是它比起更“深层”的 EVM 改动风险较低。开发者应该要注意，不要在一笔交易中花费超过一个区块能容纳的 gas，也永远不要把呼叫合约时所需要花用的 gas 写死（这本来就是会给开发者的标准建议）。

另一个解决资源限制问题的替代方式，是直接对每一个运算可以被呼叫的次数设下硬性的限制。这在电路上更容易实施，但是对 EVM 的安全性假设就没有那么合适。这种做法我认为属于第 3 类而非第 2.5 类。

第 3 类：接近以太坊虚拟机等效（almost EVM-equivalent）

第 3 类 ZK-EVM 是 接近 EVM 等效，只有作了退让，以改善证明者运算时间，并让开发更容易。

优点：更容易实施，证明者运算时间缩短

第 3 类 ZK-EVM 可能会拿掉一些特别难改成 ZK-EVM 的功能。最有可能被拿掉的，就是预编译。此外，各种第 3 类 ZK-EVM，在处理合约程序代码（contract code）、内存（memory）或堆栈（stack）上，也有些微差异。

缺点：不相容性

第 3 类 ZK-EVM 的目标是跟 多数 的应用程序相容，并且只需要重写极少部分。即便如此，还有一些需要重写的应用程序，因为他们要么使用了第 3 类 ZK-EVM 拿掉的预编译功能，或是在特殊情况（edge cases）之下，某些之间虚拟机处理方法不同的相依性问题（dependencies）。

实例

Scroll 和 Polygon，虽然它们预期会在未来改善相容性，但目前都属于第 3 类。Polygon 有一个特别设计，是要验证自己的语言，zkASM，而他们编译 ZK-EVM 程序用的是 zkASM。尽管如此，我还是认为这是第 3 类 ZK-EVM。它仍能验证 EVM 程序代码，只是换了内部逻辑。

现阶段，没有哪个 ZK-EVM 团队是 想要成为 第 3 类 ZK-EVM。第 3 类只是一個過渡期，正在等待预编译功能完成，再换到第 2.5 类。但是在未来，第 1 或 2 类可能会加入 ZK-SNARK 友善的预编译，自发地变成第 3 类，让证明者运算时间和 gas 都降低。

第 4 类（等价高阶语言（high-level-language equivalent））

第 4 类把（例如：Solidity、Vyper，或其他这两种语言都会编译成为的中间语言）然后把 高阶语言 编译成其他有特别设计过、对 ZK-SNARK 友善的语言。

优点：证明者所需运算时间非常短

只要从高阶语言就有利用零知识证明，而非等到执行阶段的各个步骤，才开始用在 EVM 上，就可以省掉 很多 麻烦。

我虽然只用了一句话描述这个优点（但下面列出那么多相容性的缺点），但我并不是要说第 4 类没什么优点。这是个非常大的优点！直接从高阶语言编译真的可以大幅降低成本，也因为参与证明的门槛变低，所以更去中心化。

缺点：相容性低

通常一个“一般”的，由 Vyper 或 Solidity 写成的应用程序可以编译然后就能用了，但是有很多应用程序没办法那么“一般”，而且理由很重要：

• 因为在 CREATE2 合约地址要看 bytecode 决定，所以 “第 4 类系统中的合约地址”与“EVM 的合约地址”不一定相同。这会造成很多应用程序不能使用，例如依赖尚未部署的“反事实合约（counterfactual contracts）”的系统、ERC-4337 钱包、EIP-2470 singletons、等应用程序。
• 手刻的 EVM bytecode 更难被利用。许多程序某些部分会用手刻 EVM bytecode 来提高效率。第 4 类的系统就不支持。虽然有些方法可以实施有限的 EVM bytecode support 来满足这些情况，不一定要直接上第 3 类 ZK-EVM。
• 很多除错的基础设施无法被直接利用，因为这些基础设施只能跑在 EVM bytecode 上。话虽如此，有很多来自传统高阶或中阶语言（例如 LLVM）的除错工具可以用来缓解这个缺点。

以上都是工程师需要留意的问题。

实例

ZKSync 是第 4 类系统，虽然随着时间他们可能会改善对 EVM bytecode 的相容性。Nethermind 的 Warp 项目正在建一个能把 Solidity 编译成 Starkware 的 Cairo 语言的编译器，这会因此把 StarkNet 在实然上变成第 4 类系统。

ZK-EVM 类型的未来展望

以上不同类型之间没有谁更“好”或更“坏”，而是取舍的不同：越靠近 第 1 类的类型跟既有的基础设施相容性更高，但是更慢。越靠近第 4 类的类型相容性比较差，但是速度更快。通常来说，对整个生态比较好的做法，就是每种不同类型，都有人研究。

靠近第 4 类的 ZK-EVM 类型，也可以随着时间，再慢慢改成靠近第 1 类的类型。反之亦然。举例来说：

• ZK-EVM 可以先跳过很难用零知识证明的功能，当第 3 类就好。之后，再慢慢把功能加上去，逐渐转成第 2 类。
• ZK-EVM 也可以先当第 2 类，然后之后提供在以太坊完全等效的环境中，或是证明速度更快、改动过的状态树，变成第 2 和第 1 类的综合体。Scroll 正在考虑用这个策略发展。
• 原本是第 4 类的系统，也可以慢慢加上处理 EVM opcode 的能力（虽然开发者仍然被鼓励直接从高阶语言编译，以节省手续费和改善证明者所需运算时间）。
• 假设以太坊本身变得更零知识友善，原本是第 2 类或第 3 类开始的 ZK-EVM，就会变成第 1 类。
• 如果在第 1 类或第 2 类 ZK-EVM 预编译组件（precompiles），这样就能使其变成第 3 类 ZK-EVM。这些预编译组件的验证效率很高，是由一种 ZK-SNARK 友善的语言撰写而成。这样开发者就能在以太坊的相容性和速度之间作选择。这种 ZK-EVM 属于第 3 类，因为它牺牲了完美以太坊等价性，但是从实用性的角度来看，它比起第 1 类或第 2 类有更多好处。主要的缺失在于某些开发者工具不支持 ZK-EVM 客制化的预编译，然而，这可以被改善：透过开发者手动指定设置文件，开发者工具可以支持将预编译组件转换回同等功能的 EVM 程序代码，这样就能适用于所有环境。

我个人的希望，是随着时间，ZK-EVM 技术的进步，以及以太坊本身对 ZK-SNARK 的设计更友善之后，所有的 ZK-EVM 能渐渐发展为第 1 类。在这样的未来，我们会有好几个能够同时作为 ZK-rollup 以及验证以太链本身的 ZK-EVM。理论上，没有必要将以太坊标准化为只能供一种 ZK-EVM 使用的 L1。要有不同的客户端使用不同的证明方式，我们才能收获冗余实现（code redundancy）的好处。

然而，要花一些时间，才会抵达这样的未来。在这条路上，将会看到很多扩展以太坊、以太坊 ZK-rollups 技术的日新月异。

• 原文链接： vitalik.eth.limo/general...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～