Jolt：澄清、批评、反思

我们在 Lasso 和 Jolt — 我们新的、简单的、高性能的查找参数和 zkVM 上稳步前进 — 从 理论 论文 和 Lasso 实现 在去年夏天开始，最近在上个月发布了完全开源的 Jolt 实现。

该实现展示了相对于现有技术 Jolt 的潜力，并且 挑战了许多传统观念 的 SNARK 设计。自发布以来，我们已 增加对 Rust 标准库的支持，整合了超过 10 个贡献者的改进，合并了近 50 个拉取请求，并提高了代码库的模块化和可扩展性。

在我们继续增强 Jolt 的同时，我想回答一些问题，澄清误解，并分享我对关键问题的看法。我在这里讨论的四个领域是（1）sum-check 协议和 Binius 承诺方案之间的关系，（2）sum-check 和查找在 Jolt 中的作用，（3）椭圆曲线与哈希，和（4）预编译与 zkVM 的关系。

1. sum-check 协议和 Binius 承诺方案

承诺方案常被强调为 SNARK 的关键构建块。但同样重要的是要记住另一个组件：多项式 IOP 的重要角色。例如，Binius 针对多线性多项式的承诺方案代表了一个重大进展，但必须与多项式交互式 Oracle 证明（PIOP）配对，以证明已承诺的数据确实验证了证明者的主张。

Binius 的承诺特别与使用 sum-check 协议的 PIOP 兼容。这是因为两个原因：一个明显（sum-check 依赖于多线性多项式，而不是单变量多项式；并且 FRI-Binius 甚至在内部使用了 sum-check），一个微妙（sum-check PIOP 自然在任意特征的域上运行，这对于充分利用 Binius 的新颖性能特性至关重要）。Binius 的承诺与今天最常用的 PIOP 并不兼容，后者不幸的是并没有使用 sum-check。

设计一个快速的 PIOP 需要比单纯的“应用 sum-check”更深入的见解。Binius 采用了十多年的工作，利用 sum-check 协议实现高效的证明者友好多项式 IOP。在 Binius 论文 的第 4 和第 5 节中，专门致力于设计新的高效的基于 sum-check 的 PIOP，以与承诺方案结合。

Binius 承诺与 Jolt 相辅相成，因为 Jolt 是如今唯一完全基于 sum-check 协议的 zkVM。目前，Jolt 使用基于椭圆曲线密码学的承诺方案，但将 Binius 承诺纳入 Jolt 是我们最高优先事项。

2. sum-check、查找、性能和简单性

是什么使 Jolt 独特？是它是第一（也是目前唯一）一个完全使用基于 sum-check 的多项式 IOP 的 zkVM，还是因为 Jolt 实现了 查找奇点（即，它几乎全部通过查找而非约束系统或电路来完成）？答案是，两者皆是。Jolt 在相对于以前的 zkVM 的许多 简单性 优势来自于查找，而其 性能 优势则源于其查找和 sum-check 的结合。

仅使用查找的方法对于一些指令更好——比如那些没有非常小电路的指令——但对于其他那些确实具有非常小电路的指令，如在特征为2的域上工作的逐位异或指令，可能就差了一点，这对应于原生域加法。不过总体来说，纯查找的方法在性能上是积极的，至少在处理 256 位域时是如此。今天，Jolt 的证明者大约花费 20% 的时间在这些“指令执行”查找上，而 40% 的时间在证明约束上。增加更多约束以减少查找将没有帮助。

简单来说，Jolt 使用查找来实现 CPU 的取指-解码-执行循环的“获取”和“执行”部分。这些查找的速度足够快，以至于证明者大部分时间都花在证明它运行了“解码”，这是通过传统约束处理的。

仅查找的方法还导致了更简单的且 更易于审计的 实现。这些益处难以量化，需要时间去认知和欣赏。但 Jolt 在粗略的代理指标上表现良好，比如代码行数（Jolt 代码库大约有 25,000 行代码，比以前的 RISC-V zkVM 少了 2x 到 4x）和开发时间。这种改进相对于性能的获得要困难得多：虽然我预计 zkVM 的证明速度将在未来几个月内比 2023 年 8 月时快近 100 倍，但很难想象有 zkVM 对应的代码行数能少 10 倍。

3. 再谈椭圆曲线

