a16z：如何分阶段实现安全高效的 zkVM？

1 0 0

开发者必看。

撰文：a16z crypto

编译：Odaily 星球日报 Golem

zkVM（零知识虚拟机）承诺「使 SNARK 大众化」，允许任何人（即使是没有专业 SNARK 专业知识的人）证明他们已经正确运行了给定输入（或见证）上的任何程序。它们的核心优势在于开发人员体验，但目前它们在安全性和性能方面都面临巨大挑战。为了让 zkVM 的愿景兑现承诺，设计人员必须克服这些挑战。在这篇文章中，我列出了 zkVM 开发的可能阶段，完成这些阶段将需要几年时间。

挑战

在安全方面，zkVM 是高度复杂的软件项目，仍然充满了漏洞。在性能方面，证明程序正确执行的速度可能比本地运行慢数十万倍，这使得大多数应用程序目前无法在现实世界中部署。

尽管存在这些现实挑战，但区块链行业的大部分公司都将 zkVM 描绘为可以立即得到部署。事实上，一些项目已经支付了大量计算成本来生成链上活动的证明。但因为 zkVM 仍不完善，这仅仅是假装系统受到 SNARK 保护的一种昂贵的方式，而实际上它要么通过许可来保护，要么更糟的是，容易受到攻击。

我们距离实现安全且高性能 zkVM 还有数年的时间。这篇文章提出了一系列分阶段的具体目标来跟踪 zkVM 的进展——这些目标可以消除炒作并帮助社区专注于真正的进步。

安全阶段

基于 SNARK 的 zkVM 通常包括两个主要组件：

多项式交互式 Oracle 证明 (PIOP)：用于证明关于多项式（或从中得出的约束）的陈述的交互式证明框架。
多项式承诺方案 (PCS)：确保证明者不能在不被发现的情况下对多项式评估撒谎。

zkVM 本质上将有效的执行跟踪编码为约束系统——广义上意味着它们强制虚拟机正确使用寄存器和内存——然后应用 SNARK 来证明这些约束得到满足。

确保像 zkVM 这样复杂的系统没有错误的唯一途径是形式化验证。以下是安全阶段的细分。第 1 阶段侧重于正确的协议，而第 2 阶段和第 3 阶段侧重于正确的实现。

安全阶段 1 ：正确的协议

PIOP 可靠性的正式验证证明；
PCS 在某些加密假设或理想模型下具有约束力的形式验证证明；
如果使用 Fiat-Shamir，则通过结合 PIOP 和 PCS 获得的简洁论证在随机预言模型中是安全的正式验证证明（根据需要使用其他加密假设进行增强）；
PIOP 所应用的约束系统等同于 VM 的语义的形式验证证明；
将以上所有这些部分全面「粘合」成一个单一的、经过形式化验证的安全 SNARK 证明，用于运行 VM 字节码指定的任何程序。如果协议打算实现零知识，则还必须对此属性进行形式化验证，以确保不会泄露有关见证人的敏感信息。

递归警告：如果 zkVM 使用递归，则必须验证该递归中任何地方涉及的每个 PIOP、承诺方案和约束系统，才能将此阶段视为完成。

安全阶段 2 ：正确的验证器实现

形式化验证证明 zkVM 验证器的实际实现（使用 Rust、Solidity 等）与第 1 阶段验证的协议相匹配。实现这一点可确保实现的协议是合理的（而不仅仅是纸面上的设计，或用 Lean 等编写的低效规范）。

第 2 阶段仅关注验证器实现（而不是证明器）的原因有两个方面。首先，正确使用验证器已经足以保证可靠性（即确保验证器无法相信任何虚假陈述实际上是真实的）。其次，zkVM 验证器实现比 prover 实现简单一个数量级以上。

安全阶段 3 ：正确的证明器实现

zkVM 证明器的实际实现正确生成了第 1 阶段和第 2 阶段验证的证明系统的证明，即得到正式验证。这确保了完整性，也就是说，任何使用 zkVM 的系统都不会被无法证明的语句「卡住」。如果证明器打算实现零知识，则必须正式验证此属性。

预计时间表

第 1 阶段进展：我们可以期待明年取得逐步成就（例如 ZKLib ）。但至少两年内没有 zkVM 能够完全满足第 1 阶段的要求；

第 2 和第 3 阶段：这些阶段可以与第 1 阶段的某些方面同时推进。例如，一些团队已经证明 Plonk 验证器的实现与论文中的协议相匹配（尽管论文的协议本身可能没有完全验证）。尽管如此，我预计任何 zkVM 都不会在不到四年的时间内达到第 3 阶段——而且可能更长。

关键注意事项：Fiat-Shamir 安全性和经过验证的字节码

一个主要的复杂因素是，围绕 Fiat-Shamir 转换的安全性存在未解决的研究问题。所有三个阶段都将 Fiat-Shamir 和随机预言机视为它们无懈可击安全性的一部分，但实际上整个范式可能存在漏洞。这是由于随机预言机过于理想化和实际使用的哈希函数之间的差异。在最坏的情况下，由于 Fiat-Shamir 问题，已经达到第 2 阶段的系统后来可能会被发现完全不安全。这引起了严重的担忧和持续的研究。我们可能需要修改转换本身以更好地防范此类漏洞。

