自从去年夏天我们发布了主题论文和Lasso实现开始，直到上个月发布完全开源的Jolt实现，我们在Lasso和Jolt（这是我们新开发的简单高效的查找参数和zkVM）方面取得了稳步进展。这一实施不仅展示了Jolt相对于现有技术的前景，而且挑战了SNARK设计中许多传统的观点。自发布以来，我们增加了对Rust标准库的支持，纳入了超过10位贡献者的改进，合并了近50个拉取请求，并提高了代码库的模块化与可扩展性。 在我们继续提升Jolt的性能的同时，我想解决一些问题，澄清误解，并分享我对几个关键问题的看法。这里我将探讨四个领域：（1）和检查协议与Binius承诺方案之间的关系，（2）和检查与查找在Jolt中的角色，（3）椭圆曲线与散列，以及（4）与zkVM相关的预编译。 1.求和检查协议和Binius承诺方案承诺方案通常被强调为SNARK的关键组成部分。但同样重要的是，我们也需记住多项式IOP的重要作用。例如，多线性多项式的Binius承诺方案代表了一项重大进步，但它必须与多项式交互式预言机证明（PIOP）配合使用，以证明提交的数据确实验证了证明者的主张。Binius的承诺特别与使用和检查协议的PIOP兼容。这是由于和检查依赖于多线性多项式，而不是单变量多项式；FRI-Binius甚至在内部使用和检查，并且和检查PIOP自然地跨任何特征的字段进行操作，这对于充分利用Binius新颖的性能特征至关重要。不幸的是，现今最常见的PIOP并不使用求和检查。 设计快速PIOP需要更多的洞察力，而不仅仅是简单地“应用求和检查”。Binius利用和检查协议进行了十多年的工作，以实现可证明高效的多项式IOP。Binius论文的第4节和第5节专门致力于设计新的基于和检查的高效PIOP，以与承诺方案相结合。Binius承诺和Jolt的结合就像花生酱与果冻的完美搭配，因为Jolt是目前唯一完全基于和检查协议的zkVM。如今，Jolt使用基于椭圆曲线密码学的承诺方案，但将Binius承诺纳入Jolt是我们的首要任务。 2.求和检查、查找、性能和简单性何以令Jolt与众不同？是因为它是第一个（也是目前唯一的）专门使用基于和检查的多项式IOP的zkVM，还是因为Jolt实现了查找奇点（即，它几乎通过查找而不是通过约束系统或电路来完成所有操作）？事实上，两者兼而有之。Jolt相对于以往的zkVM的简单性优势主要来自于查找；其性能优势则源于其对查找和求和检查的利用。 仅通过查找方法对于某些指令（没有非常小的电路的指令）来说更为适合，但对于具有非常小的电路的其他指令来说可能效果较差，例如在特征为2的字段上工作时的按位异或指令，这对应于本机字段加法。但总体来说，仅查找方法在性能上是有益的，至少在256位字段上是这样。如今，Jolt的证明者将大约20%的时间花在这些“指令执行”查找上，并用40%的时间证明约束。添加更多的约束以减少查找并不会有所帮助。 粗略地说，Jolt使用查找来实现CPU的获取-解码-执行循环的“获取”和“执行”部分。这些查找的速度足够快，以至于证明者的大部分时间都花在了证明它运行“解码”上，这是通过传统约束处理的。仅查找方法还可以实现更简单且更可审计的实现。这些好处很难量化，需要时间来认识和欣赏。但是，从Jolt的代码行数（Jolt代码库大约有25,000行代码，比之前的RISC-V zkVM少2到4倍）和开发时间等粗略代理方面看，这种改进表现出色。虽然这种改进比性能改进更难获得：虽然我预计zkVM证明者在未来几个月内将比2023年8月快近100倍，但很难想象zkVM的代码行数会减少10倍。 3.再次谈论椭圆曲线公众讨论常常低估了在椭圆曲线上运行的快速zkVM的好处，部分原因是对Binius等基于哈希的承诺方案的热情。在证明有关椭圆曲线密码学的陈述时，基于曲线的zkVM可以避免非本机字段算法，从而使证明时间增加数百到数千倍的开销。此类应用包括证明许多数字签名的知识（主要与区块链轻客户端和基于SNARK的桥相关）；聚合Plonk/Groth16/Nova/Honk证明；并证明Verkle树认证路径的知识。 我乐观地认为，社区将围绕基于和检查的PIOP与FRI-Binius承诺方案相结合，作为在许多应用程序中实现高性能SNARK的正确方法。即使发生这种情况，基于快速曲线的SNARK仍然会发挥作用，除非世界完全放弃椭圆曲线密码学（例如，在社会完成从非量子安全的密码系统的转变之后）。 总结如下： Jolt-with-curve-based-commitments 在当前所有其他 zkVM 中占据着有力的竞争地位（这些 zkVM 已经在使用基于哈希的承诺方案并在小字段上进行运作）。Jolt-with-curves 成为了在证明椭圆曲线相关陈述时所必需的工具（在非本地域算术证明方面尚无重大进展的情况下至少如此）。作为纯 zkVM，Jolt-with-Binius-commitment 的处理速度将远超其他方案，除非是在需要证明与曲线相关的陈述或在极小的空间内进行证明的情况下（在这种情况下，人们通常会选择 Jolt-with-curves）。基于椭圆曲线的 SNARK 将继续被用来在链上发布证明之前进行证明大小的压缩和降低验证者的成本。只要这种需求仍然存在，广泛应用的 zkVM 就会持续发挥其作用。即使在今天，基于哈希的 zkVM 项目实际上也是利用定义在 BN254 标量域上的 zkVM 作为其递归管道的一部分。 关于预编译及其在 zkVM 和基准测试中的作用已有一些探讨。在深入讲解之前，了解预编译的概念至关重要，因为该术语在不同的上下文中具有不同的含义。在以太坊中的“预编译”是指在以太坊虚拟机（EVM）中为了提高效率而由原生支持的频繁执行的操作。这种做法避免了通过冗长的 EVM 操作码序列执行这些操作时产生的大量开销和高昂的 Gas 成本。“EVM 预编译”和“原始指令”（操作码）之间的区别主要在于语义上。例如，Keccak 哈希函数是作为 EVM 操作码存在，而 SHA-2 则作为 EVM 预编译存在。预编译和操作码都是以太坊本身支持的频繁执行的操作，其目的是优化效率和成本。无可否认，预编译是 EVM 的一部分，通常用于描述以太坊的执行环境，这不仅包括操作码。如果 EVM 的功能与操作码本质上相同，为什么还要进行预编译呢？这主要是出于习惯。另一个可能的原因是预编译包含相对复杂的操作，例如在将来可能需要更改的加密原语，如果没有为它们分配操作码，则更改它们会更容易。 在 zkVM 设计中的“预编译”是指针对特定功能（例如 Keccak 或 SHA 哈希）或特定椭圆曲线组操作的特殊用途 SNARK。如今，SNARK 预编译通常是通过手动优化的约束系统来实现的（尽管随着社区转向基于和检查的 SNARK，这些约束系统的性质及其证明方式将会发生变化）。EVM 预编译和 zkVM 预编译之间存在着深刻的相似之处。在 Jolt 之前，zkVM 通过手动优化的约束系统来实现原始指令，每条指令一个指令，就像实现预编译一样。zkVM 预编译和原始指令之间的区别纯粹是语义上的，实际上并无差别。在 Jolt 中，我们通过查找而不是传统约束来实现原始指令。但是选择通过约束来实现一些原始指令也没有什么问题。（事实上，查找甚至可以被视为一种约束。）实际上，正如我之前所说，一旦我们切换到 Binius 承诺方案，可能不得不使用传统约束来实现 RISC-V 加法和乘法。 zkVM 基准测试在此背景之下，我想分享一些关于 zkVM 以及基准测试的预编译的看法。首先，对于各种 RISC-V zkVM 的基准测试，如果不包括预编译，才能真正体现基准测试的意义。虽然“zkVM”一词并不是正式的术语，因此理解上可能有所分歧，但我认为，一旦涉及一次或多次预编译，RISC-V zkVM 就不再是纯粹的 RISC-V zkVM，而是演变成了基于 RISC-V 的新指令集，将每次预编译作为原始指令加入。至少，每个加入到 zkVM 的预编译操作，都在一定程度上削弱了 zkVM 范式的价值——每增加一个电路，就可能增加漏洞的面积，而现有的程序无法直接利用这些新的预编译内容。 此外，有些人将 zkEVM 的 EVM 预编译概念与 zkVM 的预编译概念混淆。但实际上，这两者是截然不同的。尽管 zkEVM 的一些关键功能（如 Merkle 哈希和数字签名验证）确实比原始的 RISC-V 指令复杂，但这并不意味着 EVM 预编译与原始 EVM 指令之间不存在功能上的差异。为了保持与 EVM 的一致性，zkEVM 必须支持 EVM 预编译。换言之，不支持 EVM 预编译的 zkEVM 与例如 Jolt 的 RISC-V zkVM 不同，后者通过预编译将指令集扩展至 RISC-V 之外。 关于如何为 zkVM 选择一组“公平”的功能进行基准测试，这是另一个讨论点。但对于 RISC-V zkVM 来说，任何功能集都应被视为公平。验证时间几乎完全取决于 RISC-V CPU 的运行周期，主要基于两个原因：首先，证明者在“获取-解码-执行”循环中的“执行”阶段只占少部分时间；其次，不同的 RISC-V 指令和内存访问在证明时间上相差无几（在 Jolt 中，这些都通过离线内存检查技术处理）。 最后，如果考虑预编译的因素，Jolt 的表现可能不会逊色于其他选项。实际上，我预期它的表现会更好，因为基于查和检查的预编译可能是最快的，且由于专门使用基于查和检查的 PIOP，能够无开销地集成到 Jolt 中。目前，有人担忧使用椭圆曲线承诺方案的预编译可能不如使用基于哈希的方案的预编译。尽管如此，Jolt 目前采用的是曲线方案，但我们对切换到 Binius 的计划持开放态度。 关于基准测试的更广泛的思考我们进行基准测试的主要目标是揭示不同证明系统的内在性能特征，从而实现与具体实现的隔离。这种方法让社区能够理解并专注于设计高性能且安全的 SNARK 的正确技术路线。然而，在尝试比较两种不同的 SNARK 时，存在众多的混杂因素，这些因素通常使得进行“同类”比较几乎成为不可能任务。 工程实施是这些混杂因素之一，尽管社区中许多人持有相反的观点。他们认为，如果一个项目引入了预编译或针对特定硬件的优化等“功能”，则应该在任何基准测试中获得“认可”。两种观点都有其合理之处，但如果推行过头，后者显然是不可持续的。新方法在任何基准测试中都将永远处于不利地位，因为实施这些方法的团队无法在短时间内与成熟的项目匹配，这无疑会阻碍进步。 随着时间的推移，我预期这些基准测试中的混杂因素将得到缓解。随着构建 SNARK 的工具越来越成熟，构建 SNARK 将需要更少的工程投入来实现良好的性能。这对 RISC-V 来说几乎是一种奇迹——zkVM 的成本主要依赖于周期计数，而非任何特定应用的特性。如果人们专注于选择约束系统（而非当前如 R1CS、AIR、Plonkish 等的多样化状态），可能会出现类似情况，简单的约束系统大小将取代复杂循环成为重要的度量标准。 在这之前，要在控制不足和过度控制之间找到恰当的平衡将是一项挑战。分歧不可避免，因此构建者必须提供任何基准测试背后的完整背景、细节和理由，以便社区能够充分理解并进行讨论。