“Jolt Inside” - 构建者需要了解的全新武器

LayerZero 的新链 Zero 具有多项技术进步，包括一种将交易执行与验证分离的零知识证明的新方法。它在“Jolt inside”的帮助下实现这一点。

什么是 Jolt？Jolt 是一个开源的 RISC-V zkVM（零知识虚拟机，或者更确切地说，是一个“简洁”的虚拟机），它快速、安全且易于使用。它代表了一种最先进的 SNARK 设计方法，该方法基于 a16z crypto 三年的研发，我们将其开源，供任何人使用或进一步开发。但 Jolt 实际上是一个酝酿了数十年的故事。

为什么 zkVM 和 SNARK 设计很重要？

在深入研究 SNARK 设计的演变之前，首先值得更多地讨论 zkVM 是什么。

这些类型的虚拟机通常被称为“zk”VM，但这里更常用的属性是简洁性。虽然“ 零知识 ”对于保护隐私很重要，但“简洁”意味着证明简短且验证速度快——它们是两个有用但不同的属性通常混淆在一个标签下 。（Jolt 已经具有简洁性的属性，并且很快也将是零知识的。）

但是为什么 zkVM 很重要呢？zkVM 以及更广泛的 SNARK 或知识的简洁非交互式论证是区块链可扩展性、隐私、安全等的重要构建块。对于此类证明、论证和零知识 （统称为可验证计算技术）在加密行业 和其他领域 都有无数应用。

由于遗留的设计架构和其他原因，到目前为止，该行业一直采用复杂的方法来构建 zkVM；更多内容见下文。然而，有了 Jolt，我们从一开始就专注于一种非常不同的 SNARK 设计方法，该方法可以提高效率、可用性和性能。

简而言之，zkVM 是一种证明 你正确运行了计算机程序的方法。zkVM 相对于其他 SNARK 的优势在于它们对开发者友好。通过利用现有的计算基础设施（如开源 LLVM 编译器生态系统），开发者可以释放 SNARK 的强大功能，同时仍然使用他们选择的编程语言，而不是特定领域的语言（DSL）。

这与当今的大部分现代密码学非常相似 —— 我们有用于加密和数字签名的标准、已构建的库 —— 普通开发者每天都在使用它们，而无需了解它们的内部工作原理。Jolt 向开发者授予了相同级别的抽象：获取现有程序并证明它们，而无需担心两者之间的交互。这是任何新密码学成为商品的必要条件。

开发者可以做任何事情。使用 Jolt，开发者可以获取他们已经编写的计算机代码 —— 无需任何关于 SNARK 的特殊专业知识 —— 点击一个按钮，就会生成 Jolt 证明。

但即使 Jolt 有了所有进步，证明任何稍微复杂的事情 —— 比如标准 CPU 内核一秒的执行 —— 也需要大量的计算能力。你需要多个 GPU 才能在合理的时间内生成复杂的证明。使用 Zero，LayerZero 将 Jolt prover 移植到 CUDA：将 Jolt 底层的高度可并行化算法与 GPU 的并行硬件结合在一起，以释放新的扩展规模。LayerZero 将 Jolt 推向生产级 GPU 证明的工作 —— 包括与我们合作提出 Jolt 算法的 GPU 友好版本 —— 对于使 zkVM 和证明更具可扩展性非常重要。

开源研发

Jolt 本身是开源的，因此任何人都可以使用或构建在其创新技术之上。开源是终极的倍增器：公开分享工作成果 允许生态系统中更多的人使用、重新使用、压力测试/审计/修复、改进并进一步创新。

风险投资公司投资开源可能看起来不寻常，但现代研究和工程的结构意味着，大多数开发要么发生在公司内部 —— 就像过去的企业实验室或今天的基金会实验室一样 —— 要么发生在学术界内部。我们建立 a16z 加密研究的目的是建立一个工业研究实验室和工程团队，将学术理论与行业实践联系起来。作为一家 VC，我们还能够资助其他人无法完成的工作……尤其是在这是一个逆向押注时。

在 Jolt 方面，支持一种与 SNARK 设计相反的方法尤其重要，因为它代表了与先前设计方法的一次重大“范式转变”。这种设计演变历时多年。

创新的故事通常是关于架构设计转变的故事

要理解 Jolt 方法底层的大转变，我们必须从 2000 多年前开始：从古希腊人开创的形式数学证明系统的发展，后来由中东、亚洲及其他地区的学者扩展。

这些早期的证明 —— 以逐步方式写下的逻辑推导 —— 以形式语言或公式写下来，以便任何人都可以验证它们。例如，数学家可以将证明写在“书”中，然后另一位数学家会逐字阅读该书以验证它。这种静态书面证明的传统概念被著名的复杂度类别 NP 的“P vs. NP” 著名 所捕获。

