RISC0的高性能zkVM设计路线

1. 引言

本文深入探讨了 zkVM 的证明系统设计，分为两大部分：

1）在第 1 部分中，将概述 RISC Zero 的 zkVM 所依赖的证明系统，以及RISC Zero未来改进 zkVM 性能的计划。
2）在第 2 部分中，将深入研究 RISC Zero 的证明架构，仔细研究证明系统的每一层，并涉及Folding方案、JOLT、Binius 和 Circle STARK 等创新的设计考虑。

2. zkVM 设计概览

一年前（2023年），业界对 RISC-V zkVM 的实用性仍不确定。RISC Zero 的 zkVM 是唯一可以证明 Rust 等高级语言的选项，而构建者对放弃使用 Circom 和 Noir 等电路语言持怀疑态度。当时，大多数 ZK 行业都专注于为构建 zkEVM 而手写自定义电路的问题。
在这里插入图片描述
RISC Zero 的早期设想（2022年4月）是：

让开发人员能够使用 Rust 等成熟语言（而不是手写电路），将在，将可验证软件应用程序推向市场的可行性方面实现从0到1的突破。

2023年8月 RISC Zero发布的 Zeth是这一价值主张的首次重大展示。

Zeth 是第一个完全兼容以太坊的 zkEVM，它的简单性使 zkVM 的价值主张变得清晰。
- 当其他团队为 zkEVM 开发筹集数亿美元时，RISC Zero 却随意发布了第一个完全兼容以太坊的 zkEVM，它由 3 名工程师在大约 2 周内构建而成。

从那时起，已看到了像 Taiko（2024年1月）这样的团队通过中止他们的 zkEVM 电路开发项目转而支持 Zeth，大大加快了他们的上市时间。

归根结底，快速开发 zkEVM 的关键解锁是：

在 zkVM 内运行现有的 EVM 实现。

简而言之，通过在 zkVM 内运行 reth 可以实现 Zeth。
类似地，通过在 zkVM 中使用 OIDC 库解锁了Bonsai Pay（2023年11月），并通过在guest中运行 Doom 库解锁了zkDoom（2024年2月）。

构建者不必每个项目都从头开始构建原语，只需导入相关的 Rust 库并继续前进即可。这使构建者能够快速构建他们的项目，并将维护负担减少到接近零。为了让 Zeth 与以太坊的最新更新保持一致，只需更新到最新版本的 reth。为了进一步证明 Zeth 中使用的方法的稳健性，以太坊基金会最近宣布了一项重大计划，通过这种 EVM-inside-zkVM 设计形式化验证 zkEVM （详情见zkEVM Formal Verification Project）。

如今，越来越多的人认为 zkVM 是构建和部署可验证软件应用程序的正确方法，并且越来越多的人认为 RISC-V 是构建 zkVM 的正确基础。RISC Zero团队很高兴看到其关于 RISC-V zkVM 的假设得到了整个行业的验证，并且很高兴看到过去几个月出现了许多有趣的新项目。

RISC Zero团队经常被问及对这些较新的 zkVM 和较新的证明系统的看法，以及是否计划采用这些技术。当谈到证明系统和相关技术时，答案通常是一样的——RISC Zero团队密切关注生态系统中的所有主要项目和研究，以便为RISC Zero的设计和优先事项提供参考。RISC Zero团队通常认为，在工程层面上可以获得比在证明系统设计层面上更容易、更有影响力的性能改进，因此会相应地确定优先事项。

2.1 证明系统改进的简单方法

现在，随着2024年6月 zkVM 1.0的发布，RISC Zero的 API 设计已经成熟，在许多链上部署了verifier（如以太坊、Arbitrum、Avalanche、Base、Optimism、Lean、Polygon zkEVM），并构建了高效的证明服务——Bonsai，RISC Zero改进 zkVM 的主要目标是：

尽量降低证明生成的成本，特别是对于需求最大的用例——包括 EVM rollup、OP rollup、Eigenlayer 部分提款和来自各种证明系统的证明聚合。

使用Amdahl定律的传统技术，即识别瓶颈并解决它，已经在今年上半年看到10 倍的成本改进。RISC0 zkVM能够提供市场上最便宜的 zkVM，并期待在未来几个月内进一步降低成本。

扫描二维码关注公众号，回复： 17423563 查看本文章

