zkVM 基准评估：现状与前景

17 min readJun 17, 2025

特别感谢分布式资本（Fenbushi Capital）对本项研究的支持，ICME Labs（Novanet 的运营方）为我们参加 ZKProof7 提供差旅资助，以及 ClankPan 和 Yuki Aoki在代码方面的重大贡献。

代码: Benchmark repository

零知识虚拟机 (zkVM) 正在成为以太坊扩容的基础构件。然而，现有的基准测试 — — 例如 SP1 发布文章中的基准测试如the Vac report, 和 zkbenchmarks.com — 大多采用不一致的方法，从而掩盖了关键的性能权衡。

我们引入了一个标准化的测试平台，并评估了八种 zkVM — — SP1, RISC Zero, OpenVM, Pico, ZKM, Jolt, Nexus,和 Novanet — — 在四种计算任务和三种性能指标（证明者时间、证明大小和峰值 RAM 利用率）上的表现。我们的研究结果阐明了哪些 zkVM 架构最适合以太坊生态系统中的特定用例。

1. 引言

1.1 zkVM的概念

零知识虚拟机 (zkVM) 代表了一种技术框架，旨在在不泄露输入或中间计算状态的情况下，以密码学方式验证程序执行的正确性。其操作流程通常包括三个主要阶段：

执行（Execute）：程序被执行，并生成一个完整的记录（称为执行轨迹），该记录捕捉了每一步计算中的指令、CPU 状态和内存数值。
证明（Prove）：基于执行轨迹，构造一个加密证明（通常使用 SNARK — — 简洁非交互式知识论证）来证明计算过程的正确性。
验证（Verify）：对生成的证明进行验证，以确认计算结果的正确性，而无需重新执行原始程序。

zkVM 利用 SNARKs（简洁非交互式知识论证）来验证虚拟机每一步状态转换的正确性，具体通过构建以下三种基础的加密保障来实现：

读写内存一致性证明（Read-Write Memory Consistency Proof）：确保在整个计算过程中内存的一致性和操作的正确性。
指令编码证明（Instruction Encoding Proof）：验证所执行的指令与其定义的编码严格一致。
指令执行证明（Instruction Proof）：确认每条指令根据虚拟机的形式化规范产生了正确的结果。

必须明确的是，zkVM 的核心用途在于实现对计算完整性的高效验证，而非隐私保护。

1.2 为什么以太坊需要 zkVM

目前，以太坊的每一个验证者都需要重新执行所有交易，这使得 Gas 成本与原始计算复杂度直接相关联。引入 zkVM 后，计算密集型操作由链下的证明者（prover）执行，并生成加密证明，然后只将结果状态根和该证明提交到链上。验证者仅需验证这些证明 — — 这是一个与代码复杂度无关、时间复杂度为 O(1) 的过程。因此，即便是如机器学习推理或其他高强度计算的智能合约执行，交易费用也能维持在一个相对稳定的水平。

1.3 本研究的目标

众多 zkVM 项目声称具备优越的性能指标，但这些指标往往是在不同测试条件下得出的，从而使得客观的对比分析变得复杂。某些被宣传为“最快”的系统，可能存在显著局限性，例如内存需求过高，或仅能支持特定类型程序的有限功能。

本研究提出了一个经过严格标准化的基准测试框架，旨在对多个 zkVM 实现进行全面对比分析。我们从多种性能指标出发，结合具有代表性的计算任务进行评估。这种系统化方法有助于识别当前 zkVM 技术的性能瓶颈，并为其高效部署与应用制定最佳实践。

2. 零知识虚拟机（zkVM）实现的分类与技术

2.1 zkVM 的分类

在 zkVM 领域，目前主要存在以下几种主流的证明系统架构：

FRI-STARK-based: 此类系统结合了快速里德-所罗门交互式接近性证明（FRI）与可扩展的透明知识论证（STARKs）。它们通常使用 32 位扩展域，以优化证明生成的效率。代表项目包括：SP1、RISC Zero、OpenVM、Pico、ZKM 和 Valida。
Nova-based: 这类实现采用折叠（folding）方案，一种能够高效地逐步聚合多个证明的技术。Novanet 和 Nexus 1.0 是此方法的代表。
Lasso Lookup: 该技术通过从预计算的查找表中提取执行数据，以降低计算开销。Jolt 项目采用了这种创新方法。
GKR: 基于 Goldwasser-Kalai-Rothblum 协议，GKR 技术通过逐层展示电路可满足性，通常从输出层向输入层推进，并借助 sum-check 协议来完成。Ceno 是此方法的重要实现。

此外，zkVM 架构还可以进一步细分为两种主要范式：

