zk-VM 是什么？全面解析零知识虚拟机的工作原理与应用场景

转发原文标题《零知识范式： 第 1 部分 – 什么是 zk-VM？》

1. 零知识证明：入门

什么是零知识证明（ZKP）？

如果您对零知识证明（ZKP）一无所知， Wired的这个视频 通过易于理解的示例和演示，以交互方式解释五个难度级别的概念。强烈推荐。

简而言之，ZKP 使一方（证明者）能够向另一方（验证者）证明他们知道某件事，而无需透露该事物是什么或任何其他信息。更具体地说，ZKP 证明了对一段数据的了解，或对计算结果的了解，而不泄露数据或输入。创建零知识证明的过程涉及一系列数学模型，将计算结果转换为一段无意义的信息，证明代码成功执行，并可以在以后进行验证。

在某些情况下，验证证明（在多轮代数转换和密码学之后构建）所需的工作量比运行计算所需的工作量要少。这种安全性和可扩展性的独特组合使得零知识加密成为如此强大的工具。

zkSNARKs：零知识简洁非交互式知识论证（Zero Knowledge Succinct Non-Interactive Argument of Knowledge）

• 依靠初始（可信或不可信）设置过程来建立验证参数
• 需要证明者和验证者之间至少进行一次交互
• 证明体积小且易于验证
• zkSync、Scroll 和 Linea 等汇总（rollup）使用基于 NARK 的证明

zkSTARKs：零知识可扩展透明知识（Zero Knowledge Scalable Transparent Argument of Knowledge）

• 无需可信设置
• 通过使用可公开验证的随机性来创建无需信任的可验证系统，即生成可证明的随机参数以进行证明和验证，从而提供高透明度
• 高度可扩展，因为它们可以快速（并非总是）生成和验证证明，即使底层见证（数据）的大小很大
• 证明者和验证者之间不需要交互
• STARK 需要生成更大的证明，因此比 SNARK 更难验证
• 与某些 zkSNARK 证明相比，该证明更难验证，但并不像其他证明那么难验证
• Starknet 以及 Lita、Risc Zero 和 Succinct Labs 等 zkVM 都使用了 STARK

（注意：Succinct 的桥接器使用 SNARK，但 SP1 是基于 STARK 的协议）

值得注意的是，所有的 STARK 都是 SNARK，但并非所有的 SNARK 都是 STARK。

为了更好地全面了解 SNARK 和 STARK，我们建议阅读Axiom的Yan Zhang和Yi Sun撰写的本<a href="https://medium.com/@krzhang/privacy-in-cryptocurrencies-zero-knowledge-and-zk-snarks-1-2-68ce1838fd9c”>系列文章，以及Ventali Tan 的 github中的本系列文章。

2.什么是zkVM？

虚拟机 (VM) 是运行程序的程序。在上下文中，zkVM 是作为生成零知识证明的系统实现的虚拟计算机，或用于为任何程序或计算生成 ZKP 的通用电路或工具。

zkVM 消除了设计和编写 ZK 时学习复杂数学和密码学的需要，并允许任何开发人员执行用他们喜欢的语言编写的程序并生成 ZKP，从而更容易与零知识集成和交互。从广义上讲，大多数对 zkVM 的引用都隐含地包括附加到执行程序的虚拟机上的编译器工具链和证明系统，而不仅仅是虚拟机本身。下面，我们总结了 zkVM 的主要组件及其功能：

zkVM 的主要组件

每个组件的设计和实现都由证明的选择（SNARK 或 STARK）和 zkVM 的指令集架构 (ISA) 决定。传统上，ISA 指定 CPU 的功能（数据类型、寄存器、内存等）以及 CPU 执行程序时执行的操作顺序。在上下文中，ISA 确定 VM 可解释和执行的机器代码。选择 ISA 可能会对 zkVM 的可访问性和可用性以及证明生成过程的速度和效率产生根本性的影响，并支撑任何 zkVM 的构建。

