1. 引言

2025年3月，Nexus团队发布了 Nexus zkVM 3.0，本文将更详细地介绍其设计意图与功能。

零知识虚拟机（zkVM）领域正在迅速演进，推动力来自于对可扩展、高效且可靠的系统的需求——这些系统应能够在不受计算规模、编程语言或底层架构限制的前提下，证明任意程序的正确执行。

Nexus正是基于这一愿景推出了 Nexus zkVM 3.0，它是一次经过深思熟虑的虚拟机重构，解决了长期存在的限制问题，并为新一代零知识虚拟机引入了关键创新。

在 zkVM 3.0 中，引入了多个架构性进步，包括：

• two-pass execution model 双遍执行模型
• 通过对数导数（logarithmic derivatives）进行的离线内存检查，
• 以及与 S-two 证明器的集成。

这些改进旨在提升证明效率、减少内存开销，并为模块化和可扩展的系统奠定基础。更重要的是，zkVM 3.0 建立在前几代产品的经验教训之上，为未来的分布式和按需选择式（a la carte）证明打下了良好基础。

2. 基础回顾：zkVM 1.0 与 2.0

最初版本的 Nexus zkVM 为可扩展、可验证的计算奠定了重要基础。

zkVM 1.0 引入了一个通用型的递归零知识虚拟机，利用了如 Nova、SuperNova 和 CycleFold 等基于 folding 的证明系统。

这些系统展示了递增式可验证计算（incrementally verifiable computation，IVC）的可行性，能够对任意长度的程序执行生成简洁的证明。其架构采用了 RISC-V RV32I 指令集，支持标准编译工具链，突显了递归在大规模计算中的强大威力。

在此基础上，zkVM 2.0 通过支持 HyperNova 和集成 Jolt（一个基于 Lasso lookup argument的证明系统）扩展了架构。

这些增强提升了前端表达能力和证明组合性。基于 Nova 和 HyperNova 的版本也采用了优雅而富有表现力的 folding 式递归方式，支持复杂程序，并保持低内存开销。

然而，这些设计也面临挑战：

• 基于 folding 的递归证明系统在内存检查方面依赖于 Merkle Trie，虽然这是一种安全且成熟的结构，但它带来了性能开销，限制了可扩展性。

此外，Nexus的 folding 式证明系统实现的是统一的 IVC 方案，不支持成本模块化 —— 即所有指令路径的证明开销近乎相同，无论实际使用与否。为了实现递归组合，依赖 Grumpkin 椭圆曲线循环，这又引入了非原生域运算的额外复杂性。最后，由于使用了 Kate、Zaverucha 和 Goldberg 提出的 KZG 多项式承诺方案，这两个版本都需要可信设置。

尽管存在这些权衡，zkVM 1.0 与 2.0 在通用 zkVM 的发展过程中发挥了关键作用，并为 zkVM 3.0 中的创新提供了坚实基础。

3. zkVM 3.0：为可扩展证明而优化的架构

通过 zkVM 3.0，Nexus在早期版本的基础上，构建了一个重新设计的架构，以提升证明系统的效率与模块化能力。本次发布解决了前几代实现中的关键限制，提供了一个更具可扩展性、对开发者更友好的可验证计算平台。

Nexus将重点转向可扩展性与灵活性，并引入了一系列关键创新，以简化性能瓶颈并扩展系统能力：

• 1）基于 LogUps 的离线内存检查
• 2）双遍执行模型
• 3）集成 S-two 证明器
• 4）迁移至小数域（M31）
• 5）支持 RISC-V RV32I
• 6）基于组件的架构

3.1 基于 LogUps 的离线内存检查

用一种基于对数导数的全新技术（称为 LogUps）替代了基于 Merkle 树的内存检查。这种方法允许在不存储或管理整个内存状态的情况下，跟踪并验证内存访问模式。

相反，只需维护紧凑的摘要，便可高效地总结内存的读写操作。这大大降低了证明复杂性，使得能够以无状态且可扩展的方式验证内存行为。

3.2 双遍执行模型

