a16z 旨在 Jolt 打造为一个开源的公共产品，加速 zkVM 研究、更广泛的 SNARK 研究以及整个 web3 行业的发展。

撰文：Michael Zhu（a16z Crypto 研究工程师），Sam Ragsdale（a16z Crypto 投资工程师）

翻译：金色财经 xiaozou

2024 年 4 月 9 日，a16z 加密研究和工程团队发布了 Jolt 的初步实现，这是一种新的 SNARK 设计方法，速度比现有技术快 2 倍，并且还会有更多改进。

可验证计算（俗称 ZK）是一项非常强大的技术，既适用于区块链也适用于非区块链。它使一台计算机（verifier 验证者）能够将计算委托给另一台更强大的计算机（prover 证明者），并由其有效地验证计算是否被正确执行。

在加密行业，可验证计算的应用（尤其是 SNARKs）包括：

Layer 2（L2）区块链使用 SNARKs 来保证其状态转换的完整性。

跨链桥使用 SNARKs 来证明一条链到另一条链上的存款 / 取款转移。

一个「ZK 协处理器」（由 Axiom 定义）使用 SNARKs 来证明一些链上数据的链下计算，如若这些链上数据在智能合约中进行原生计算成本则太过高昂。

还有许多几乎未被探索的有趣的非区块链用例。例如，云服务提供商可以向其客户端证明他们正确地运行了委托给其服务器的某些计算。像 npm 或 crates.io 这样的软件注册表可以证明二进制文件是从特定的源代码编译的，从而降低了软件供应链攻击的风险。或者一个人可以证明他们的《超级马里奥兄弟》的工具辅助竞速（TAS）打破了世界纪录（RISC Zero 也描写过这个想法）。

这些应用程序中有很多涉及到的程序过于复杂，无法转换成电路 DSL（特定域语言）——想象一下，例如，使用 Circom 语言重写整个编译器或 NES 模拟器。但是，如果程序编译成由 zkVM 支持的指令集，则不需要手写电路或 DSL 转换：程序员只需要用他们选择的高级编程语言编写程序，由 zkVM 处理其余的工作。

那么，剩下的挑战就是 zkVM prover 的性能：它需要足够快才有用。这对于区块链用例尤其重要，因为 prover 时间会影响延迟，从而影响用户体验。

可验证计算长期以来一直被吹捧为有望是区块链扩容的终极解决方案，但该技术在采用方面面临三大障碍：

性能：与原生执行相比，证明程序的执行会引入高几个数量级的开销。复杂性：SNARKs 的复杂性引发了人们对其实现安全的担忧，因为将肩负着数十亿美元链上资产的安全保障。可用性：像 Circom 这样的特定域语言（DSLs）所要求的专业知识是大多数软件开发人员无法获得的。

零知识虚拟机（zkVMs）的发展克服了第三个障碍（可用性），因为 zkVMs 允许开发人员使用 Rust 或 Go 等高级编程语言编写程序，而不需要任何底层 SNARK 的知识来证明其执行。但是 zkVMs 可用性的提高也导致了高昂的性能开销（8 到 9 个数量级）和复杂的部署。

去年，一篇 Jolt 文章为 zkVMs 引入了一个新范式，承诺克服性能开销和部署复杂性这两大挑战。与基于 STARK 的既有想法相比，Jolt 的理论背景有所不同。通过利用 Lasso 查询参数和其他基于 sumcheck 的技术，Jolt 可以比以往更快地证明程序，并且比以往更容易部署新的 VM 指令。

如今，我们很高兴为 RV32I 指令集发布一个 Jolt 开源部署，实现了那篇 Jolt 文章里所做的承诺。

快速：我们的部署比 RISC Zero 快 5 倍以上，比刚刚发布的 SP1 在初步基准测试中快 2 倍。（相对）简洁：整个代码库不到 25,000 行 Rust（不到其他 zkVMs 的一半），单个 CPU 指令只需 50 行代码即可实现。

下面，我们一起来看性能基准，可以看出 Jolt 是最先进的新兴 zkVM。我们还为有兴趣开发使用 Jolt 的应用程序的开发者提供了一些指导，同时也为有兴趣为 Jolt 做出贡献的开发者提供了一个路线图预览——我们预计在未来几个月里，Jolt 会变得更快、更易使用。

