探索zk-VM设计权衡：零知识范式（第二部分）

探索 zkVM 设计的权衡

2024 年 9 月 4 日

1. 介绍：设计、平衡、权衡

在我们之前的博客中，我们深入研究了零知识证明 (ZKP) 和零知识虚拟机 (zkVM) 的基础知识，全面了解了 zkVM 的流程。现在，让我们重点关注塑造 zkVM 的复杂设计选择和权衡。

追求最佳 zkVM 设计的关键在于实现微妙的平衡。这不仅仅是关于核心性能指标——正确性、安全性、零知识性、信任假设、效率、速度和简洁性。它还需要仔细考虑开发人员的体验、更广泛的采用潜力以及整体系统复杂性。认识到这个复杂领域中固有的权衡至关重要。本文旨在分享我们从研究和设计过程中获得的宝贵见解。我们希望引发关于优化 zk-VM 性能和可用性的讨论，最终为更广泛的采用铺平道路，并加速可验证计算的创新。

2. 揭秘 zk-VM 设计：鸟瞰

在深入研究设计权衡的复杂性之前，让我们先探讨 zk-VM 的基本设计方面及其在 zk-VM 系统和可验证计算过程中的相互关联的角色。

zk-VM 设计：鸟瞰

ISA ↔ VM

指令集架构 (ISA) 是由物理计算机或虚拟机实现的计算模型。它规定了编译器生成并由 VM 执行的机器代码的格式，包括 VM 的机制，例如寄存器布局和内存模型。

编程语言支持 ↔ 编译器

选择要支持的编程语言决定了哪些高级语言可以编译成机器代码。

算术化 ↔ VM, Prover, Verifier

算术化是将计算问题转换为代数问题的过程。 这包括：

i) 约束系统：一种通过多项式约束编码 VM 执行正确性的系统。

ii) 域：用于在算术化中表示和操作数据的代数结构。

证明系统 ↔ Prover, Verifier

证明系统是一种密码协议，用于生成和验证简洁的零知识证明，证明者“知道”算术化定义的代数问题的解。它由两个主要组成部分构成：

i) 交互式预言机证明 (IOP)：证明者通过涉及预言机的交互来说服验证者某个事实的真实性的过程。证明者将多项式发送给预言机，验证者查询预言机以获取特定点的评估，预言机提供诚实的答案。

ii) 多项式承诺方案 (PCS)：一种用于承诺多项式并在以后证明它们在特定点的评估的密码协议。

• 模块化 vs. 整体架构 ↔ 整个 zk-VM 系统

zk-VM 的设计可以是模块化的，由可插拔的组件构建，也可以是整体的，是一个封闭的集成解决方案。

以下部分剖析了上述各个方面关键设计选择背后的动机。

3. zkVM 应该使用什么指令集架构？

ISA 是物理计算机和 VM 的一个关键组件，定义了它们实现的计算模型。

ISA 解决的关键问题

1. 内存模型：定义存在多少地址空间、它们的大小和它们的功能。 例如：

• 冯·诺依曼架构：用于读取、写入和执行的单个地址空间
• 哈佛架构：用于数据（可读写）和代码（可执行）的单独地址空间
• 32 位 vs. 64 位 ISA：32 位地址允许 2^32 个不同的地址，而 64 位地址允许 2^64 个不同的地址。

2. 指令集：指定模型定义的原始操作，形成所有程序的构建块。
3. 寄存器：详细说明寄存器的数量、它们可以保存的数据类型及其用途。
4. 调用约定：概述函数调用的协议，包括参数传递、返回值和寄存器管理。

用于 zk-VM 的 ISA 可以大致分为通用 ISA 和 zk 优化 ISA。

通用 ISA 与 zk 优化 ISA

指令复杂度

支持更多指令或执行更多工作的指令的 ISA 往往会导致每个指令的证明和验证复杂度更高。 然而，它们也减少了解决问题所需的指令数量。

对成本的净影响

ISA 复杂度对证明和验证成本的净影响并不简单。 特定计算的总成本可以量化为：每个指令的成本 x 指令数量。

增加 ISA 复杂度往往会增加每个指令的成本，同时减少所需的指令数量。 根据具体情况，添加或删除复杂度可能是有益的，也可能是有害的。

zk-VM ISA：选择与影响