vRAM Style: 这种架构根据指令类型（例如 CPU 指令、内存操作）将程序执行轨迹进行分组处理。每个组随后以数据并行方式生成电路证明，并最终进行聚合。SP1、RISC Zero 和 ZKM 采用了该架构风格。
Modular Style: 该方法为每个操作码定义专用电路或查找表，并根据需要依次执行，再将所有结果证明进行聚合。OpenVM 和 Jolt 采用了此类模块化设计。

2.2 优化技术

在各类 zkVM 实现中，常见的优化方法包括：

预编译（Precompiles）: 利用专门优化的电路，高效证明特定且经常调用的操作，例如大整数运算、浮点计算或加密哈希函数（如 Keccak）。
连续性证明（Continuation）: 将程序的执行轨迹划分为多个独立的片段。这样可以并行地为每个片段生成证明，特别是在处理计算密集型操作时，有助于显著减少整体的证明时间。
按需生成（À la carte Proving）: 通过架构设计，使得证明开销仅在实际执行的指令上发生，而非为所有可能的指令都生成证明，从而提升效率和灵活性。

3. 基准测试结果与分析

本次基准测试在一台运行 Ubuntu 24.04 的 Linux 系统上进行，配备有 8 个虚拟 CPU、192GB 内存，以及一块配备 32GB 显存的 NVIDIA RTX 5090 GPU。

测试评估所使用的四个程序包括：

计算第 100,000 个斐波那契数（Fibonacci）
进行 SHA2–2048 哈希计算
基于 secp256k1 椭圆曲线的 ECDSA 签名验证
模拟 100 笔以太坊转账交易（ETHTransfer）

3.1 执行时间效率（Prover Time）

下方的四个柱状图展示了各项基准测试的证明生成时间（从上到下依次为：Fibonacci、SHA2–2048、ECDSA k256、100 ETHTransfer）。

整体而言，RISC Zero（GPU）、SP1（GPU）以及 OpenVM（CPU）在时间效率方面表现出色。相比之下，Pico 和 Jolt 的性能则因具体程序而异，波动较大。

与在 EC2 g5.x16xlarge instance实例上的测试结果对比显示，SP1 的 GPU 性能在很大程度上依赖于底层硬件配置。

值得关注的是，OpenVM 在 CPU 执行方面的出色表现，这可能表明其模块化架构设计在效率上具有一定优势。

Fibonacci（第 100,000 项）证明生成时间如下：

SP1 (GPU): 3.4s
RISC Zero (GPU): 3.6s
OpenVM (CPU): 7.5s
Pico (CPU): 20s

由于该程序主要涉及简单的迭代计算且内存访问极少，因此 GPU 加速所带来的性能优势尤为明显

SHA2–2048 哈希计算证明生成时间如下：

RISC Zero (GPU): 0.54s
OpenVM (CPU): 0.99s
Jolt (CPU): 2.7s
SP1 (GPU): 12s
ZKM (CPU): 22s

对于 SHA2 这类加密操作，基于预编译（Precompile）的加速机制是当前主流的优化策略。这也解释了 RISC Zero、OpenVM、SP1 和 ZKM 在该测试中实现较快速度的原因 — — 它们都实现了相关的预编译模块。Jolt 当前尚未支持 SHA2 的预编译优化，因此通过查找表（lookup table）来降低大规模位运算的计算开销，从而弥补性能不足。

ECDSA Verification (secp256k1)证明生成时间如下:

RISC Zero (GPU): 1.0s
SP1 (GPU): 12s
OpenVM (CPU): 14s
Jolt (GPU): 83s

与 SHA2 的测试结果相似，RISC Zero、SP1 和 OpenVM 的出色性能同样得益于它们对相关加密操作的预编译支持（precompiles）。这些预编译模块大幅降低了执行复杂加密算法所需的计算成本。Jolt 在本项测试中表现较差，远不如其在 SHA2 测试中的相对效率，主要原因在于其目前尚未支持用于 ECDSA 的有限域运算查找表（lookup tables），这导致其在处理该类复杂算术运算时计算开销显著上升。

100 ETHTransfer 交易模拟证明生成时间如下：

RISC Zero (GPU): 7.3s
OpenVM (CPU): 7.6s
SP1 (GPU): 13s
Jolt (GPU): 82s

再一次，RISC Zero、OpenVM 和 SP1 表现出色，得益于它们对 EVM 关键操作（如 Keccak 哈希）的预编译支持。这种优化显著提升了模拟以太坊交易执行的证明生成速度。值得强调的是：即便在桌面级硬件上，能够在大约 7 秒内完成模拟 EVM 执行的证明生成，已代表 zkVM 技术的一个重要里程碑。如需进一步比较连续 EVM 区块执行的性能，建议访问 ETHProofs website 网站以获取更详细的数据与分析。