公众舆论低估了拥有一个快速工作于椭圆曲线的 zkVM 的益处，这在一定程度上是由于对 Binius 这类基于哈希的承诺方案的合理热情。

在证明关于椭圆曲线密码学的陈述时，基于曲线的 zkVM 可以避免需要非原生字段算术，从而为证明时间增加数百到数千倍的开销。这类应用包括证明对许多数字签名的知识（与区块链轻客户端和基于 SNARK 的桥接相关的主要工作）；聚合 Plonk/ Groth16/ Nova/ Honk 证明；以及证明对 Verkle tree 认证路径的知识。

我乐观地认为，社区会聚焦于基于 sum-check 的 PIOP 结合 FRI-Binius 承诺方案作为在许多应用中实现高性能 SNARK 的正确方法。即使这种情况发生了，基于椭圆曲线的快速 SNARK 仍将发挥作用，除非世界完全放弃椭圆曲线密码学（例如，在社会完成从非量子安全加密系统的转变后）。

总结：

• Jolt 与基于曲线的承诺在与目前所有 zkVM 的竞争中都是具有竞争力的（所有其他 zkVM 当前都已经使用基于哈希的承诺方案且在小领域上工作）。
• Jolt 与曲线的结合是当证明关于椭圆曲线的陈述时人们所想要使用的（至少，在没有显著进展证明非原生字段算术的情况下）。
• Jolt 与 Binius 承诺作为纯 zkVM 将比替代方案要快，并且人们将在证明关于曲线的陈述或在使用非常小空间进行证明时使用 Jolt 与曲线。此时，人们将使用 Jolt 与曲线。
• 基于椭圆曲线的 SNARK 将继续被用于在将证明上链前压缩证明大小和验证者成本。只要如此，基于大领域的 zkVM 将发挥作用。即便在今天，人们认为是一种基于哈希的 zkVM 项目实际上正在将定义在 BN254 的标量域上的 zkVM 作为其递归管道的一部分。

4. 预编译和 zkVM 基准测试

关于预编译及其在 zkVM 和基准测试中的作用有一些讨论。在我解释之前，了解一下什么是预编译很有帮助，因为这一术语的含义因上下文而异。

以太坊中的“预编译”。在以太坊虚拟机（EVM）中，预编译是经常执行的操作，并得到了本地支持以提高效率。这避免了通过冗长的 EVM 操作码序列执行这些操作带来的巨大开销和高昂的 gas 成本。

“EVM 预编译”与“原始指令”（操作码）之间的区别主要是语义层面的。举例来说，Keccak 哈希函数是一个 EVM 操作码，而 SHA-2 是一个 EVM 预编译。预编译和操作码都是以太坊本地支持的经常执行的操作，目的相同：优化效率和 gas 成本。预编译无疑是 EVM 的一部分，EVM 通常被用来广泛描述以太坊执行环境，包括远超过操作码的内容。

为什么 EVM 甚至会有预编译，如果它们本质上和操作码的函数是一样的？主要这就是惯例问题。还有一个可能的原因是，预编译由相对复杂的操作构成（例如加密基元），这些操作未来可能需要变更，如果它们没有分配给操作码，则更容易修改。

在 zkVM 设计中的“预编译”。在 zkVM 设计中，预编译是指针对特定功能（如 Keccak 或 SHA 哈希，或特定椭圆曲线组操作）而设计的特殊目标 SNARK。如今，SNARK 预编译通常通过手动优化的约束系统实现（尽管随着社区转向基于 sum-check 的 SNARK，这些约束系统的性质及其证明方式将发生变化）。

EVM 预编译与 zkVM 预编译之间有深刻的相似之处。在 Jolt 出现之前，zkVM 通过手动优化的约束系统实现原始指令，每个指令一个，正如它们实现预编译一样。被称为 zkVM 预编译和被称为原始指令之间的区别纯粹是语义上的。它们之间实际上没有区别。

在 Jolt 中，我们通过查找实现原始指令，而不是传统的约束。但选择通过约束实现一些原始指令并没有重大问题。（事实上，查找甚至可以被视为一种约束。）确实，正如我之前所说的 以前，我们可能会_不得不_使用传统约束来实现 RISC-V 的加法和乘法，一旦我们转向特征为 2 的字段上的 Binius 承诺方案。