总的来说，ISA 的选择会影响 zk-VM 的效率、速度和简洁性，以及指令的复杂度。 具有更复杂指令的 ISA 减少了所需的指令数量，但增加了每个指令的复杂度。 zk 优化 ISA 提供了针对零知识证明量身定制的潜在性能优势，而通用 ISA 则利用现有的编译器技术和优化，从而降低了开发复杂性并缩短了上市时间。

为什么 Valida 选择自定义 ISA？

Valida 使用针对高性能 zk 证明优化的自定义 ISA，这与为电子计算机设计的标准 ISA 不同。 使用自定义 ISA 的权衡是，它需要 Lita 构建我们自己的编译器工具链，使开发人员能够用熟悉的语言（如 C）编写代码并生成等效的 Valida ISA 机器代码。 这是一项具有挑战性的工作，但我们相信，新的特定领域 ISA 对于促进向无需信任系统的范式转变至关重要。 尽管存在挑战，但这种承诺推动了我们的努力。

我们将在以后的文章中更深入地讨论 Lita 的自定义 ISA。

4. zkVM 应该支持哪些编程语言？

用于 zk-VM 的编程语言可以大致分为两个维度：抽象级别和领域特异性。

抽象级别

• 低级语言：这些语言呈现了一种低抽象的计算模型，要求程序员详细说明如何执行计算，相对于目标计算环境支持的原始操作而言。
• 高级语言：这些语言提供了一种更高的抽象模型，允许程序员指定所需的结果，而无需明确指定如何执行计算。

领域特异性

• 通用语言：这些语言专为广泛的应用而设计，没有针对任何特定领域进行定制。
• 领域特定语言：这些语言专为特定的应用领域而设计，优化了针对目标用例的功能和特性。

与领域特定语言绑定的优势

一些 zk-VM 项目与领域特定语言绑定，该语言是支持该 zk-VM 编程的唯一高级语言，从而提供以下优势：

1. 支持具有最小功能集的单一语言简化了实现。
2. 可以根据 zk-VM 的功能定制语言特性，从而提高实现的简易性。
3. 可以针对最有效的 zk-VM 实现优化高级语言。

此类 zk-VM 的示例包括：Cairo zk-VM（与 Cairo 语言绑定）、Lurk zk-VM（与 Lurk 语言绑定）和 Polygon zk-EVM（与 Solidity 绑定）。

支持多种通用高级语言的优势

或者，某些 zk-VM 项目支持多种通用高级语言，从而提供以下优势：

1. 开发人员可以使用功能丰富、熟悉的语言。
2. 开发人员可以利用已建立的编译器技术，从而降低开发成本，并且允许复杂的编译器优化，而无需重新实现。

此方法的著名示例包括 Valida、RISC Zero 和 Succinct SP1。

zk-VM 编程语言：选择与影响

选择要支持的适当语言会极大地影响解决复杂问题的难易程度以及开发人员的采用率。 本质上，这归结为可用性和可访问性。 理想情况下，zk-VM 会支持所有语言，从而使 ZKP 真正通用。 然而，要实现这一雄心勃勃的目标，需要一种战略方法。

这些考虑因素与通用编程类似。 例如，与 C 相比，Rust 的严格内存模型最大限度地减少了安全漏洞，但代价是增加了复杂性，并且可能降低效率。 最终，最佳选择取决于项目的具体目标和开发社区的需求。 在这些因素之间取得平衡对于构建既强大又易于访问的 zk-VM 至关重要。

5. zkVM 应该使用什么算术化策略？

算术化是将计算语句（例如 VM 的机器指令）根据代数进行编码的过程。 在 zk-VM 中，此过程涉及执行跟踪的表示和表达正确执行的多项式约束。

通常，算术化中的事实是从环上的向量空间（通常是有限域）中的元素集合。 这些事实可以表示为系数形式或点评估形式的多项式。

我们将讨论算术化策略，重点关注两个主要方面：约束系统和域。

5.1 约束系统

在 zk-VM 中，执行跟踪（记录 VM 在每个计算步骤的状态）被转换为有限域元素的矩阵或向量。 然后，执行的正确性被编码为这些元素之间的多项式方程或“约束”，从而允许使用代数技术解决计算问题。

1. Rank-1 约束系统 (R1CS)

R1CS（Rank-1 约束系统）约束可以从更高级别的“电路”规范自动生成和优化，如 Circom 等工具中所见。 然而，约束规范通常可能比见证大得多，因此需要进行预处理才能有效地管理复杂性。 这可能会导致证明系统中的巨大复杂性，如 Groth16 的电路特定可信设置或 Spartan 的“稀疏矩阵承诺”等协议所证明的那样。