没有递归的系统在理论上更为稳固，因为某些已知攻击涉及的电路类似于递归证明中使用的电路。

另一个值得注意的是，如果字节码本身存在缺陷，那么证明即使已正确运行了计算机程序（通过字节码指定），价值也是有限的。因此，zkVM 的实用性在很大程度上取决于生成形式化验证的字节码的方法——这是一个巨大的挑战，超出了本文所讨论的范围。

关于后量子时代的安全性

至少在未来五年内（可能更长），量子计算机不会构成严重威胁，而漏洞则是一种生存风险。因此，现在的主要重点应该是满足本文中讨论的安全性和性能阶段。如果我们能够使用非量子安全的 SNARK 能够更快地满足了这些安全要求，那么我们就应该这样做，直到后量子 SNARK 赶上来，或者人们严重担心加密相关的量子计算机出现在考虑其他。

zkVM 的性能现状

目前，zkVM 证明器产生的开销系数接近原生执行成本的 100 万倍。如果程序需要 X 个周期才能运行，则证明正确执行的成本约为 X 乘以 100 万个 CPU 周期。一年前便是这种情况，，今天仍然如此。

流行的叙事通常以听起来可以接受的方式来描述这种开销。例如：

「为所有以太坊主网生成证明每年的成本不到一百万美元。」
「我们几乎可以使用由数十个 GPU 组成的集群小白导航实时生成以太坊区块证明。」
「我们最新的 zkVM 比其前身快 1000 倍。」

虽然从技术上讲这些说法是准确的，但如果没有适当的背景，可能会产生误导。例如：

比旧版 zkVM 快 1000 倍，但绝对速度仍非常慢。这更多说明的是事情有多糟糕，而不是有多好。
已经有人提议将以太坊主网处理的计算量增加 10 倍。这将使当前的 zkVM 性能变得更慢。
人们所说的「以太坊区块的近乎实时证明」仍然比许多区块链应用程序所要求的要慢得多（例如，Optimism 的区块时间为 2 秒，比以太坊的 12 秒区块时间快得多）。
「数十个 GPU 始终运行，毫无差错」无法达到可接受的活性保证。
每年花费不到一百万美元来证明以太坊主网上的所有活动反映了以太坊完整节点每年仅需要花费约 25 美元执行计算的事实。

对于区块链以外的应用程序，这样的开销显然太高了。任何并行化或工程都无法抵消如此巨大的开销。我们应该以相较于本机执行，zkVM 速度减慢不超过 100, 000 倍为基本基准——即使这只是第一步。真正的主流采用可能需要接近 10, 000 倍或更低的开销。

如何衡量性能

SNARK 性能有三个主要组成部分：

底层证明系统的内在效率。
特定于应用程序的优化（例如预编译）。
工程和硬件加速（例如 GPU、FPGA 或多核 CPU）。

虽然后两者对于实际部署至关重要，但它们通常适用于任何证明系统，因此它们不一定能反映基本开销。例如，在 zkEVM 中添加 GPU 加速和预编译可以轻松实现 50 倍的加速，而这比纯基于 CPU 的无预编译方法要快得多——足以让本质上效率较低的系统看起来优于没有经过同样打磨的系统。

因此，下面重点介绍在没有专门硬件和预编译的情况下，SNARK 的性能。这与当前的基准测试方法不同，后者通常将所有三个因素归结为一个「标题数字」。这相当于根据钻石的抛光时间而不是其固有的净度来判断钻石价值。我们的目标是排除通用证明系统的内在开销——帮助社区消除混杂因素，专注于证明系统设计的真正进展。

性能阶段

以下是 5 个性能实现的里程碑。首先，我们需要将 CPU 上的证明器开销削减多个数量级。只有这样，重点才应该转向通过硬件进一步减少。内存使用率也必须提高。

在下面的所有阶段中，开发人员都不必根据 zkVM 设置定制的代码来实现必要的性能。开发人员体验是 zkVM 的主要优势。牺牲 DevEx 来满足性能基准会违背 zkVM 本身的意义。

这些指标侧重于证明者成本。但是，如果允许无限制的验证者成本（即证明大小或验证时间没有上限），则可以轻松满足任何证明者指标。因此，对于要符合所述阶段的系统，必须为证明大小和验证时间指定最大值。

性能要求

第 1 阶段要求：「合理且非平凡的验证成本」：

证明大小：证明大小必须小于见证大小。
验证时间：验证证明的速度不得慢于本机运行程序（即，在没有正确性证明的情况下执行计算）。

这些是最低限度的简洁要求。它们确保证明大小和验证时间不会比将见证发送给验证者并让验证者直接检查其正确性的方法更差。

第 2 阶段及以后要求：

最大证明大小： 256 KB。
最大验证时间： 16 毫秒。

