zkVM选型要点

1. 引言

当选择ZK工具，来做可验证链下计算来扩容区块链时，需考虑：

1）为何应选择zkVM？
2）zkVM有哪些基本功能？
3）哪些zkVM可提供这些基本功能？

2. 为何应选择zkVM？

2年前，主流的ZK软件开发是：

使用circom来手写电路

这种手写电路的方式是劳动密集型的：

电路难以编写、更新、审计和维护

将基于电路的ZK项目上市所需的时间约为2年，成本约为1亿美金。

过去2年来，RISC Zero已证明，相比于直接编写电路，为zkVM编写应用程序能更快、更便宜地让项目上市。zkVM使得ZK技术对普通开发者可用，使得可在一个周末即可实现复杂应用。

早在2022年，RISC Zero团队就解锁了证明常规Rust代码正确执行的能力，如证明最受欢迎的Rust库等。使得ZK builders可专注于构建实际的应用程序，利用所有Rust生态的成熟工具。

3. zkVM有哪些基本功能？

当今有很多zkVM可供选择，实际应用时，应考虑如下4大基本功能：

1）支持导入crates/packages。
2）支持链上proof验证。
3）支持unbounded计算，而不会让验证开销膨胀。即支持unbounded计算，但有constant proof size，从而具有constant验证开销。
4）支持proof composition。

为了实现ZK的未来，以上四大功能是必需的。

4. 哪些zkVM可提供这些基本功能？

截止到2024年4月24日，当前市场上已有的zkVM有：

在这里插入图片描述

4.1 支持库导入

原因在于：

若不支持库导入，软件开发将是噩梦。允许开发者导入库是任何复杂应用的基本诉求。

为何难以实现：

数年前，ZK系统是效率低下的、难以构建的，以至于让ZK系统支持像Rust或C++这样的成熟语言，在技术上似乎遥不可及。如今，zkVM开发的趋势已经从定制指令集转向RISC-V、MIPS和WASM等标准指令集。

RISC Zero的方案：

2022年4月，RISC Zero发布了首个zkVM，支持对像Rust或C++这样的高级语言生成proofs。如今，RISC Zero团队每晚都会进行测试，以检查前1000个Rust库与RISC ZerozkVM的兼容性：当前70%的库都是开箱即用。

4.2 支持链上proof验证

原因在于：

链上验证是区块链领域ZK应用的基本要求：
- 链下证明计算
- 链上验证计算

为何难以实现：

证明系统设计涉及Prover复杂度和Verifier复杂度之间的基本权衡。目前的趋势是，基于哈希和纠错码的SNARK（又名STARK）为zkVM提供了最好的prover开销，而基于椭圆曲线的SNARKs提供了更好的链上验证开销。如今的zkVM通常包括多个证明系统的合并，以便两全其美。

RISC Zero的方案：

RISC Zero使用STARK进行有效证明，然后在SNARK电路内验证STARK证明，以便将STARK“翻译”为SNARK。2023年8月，RISC Zero团队在Sepolia上发布并验证了首个proof。如今，RISC Zero支持适用于任何zkVM应用程序的链上verifier合约。

4.3 支持unbounded计算，但验证开销为constant

原因在于：

若想要证明某以太坊区块或某OP区块构建正确，对应的是需对a very large computation的证明。

为何难以实现：

对large computations直接证明，并不能很好的扩展——增加2倍的computation size，对应的计算复杂度将增加超过2倍。为解锁unbounded computation size（而不妨碍链上验证），有2大技术难点：
- 将large computation切分为chunks的能力，并对各chunks独立证明
- 将“segment proofs”聚合为单个succinct proof的能力。

RISC Zero的方案：

RISC Zero引入了continuations来解决为unbounded sized computation生成proof的难题——可独立证明每个segment，然后使用recursion递归来聚合segment proofs。这样，RISC Zero可实现linear-time proving with constant verification costs。

4.4 支持proof composition

原因在于：

proof composition（又名proof of proof），解锁了大量不同应用，包括更复杂的隐私应用、更模块化的zkVM应用，以及proof聚合（所聚合的proof可源自RISC Zero，也可源自其它证明系统）。

为何难以实现：

使proof composition高效是极具挑战的。解锁此功能不仅需要解决递归问题，还需要构建一个API，以允许开发人员从zkVM内部调用recursive prover。

RISC Zero的方案：

用户可通过调用RISC Zero zkVM内的env::verify()函数来访问proof composition。该功能是2024年2月新加的。更多信息可参考：
- 2024年2月视频 Proof Composition RISC Zero Study Club
- 2024年2月博客 Proof Composition: Unlocking Recursion and Modularity for ZK Developers

5. 递归电路：ZK building的最难部分

zkVM四大功能中的3个（链上验证、unbounded computation、proof composition）都依赖于递归。在ZK世界，递归是指：

证明，某proof正确验证，的能力。

换句话说，递归是指：

在prover内运行verifier。

这听起来可能很直观，但构建递归电路是出了名的复杂。RISC Zero zkVM的设计尽可能易于使用，但在本质上，保持了三个相关但独立的ZK电路的兼容性。

在RISC Zero中，实际上有两个基于STARK的zkVM：
- 首先使用RISC-V电路来生成RISC-V执行的证明
- 然后使用单独的递归电路来聚合这些证明。
最后，将结果输入SNARK电路，以便进行链上验证。

为此，当前RISC Zero团队正在构建一种基于MLIR的语言，用于构建名为Zirgen的递归电路。更多Zirgen详情，可查看Julian Sutherland（Nethermind）的演讲：(Almost) effortless formal verification of ZK-circuits by Julian Sutherland (Nethermind Security)。

6. 如何对比现有zkVMs？

性能似乎是最自然的比较维度，但不幸的是，ZK项目的基准测试仍处于初级阶段。有很多基准项目，但事实证明，要为apples-to-apples的比较提供一个强大的框架是非常困难的。
在比较性能之前，需确保以上提及的4大功能的完整性。
当某个新加入者宣布其Zeth版本时，声称区块构造证明比RISC Zero快30倍。但不幸的是，其Zeth proof也比RISC Zero的大1000倍。若不能在链上验证proof，那能以多快的速度生成证明真的重要吗？

RISC Zero一直致力于为生产使用准备一个功能完整的zkVM。一旦RISC Zero完成了审计和可信的设置仪式，并在主网上部署了verifier，就可以指望得到一些重大的性能改进。目前，推荐使用唯一功能完整的zkVM：RISC Zero。

7. 其它重要功能？

除以上提及的4大功能之外，还有多个功能值得提及：

1）Deterministic builds。zkVM原生支持某给定二进制文件的正确执行，但对于大多数应用场景，想要的是能证明某指定Rust（或其它高级语言）程序的正确执行。RISC Zero通过引入cargo-risczero工具来解决该问题。
2）支持Accelerator电路。当识别某zkVM应用的性能瓶颈时，可修改zkVM来提供应用专用的acceleration。如，可添加Keccak accelerator来支持以太坊区块构建的高效证明。RISC Zero当前提供了大整数运算和SHA的accelerator。
3）支持proof aggregation。proof aggregation是指将许多证明合并为单个证明的能力。这一功能对于使链上验证开销合理至关重要。proof composition启用了proof aggregation功能，但值得注意的是，其他系统可能会提供proof aggregation的解决方案，而不会完全解决proof composition的问题。