展望未来，RISC Zero团队瞄准的下一个主要成本改进：

来自特定应用加速器电路（又名预编译/gadgets小工具/chiplets小芯片）的集成。

通过将 RISC-V zkVM 与集成特定应用加速器电路的支持相结合，可以在不牺牲prover效率的情况下实现最快的开发时间。应用程序开发人员推荐的开发流程与标准软件开发实践相似：构建原型，然后测量性能。观察瓶颈，设计针对这些瓶颈的解决方案，然后重复。为了简化此过程，为构建者编写了优化指南。

一旦发现了重大瓶颈，就可以将特定于应用程序的加速器电路集成到 zkVM 中，以解决该瓶颈。RISC Zero团队正在发布 RSA 加速器，随后将发布用于 Keccak、ECDSA、配对和 BLS12-381 的附加电路。这些操作构成了今天看到的大多数证明需求的瓶颈。将继续识别和解决瓶颈，即将发布一些令人兴奋的公告，使用户能够构建自己的加速器电路。
在这里插入图片描述
在推出这些加速器电路后，将发布 RISC-V 电路的 V2。与 V1 相比，预计电路尺寸将缩小 2 倍，这是由于更高效的内存argument、更好的编译器技术以及各种细微的设计改进。

2.2 zkVM 的证明系统架构

随着zkVM领域参与者数量的增加，技术进步的步伐也越来越快，看到 zkVM 设计和证明系统设计方面有如此多的创新令人兴奋。

在这个阶段，RISC Zero、Succinct 和 a16z 各自都有基于 RISC-V 的 zkVM 实现。
与此同时，许多其他项目正瞄准其他高级 ISA，如 WASM 和 MIPS，
而其他项目（STARKware、Valida）则瞄准自定义指令集。

在 zkVM 设计的底层，在过去 12 个月中看到了证明系统设计方面的许多创新，这些创新同样令人兴奋。

在ZK10: FRI-based recursion with a Groth16 Wrapper - Paul Gafni和开发文档中均概述了 RISC Zero 证明系统的设计。该设计不仅是 RISC Zero zkVM 的基础，也是 Polygon 和 zkSync 以及 SP1 构建的 zkEVM 的基础。下图展示了“基本”思想，可分为四个部分：执行、RISC-V 证明、聚合证明和STARK-to-SNARK 证明。
在这里插入图片描述

1）执行。程序执行后会生成若干个“segments段”。
2）RISC-V 证明。每个片段都使用FRI-based prover进行证明。
3）聚合证明。使用FRI-based prover，将所有segment proofs聚合为单个证明。
4）STARK 到 SNARK 证明。为了输出足够小的证明以在链上进行验证，证明系统的最后一步依赖于基于椭圆曲线的prover。

其中：

使用 FRI 是因为：它对于水平可扩展递归证明非常有效，
使用 Groth16 是因为：它在链上验证的成本非常低。

RISC Zero团队一直在寻找对这种高级设计及其实现的改进，无论是通过小调整还是大改动。在考虑替代方案时，需要考虑系统的许多方面，包括：

Proof size
证明成本/时间
prover的硬件要求
verifier成本/时间
递归证明成本/时间（即在prover内部运行验证算法）
可并行性
去中心化
安全
可审计性
隐私

2.3 0STARK 协议

为了更轻松地讨论RISC Zero的证明系统，使用 0STARK 来指代，RISC Zero密码学文档——RISC Zero zkVM: Scalable, Transparent Arguments of RISC-V Integrity中所描述的，以及risc0-zkp 库中所实现的， IOP 协议。

0STARK 协议在结构上与 plonky2 和 eSTARK 论文中描述的证明系统非常相似：

算术方案基于 AIR，
承诺方案基于 FRI。

0STARK 专为 GPU 上的高效递归而设计，是 GPU 集群上大规模可扩展证明生成的最有效选择。

RISC Zero zkVM 底层的证明系统可简洁描述为：：

1）使用continuations延续性将大型计算分成几个segments。
2）使用0STARK来证明segements，每个segement产生 1 个 STARK。
3）使用0STARK来聚合这些 STARK。
4）最后用Groth16输出一个可以在链上发布和验证的证明。

在这里插入图片描述

3. zkVM 设计中的权衡

到目前为止，已经概述了 RISC Zero zkVM 基础的证明系统设计的高级设计。简而言之，该系统由 4 层组成：