值得注意的是，这种传统的证明方法是顺序的，需要轮流进行：它是静态的，而不是交互式的。

但随后快进到 1985 年*，当时 Shafi Goldwasser、Silvio Micali 和 Charles Rackoff 引入 了交互式证明（“IP”）的概念。[实际上是几年前，但该论文在被接受之前被拒绝了几次。] 这种交互式证明方法背后的见解是，例如，如果两位数学家正在相互交谈，他们不需要等待一个人写下他们的证明，然后等待说服另一个人它是真的。相反，他们可以实时相互提问；换句话说，通过相互交互来获得证明的真相。

这些类型的交互式证明的巨大力量 —— 相对于古希腊人开创的传统静态证明 —— 直到 5 年后的 1990 年才被充分认识到，当时 Carsten Lund、Lance Fortnow、Howard Karloff 和 Noam Nisan 引入 了sum-check协议：交互式证明系统的代数方法。结合 Adi Shamir 的后续工作，这很快导致了“IP=PSPACE”的基础结果 —— 一种捕捉以下直观陈述的技术方式：

• 如果证明者和验证者可以交互 —— 也就是说，参与挑战-响应，就像传统的证明系统一样[证明者撒谎但不被它无法回答的挑战“抓住”的几率极小]，

• 那么与古希腊人的传统静态书面证明相比，可以快速验证极其复杂的陈述。

换句话说：交互属性在证明系统中给了我们很大的杠杆。sum-check是将该杠杆转化为高效验证的主力 —— 让验证者可以验证所声称的结果，而无需重建正在证明的整个计算。

几年后，Joe Kilian 提议 从概率可检查的证明（PCP）开始构建简洁的零知识论证。在证明的 PCP 视图中，证明者（想想古希腊数学家，只不过现在他们是计算机）以高度冗余的格式将普通证明写在“书”中。值得注意的是，这种冗余让验证者避免阅读整本书：验证者可以只采样几个随机位置 —— 比如书中的三个“单词” —— 并且仍然可以高度自信地确定整个证明是否有效。

但问题是，即使验证很便宜，PCP proof 也很长。

因此，Kilian 展示了如何将 PCP 与密码学结合，允许证明者“提交”这本长书，然后只显示几个采样的单词，以及一个简短的密码认证。Kilian 协议中的最终证明实际上只是几个单词（加上一些密码认证数据）—— 但它们足以说服验证者整本书都通过了检查。