zkVM 3.0 引入了双阶段执行模型，以改进执行轨迹（execution trace）的生成方式。

• 在第一遍中，程序采用较为传统的哈佛架构执行，zkVM 执行程序以收集内存使用和执行统计信息，帮助建立固定的内存布局。
• 在第二遍中，采用固定内存布局再次执行相同的程序，zkVM 在该布局下对程序进行确定性重执行，生成简洁且优化后的执行轨迹。

这一策略帮助减少不必要的轨迹数据，同时实现精确的约束编码，从而提升证明生成性能与验证效率。

3.3 集成 S-two 证明器

为了避免可信设置并提升证明性能，集成了由 StarkWare 开发的透明 STARK 证明器 —— S-two。S-two 使用基于哈希的承诺方案，并支持代数中间表示（AIR），Nexus用其来编码 zkVM 的约束系统。

这一选择提升了安全性，简化了部署流程，并进一步提供了可预期的后量子安全性。

3.4 迁移至小数域（M31）

zkVM 3.0 将其执行域迁移至 S-two 所使用的Mersenne素数域（M31），该域支持在 32 位架构上实现快速的原生算术运算。

这一迁移减少了承诺开销，避免了非原生算术转换的需要，简化了约束的生成与评估流程。同时也确保证明和验证两个阶段都能受益于硬件加速与更紧凑的执行轨迹表示。

3.5 支持 RISC-V RV32I

Nexus zkVM 指令集基于广泛采用的开放指令集架构 RISC-V RV32I。这个决策确保开发者几乎无需修改即可使用标准工具链和熟悉的编译器基础设施。这也为未来的扩展提供便利，并提升真实世界应用的可移植性。

3.6 基于组件的架构

Nexus团队重构了其 zkVM 的执行轨迹矩阵，使其遵循组件化模型。更具体地说，执行轨迹现在被划分为若干逻辑单元 —— 包括 CPU、寄存器内存、程序内存、数据内存以及执行逻辑 —— 每个组件负责执行轨迹中的一个特定部分。

这种设计实现了模块化，简化了未来的扩展（如分布式证明），并为“按需付费”的成本模型奠定基础 —— 开发者只需为其程序实际使用的功能付费。

4. zkVM 3.0 组件

Nexus将 zkVM 3.0 的执行轨迹结构化为一个统一的矩阵，其中每一行对应一次指令执行周期，每一列则追踪一个特定变量或子组件的状态。这个轨迹记录了虚拟机状态的完整演化过程，并构成 zkVM 输出证明的基础。

为了支持模块化和清晰的语义划分，轨迹在概念上被划分为以下几个组件：

• 1）CPU
• 2）寄存器内存（Register memory）
• 3）程序内存（Program memory）
• 4）数据内存（Data memory）
• 5）指令执行（Instruction execution）

4.1 CPU

CPU 组件负责取指、解码并为指令执行做好准备。它包含的轨迹列包括：

• 当前的程序计数器（PC）
• 解码后的操作码（opcode）
• 指令分类与跳转行为的控制标志（control flags）

该组件确保程序能按正确的指令流推进，并强制执行跳转目标与终止行为的规则。

4.2 寄存器内存（Register memory）

该组件模拟虚拟机的通用寄存器文件，用于存储中间值和持久值。其内容包括：

• 每个周期所有寄存器的值
• 读/写操作的标志位
• 用于确保读、写与执行之间数据一致性的约束

寄存器内存确保算术、逻辑和内存类指令在寄存器使用上的正确性。

4.3 程序内存（Program memory）

程序内存是只读的，用于存储按字节寻址的指令流。其列用于：

• 表示程序的字节级内容
• 支持取指逻辑（通过内存读取约束）
• 强制执行与数据内存的哈佛结构分离

这使验证者可以确认每条指令确实来自已提交的程序区域。

4.4 数据内存（Data memory）

数据内存在程序执行过程中处理读写操作，用于堆栈操作、堆分配和基于内存的计算。
其轨迹列用于追踪：