1）执行
2）RISC-V 证明
3）聚合证明
4）STARK 到 SNARK 证明

在这里插入图片描述
在 zkVM 的迭代方面，RISC Zero的重点是最大化效率。
RISC Zero团队在做选型时：

通过更多地关注工程级问题而不是证明系统设计，以用更少的努力获得更大的性能提升。

3.1 Folding方案如何？

在Paul Gafni发表 zkSummit 演讲时所述：

RISC Zero设计的主要替代方案是基于Folding方案。
- Lurk zkVM 正在获得关注，而 Nexus zkVM 刚刚起步——两者都以基于Folding方案的 zkVM 设计为目标。

当RISC Zero团队评估基于Folding的 zkVM 选项时，评估结论是：

基于Folding的 zkVM 设计不利于高效并行化或去中心化。

为了使Folding更加可并行化，已经进行了一些令人鼓舞的工作，包括Paranova和Cyclefold，但RISC Zero团队的评估结论仍然是：

基于 FRI 的系统为正在构建的大规模分布式证明架构提供了一种更有效的机制。

Paul Gafni在zkSummit 演讲的最后几分钟简要讨论了这一点，并在Napkin Math: Communication Complexity of Decentralized Proving 分析中进一步阐述了细节。

因此，RISC Zero团队不太可能在短期内转向基于Folding的 zkVM。另一方面，其他一些最近的工作对实现RISC0 zkVM目的来说看起来更有希望。
当展望 zkVM 证明的未来时，执行、segment证明、聚合证明、STARK 到 SNARK 证明的整体结构似乎相当稳定。主要问题是如何最好地处理proving stack的每一层。

在深入研究每个层之前，先从高层次的角度介绍一下每个层的效率。如下表所示，要明确回答“瓶颈是什么？”这个问题并不容易。答案取决于是专注于最小化时间还是最小化成本，以及是否有兴趣证明小型计算或证明大型计算。
在这里插入图片描述
这里有一个令人惊讶的发现，用户最大的痛点是流程的最后一步——STARK 到 SNARK 证明。对于签名验证等小型证明，STARK 到 SNARK 证明所需的时间是证明系统其余部分总和的5 倍。

当今在 CUDA 上， STARK 到 SNARK 大约需要 15 秒，而输出 STARK 证明大约需要 2.5 秒。

3.2 STARK 到 SNARK 证明

虽然证明系统的早期部分针对高效的证明生成进行了优化，但最后阶段针对可以在链上有效验证的小证明进行了优化。
而在最小化证明大小方面，基于椭圆曲线的 SNARK（Groth16、PLONK、FFLONK 等）显然是赢家。椭圆曲线 SNARK 的证明大小约为数百字节，而基于哈希的 SNARK（如基于 FRI 的系统）的证明大小约为数百kB。
正如上节所示，最后一层 “STARK-to-SNARK Proving” 是RISC Zero zkVM 和其他应用的主要瓶颈。目前已成功将 Bonsai 上的 Groth16 证明时间缩短至约 15 秒，但即使有了这些改进，这仍然是许多应用程序中的时间瓶颈。
RISC Zero想要的是一个功能齐全、可靠的实现：

不需要特定于电路的可信设置
链上验证成本低
Actually works 确实有效
Doesn’t take forever

Groth16 在prover效率方面明显处于领先地位，但它需要特定于电路的可信设置，而RISC Zero更愿意避免这种情况。理论上，这里有很多不错的选择，包括 PLONK、FFLONK 和 Pianist。在实践中，这是工程比理论更难的另一个情况。选择 Groth16 主要是因为当准备投入生产时，可用的工具功能更强大。
在尝试了目前可用的各种选项之后，仍然没有找到完全令人满意的方法：

目前的分析表明，可以使用需要特定电路可信设置的系统，也可以使用需要几分钟才能生成证明的系统。

目前，RISC Zero选择使用最成熟工具（Groth16）的快速选项。希望能够将 Groth16 证明时间缩短到几秒钟，方法是从 rapidsnark 转移到 gnark，并通过调整证明系统参数来缩小聚合证明的最后阶段的证明大小。

3.3 执行