2. 代数中间表示 (AIR)

另一方面，AIR 约束提供了一种统一的表示，允许验证者直接使用简洁的格式，从而无需预处理。 尽管有此优势，AIR 约束需要精心设计，从而限制了自动化工具的使用。 它们的统一性也使得它们不太适合描述没有通常在 VM 中发现的重复结构的计算。

3. PLONKish

PLONKish 约束代表了一种折衷方案，具有部分统一的结构。 它们利用非统一的“复制约束”和“选择器”来以统一的方式表达更通用类型的计算。 虽然这些约束需要预处理，但与 R1CS 相比，该过程更简单且成本更低。 大多数现代基于 AIR 的证明系统，包括 plonky3/Valida，都包含这些更通用类型的约束，以增强其表达能力。

通用 vs. 特殊用途协议

诸如 AIR、R1CS 和 PLONKish 之类的约束系统是通用的，这意味着它们可以编码任意计算。 这种灵活性使它们适用于广泛的应用。

然而，算术化过程还可以包含特殊语句，这些语句编码难以或昂贵地表达为多项式方程的事实。 例如，确保一个向量包含与另一个向量相同的条目（可能以不同的顺序排列）可能是一项复杂的任务。 可以使用专门的

IOP 作为子协议来证明这些特殊语句。有效合并此类专门语句可以极大地提高 zk-VM 的效率和复杂性。

5.2 域

环是一种代数结构，其特征在于加法和乘法运算，这些运算满足一些基本的代数定律。 在环中，要求加法是可交换、结合、零消除和可逆的。 环中的乘法要求是结合、单位和对加法的可分配。 根据定义，域是乘法可逆的环，这意味着域的每个非零元素都具有乘法逆元。 有限域是只有有限多个不同值的域。

设计 ZK 证明协议通常需要选择一个或多个环或域，通常涉及扩展域以获得额外的安全性。

基于椭圆曲线的协议： 基于椭圆曲线的 ZK 证明协议尤其受到系数域选择的影响。 每条椭圆曲线都由有限域上的多项式方程定义，从而形成椭圆曲线群。 该协议从此群中选择一个点，以生成素数阶的循环子群，该子群通常与有限域 Fp 同构。

此设置允许从 Fp 的加法群到椭圆曲线群的同态，从而可以使用来自 Fp 的系数的多项式来促进零知识协议。 这些协议通常需要大域（例如，255 位）以确保安全性，这会引入计算开销，但简化了使用大数的运算。 对于较小的域（例如，32 位或 64 位），使用扩展域来实现必要的安全级别，如 Plonky2 和 Plonky3 等协议中所见。

最新进展： 最近的进展使 ZK 证明协议能够在各种类型的域和环上运行，从而提高了灵活性和性能。 例如，新协议可以在二元域（例如，Binius）、任意有限域（例如，Brakedown）甚至不是域的环（例如，Rinocchio）上工作。 这些发展允许选择最适合特定用例的环。 然而，在当前研究中，容纳常用的环（如 32 位和 64 位整数环）仍然是一个挑战。

zk-VM 算术化策略：选择与影响

选择正确的约束系统对于优化 zk-VM 的效率和复杂性至关重要。 诸如 R1CS、AIR 和 PLONKish 之类的系统在预处理要求和对不同类型计算的适用性方面提供了各种优势和权衡。 域（和环）的选择是 zk-VM 设计的一个基本方面，直接影响零知识证明的效率和安全性。

由于各种 zk-VM 设计中不同的算术化策略结果不一，很难将其归纳。但是，一项指标上的改进通常会使另一项指标恶化。例如，更大的简洁性通常会增加证明的复杂性。小巧、安全、易于验证的证明很难生成，而更容易生成的证明往往更大、更难验证或安全性较低。因此，并不存在普遍的最佳策略；用例和优先级将始终驱动设计选择。

6. 什么证明系统最适合 zkVM？

zk-VM 中的验证系统通常是一个 (zk)-SNARK 或 (zk)-STARK，由两个主要组成部分构成：

1. 交互式预言机证明 (IOP)：在此协议中，证明者将见证的列表示为多项式，并通过提供这些多项式在验证者随机抽样的“挑战点”的评估来论证见证满足约束。

2. 多项式承诺方案 (PCS)：此加密协议允许证明者使用简洁的“承诺”来表示多项式，并在以后证明这些承诺的多项式在选定的查询点评估为特定值。