以下是 zkVM 及其组件的一些示例，供您参考。

zkVM 及其组件

目前，我们将从高层次上关注每个组件之间的交互，以便在后续文章中提供一个框架来理解代数和加密过程以及 zkVM 的设计权衡。

3. 抽象 zkVM 流程

下图是 zkVM 的抽象、概括的流程图，在程序通过 zkVM 组件时，根据程序的格式（输入/输出）进行拆分和分类。我们将在后续文章中深入研究每个过程。

zkVM 的一般流程

zkVM的流程大致如下：

• 编译阶段

1. 编译器首先将用传统语言（C、C++、Rust、Solidity）编写的程序编译为机器代码。机器代码的格式由 ISA 的选择决定。

• 虚拟机阶段

1. VM 执行机器代码并生成执行轨迹，即底层程序的一系列步骤。其格式由算术化选择以及多项式约束集预先确定。常见的算术化方案包括Groth16中的 R1CS 、halo2中的PLONKish 算术化以及plonky2和plonky3中的 AIR 。

• 验证阶段

1. 证明者接收轨迹并将其表示为一组受一组约束约束的多项式，本质上是通过数学方式映射事实将计算转换为代数。

2. 证明者使用多项式承诺方案 (PCS) 对这些多项式做出承诺。承诺方案是一种协议，允许证明者创建某些数据 X 的指纹，这称为对 X 的承诺，然后使用对 X 的承诺在不透露 X 的情况下证明有关 X 的事实。PCS 就是指纹；计算约束的“预处理”简洁版本。这允许证明者使用验证者在以下步骤中提出的随机值来证明有关计算的事实（现在以多项式方程表示）。

3. 证明者运行多项式交互式预言证明 (PIOP, Polynomial Interactive Oracle Proof)，以表明已提交的多项式代表满足给定约束的执行轨迹。PIOP 是一种交互式证明协议，由一系列轮次组成，其中证明者向多项式发送承诺，验证者用随机字段值响应，证明者在这些随机值下提供多项式的评估，类似于使用随机值“求解”多项式方程以概率说服验证者。

4. 应用 Fiat-Shamir启发式算法；证明者以非交互模式运行 PIOP，其中验证者的行为仅限于发送伪随机挑战点。在密码学中，Fiat-Shamir 启发式将交互式知识证明转换为数字签名以进行验证。此步骤对证明进行加密并使其零知识。

5. 证明者必须让验证者相信，相对于它发送给验证者的多项式承诺，所声称的多项式评估是正确的。为此，证明者生成“评估”或“开场”证明，该证明由多项式承诺方案（指纹）提供。

• 验证者阶段

1. 验证者通过遵循证明系统的验证协议，使用约束或承诺来检查证明。验证者根据证明的有效性接受或拒绝结果。

总之，zkVM 证明证明，对于给定的程序、给定的结果和给定的初始条件，存在一些输入导致程序在从给定的初始条件执行时产生给定的结果。我们可以将此陈述与流程结合起来，得到以下 zkVM 的描述。

zkVM 证明可以证明，对于给定的 VM 程序和给定的输出，存在某些输入会导致给定的程序在 VM 上执行时产生给定的输出。

4. 评估 zkVM

我们评估 zkVM 的标准是什么？换句话说，我们什么时候应该说一个 zkVM 比另一个更好？说实话，答案取决于用例。

Lita 的市场研究表明，对于大多数商业用例，在速度、效率和简洁性中，最重要的属性是速度或核心时间效率，具体取决于应用程序。有些应用程序对价格敏感，希望优化低能耗和低资本使用；对于这些应用程序，核心时间效率可能是最重要的优化指标。其他应用程序，特别是金融或交易相关的应用程序，对延迟敏感，希望优化速度。

大多数公开的性能比较都只关注速度，这很重要，但不是性能的整体衡量标准。还有一些重要的属性可以衡量 zkVM 的可靠性；其中大多数都达不到生产就绪标准，即使对于市场领先的现有企业来说也是如此。

