推出 Twist 和 Shout

Jolt 是我们的 开源 zkVM，它提供了无与伦比的速度和简洁性。之前的一篇文章 介绍 了 Jolt 设计理念的主要要点和思想。现在，Srinath Setty 和我发布了一篇新论文，揭示了 Twist and Shout，这是两个新的内存检查参数，用于确保证明者正确处理对 VM 内存的每次读取和写入。

Twist and Shout 背后的关键见解是，证明者可以快速提交到非常大但又高度稀疏的向量。一旦完成此提交，内存检查将简化为大规模但直接的约束系统，sum-check 协议可以处理这些系统。至关重要的是，这些约束系统保持稀疏，并且 sum-check 证明者在生成证明时仅为其非零元素付费。

通过集成 Twist and Shout，我预计 Jolt 将实现大约 3 倍的端到端证明者加速，以及更短的证明——此外，我们正在实施的已知证明者优化的额外 2 倍提升。

（这些预期基于对证明者在 SNARK 中所做工作的精确核算。例如，当将一个基于椭圆曲线的 SNARK 与另一个进行比较时，你可以计算证明者完成的群和域运算，从而在实现之前判断 SNARK 的性能。如果一个 SNARK 证明者执行 X 个群运算和 Y 个域乘法，而另一个执行 2X 和 3Y，则第一个证明者会更快。有关详细信息，请参阅论文。）

换句话说，Twist and Shout 强化并放大了 Jolt 的核心设计原则。下面，我们将重点介绍 Twist and Shout 的核心教训及其对 zkVM 设计和更广泛的 SNARK 的影响。

1. Jolt 以查找为中心的架构的验证

Jolt 将每个 VM 动作转换为以下两种之一：

1. 查找只读内存，通过 Lasso 查找参数证明，或者
2. 读取和写入寄存器和 RAM，通过 Spice 内存检查参数证明。

这种方法产生了一个简单而模块化的架构。现在，我们可以用 Shout 替换 Lasso，用 Twist 替换 Spice，以实现 3 倍的证明者加速。

2. sum-check 协议是快速 SNARK 证明者的关键

SNARK 社区中的一些人将“椭圆曲线 vs. 哈希”（即“大域 vs. 小域”）描绘成区分快速 SNARK 和慢速 SNARK 的主要分歧。他们经常将具有 256 位域且基于椭圆曲线的 SNARK 描述为极其缓慢。但是这种框架忽略了两个问题：

1. 性能数据直接与此观点相矛盾。例如，带有椭圆曲线承诺的 Jolt 当前 是 最快 的 最快 RISC-V zkVM。
2. “哈希 vs. 曲线”只是一个多维空间的一个维度。最重要的性能维度是采用多线性多项式和 sum-check 协议，还是采用单变量多项式和求商。

在实践中，带有 Twist-and-Shout 和椭圆曲线的 Jolt 将比依赖于单变量多项式的基于哈希的 SNARK 快一个数量级。基于二进制域的带有 Twist-and-Shout 的 Jolt（带有 Binius 或另一个基于哈希的方案）会更快，但这并不是因为“哈希 vs. 曲线”是关键。的确：

1. Binius 内部依赖于 sum-check 协议，以实现对 0 和 1 等小值的非常快速的承诺。
2. 一旦实现，基于二进制域的 Jolt 将增加代码复杂性，需要更多的证明者内存，并且在大多数 CPU 上只能提供适度的加速。此外，其最大的性能改进需要硬件对二进制域算术提供比当今 CPU 更强大的支持。

3. 256 位或二进制域最适合 SNARK 性能

尽管基于 31 位或 64 位域的 SNARK 在性能上很受欢迎（尤其是那些使用单变量多项式代替多线性多项式和 sum-check 协议的 SNARK），但它们很慢。

为什么是 256 位或二进制域，而不是 31 位特征域？Twist and Shout 仅强调了众多原因中的一个：

• 在二进制域中提交到 0 的速度大约比在 31 位域中快 30 倍。
• 对于 256 位域，差异甚至更大。当使用基于这些域的椭圆曲线承诺时，0 根本不会影响承诺，可以简单地忽略。

Twist and Shout 利用了这种对 0 的快速承诺，以及 sum-check 协议，该协议避免为这些 0 “在承诺方案之外”付费。结果是一个极其快速、直接的内存检查参数系列。

4. “SNARK 友好” VM 实际上并不 SNARK 友好

Jolt 已经表明，为真实 CPU 设计的指令集也可以是 SNARK 友好的。使指令对硬件高效的相同原理（例如，输出是输入位的简单函数）也适用于基于 sum-check 的查找参数。

现在，Twist and Shout 通过引入第一个在内存大小较小或内存访问保持在本地时速度会显着提高的内存检查参数，进一步推动了这一点。随着 SNARK 设计的进步，zkVM 证明者的性能曲线将越来越接近真实 CPU 的性能曲线。最后，任何今天被宣传为“SNARK 友好”的 VM 可能会证明仅仅是“友好”于当今 SNARK 的当前局限性。最重要的是，这些 SNARK 存在重大缺点——例如无法利用现有的工具生态系统。

5. 这不仅仅是关于 zkVM

Twist and Shout 在 SNARK 设计中作为独立原语广泛有用。例如，Shout 意味着一种新的非均匀电路 SNARK（我们称之为 SpeedySpartan），它比 Spartan 本身快一个数量级。在 SpeedySpartan 中，门输入只是查找“门值表”，而证明者的主要任务是提交到 witness；其他一切都简化为字段运算。 此外，Twist and Shout 的技术基础是新的且强大的。Twist and Shout 让证明者提交到非常大但非常稀疏的向量，并且只为稀疏性而不是这些向量的总大小“付费”。我预计这种方法将在广泛的应用和环境中催化新的高性能 SNARK 协议。 集成到 Jolt 中的 Twist and Shout 将在速度和简洁性方面提供巨大的飞跃。它们验证了我们更广泛的设计选择，并进一步强调 sum-check 协议是构建快速 SNARK 的核心。 Justin Thaler 是 a16z 的研究合伙人，也是乔治城大学计算机科学系的副教授。他的研究兴趣包括可验证计算、复杂性理论和大规模数据集算法。 该内容仅代表所示日期的情况。这些材料中表达的任何预测、估计、预测、目标、前景和/或意见如有更改，恕不另行通知，并且可能与其他人的意见不同或相反。请参阅 https://a16z.com/disclosures/ 了解更多重要信息。

• 原文链接： a16zcrypto.com/posts/art...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～