6.1 交互式预言机证明

重要的是要注意，“IOP”和“多项式 IOP”通常可以互换使用。 在 zk-VM 中，所有 IOP 都涉及 SNARK 中的多项式预言机。 在这种情况下，此处对 IOP 的所有引用都指的是 PIOP。

IOP 是在证明者和验证者之间进行的交互协议。 协议的每一轮都包括：

• 证明者将多项式“预言机”发送给验证者。 这些预言机是验证者可以查询的多项式的抽象表示。 查询涉及验证者将一个点发送给预言机，预言机以该点处多项式的评估作为响应。

• 验证者随机抽样一些“挑战”值，并将这些值发送给证明者。 这些挑战值应来自足够大的域，以提供加密安全性（例如，100 多位）。 这些挑战包括验证者查询预言机的点以及论证中使用的其他随机值。

这种交互过程涉及多轮交换，可确保验证者严格检查证明者关于见证正确性的断言。

交互式预言机证明过程

构建 zk-SNARK

IOP 和 PCS 可以组合起来以构建 zk-SNARK：一种零知识简洁非交互知识论证。

• 承诺代替预言机：证明者不发送 IOP 中的抽象预言机，而是使用 PCS 来“承诺”多项式，并将这些简洁的承诺发送给验证者。
• 使用 PCS 构建评估证明：当验证者查询多项式预言机以获取其在某个点的评估时，证明者使用 PCS 构建评估证明，并将此证明与评估一起发送给验证者。
• Fiat-Shamir 启发式：为了使论证具有非交互性，证明者应用 Fiat-Shamir 启发式。 证明者不是要求验证者抽样随机挑战值，而是在承诺上评估加密哈希函数。 此启发式将加密哈希函数建模为“随机预言机”，这意味着哈希函数的输出无法与依赖于输入的随机值流区分开来。

IOP 和约束系统

IOP 旨在证明特定的约束系统，并且通常依赖于这些系统的特定特征。 它们与某些有限域和多项式属性兼容，例如“FFT 友好”。

可以使用各种 IOP 来证明给定的约束系统，每种都提供不同的优势和权衡。 对于每种常见的约束系统，都有已知的单变量和多线性 IOP 来证明它们。 算术化独立于这些考虑因素； 它们本质上不是多线性的或单变量的。

IOP 根据所涉及的多项式是否具有一个或多个变量分为单变量和多线性类型。

• 单变量 IOP

次数小于 N 的单变量多项式通过要求 t[ i] = p( xi)与长度为 N 的迹向量 t 唯一对应，其中 D = xii = 1 N 是域 𝔽 的一组指定元素（D 通常是乘法子群）。

• 多线性 IOP

多线性多项式是 n 个变量中的多项式，每个变量的次数最多为 1。 这些多项式通过要求 t[ i] = p( ϵ 1, …, ϵn)与长度为 N = 2 n 的迹向量 t 唯一对应，其中 [ ϵ 1, …, ϵn] 是整数 i 的二进制表示。

‍

单变量和多线性 IOP 之间的选择决定了可以使用的多项式承诺方案。 从历史上看，单变量 IOP 更为常见，部分原因是唯一已知的具有恒定大小证明的多项式承诺方案是单变量的。 然而，多线性多项式承诺方案近年来取得了重大进展。

可除性论证与基于 Sumcheck 的

为了表明多项式方程在大型集合中的每个点都成立（即，对于执行迹的每一行），单变量 IOP 通常使用可除性论证，而多线性 IOP 使用 sumcheck 协议。 每种方法都依赖于不在设置之间直接转换的不同代数技术，从而导致重要的性能差异。

• Sumcheck 协议（多线性 IOP）

sumcheck 协议通常更快且更灵活。 证明者只需要执行一定数量的域运算（主要是计算向量的线性组合），这些运算会随见证大小 NN 线性缩放。 除了那些编码见证本身之外，此方法不需要向验证者发送额外的预言机。

• 可除性论证（单变量 IOP）

另一方面，单变量 IOP 中使用的可除性论证通常涉及计算 FFT（快速傅里叶变换），这需要 Nlog⁡(N)Nlog(N) 域运算。 此外，证明者必须将辅助多项式的预言机发送给验证者，这使得该过程在计算上更加密集。

6.2 多项式承诺方案