我们特此建议 zkVM 应根据以下标准进行评估，分为两个子集：

评估 zk-VM 的主要标准

基线：衡量 zkVM 的可靠性

• 正确性
• 安全
• 信任假设

性能：衡量 zkVM 的功能

• 效率
• 速度
• 简洁

4.1 基线：正确性、安全性和信任假设

在评估任务关键型应用程序的 zkVM 时，应将正确性和安全性视为基线。需要有足够的理由对正确性充满信心，并且需要足够强大的安全性。此外，对于应用程序来说，信任假设必须足够弱。

如果没有这些属性，zkVM 对于应用程序来说可能比无用更糟糕，因为它可能无法按指定执行，并使用户遭受黑客攻击和利用。

一. 正确性

• VM必须按预期执行计算
• 证明系统必须满足其声称的安全属性

正确性由三个属性组成：

• 可靠性：证明系统是真实的，因此它所证明的一切都是正确的。验证者拒绝虚假陈述的证明；只有当输入确实产生结果时，它才会接受计算结果。
• 完整性：证明系统完整，可以证明所有真实的陈述。如果证明者声称它可以证明计算结果，那么它必须能够提供验证者接受的证明。
• 零知识：拥有证明并不能比知道结果本身更多地揭示计算的输入

‍

你可以有完整性而无可靠性；如果证明系统证明了一切，包括虚假性，显然它是完整的，但不可靠。相反，你可以有可靠性而无完整性；如果证明系统证明了某个程序存在，但无法证明计算，显然它是可靠的（毕竟，它从未证明过任何虚假性），但不完整。

二.安全性

• 涉及可靠性、完整性和零知识的容差

实际上，所有三个正确性属性都具有非零容差。这意味着所有证明都是正确性的统计概率，而不是绝对确定性。容差是指一个属性失败的最大可容忍概率。零容差当然是理想的，但 zkVM 在实践中并没有对所有这些属性都实现零容差。完美的可靠性和完整性似乎与简洁性不相容，并且没有已知的方法可以实现完美的零知识。衡量安全性的一种常见方法是使用安全位，其中 1 / (2^n) 的容差称为n位安全。安全位越多越好。

如果 zkVM 完全正确，那并不一定意味着它是可靠的。正确性仅意味着 zkVM 满足其安全属性，直至声明的容差。这并不意味着声明的容差足够低，可以投入市场。此外，如果 zkVM 足够安全，那并不意味着它是正确的；安全性指的是声明的容差，而不是实际实现的容差。只有当 zkVM 既完全正确又足够安全时，才能说 zkVM 可靠，直至声明的容差。

三.信任假设

• 假设证明者和验证者诚实，从而得出 zkVM 可靠运行的结论

当 zkVM 具有信任假设时，这通常采用可信设置过程的形式。在使用证明系统生成第一个证明之前，ZK 证明系统的设置过程会运行一次，以生成一些称为“设置数据”的信息。在可信设置过程中，一个或多个人会生成一些随机性，这些随机性会被纳入设置数据中，并且需要假设其中至少有一个人删除了他们纳入设置数据的随机性。

实践中常见的信任假设模型有两种。

诚实多数信任假设是指在一组 N 个个体中，超过 N/2 的个体在与系统的某些特定交互中表现出诚信，这在区块链中很常见

“N 中 1” 信任假设指出，在一组 N 个个体中，至少有一个人在与系统的一些特定交互中表现出诚信，这通常用于基于 MPC 的工具和应用程序。

人们普遍认为，在其他条件相同的情况下，没有信任假设的 zkVM 比需要信任假设的 zkVM 更安全。

4.2 zkVM 三难困境：平衡 zkVM 中的速度、效率和简洁性

zkVM 的三难困境：速度、效率和简洁性

