a16z：构建者的关键要素：‘Jolt Inside’

文章作者：a16z crypto

前言

今天，LayerZero 发布了他们的新链 Zero，该链包含多项技术进步——包括一种全新的零知识证明方法，该方法将交易执行与验证解耦。这一切都得益于“Jolt Inside”。

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

为什么 zkVM 和 SNARK 设计如此重要？

在深入探讨 SNARK 设计的演变之前，我们首先需要详细了解一下 zkVM 是什么。

这类虚拟机通常被称为“zk”虚拟机，但这里更常用的特性是简洁性。虽然“零知识”对于隐私保护至关重要，但“简洁”意味着证明简短且易于验证——这是两个有用但不同的特性，却常常被混为一谈。（Jolt 已经具备简洁性，并且很快也将实现零知识。）

但为什么 zkVM 如此重要？zkVM 以及更广泛意义上的 SNARK（简洁非交互式知识论证）是区块链可扩展性、隐私性、安全性等诸多方面的重要组成部分。这类证明、论证和零知识（统称为可验证计算技术）在加密行业及其他领域都有着无数的应用。

由于传统设计架构和其他原因，业界迄今为止在构建 zkVM 方面一直采取较为复杂的方法；下文将对此进行更详细的阐述。然而，Jolt 从一开始就专注于一种截然不同的 SNARK 设计方法，旨在实现更高的效率、可用性和性能。

简而言之，zkVM 是一种证明你正确运行了计算机程序的方法。zkVM 相较于其他 SNARK 的优势在于其对开发者友好。通过利用现有的计算基础设施（例如开源的 LLVM 编译器生态系统），开发者无需使用领域特定语言 (DSL)，即可在自己选择的编程语言中发挥 SNARK 的强大功能。

这与当今许多现代密码学领域颇为相似——我们拥有用于加密和数字签名的标准、内置库——普通开发者每天都在使用这些库，而无需了解其内部运作机制。Jolt 为开发者提供了同样的抽象层：只需使用现有程序并对其进行验证，而无需担心两者之间的交互。这是任何新型密码学普及应用的必要条件。

开发者可以专注于实际操作。借助 Jolt，开发者无需任何 SNARK 方面的专业知识，只需按下一个按钮，即可使用他们已编写的计算机代码生成 Jolt 证明。

然而，即使 Jolt 取得了诸多进步，证明任何中等复杂程度的证明（例如单个标准 CPU 核心执行一秒钟的操作）仍然需要强大的计算能力。要想在合理的时间内生成复杂的证明，你需要多个 GPU。LayerZero 将 Jolt 证明器移植到 CUDA，并推出了 Zero：它将 Jolt 底层高度并行化的算法与 GPU 的并行硬件相结合，从而实现了更高阶的扩展性。

LayerZero 致力于将 Jolt 推向生产级 GPU 证明，包括与我们合作开发 Jolt 算法的 GPU 友好版本，这对于提升 zkVM 和证明的可扩展性至关重要。

开源研发

Jolt 本身是开源的，因此任何人都可以使用或基于其创新技术进行开发。开源是终极倍增器：公开共享成果，让生态系统中更多的人能够使用、重用、进行压力测试/审核/修复、改进，并在此基础上进行进一步创新。

风险投资公司投资开源项目或许看似不同寻常，但现代研发的结构决定了大部分开发工作要么发生在公司内部——例如过去的企业实验室或如今的基金会实验室——要么发生在学术界。我们成立 a16z 加密研究机构的目的，就是为了打造一个连接学术理论与产业实践的产业研究实验室和工程团队。作为一家风险投资公司，我们还能资助其他机构无法资助的项目……尤其是在逆向投资的情况下。

支持 SNARK 的逆向设计方法对于 Jolt 而言尤为重要，因为它代表着与以往设计方法截然不同的重大“范式转变”。这种设计演进历经多年。

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

要理解 Jolt 针对 SNARK 设计方法所采取的重大变革，我们必须追溯到两千多年前：古希腊人开创了形式化数学证明系统的发展，后来中东、亚洲及其他地区的学者也对其进行了拓展。

