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证明。
微信扫一扫 