基准测试 zkVM

基于这些背景，以下是我对预编译与 zkVM 和基准测试相关的看法。

首先，在没有预编译的情况下基准测试各种 RISC-V zkVM，就意味着真正地仅仅基准测试 RISC-V zkVM。“zkVM”这一术语是非正式的，因此存在不同看法的空间，但在我看来，拥有一个或多个预编译的 RISC-V zkVM 不再是一个针对 RISC-V 的 zkVM：它是一个基于 RISC-V 添加每个预编译作为原始指令的新指令集的 zkVM。至少，将每个添加到 zkVM 的预编译都削弱了 zkVM 概念的价值主张——每个额外的电路都会增加漏洞的可能性，而现有的程序无法直接利用新预编译。

一些人还混淆了 zkEVM 的 EVM 预编译与 zkVM 的预编译的概念。但这些都是非常不同的东西。虽然 zkEVM 的一些关键操作——如 Merkle 哈希和数字签名验证——的确比 RISC-V 的原始指令要复杂，但这并不能改变 EVM 预编译和原始 EVM 指令之间没有功能性区别的事实。 zkEVM 必须支持 EVM 预编译才能宣称与 EVM 相等。换句话说，若某个 zkEVM 不支持 EVM 预编译，那么它不对应于像 Jolt 这样的 RISC-V zkVM，其中预编译将被用来扩展指令集超越 RISC-V。

另一个问题是如何选择一组“公平”的功能用于基准测试 zkVM。但对于 RISC-V zkVM，任何 功能集都是公平的。证明时间几乎完全由 RISC-V CPU 执行的周期数量决定，原因有二。首先，证明者在“取指-解码-执行”循环的“执行”部分花费的时间只有一小部分。其次，不同的 RISC-V 指令以及内存访问的证明时间相当相似。（在 Jolt 中，它们都通过离线内存检查技术处理。）

最后，如果引入预编译，Jolt 可能不会比其他方案做得更差。实际上，我预计它会做得更好，因为基于 sum-check 的预编译将是最快的，并且可以无开销地集成到 Jolt 中，因为它完全使用基于 sum-check 的 PIOP。在这一点上，一些人表示担忧，使用椭圆曲线承诺方案的预编译将比使用基于哈希的方案要差得多。Jolt 目前使用曲线，但这并不是必要的，我们已公开了转向 Binius 的计划。

对基准测试的更广泛思考

我们在基准测试中的主要目标是尽可能确定不同证明系统的内在性能特征，以至于它们可以从其实现中被隔离开。这种方法使社区能够理解并聚拢正确的设计高性能和安全 SNARK 的技术。但在尝试比较两个不同的 SNARK 时，总是存在无穷无尽的混淆因素，使得“同苹果比同苹果”的比较几乎不可能。

工程努力代表了这些混淆因素之一，尽管大部分社区似乎持有相反的观点。思路大致是这样的：如果一个项目添加了诸如预编译或特定硬件的优化实现之类的“功能”，那么它在任何基准测试中应该得到“认可”。

两种观点都有其合理性。但如果过于极端，后者的观点显然是不可行的。新方法在任何基准测试中始终处于劣势，仅仅因为那些实施它们的人尚未有与较旧项目相称的时间。这会阻碍进步。

随着时间的推移，我预计基准测试中的混淆因素将会减轻。随着构建 SNARK 的工具的成熟，SNARK 将需更少的工程努力以获得良好的性能。而且，至少在 RISC-V 中，zkVM 成本主要依赖于周期计数，这本身就是一个小奇迹，而不是某个特定应用的特性。如果人们在选择约束系统上达成共识（与当前被 R1CS、AIR、Plonkish 等割裂的状态相比），类似的情况可能会发生在针对约束系统的 SNARK 上，简单的约束系统大小度量可代替周期计数。

在那之前，很难在对混淆因素的控制不足和控制过度之间取得正确平衡。分歧将是不可避免的，建设者们必须提供任何基准测试的完整背景、细节和理由，以便社区能够理解和讨论它们。

\\\\

Justin Thaler 是 a16z 的研究合伙人，并且是乔治敦大学计算机科学系的副教授。他的研究兴趣包括可验证计算、复杂性理论和大数据集的算法。

\\*\

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