Scalability with Input Size (Fibonacci) 随输入规模扩展的可伸缩性（Fibonacci 测试）:
当 Fibonacci 序列的输入规模从第 10 项提升到第 100,000 项时，大多数 zkVM 实现的证明生成时间呈现出近似线性或略超线性增长趋势。

SP1（GPU）表现尤为出色，增长幅度极为缓慢，几乎没有明显的性能下降。
RISC Zero 和 OpenVM 的性能增长保持在中等水平，显示出一定的扩展能力。
Pico、Jolt 和 ZKM 的证明时间增长最为显著。

在某些 zkVM 实现中观察到的亚线性（sub-linear）增长可能并非计算效率本身提升，而是与证明聚合过程中产生的额外开销有关，尤其体现在缺乏或未充分优化连续性证明机制（continuation mechanisms）的架构中。

3.2 内存效率（峰值内存使用）

下图（原文所附）展示了不同 zkVM 项目在四个基准任务中的峰值内存使用情况（仅限 CPU 执行模式，部分含 GPU 数据）。对于每个项目，图中四个柱状分别代表其在 Fibonacci、SHA2、ECDSA 和 ETHTransfer 测试中的内存占用。

峰值内存使用示例（部分项目）：

100k-Fibonacci:
RISC Zero (GPU): 0.63GB (GPU Mem)
SP1 (GPU): 1.3GB (GPU Mem)
Nexus/Novanet (CPU): ~4GB
OpenVM (CPU): 8.2GB
RISC Zero (CPU): 9.2GB
Pico (CPU): 21GB
Jolt (CPU): 28GB
ZKM (CPU): 82GB
ECDSA Verification (k256):
RISC Zero (GPU): 0.49GB (GPU Mem)
SP1 (GPU): 1.3GB (GPU Mem)
Nexus/Novanet (CPU): ~4GB
RISC Zero (CPU): 4.5GB
OpenVM (CPU): 11GB
Pico (CPU): 20GB
SP1 (CPU): 21GB
Jolt (CPU): 58GB
ZKM (CPU): 84GB

SP1（GPU）、RISC Zero（GPU）、Nexus 和 Novanet 表现出相对恒定的内存使用，无论测试程序如何变化。然而，其他项目的内存占用则因程序特性而大幅波动，这种差异很可能受到数据结构设计以及内存访问频率的影响。

GPU 实现方案通常会降低主机（CPU）内存的使用，但会消耗大量的 GPU 显存；在本次基准测试中，所有基于 GPU 加速的项目都至少需要 24GB 显存。

Nexus 和 Novanet 即使在输入规模扩大时，也能维持稳定的内存使用量，但这种一致性是以显著延长的执行时间为代价的。

内存效率仍是 zkVM 技术中的一个积极研究方向，常见的优化方法包括：采用更高效的内存一致性证明机制（如多项式交互式证明，polynomial IOPs）、使用更小的加密字段，以及引入如“continuation（连续证明）”等优化技术。

3.3 证明大小（Proof Size）

下图展示了各个 zkVM 项目生成的证明文件大小（单位为千字节 kB）。

Proof Sizes (Selected Examples — 100k Fibonacci):

RISC Zero: 222 kB
Jolt: 232 kB
ZKM: 415 kB
OpenVM: 838 kB
SP1: 1.8 MB
Novanet, Nexus: Tens of MB

在所有基准测试中，RISC Zero 和 Jolt 一贯生成最为紧凑的证明文件，在文件体积方面表现优异。

相反，SP1 的证明显著更大（在 Fibonacci 以外的任务中超过 6 MB）。在部分场景下，SP1 和 ZKM 所生成的证明超过 1 MB，这可能表明其证明聚合算法仍有进一步优化的空间。

3.4 性能总结

下表汇总了各 zkVM 项目的综合性能结果。

在每个指标类别中表现最优的数据以绿色标注（原文图表所示）。

峰值内存使用仅比较 CPU 执行模式，因为 GPU 的显存分配机制不同，无法直接进行对比。

综合来看，RISC Zero 的整体性能展现出极高的一致性与稳定性；与此同时，SP1、OpenVM、Pico 和 Jolt 也在多个单项指标中取得了优异的表现。

3.5 瓶颈分析

通过详细的性能分析，识别出各 zkVM 实现中的主要性能瓶颈如下：