这些截止值是故意有加大的，以适应可能带来更高验证成本的新型快速证明技术。同时，它们排除了非常昂贵的证明，以至于很少有项目愿意将它们包含在区块链中。

速度阶段 1

单线程证明必须比本机执行慢最多十万倍，在一系列应用程序中进行测量（不仅仅是证明以太坊区块），而不依赖于预编译。

具体来说，想象一下在现代笔记本电脑上以每秒大约 30 亿次周期运行的 RISC-V 进程。实现第 1 阶段意味着您可以在同一台笔记本电脑上每秒证明大约 30, 000 个 RISC-V 周期（单线程）。但验证成本必须如前所述「合理且非平凡」。

速度阶段 2

单线程证明必须比本机执行慢最多一万倍。

或者，由于一些有前途的 SNARK 方法（尤其是基于二进制字段的方法）受到当前 CPU 和 GPU 的阻碍，您可以通过比较使用 FPGA（甚至 ASIC）达到此阶段：

FPGA 可以以本机速度模拟的 RISC-V 内核数量；
模拟和证明（近乎）实时执行 RISC-V 所需的 FPGA 数量。

如果后者最多比前者多 10, 000 倍，则您有资格进入第 2 阶段。在标准 CPU 上，证明大小必须最多为 256 KB，验证器时间最多为 16 毫秒。

速度阶段 3

除了达到速度阶段 2 之外，还可以使用自动合成和形式验证的预编译实现低于 1000 倍的证明开销（适用于广泛的应用程序）。本质上，可以为每个程序动态定制指令集以加速证明，但要以易于使用和形式验证的方式进行。

内存阶段 1

第 1 阶段的速度是在证明器所需的内存少于 2 GB 的情况下实现的（同时还实现了零知识）。

这对于许多移动设备或浏览器来说至关重要，因此开启了无数客户端 zkVM 用例。客户端证明很重要，因为我们的手机是我们与现实世界的持续联系：它们跟踪我们的位置、凭证等。如果生成证明需要超过 1-2 GB 的内存，那么对于当今的大多数移动设备来说实在是太多了。需要澄清两点：

2 GB 空间界限适用于大型语句（需要数万亿个 CPU 周期才能本地运行的语句）。仅针对小型语句实现空间界限的证明系统缺乏广泛的适用性。
如果证明器非常慢，则很容易将证明器的空间保持在 2 GB 内存以下。因此，为了使内存阶段 1 变得不简单，我要求在 2 GB 空间界限内满足速度阶段 1 。

内存阶段 2

阶段 1 的速度是在内存使用量不到 200 MB 的情况下实现的（比内存阶段 1 好 10 倍）。

为什么要推到 2 GB 以下？考虑一个非区块链示例：每次通过 HTTPS 访问网站时，您都会下载证书以进行身份验证和加密。相反，网站可以发送拥有这些证书的 zk 证明。大型网站每秒可能会发出数百万个这样的证明。如果每个证明都需要 2 GB 内存来生成，那么总共需要 PB 级的 RAM。进一步降低内存使用量对于非区块链部署至关重要。

预编译：最后一英里还是拐杖？

在 zkVM 设计中，预编译是指针对特定功能量身定制的专用 SNARK（或约束系统），例如用于数字签名的 Keccak/SHA 哈希或椭圆曲线群运算。在以太坊中（大部分繁重工作涉及 Merkle 哈希和签名检查），一些手动制作的预编译可以减少证明器开销。但依赖它们作为拐杖并不能让 SNARK 达到它们需要的目的。原因如下：

对于大多数应用程序（区块链内部和外部）来说仍然太慢：即使使用哈希和签名预编译，当前的 zkVM 仍然太慢（无论是在区块链环境内还是在区块链环境之外），因为核心证明系统效率低下。
安全故障：未经正式验证的手写预编译几乎肯定充斥着错误，有可能导致灾难性的安全故障。
开发人员体验不佳：在当今的大多数 zkVMs 中，添加新的预编译意味着为每个功能手动编写约束系统——本质上回到了 1960 年代风格的工作流程。即使使用现有的预编译，开发人员也必须重构代码以调用每个预编译。我们应该针对安全性和开发人员体验进行优化，而不是为了追求增量性能而牺牲两者。这样做只能证明性能没有达到应有的水平。
I/O 开销且无 RAM：尽管预编译可提高繁重加密任务的性能，但它们可能无法为更多样化的工作负载提供有意义的加速，因为它们在传递输入 / 输出时会产生大量开销，并且它们无法使用 RAM。即使在区块链环境中，只要您超越像以太坊这样的单片 L1（例如，您想要构建一系列跨链桥），您就会面临不同的哈希函数和签名方案。在问题上一次又一次地进行预编译无法扩展并带来巨大的安全风险。

出于所有这些原因，我们的首要任务应该是提高底层 zkVM 的效率。产生最好的 zkVM 的技术也会产生最好的预编译。我确实相信预编译从长远来看仍将至关重要，但前提是它们被自动合成并正式验证。这样，就可以保持 zkVM 的开发人员体验优势，同时避免灾难性的安全风险。这一观点反映在速度阶段 3 中。