承诺方案是一种密码协议，其中证明者创建数据的简洁指纹（承诺），并在不泄露数据本身的情况下证明有关它的事实。 多项式承诺方案将其扩展到多项式，允许证明者承诺多项式，并在以后证明它们在特定点的评估。

多项式承诺方案可以大致分为几类。 虽然此分类并非详尽无遗，但它提供了不同类型 PCS 的全面概述。

1. 系数环

PCS 使用来自特定环（通常是有限域）的系数的多项式进行运算。 系数环的选择会影响多项式约束系统的复杂性，较大的域会简化约束，但会增加计算开销。

例如，Cairo zk-VM 设计其源语言和 ISA，以与 PCS 最自然的系数环对齐。

2. 单变量与多线性

单变量 PCS：提交到单变量多项式，不能在多线性协议中使用。 提供恒定大小的证明（例如，KZG）。

多线性 PCS：提交到多线性多项式，可以在单变量协议中使用。 提供更有效的编码和线性证明复杂度。

3. 单数与批处理

单数 PCS：提交到单个多项式并证明单个点评估。

批处理 PCS：同时提交到多个多项式并证明多个点评估，这在复杂的 SNARK 协议中很有用。

4. 基于椭圆曲线与基于哈希

基于椭圆曲线的 PCS：涉及通过从向量空间到椭圆曲线组的同态进行承诺，如 KZG 等方案中所见。 主要优点是生成较小的证明。

基于哈希的 PCS：利用哈希（例如，基于 FRI 的 PCS），从而降低证明复杂性和有限域运算。 通常，KZG PCS 的验证复杂性低于基于 FRI 的 PCS，而基于 FRI 的 PCS 的验证复杂性又低于内积论证。

性能注意事项

zk-SNARK 中的简洁性涉及三个关键指标：证明大小、验证者时间复杂性和验证者空间复杂性，所有这些对于在Layer1区块链上验证 SNARK 证明至关重要。 Layer1区块链由于其高度复制的计算而具有严格的资源约束，因此需要严格限制事务大小和计算复杂性。

证明大小、验证者时间复杂性和验证者空间复杂性可以是恒定的、亚线性的或线性的。 例如，KZG PCS 提供恒定指标，但需要可信设置。 虽然 KZG PCS 非常适合简洁性，但它们需要大量的设置，并且证明复杂性较低的 PCS 通常会生成更大、更难验证的证明。 基于 FRI 的 PCS 虽然在证明方面不太复杂，但与 KZG PCS 相比，会导致更大且更难以验证的证明。

zk-VM 证明系统：选择与影响

zk-VM 中 IOP 的设计和选择涉及计算效率、证明大小和复杂性方面的权衡，从而影响证明系统的整体性能。 单变量和多线性 IOP 之间的选择会极大地影响所使用的多项式承诺方案。 由于 KZG 等恒定大小证明方案，单变量 IOP 传统上更为常见，而多线性 IOP 因其高效的编码和线性证明复杂性而越来越受欢迎。 单变量 IOP 通常依赖于计算密集型的可除性论证，而多线性 IOP 使用 sumcheck 协议，从而以更少的要求提供更快、更灵活的操作。

如果优先级是低证明复杂性、不需要可信设置过程以及可管理的证明大小，则多线性基于哈希的 PCS 目前是理想的。 相反，如果主要担心的是最大限度地减少证明大小和验证复杂性，并且可信设置过程是可以接受的，则 KZG PCS 更适合。 随着研究的进展和新进展的出现，这些评估可能会发生变化，因此需要不断重新评估和调整。

7. zkVM 应该是模块化的还是整体的？

可以采用两种基本方法来设计 zk-VM：模块化或整体式。

zk-VM：模块化还是整体式

模块化 vs. 整体式 zk-VM：选择与影响

模块化 zk-VM 提供了广泛的定制性，允许添加针对特定用例量身定制的指令，从而减少了指令数量，并减少了证明者需要进行的工作。 然而，这种灵活性是以增加复杂性和维护费用为代价的。 相比之下，整体式 zk-VM 由于其中心化、封闭式架构而更易于管理和维护，但其灵活性较差，并且仅限于以集中方式提供的指令。

模块化还是整体式 zk-VM 之间的选择取决于项目的目标以及在定制性和易于管理性之间需要的平衡。

8. 性能之外：Valida 的设计选择

在探索了 zk-VM 设计选择的复杂性之后，让我们深入研究 Valida 架构背后的核心原则以及我们战略决策的原理。

1. 用于高性能 zk 证明的自定义 ISA