2023 年 5 月，RISC Zero引入了一项名为continuations的新功能，使 RISC Zero 成为第一个能够为任意复杂计算生成证明的 zkVM。基本思想是将大型计算分成多个较小的segment，每个segment单独进行证明。
为了展示延续的强大功能，2023年8月发布了 Zeth —— 第一个 Type 1 zkEVM。在continuations之前，甚至无法证明任何一笔以太坊交易。有了continuations，突然能够证明整个以太坊区块。

如今，continuations已成为 zkVM 的标准设计模式，但各个项目在处理跨多个segment的内存一致性检查方面存在一些差异。如，假设将值“5”写入第一个segment中的某个内存位置，然后在第二个segment中从该位置读取。

zkVM 通常使用 permutation argument 来强化内存读/写操作。Prover承诺“main trace”，然后生成 Fiat-Shamir 随机性，然后承诺“auxiliary trace”。
为了实现具有continuations的 zkVM，选择在每个segement上运行一个permutation argument，还是选择运行跨越多个segment的单个permutation argument。换句话说，RISC Zero是在每个segment的基础上生成 Fiat-Shamir 随机性，还是生成所有segments然后计算Fiat-Shamir 随机性？
在这里插入图片描述
RISC Zero选择：

每个segment 运行一个permutation argument。
- 这种方法由于paging分页成本而引入了一些开销，但它为在水平扩展证明基础设施方面省去了许多麻烦。
- 值得注意的是，这种方法允许在构建每个segment后立即开始证明它。
  - 在 Bonsai 上，在完成执行程序运行之前就开始证明segment，这减少了证明时间并提高了系统利用率。
  - 使用跨越多个segment的permutation argument意味着不能在构建最后一个segment之前开始证明。

3.4 RISC-V 证明和聚合证明

对于 RISC-V 证明和聚合证明，RISC0 zkVM 使用在BabyBear 域上定义的多项式约束，并搭配基于 FRI 的承诺方案。纵观证明系统的这一部分，有很多闪亮的新选择，包括 JOLT、Circle STARKs、Binius 和 STIR。

RISC Zero团队已经研究过所有这些选项，但从平衡工程优先级的角度来看，除非看到巨大的优势，否则采用新的证明系统对RISC0 zkVM来说毫无意义。在这个阶段，与重新设计证明系统相比，集成特定应用的加速器电路、继续优化 GPU 内核以及推出 RISC-V 电路的 V2 版，可看到更大的优势。

3.4.1 Jolt

JOLT 使用查找表来尽量减少手写多项式约束的数量。
这在降低代码复杂性和提高可审计性方面提供了很大的好处，而且从prover效率的角度来看，使用 Sumcheck/GKR 始终是一个有吸引力的选择。

不幸的是，底层证明系统 LASSO 导致verifier复杂性高于 FRI（并且递归性更差）。
JOLT 正在从 LASSO 转向 Binius，这使得这种以查找为中心的设计更加引人注目。RISC Zero团队将密切关注这一进展！

更多Jolt信息，可参看：

Paul Gafni Jolt笔记
2024年4月9日，Justin Thaler A new era in SNARK design: Releasing Jolt

3.4.2 Circle STARK

尽管RISC0 zkVM 是使用名为 BabyBear 的 31 位域构建的，但 STARKware 和 Plonky3 正在努力过渡到使用另一个名为 Mersenne 31 的 31 位域，并使用一种名为 Circle STARKs 的技术。据作者称，在 CPU 证明方面，这种方法比 BabyBear 提高了 30%。
但是RISC Zero的zkVM系统是针对 GPU 验证进行设计和优化的，并不期望这 30% 的改进能够转化为正在优化的 GPU 环境——更不用说可能需要构建一组全新的 GPU 内核才能找到答案。

在此回顾下 Baby Bear 和 Mersenne31 背后的背景。过去几年，zkVM 设计的主要主题之一是从大域转向小域。STARKware 的 Stone prover建立在 251 位域上。使用如此大的域会导致 Binius 作者所说的嵌入开销。尽管 zkVM 中使用的大多数值都是位或字节，但用户仍被迫支付整个域元素的成本。

Mir 协议（最终成为 plonky2）在引入小域 STARK 技术时降低了嵌入开销的重要性，该技术在称为“Goldilocks”或“Oxfoi”的 64 位域上运行。RISC Zero 更进一步，在 31 位域（称为“BabyBear”）上构建了RISC0 zkVM。Circle STARK 紧随其后，选择使用 31 位域，但其选择的是不同于RISC Zero所选择的31位素数。