这些早期的证明——一步一步写出的逻辑推导——被用形式语言或公式记录下来，以便任何人能够验证。例如，一位数学家可以将证明写在一本“书”中，然后另一位数学家逐字阅读这本书来验证它。这种传统的静态书面证明概念，正是著名的“P vs. NP”复杂度类 NP 的体现。

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

但时间快进到 1985 年*，Shafi Goldwasser、Silvio Micali 和 Charles Rackoff 提出了交互式证明（“IP”）的概念。[*实际上，他们的论文提出时间更早几年，但论文被多次拒绝后才被接受。]这种交互式证明方法的核心思想是：例如，如果两位数学家在交流，他们无需等待一方写下证明，然后再去说服另一方。相反，他们可以实时提问；换句话说，通过互动来探寻证明的真谛。

这类交互式证明的巨大威力——相对于古希腊人开创的传统静态证明——直到五年后的 1990 年才被人们充分认识。当时，Carsten Lund、Lance Fortnow、Howard Karloff 和 Noam Nisan 提出了求和检验协议：用于交互式证明系统的代数方法。结合 Adi Shamir 的后续工作，这很快促成了“IP=PSPACE”这一基础性结论——这是一种技术性的说法，它概括了以下直观的陈述：

如果证明者和验证者能够交互——即像传统证明系统那样进行挑战-回应，(假设一个撒谎的证明者不会被其无法回答的挑战“抓到”），那么，与古希腊传统的、静态的、书面证明相比，我们可以快速验证更为复杂的陈述。

换句话说：交互属性赋予了我们在证明系统中极大的优势。而求和检验（sum-check）正是将这种优势转化为高效验证的核心——它允许验证者在无需重构整个待证明的计算过程的情况下，验证所声称的结果。

几年后，Joe Kilian 提出了从概率可验证证明（PCP）出发构建简洁的零知识论证。在 PCP 的证明理论中，证明者（可以想象成古希腊的数学家，只不过现在是计算机）将一个普通的证明写在一本“书”里，但格式高度冗余。值得注意的是，这种冗余使得验证者无需阅读整本书：验证者只需随机抽取固定数量的证明位置——比如书中的三个“词”——就能高置信度地判断整个证明是否有效。

然而，问题在于 PCP 证明本身很长，尽管验证成本很低。

因此，Kilian 展示了如何将 PCP 与密码学相结合，允许证明者“承诺”完成这本“长书”，然后只公开抽取的几个词，并附上简短的密码学认证。Kilian 协议中的最终证明实际上就是这几个词（加上一些密码学认证数据）——但它们足以让验证者相信整本书都有效。

这些证明当时仍是交互式的。随后，Micali 展示了如何通过应用 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 设计师们始终没有回归其根本来源——求和校验协议——来获得如今借助现代计算已然可能实现的更快、更易用的证明者。

退一步讲：要更早地采用求和校验协议，就需要以非线性的方式审视我们上面概述的 SNARK 的历史和演变。从 (a) 交互式证明 → (b) PCP → (c) 简洁交互式论证 → (d) 早期 SNARK 的发展历程中，业界经历了以下转变：

在从(a) 交互式证明 → (b) PCP 的转变过程中，主要挑战在于如何在保持验证简洁性的同时，从证明系统中移除交互。这促使设计者摒弃了求和校验协议（即交互部分）。

但当从 (b) PCP 过渡到 (c) 简洁零知识论证时，交互又重新出现……最终，通过 Fiat-Shamir 变换将其移除，从而实现了从 (c) 简洁交互式论证到 (d) 早期 SNARK 的转变。

事后看来，从 (a) → (b) → (c) → (d) 线性地审视所有这些步骤，我们可以清楚地看到，SNARK 设计者实际上两次省略了交互——一次是从 (a) → (b)，另一次是从 (c) → (d)。

但如果我们打算使用 Fiat-Shamir 来消除交互……我们应该直接跳过中间步骤 (b)，也就是概率可验证证明！跳过中间这个 (b) 步骤，正是 Jolt 方法背后的关键洞见，它直接从交互式证明构建 SNARK——直奔求和验证。

为什么更多的人没有更早地转向基于求和验证协议的设计方法呢？早期的 SNARK 设计者可能没有这样做，是因为 PCP 和 SNARK 表面上看起来很相似，因为它们都实现了简洁验证的概念。至于后续发展，架构——以及误解——可能会持续存在。

对我们而言，将大量工程和研究资源投入到基于求和校验的 zkVM Jolt 中，是一种逆向押注，因为它与 SNARK 领域数十年来占据主导地位的范式背道而驰。

‘Jolt Inside’

Jolt 的 SNARK 设计方法（其本身基于批量求值和内存检查机制，例如 Twist + Shout）基于交互式证明和求和校验协议。

如今，在我们开始构建 Jolt 几年之后，其他人也开始在他们的设计中采用求和校验协议方法。那么，Jolt 在当今的 zkVM 中有哪些显著特点呢？Jolt 最大限度地利用了 CPU 执行中的重复结构。通过观察每个 CPU 核心的“取指-解码-执行”抽象如何适用于批量求值机制，Jolt 以最小的复杂度实现了无与伦比的效率。

与之相对，其他 zkVM 则严重依赖“预编译”（类似于 ASIC 的加速器，用于特定子程序）来实现合理的性能。Jolt 摒弃了这些预编译，因为它们会重蹈 zkVM 出现之前 SNARK 设计方法的覆辙：由于需要专家来设计这类专用 SNARK，它们更容易出现 bug，也更难被广大开发者使用。Jolt 的重点在于普及 SNARK。

验证 CPU 执行的正确性正是 zkVM 的核心价值所在——也是开发者体验的一大突破——因为它允许重用现有的、经过强化的通用计算基础设施。全球的计算基础设施都是为了支持 CPU 而构建的，而 Jolt 则充分利用了 CPU 执行固有的“结构”，最大限度地提升了简洁性和性能。

Jolt 从一开始就将可用性与生产级性能放在首位：开发者可以直接验证现有程序；即使是为了快速验证，也无需修改任何代码。Jolt 不会像其他方案那样，为了达到可接受的性能而强迫团队围绕“预编译”或特殊 API 重构应用程序，而是保持原始代码的完整性，使其更易于采用、更易于审计，并且迭代成本更低。

更重要的是，Jolt 不仅速度更快，而且更简单。其他方案需要 zkVM 设计者为虚拟机的每条基本指令指定一个电路，而 Jolt 则不需要：在 Jolt 中，每条基本指令只需大约十行 Rust 代码即可指定。无需电路，只需十行代码。

Jolt 的下一步是什么？

我们在速度方面已经处于领先地位。随着进一步的优化和功能的加入，包括递归和零知识证明——尤其是我们计划从椭圆曲线密码学到格密码学的转变——我们将在今年晚些时候实现速度的又一个数量级提升，更不用说后量子时代了。

Jolt 让更多应用成为可能。对于区块链而言，大家期待已久的可扩展性和去中心化将变得更加易于部署。零知识证明汇总可以开箱即用，无需耗费数月甚至数年的密码工程。

但随着 Jolt 的进一步发展——例如，打造可在手机和笔记本电脑上运行的快速简便的零知识证明虚拟机——开发者将能够在客户端和隐私保护方面解锁更多用例。例如，手机上的隐私保护应用可以从难以维护、几乎无法运行，轻松实现开箱即用。

从长远来看，这些证明系统将成为世界数字基础设施的核心组成部分，类似于加密和数字签名。这种通用的加密压缩技术——任何人只需发送一个 50 千字节的证明文件，而非全部数据，即可证明自己掌握了满足特定属性的数 GB 数据——功能如此强大，以至于很难预测人们会用它开发出哪些应用。其可能性无穷无尽。

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。