• 每个周期读/写的内存地址和值
• 离线内存检查所使用的访问模式
• 基于 LogUp 的约束，用于验证摘要正确性

与程序内存不同，数据内存是动态的，其访问模式由执行过程中计算出的值决定。

4.5 指令执行（Instruction execution）

该组件负责指令的具体语义执行。包括：

• 每条指令的输入/输出操作数
• 定义指令类型的标志位（例如 ALU、内存、控制流等）
• 用于强制执行算术与逻辑操作的约束

每一行都会激活与特定指令操作码对应的约束，确保其在输入有效的前提下执行正确的计算。

这些组件在执行轨迹矩阵中并不是物理上分离的，而是逻辑上区分开的，以便于理解。在内部，zkVM 3.0 使用共享列与专用列组合来表示这些组件，从而在保持模块化语义的同时，实现高效的约束组合。这种组织方式也为未来版本中按组件进行证明提供了清晰路径。

5. 算术化示例概览

为了说明 zkVM 3.0 如何构造一个可验证的执行证明，接下来看一个在虚拟机中运行的简单 RISC-V 程序。算术化过程将该程序的行为转换为结构化的执行轨迹，随后通过代数约束进行验证。

5.1 作为矩阵的执行轨迹

zkVM 3.0 将程序的执行表示为一个大型矩阵，其中：

• 每一行对应一次指令执行周期
• 每一列表示 zkVM 某个组件（如 CPU、内存、执行逻辑等）所用的状态变量或控制信号

该执行轨迹捕获以下内容：

• 程序计数器以及当前正在执行的指令
• 指令执行前后的寄存器值
• 被读写的内存地址与数据值
• 用于解码、分支和算术操作的中间信号

随着程序的运行，该矩阵逐行演化，最终形成完整的计算记录。

下图展示了该矩阵及其逻辑结构的可视化布局：

5.2 基于 AIR 的约束系统

该轨迹的正确性通过代数中间表示（Algebraic Intermediate Representation，AIR）强制执行。AIR 系统定义了：

• 代数转移约束：用于将时间点 $t$ 与 $t+1$ 的状态联系起来
• 边界约束：如输入/输出条件等限制

如：

• 针对如 ADD 这类 ALU 指令的转移约束，会确保程序计数器（PC）在相邻两行之间增加 4。也就是说，如果第 $i$ 行对应一条 ADD 指令，则有 PC[i+1] = PC[i] + 4。这符合 RISC-V 的语义，其中大多数指令占用 4 个字节。
• 边界约束 会确保程序计数器从正确的入口点开始（通常是 0），并在执行结束时满足一个终止条件。

这些约束均以有限域（zkVM 3.0 中为 M31）上的low-degree多项式 表示，从而能高效地在 S-two 证明系统中强制执行。

5.3 子列与子约束集（Subsets of columns and constraints）

并非所有列在每一行上都处于激活状态：

• 某些列仅在取指、内存读写或算术运算时相关。
• zkVM 将这些列按逻辑组件组织，使得特定的约束只在需要时才激活。

这种结构在保持完整表达能力的同时，最大程度地减少了约束开销。

下图展示了不同组件如何映射到统一轨迹中的列子集：

5.4 基于摘要的内存约束

为避免开销高昂的 Merkle 证明，zkVM 3.0 使用 LogUps 实现离线内存检查。zkVM 并不将内存表示为完整的状态向量，而是构造多项式约束来验证内存访问摘要：

• 执行轨迹中记录了内存地址与访问类型（读/写）。
• 使用代数规则维护并更新一组摘要行（digest row）。
• 约束确保该摘要在各时间步骤之间的行为是正确的。

这使得 zkVM 能以代数方式验证内存使用，而无需保存完整的内存状态。

这一算术化策略确保 zkVM 3.0 能将真实世界的计算转化为紧凑、可验证的证明，同时不牺牲通用性或性能。它也为未来的模块化和分布式证明架构奠定了基础。

6. 当前 Nexus zkVM 3.0 的限制