M31 由特别优雅的素数定义 $2^{31} - 1$ 。Daniel Lubarov在 ETH Denver 2023 介绍 Plonky3 时首次暗示了 M31 的使用。就高效乘法而言，这是一个特别好的域，但就 NTT 而言，它并不好。

2023 年下半年，Polygon 研究人员通过Reed-Solomon codes over the circle group 的研究解决了 M31 上 NTT 的挑战，为Circle STARKs 铺平了道路。

更多Circle STARKS信息，可参看：

Vitalik 2024年7月博客 Exploring circle STARKs
STARKware 2024年3月博客 Stwo Prover: the next-gen of STARK scaling is here
Lambdaworks 2024年7月博客 An introduction to circle STARKs

在这里插入图片描述

3.4.3 Binius

Binius 将小域的概念发挥到了极致，目标是 Towers of Binary Fields。二进制域的硬件效率极高，Binius 使用了一种packing打包技术，消除了上面描述的“嵌入开销”。与 JOLT 一样，RISC Zero团队对 Binius 发布的第一印象是：

“这对于 RISC-V 证明来说看起来很棒，但对于聚合来说却不是那么好。”

事实上，同样的观点也适用于 Ligero、Orion 和 Brakedown 等系统——证明时间看起来很棒，但verifier复杂度比 FRI 更大，导致递归性能不佳。

最近，Binius 背后的团队推出了一种 FRI 变体，该变体基于 BaseFold等见解和技术，可以与 Towers of Binary Fields原生配合使用。通过这一补充，Binius 提供了一个非常有吸引力的选择 ——从segment证明层中消除嵌入开销，而不会导致聚合证明层的成本激增。

目前，Binius 团队正在开发其递归层，而 JOLT 则致力于将 Binius 集成到其基于 RISC-V 的证明架构中。对于RISC Zero来说，采用还为时过早，但是RISC Zero将重点关注Binius进展。

更多Binius信息，可参看：

Vitalik 2024年4月博客 Binius: highly efficient proofs over binary fields
Lambdaworks 2023年12月博客 How Binius is helping move the ZK industry forward
Jim Posen 2024年4月在 zkSummit 11 上的演讲：ZK11: Binius: a Hardware-Optimized SNARK - Jim Posen

4. 押注未来

RISC Zero 在所有这些工作中都处于一个非常有趣的位置。在短期内，预计RISC Zero会比 Circle STARKs 或 Binius 更高效，因为RISC Zero整体系统已经很成熟了——在 GPU 而不是 CPU 上运行，而且已经花了近 2 年的时间在运行证明集群的背景下实现成本节约。

但忽略代码成熟度，只看底层证明系统，Circle STARKs 和 Binius 都看起来很有前途。从长远来看，希望RISC Zero的工具尽可能模块化——希望让用户在运行 zkVM 时在证明系统之间进行选择。但在实践中，构建的所有内容和支持的所有内容都有工程负担和维护负担。

目前，STARKware 和 Polygon 各自投入大量资源构建自己的 Circle STARK 实现，而 Irreducible 正在为 Binius 构建聚合证明（即递归）。

现在判断 M31、BabyBear 还是 Towers of Binary Fields 是“最佳选择”还为时过早。实际上，这个问题很大程度上取决于具体情况。因此，就目前而言，不会重新发明RISC Zero的基础（这既需要大幅放慢工程进度，又需要下大赌注决定是选择 Circle STARKs 还是 Binius），而是坚持使用 BabyBear，以便继续为RISC0 zkVM系统提供明显的迭代改进，同时扩展为真实用户支持真实用例的能力。

切换到新的炫酷证明系统的诱惑始终存在。但RISC Zero团队还没有开始实施一些非常容易实现的成果，如grinding或 LogUp，因为Amdahl’s定律要求将注意力转移到其他地方。同样，STIR 看起来比 FRI 有了明显的改进，但RISC Zero将注意力集中在其他地方，因为递归不是RISC0 zkVM的瓶颈，而 FRI 只是segment证明成本的一小部分。

当看到证明系统重新设计的投资回报率高于工程工作时，RISC Zero团队就会重新设计证明系统。

参考资料

[1] RISC Zero团队Paul Gafni 2024年9月6日博客 Designing high-performance zkVMs