Valida 使用针对高性能 zk 证明优化的自定义指令集架构 (ISA)，这与为电子计算机设计的标准 ISA 不同。 在电子处理器中，访问主内存 (RAM) 的成本很高，而访问寄存器的成本很低。 在 Valida 的 AIR 算术化中，访问 RAM 的成本很低，但访问寄存器的成本很高。 因此，我们消除了大多数寄存器，并将所有局部变量放置在主内存中，从而大大减少了 Valida CPU 芯片中的局部变量数量和具体情况逻辑。 此外，支持许多不同的指令对 AIR 来说成本很高，但对电子处理器来说成本很低，因此 Valida ISA 维护了一小而简单的指令集。 使用自定义 ISA 的权衡是，它需要 Lita 构建我们自己的编译器工具链，从而使开发人员能够用熟悉的语言（如 C）编写代码并生成等效的 Valida ISA 机器代码。

2. 广泛的编程语言支持

Valida 利用 LLVM 项目的中间表示 (IR)，从而可以编译用于 Valida zk-VM 的主流编程语言。 这使我们能够利用数十年的优化功能，使所有支持的前端语言受益。最初，我们选择 C 是因为它的广泛使用和影响，它提供了对内存的低级访问以及到机器指令的高效映射。 我们正在积极致力于支持 Rust。 我们还在考虑 WebAssembly (WASM)，它支持比 LLVM 更多的语言，并且对于 Web 应用程序至关重要。

3. 高级约束系统和 PCS

约束系统：Valida 使用 AIR（代数中间表示）的扩展，该扩展包含排列参数、查找和可选的预处理数据。 VM 执行的统一、重复结构使 AIR 非常适合。 排列和查找支持 Valida 的模块化设计，允许单独的轨迹进行通信。 预处理的数据对于静态查找表（如范围检查）非常有用，从而允许 VM 在内存中使用任意静态数据运行。多项式承诺方案 (PCS)：我们使用单变量 FRI（快速 Reed-Solomon IOP）PCS，它以其速度而闻名，其中证明者的主要操作是计算哈希。 该方案受益于长期的广泛使用，从而产生了高度优化和高性能的库，如 Plonky3。 虽然证明大小相对较大，但可以通过递归来减小它们，从而使其适合区块链使用。 我们还在探索强大的多线性 PCS 结构，如 BaseFold 和 Binius，与单变量 FRI 相比，它们以更大的证明为代价提供更快的性能。

4. 最佳域

我们使用 32 位“宝贝熊”素数域，其特征非常接近 2 的幂，从而允许在硬件中进行非常快速的计算。 该域是“FFT 友好”的，包含一个大小为 2 的幂的乘法子群，这对于支持单变量“STARK”IOP 和 FRI 至关重要。

5. 强调模块化

我们优先考虑 Valida 的模块化。 Valida 论证分为几个较小的论证，每个论证都处理特定类型的计算，然后通过排列论证将其组合在一起。 这种模块化设计具有灵活性和可扩展性，使我们能够仅证明在特定步骤执行的计算类型，而不是证明每个步骤的每种计算类型。 这种方法是我们性能的关键驱动力。

Valida 的设计选择

通过精心制作自定义 ISA、支持各种编程语言以及利用高级约束系统和多项式承诺方案，Valida 在 zk 证明生成中实现了卓越的性能和效率。此外，我们对模块化设计和选择最佳域的承诺使 zk-VM 具有无与伦比的可扩展性。 这为在 Valida 上开发强大且可扩展的零知识应用程序铺平了道路。

我们邀请你加入有关 zk-VM 设计的对话，并欢迎你的评论和想法。 如果你觉得这有帮助，请访问我们的网站和 GitBook 了解更多关于我们在 Lita 构建的信息。 此外，我们很高兴地宣布 Valida zkVM 和 C 编译器的 Alpha 版本，让你可以尝试在 Valida 上运行、证明和验证程序。

\\\__________________________________\\\

免责声明：

本博客的内容，包括文本、图形和图像，受版权保护 © 2023 - 2024 Lita.Foundation。 保留所有权利。 严禁未经本网站作者和/或所有者的明确书面许可，擅自使用和/或复制本材料。 可以使用摘录和链接，前提是要充分而清晰地注明 Lita.Foundation 的出处，并明确指向原始内容。

如有任何问题或需要获得许可，请联系 Lita Foundation.

‍

• 原文链接： lita.foundation/blog/a-z...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～