这些证明仍然是交互式的。然后，Micali [展示](https://people.csail.mit.edu/silvio/Selected Scientific Papers/Proof Systems/Computationally_Sound_Proofs.pdf) 了如何通过应用 Fiat-Shamir 转换使 Kilian 基于 PCP 的交互式论证变为非交互式。粗略地说，Fiat-Shamir“哈希掉”了验证者的随机挑战，让证明者可以自行生成它们并一次性输出整个证明。

遗留架构挥之不去

到目前为止，在证明系统的历史和演变中，我们已经从静态的、交互式的、概率的和非交互的（PCP）演变为交互式的（参见 Kilian），再到非交互式的（参见 Micali）。SNARK 出现在这个弧线的末尾：通过将 Fiat-Shamir 转换应用于 Kilian 的交互式论证，Micali 获得了我们现在用现代术语来说的首个 SNARK 构造。

但在这些早期的基于 PCP 的 SNARK 中，证明者的工作量非常大 —— 计算时间太长 —— 使它们不适合部署。

但 SNARK 的设计方式已经存在了几十年。即使当行业试图放弃 PCP 方法来设计 SNARK 时，设计者仍然使用相关的概念（如“线性 PCP”等），这些概念只是 PCP 启发技术的变体。虽然这些方法确实导致了证明极其简短的 SNARK，但它们并没有导致证明者速度最快的 SNARK。

SNARK 设计者仍然没有回到终极来源 —— sum-check协议 —— 以获得更快、更可用的证明者，而这现在由于现代计算成为可能。

退一步讲：更快地获得sum-check需要以非线性的方式看待我们上面概述的 SNARK 的历史和演变。在从 (a) 交互式证明 --> (b) PCP --> (c) 简洁的交互式论证 --> (d) 早期 SNARK 演变的过程中，该行业执行了以下操作：

• 在从 (a) 交互式证明 → (b) PCP 演变的过程中，主要的挑战是从证明系统中删除交互，同时保持验证的简洁性。这导致设计者摆脱了sum-check协议（交互）。

• 但是，当从 (b) PCP 演变为 (c) 简洁的零知识论证时，交互又重新出现...

• 然后使用 Fiat-Shamir 转换将其删除，这有助于从 (c) 简洁的交互式论证演变为 (d) 早期 SNARK。

• 事后从 (a) → (b) → (c) → (d) 线性地检查所有这些，我们可以清楚地看到 SNARK 设计者实际上两次削减了交互 —— 一次是从 (a) → (b) 演变的过程中，另一次是从 (c) → (d) 演变的过程中。

• 但是，如果我们打算使用 Fiat-Shamir 来摆脱交互……我们应该完全跳过中间的步骤 (b)，即可概率检查的证明！

跳过中间这个步骤 (b) 是 Jolt 方法背后的关键见解，该方法直接从构建基于交互式证明的 SNARK 演变为sum-check。

为什么没有更多的人更早地直接转向基于sum-check协议的设计方法？早期的 SNARK 设计者可能没有这样做，因为 PCP 和 SNARK 在表面上看起来是相关的，因为它们都实现了简洁验证的概念。至于后来，嗯，架构 —— 以及误解 —— 可能会挥之不去。

对我们来说，将大量的工程和研究资源投入到基于sum-check的 zkVM Jolt 是一项逆向押注，因为它与 SNARK 中长达数十年的主导范式背道而驰。

‘Jolt Inside’

Jolt 的 SNARK 设计方法（它本身建立在批量评估和 内存检查 论证（如 Twist + Shout ）之上）基于交互式证明和sum-check协议。

现在，在我们开始构建 Jolt 几年后，其他人也开始在其设计中采用sum-check协议方法。那么，在今天的 zkVM 中，Jolt 的标志性功能是什么？Jolt 最大限度地利用了 CPU 执行中的重复结构。通过观察到每个 CPU 的核心“fetch-decode-execute”抽象适用于批量评估论证，Jolt 设法以最小的复杂性实现了无与伦比的效率。

与此同时，其他 zkVM 则严重依赖“预编译”—— 用于特定子程序的类似 ASIC 的加速器——以实现合理的性能。Jolt 避开了这些预编译，因为它们带回了 SNARK 设计的 pre-zkVM 方法的缺点：因为你需要专家来设计这些类型的专用 SNARK，所以它们更容易出错，并且更少的开发者可以使用。有了 Jolt，我们专注于实现 SNARK 的民主化。

证明正确的 CPU 执行的能力也是 zkVM 的确切价值主张 —— 并且在开发者体验方面带来了巨大的进步 —— 因为它允许重用现有的、经过强化的通用计算基础设施。整个世界的计算基础设施都是为了支持 CPU 而构建的，Jolt 从这些 CPU 执行固有的“结构”中榨取了最后一丝简单性和性能。

Jolt 从一开始就优先考虑具有生产级性能的可用性：开发者可以按原样证明现有程序；无需更改代码，甚至可以获得快速证明。Jolt 没有强迫团队围绕“预编译”或特殊 API 重构应用程序以达到可接受的性能，而是保持原始代码不变，从而使其更易于采用、更易于审计且更便宜地进行迭代。

重要的是，Jolt 不但速度更快，而且也更简单。虽然替代方法要求 zkVM 设计者为虚拟机的每个原始指令指定一个电路，但 Jolt 则不需要：在 Jolt 中，每个原始指令都可以用大约十行 Rust 代码来指定（请参阅此处和此处以了解更多信息）。没有电路，只有十行代码。

Jolt 的下一步是什么？

我们在速度方面已经处于最先进的水平。通过进一步的优化和功能，包括递归和零知识 —— 尤其是我们计划从椭圆曲线密码学转向格 —— 我们将在今年晚些时候速度再提高一个数量级，更不用说后量子了。

Jolt 使更多应用程序成为可能。对于区块链而言，每个人都在等待的可扩展性和去中心化变得更容易部署。ZK rollup 可以正常工作，而无需数月或数年的密码工程。

但是，随着 Jolt 的进一步发展 —— 使在手机和笔记本电脑上运行的快速而简单的 zkVM 成为现实 —— 开发者将能够在客户端和保护隐私方面解锁更多用例。例如，手机上保护隐私的应用程序可以从无法维护且几乎无法运行，变为轻松地开箱即用。

从长远来看，这些证明系统将成为世界数字基础设施的核心组成部分，类似于加密和数字签名。这种通用密码压缩 —— 任何人都可以通过发送 50 KB 的证明而不是所有数据本身来证明他们知道满足某些属性的千兆字节的数据 —— 是一种如此强大的原语，以至于很难预测人们会用它来开发什么应用程序。可能性是无限的。

自己使用 Jolt 构建：https://github.com/a16z/jolt ~QED

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