速度、效率和简洁性都是可变的属性。所有这些因素都会影响 zkVM 的最终用户成本。 在评估中如何衡量它们取决于应用程序。通常，最快的解决方案不是最高效或最简洁的；最简洁的解决方案不是最快或最高效的；等等。让我们首先定义每个属性，然后再解释它们的关系

一. 速度

• 证明者多快可以生成证明
• 以挂钟时间测量，即从计算开始到结束所经过的时间

速度应根据特定的测试程序、输入和系统进行定义和测量，以确保可以对其进行定量评估。此指标对于对延迟敏感的应用程序至关重要，因为这些应用程序必须能够及时获得证明，但随之而来的是更高的开销和更大的证明大小

二.效率

• 证明者消耗的资源，越少越好
• 可以用用户时间（即程序代码所耗费的计算机时间）来近似

证明器消耗两种资源：核心时间和空间。因此效率可以细分为核心时间效率和空间效率。

核心时间效率：证明器在所有核心上运行的平均时间乘以运行证明器的核心数量。对于单核证明器，核心时间消耗和速度是一回事。对于在多核系统上以多核模式运行的多核证明器，核心时间消耗和速度不是一回事。如果一个程序充分利用了 5 个核心或线程 5 秒，那么用户时间就是 25 秒，挂钟时间就是 5 秒。

空间效率：指使用的存储容量，例如 RAM

用户时间是衡量运行计算所消耗能量的指标，这一点很有意思。在几乎所有时间所有核心都得到充分利用的情况下，CPU 的能耗应该保持相对稳定。在这种情况下，受 CPU 限制、主要为用户模式的代码执行所花费的用户时间应该与该代码执行所消耗的瓦时数（即能量）大致成线性比例。

对于任何规模足够大的验证运营而言，节约能源消耗或计算资源的使用应该是一件有趣的事情，因为验证的能源费用（或云计算费用）是一笔可观的运营成本。出于这些原因，用户时间是一个有趣的指标。较低的验证成本使服务提供商能够将较低的验证价格转嫁给对成本敏感的客户。

这两种效率都与验证过程的能耗和验证过程所用的资本量有关，而资本量又与验证的财务成本有关。为了使效率的定义可操作化以便于测量，必须相对于一个或多个测试程序、每个程序的一个或多个测试输入以及一个或多个测试系统进行定义。

三.简洁

• 生成的证明的大小以及验证它们的复杂性

简洁性是三个不同指标的综合，其中证明验证的复杂性可进一步细分为：

• 证明大小： 证明的物理大小，通常以千字节为单位
• 证明验证时间： 验证证据所需的时间。
• 证明验证空间： 证明验证期间的内存使用情况

验证通常是单核心操作，因此速度和核心时间效率在这种情况下通常是等效的。与速度和效率一样，实施简洁性的定义需要指定一组测试程序、测试输入和测试系统。

定义了每个性能属性后，我们现在来说明优化一个属性相对于其他属性的微小影响。

• 速度：证明生成速度快，证明规模大，但证明验证速度慢，生成证明需要消耗更多资源，效率低下
• 简洁性： 证明者需要更多时间来压缩证明。但证明验证速度很快。证明越简洁，计算开销就越高
• 效率：最小化资源使用会降低证明生成的速度和证明的简洁性

一般来说，优化一种品质意味着不会优化另一种品质，因此需要进行多维分析，根据具体情况选择最佳解决方案。

在评估中对这些属性进行加权的一个好方法可能是定义每个属性的可接受水平，然后确定哪些属性最重要。最重要的属性应该进行优化，但其他所有属性的水平应保持足够好。

下面我们总结了每个属性及其关键考虑因素：

zkVM 的评估特性

5. 下一步是什么？

通过上表，我们结束了我们系列的第一篇文章。在接下来的文章中，我们将基于上面所示的流程图来解释 zkVM 中的常见算术和加密过程。

如果您发现这有帮助，请访问我们的网站和gitbook以了解有关我们在 Lita 构建的更多信息。

另外，请在X和Discord上关注我们，及时了解最新动态，以免错过本系列的其余内容。