尽管 zkVM 3.0 在架构上进行了重大升级，仍然存在一些核心限制。这些权衡体现了系统快速演进过程中的挑战，也为Nexus未来的开发路线提供了指导。在持续改进 zkVM 的过程中，Nexus团队将专注于模块化、可扩展性与适应性，确保系统能灵活应对日益复杂与分布式的应用需求。

zkVM 3.0 中的以下设计选择既展示了现有成果，也揭示了未来的改进空间：

• 单体式执行轨迹（Monolithic trace）
  所有组件共享同一个轨迹矩阵，导致存在大量未使用的列，从而使证明变得更大；此外组件之间耦合紧密，限制了对各组件定制优化的灵活性。
• 无模块化证明（No modular proofs）
  zkVM 目前仅生成一个统一的证明，限制了并行/分布式证明、子组件复用和跨模块程序阶段的组合能力。
• 统一的指令成本（Uniform instruction cost）
  每条指令对轨迹施加的负载相近，这妨碍了基于使用频率的优化策略，并对资源敏感的部署造成挑战。
• 约束复杂性（Constraint complexity）
  尽管基于 AIR 的约束系统具有强大表达力，但其可能生成高次多项式并引入组件间的强依赖。

在下一版本Nexus zkVM 的优先任务是引入模块化证明、可定制的成本结构和分布式证明生成机制，让开发者在多样化环境中获得更多控制力、更高效率与更强扩展性。

7. 对未来 zkVM 的愿景：模块化与分布式证明

展望 zkVM 的下一次迭代，Nexus的目标是突破 zkVM 3.0 的单体架构，构建一个更加模块化、可扩展的系统设计。

Nexus团队计划将统一的轨迹矩阵分解为每个组件独立的轨迹（trace），每个轨迹只捕捉一个子系统（如 CPU、内存、算术逻辑单元）的行为。每个组件轨迹将配备自己的一组约束和独立的证明。为了维护系统的一致性，将通过基于 LogUp 的摘要约束将共享变量在组件之间进行连接。

7.1 模块化组件轨迹

通过分离各组件，可以实现：

• 并行化证明生成：每个子系统可以独立且同时进行证明生成
• 按需计费（a la carte costing）：开发者只需为其程序实际使用的组件支付资源费用
• 精准优化：可以根据每个组件的语义特点与使用频率，微调其约束系统

7.2 指令级拆分

除了划分主要子系统之外，还计划将每条指令的执行逻辑隔离到浅层、专用的轨迹片段中。如，像 ADD、JUMP 或 SHA256 这样的指令可以在仅在相关时激活的轻量子组件中处理。这将使得能够：

• 最小化常见程序的轨迹规模
• 降低多项式degree和约束数量
• 以最小化影响的方式支持指令集扩展

通过这一演进，Nexus的目标是使未来版本的 zkVM 更具可扩展性、可定制性和开发者友好性，同时保持当前版本所定义的通用性与安全性保障。

7.3 预期成果

• 全模块化架构，支持可选组件
• 支持预编译模块和新指令集
• 跨电路的高效复用
• 支持并行证明与轨迹压缩
• 采用透明、基于哈希的安全模型

8. 总结

通过 zkVM 3.0，Nexus朝着构建一个快速且模块化的零知识虚拟机迈出了关键一步。通过引入小域算术、离线内存验证机制以及 S-two 证明器，设计出了一个在性能与通用性之间取得良好平衡的系统。

同时，也意识到现有架构中的一些局限性——从单体式轨迹结构到固定成本的指令编码。这些经验教训将直接引导未来 zkVM 的演进方向，其中包括模块化证明、组件隔离和分布式证明生成等关键特性。

Nexus致力于打造一个开发者可以随规模扩展、灵活适配，并在高可信环境中放心使用的 zkVM。zkVM 3.0 是这一目标的基石——Nexus团队将继续在此基础上不断构建前进。

参考资料

[1] Nexus团队2025年5月30日博客 zkVM 3.0 and Beyond: Toward Modular, Distributed Zero-Knowledge Proofs
[2] Starkware团队2025年6月25日博客 Nexus x S-two: Building the future of scalable zkVMs