a16z 加密工程团队是建立在对开源价值的坚定信念之上的。将 Jolt 打造为一个开源的公共产品将加速 zkVM 研究、更广泛的 SNARK 研究以及整个 web3 行业的发展。在封闭源代码的孤岛中构建加密技术（代码无法由公众审查），通常会给本不可信的系统带去信任。

1、性能

一直以来，与原生执行相比，zkVMs 会带来大约 8 个数量级的开销，这使得许多可验证计算的应用程序无法实现。当前版本的 Jolt 将这一开销降低到了 6 个数量级以下。

虽然我们已经具备了最先进的性能，但 Jolt 的底层技术（基于 sumcheck 协议）并没有像更流行的技术（基于 FRI）那样受到工程师的关注。这表明 Jolt 还有更多的发展空间——我们已经在路线图上设定了一些优化，我们预计还会有未发现的机会。

我们的 a16z/zkvm 基准测试在各种不同 Rust 程序上对 Jolt、SP1 和 RISC Zero 进行了基准点测定。结果是在许多同类 RV32 程序中，相对性能是相似的。下图将参考一个执行 Sha2 哈希链的程序。

这些基准测试的结果如下所示。基准测试是在 AWS r7g. 16xlarge ARM 机上运行的，具有 64 CPU 内核和 512 GiB DDR5 RAM。所有基准测试都仅针对 CPU。

使用 continuations 的连续系统面临着 prover 时间和证明大小之间的利弊权衡——当证明被分割成更多「shard 分片」（或「段」）时，prover 变得更快（由于分片之间的并行化），但在递归之前具有证明体积更大。证明大小基准测试如下所示，其中 SP1 的结果由分片计数参数化：SP1（shard_count）。RISC Zero 有一个固定大小的分片，因此它的分片计数随着程序周期计数隐式增长。RISC Zero 支持递归（SP1 和 Jolt 尚未支持），但下面的基准测试是在没有递归的情况下进行的性能检测。我们也不使用「预编译」，因此基准测试反映了核心 zkVM 证明系统的性能。

2、如何在 Jolt 上开发建设

为了使 Jolt 尽可能易用，Jolt SDK（由 a16z crypto 工程合作伙伴 Noah Citron 构建）提供了围绕 Jolt 核心功能的简式 wrappers。你所要做的就是：向要证明的函数添加 jolt_sdk::provable 属性。

然后，你将能够使用 build_* 函数来创建一个 prover 和 verifier。

请在代码库中查看完整的 Fibonacci 示例（及其他）。

为了更深入地了解 Jolt 架构，Jolt Book（WIP）是一个关于没有在 Jolt 文章中记录的设计选择和代码库的实时更新文档。在接下来的几周内，我们将面向有兴趣在 Jolt 上进行开发建设或想要了解 Jolt 内部机制的开发者发布更多内容。

3、接下来是什么

虽然 Jolt 是 zkVM 领域的一个重要里程碑，但我们还有很长的路要走。退一步说，我们的性能基准测试表明，Jolt prover（在 M3 Max 上）证明了一个程序的速度与 100kHz 处理器一样快——是阿波罗 11 号载人飞行登月任务机载计算能力的两倍多。再做一个谦虚的比较，和 TI-84 图形计算器相比慢 150 倍。

为了达到计算机级别的性能，我们有很多工作要做。我们将继续改进 Jolt 的性能和可用性，以便为开发者提供最好的开发体验。路线图上的以下主要任务让我们倍感兴奋：

Binius：Ben Diamond 和 Jim Posen 最近提出了一个多线性多项式承诺方案，该方案对像 Jolt 这样的系统尤其有用，因为承诺值很小。Binius 与 Justin Thaler 的小域 sumcheck 算法相结合，将显著提高 Jolt 的 prover 性能（我们预计是 5-10 倍）。更多指令：Jolt 代码库目前部署了 RV32I，但 Jolt 结构非常灵活。我们计划添加 RISC-V 「M」 extension 提供对整数乘法和除法的支持，如 Jolt 一文中所述。此外，Jolt 可以轻松支持 64 位变体 RV64IM。Continuations 连续系统：目前，由于内存限制，Jolt 无法证明任意长度的计算。我们将使用 continuations 将长计算分成更小的计算块，每个块都可以由 Jolt 证明。这将减少内存使用，并在证明单个计算时支持额外的并行性。证明递归：通过将 Jolt 与另一证明系统组合在一起，我们进一步减少了证明大小和验证时间。例如，Jolt 验证器可以使用 Circom 语言实现，以生成可在链上有效验证的恒定大小的 Groth16 证明。