Jolt: 在 CPU 层面，其瓶颈主要来自 Lasso 的 Sumcheck 协议和 Spartan 证明生成过程。内存方面的限制则主要源于用于查找表的多变量多项式扩展（MLE）构建。
RISC Zero, SP1, ZKM, OpenVM: CPU 层面的主要瓶颈集中在递归证明（proof recursion）和多项式承诺方案（polynomial commitment schemes）上。内存开销方面，常见的瓶颈则源自 Merkle 树的构建。
Ceno: GKR 的 Sumcheck 协议同时对 CPU 和内存资源构成了主要限制。
Nexus, Novanet: 其采用的折叠式证明聚合方案（folding scheme）是导致 CPU 与内存性能受限的主要因素。

4. 选择 zkVM 的最佳实践

基于本次全面的基准测试结果，以下指南可用于帮助选择与配置适合的 zkVM 技术：

4.1 基于性能的选择标准

对于通用应用场景，若需在速度、内存效率与证明大小之间取得良好平衡，RISC Zero、SP1（尤其是在 GPU 加速模式下）以及 OpenVM 是极具吸引力的候选方案。尤其是 RISC Zero，在所有评估的计算任务中均展现出卓越且一致的性能表现。
对于那些具有高度专业化或计算密集型需求、且标准预编译无法满足的应用，强烈建议在选定的 zkVM 框架中实现自定义预编译。

4.2 GPU 配置要求

在基准测试的计算任务中，使用 GPU 加速版本的 SP1 和 RISC Zero 需要配备至少 24GB 显存的图形处理器。

4.3 内存配置建议

对于大多数 zkVM 的通用应用场景，推荐的系统内存为至少 32GB RAM。
对于内存使用密集的 zkVM，如 Jolt 或 ZKM，尤其是在运行复杂程序时，建议配置 128GB 或更高内存，以避免性能下降或内存耗尽错误。

5. 讨论

5.1 安全性与性能之间的权衡

关于这些基准测试结果的公平性，一个合理的担忧在于被评估的各个 zkVM 项目在安全性保障方面存在不同水平。若仅追求性能优化，可能会以牺牲安全性为代价。

目前，许多 zkVM 项目仍处于开发阶段，尚未完成全面的安全性验证。例如：

如果安全级别存在显著差异，性能比较可能具有误导性。未来的 zkVM 评估理应纳入对安全成熟度的评估，包括形式化验证工作的开展情况、已完成的第三方审计，以及是否存在严格的安全性证明等因素，以提供更全面的对比分析。

5.2 GPU 实现中的技术差异

SP1 和 RISC Zero 均提供了 GPU 加速功能，但它们的性能特性存在显著差异，暗示其底层架构存在根本性的不同。

通过对它们各自 GitHub 实现的比较分析，可以看出设计理念上的明显差异：

应注意，Jolt 的 GPU 实现目前仍不完整，且其架构可能会有重大调整。

在对比更为成熟的 GPU 实现时，SP1 的方法通过 Moongate 服务器对 CUDA 执行进行抽象，可能在可维护性方面具有优势，但这种方式也可能因将某些处理过程从 GPU 核心中剥离而引入额外开销。相反，RISC Zero 通过其硬件抽象层（HAL）直接访问 GPU，虽然在引入新的 CUDA 加速功能时初期实现复杂度可能更高，但该方式旨在通过减少抽象层，尽可能接近理论性能上限。

6. 结论

本研究通过标准化基准测试，对八种 zkVM 实现进行了全面比较，评估了它们的性能特征及其作为以太坊扩展解决方案的潜力。

我们的研究结果表明，RISC Zero、OpenVM 和 SP1 在执行与 EVM 相关的计算任务方面表现尤为强劲，使它们成为有望被集成至以太坊扩展方案（如 Layer 2 Rollup 或专用协处理器）的理想候选，从而直接提升网络的吞吐量与运行效率。

尤其值得注意的是，RISC Zero 在区块链相关关键指标上展现出卓越的效率：它在 GPU 模式下仅用 7.3 秒即完成了 100 笔 ETHTransfer 模拟执行的证明生成，CPU 峰值内存消耗控制在 10GB 以下（GPU 显存消耗不到 1GB），并生成了异常紧凑的证明文件（如 Fibonacci 运算约 222kB）。这些表现凸显了其在高吞吐量、低资源占用与低链上验证成本方面的巨大潜力 — — 这些都是提升以太坊可扩展性与用户体验的关键因素。

本次对比测试结果为以太坊社区的开发者、研究人员与决策者提供了宝贵的数据支持。通过更清晰地了解不同 zkVM 技术的当前能力与性能权衡，本研究旨在为高效、稳健的扩展解决方案的选择与开发提供指导，最终推动以太坊网络的持续演进与扩展。

参考文献

额外的参考资料已通过超链接形式在正文中引用。