通往安全高效 zkVM 的路径：如何跟踪进展

zkVMs（零知识虚拟机）承诺通过允许任何人，甚至那些没有专业SNARK知识的人，证明他们已在给定输入（或见证）上正确运行了任何程序，从而“使SNARK变得民主化”。它们的核心优势在于开发者体验，但目前在安全性和性能方面都面临巨大挑战。为了实现其承诺，设计者必须克服这些挑战。在这篇文章中，我列出了其发展的可能阶段，完成这些阶段需要几年的时间。不要让任何人告诉你不同的事情。

挑战

在安全性方面，zkVMs是高度复杂的软件项目，仍然饱受 bug困扰。在性能方面，证明程序的正确执行可能比本地执行慢数十万倍，使得大多数应用程序的实际部署在目前是不可行的。

尽管面临这些现实，区块链行业的许多方面展现出zkVMs已经可以立即部署。事实上，一些项目已经支付了相当大的计算成本来生成链上活动的证明。由于存在bug，这只是以高昂的代价假装一个系统是通过SNARK安全时，其实际上要么是通过权限管理保护，要么更糟糕的是，容易受到攻击。

事实是，我们仍然至少需要几年才能满足安全和性能的最基本目标。本文提出了一系列分阶段的、具体的目标，以追踪我们的集体进展——这些目标割裂了夸大的宣传，帮助社区集中精力于真正的进展。

安全阶段

背景

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

1. 多项式交互式oracle证明（PIOP）: 用于证明关于多项式（或从中派生的约束条件）陈述的交互式证明框架。
2. 多项式承诺方案（PCS）: 确保证明者无法在未被捕捉的情况下撒谎关于多项式评估的结果。

zkVM基本上将有效的执行轨迹编码为约束系统——大体上意味着它们通过虚拟机强制正确的寄存器和内存使用——然后应用一个SNARK来证明这些约束得以满足。

确保像zkVM这样复杂的系统不含bug的唯一路径是形式验证。下面是安全阶段的细分。阶段1完全专注于 正确的协议，而阶段2和3则专注于 正确的实现。

安全阶段1：正确的协议

阶段1a

一个形式验证的PIOP的健全性证明。

阶段1b

一个形式验证的证明，证明PCS在某些密码假设或理想化模型下是绑定的。

阶段1c

如果使用了Fiat-Shamir，一个形式验证的证明，证明通过结合PIOP和PCS获得的简洁论证在随机oracle模型中是安全的（根据其他适当的加密假设进行增强）。

阶段1d

一个形式验证的证明，证明将PIOP应用于的约束系统等效于虚拟机的语义。

阶段1e

将所有这些内容“组合在一起”以形成一个单一的、形式验证的安全SNARK的全面证明，用于运行任何由虚拟机的字节码指定的程序。如果协议打算实现零知识，这个属性也必须经过形式验证，以确保没有关于见证的敏感信息被泄露。

递归注意事项：如果zkVM使用递归，每个 PIOP、承诺方案和任何地方涉及的约束系统都必须经过验证才能认为子阶段完成。

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

一个形式验证的证明，证明zkVM验证器的实际实现（在Rust、Solidity等中）与阶段1中验证的协议一致。实现这一点可以确保实施的协议是健全的（而不仅仅是纸面设计或以低效方式在某种语言中书写的规范）。

阶段2专注于验证者实现的原因有两个。首先，正确实现验证者已经足以确保健全性（即确保验证者无法被说服认为任何虚假陈述实际上是真实的）。其次，zkVM验证器实现比证明者实现简单得多，数量级上相差一个数量级。

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

一个形式验证的证明，证明zkVM证明者的实际实现能够正确生成阶段1和2中验证的证明系统的证明。这确保了完整性——即任何使用zkVM的系统不会由于无法证明的陈述而“卡住”。如果证明者打算实现零知识，这个属性也必须经过形式验证。

预计时间表

• 阶段1进展：我们可以期待在接下来的一年中取得逐步成就（例如， ZKLib 就是这样一个努力）。但没有zkVM可能在至少两年内完全满足阶段1的要求。
• 阶段2和3：这些可以与阶段1中的某些方面并行推进。例如，一些团队已显示 Plonk验证器的实现与论文中的协议匹配（尽管该论文的协议本身可能没有完全得到验证）。然而，我预计没有zkVM能在四年内达到阶段3 — 而且可能会更长。

关键注意事项：Fiat-Shamir安全性与验证字节码

一个主要的复杂因素是，有关Fiat-Shamir变换安全性的开放研究问题。所有三个阶段都将Fiat-Shamir和随机oracle视为其安全性是不可侵犯的，但实际上整个范式可能会发现存在漏洞。这是因为随机oracle理想化与实际中使用的哈希函数之间的差异。在最坏的情况下，可能已达到阶段2的系统后续会由于Fiat-Shamir问题而发现完全不安全。这是一个值得严重关注和继续研究的问题。我们可能需要修改变换，以更好地防范此类漏洞。

没有递归的系统在理论基础上相对牢固，因为某些已知攻击涉及到类似于递归证明中使用的电路。但风险仍然是一个基本开放问题。

另一个注意事项是，如果提出你已正确运行计算机程序（通过字节码指定），当字节码本身有缺陷时，其价值有限。因此，zkVM的实用性在很大程度上依赖于生成形式验证字节码的方法——这是一项巨大的挑战，超出了本文的范围。

关于后量子安全

在接下来的五年内（并且可能更长），量子计算机并不构成严重威胁，而bug却是生存上的风险。因此，现在的主要关注应是实现本文中的安全和性能阶段。如果我们能够用不是量子安全的SNARKs更快地达到这些阶段，我们就应该这样做。我们应持续使用这些算法，直到量子安全的SNARKs赶上，或者有理由担心与密码学相关的量子计算机即将出现。

具体的安全级别

100位的经典安全性是任何人部署SNARK保护有价值项目的绝对最低要求（仍然存在一些未达到这一最低标准的部署）。即便如此，这也不应被视为可以接受：标准密码实践要求使用128位及更高的安全级别。如果SNARK性能真的达到了需求，我们就不会为了微小的性能提升而削减安全性。

性能阶段

当前情况

当前，zkVM证明者的开销比例接近于本地执行成本的百万倍。如果一个程序运行需要 X 个周期，证明正确执行的成本将在 X × 1000000 CPU周期级别。这种情况大约在一年前就是如此，而当前仍然如此（尽管存在误解）。

流行的叙述通常以听起来可接受的方式框架这个开销。例如，你可能会听到：

• “为以太坊主网生成证明每年花费不到一百万美元。”
• “我们几乎在使用几十个GPU集群进行以太坊区块的实时证明生成。”
• “我们最新的zkVM速度比前一代快1000倍。”

虽然在技术上准确，但这些声明在没有适当背景的情况下可能会误导。例如：

• 比旧的zkVM快1000倍仍然让其在绝对意义上是非常慢的。这更多地表明了之前的糟糕情况，而不是当前的罕见优越性。
• 已经有提案将执行计算 可以提高以太坊主网的处理能力10倍。这将使得当前的zkVM性能 远 限于可用。
• 人们称之为“几乎实时证明以太坊区块”仍然远远慢于许多区块链应用程序的需求（例如，Optimism的区块时间为2秒，远快于以太坊的12秒区块时间）。
• “始终运行的几十个GPU，毫无失败”未能满足可接受的活跃性保证。
• 这些证明者所需的时间常常是基于对许多应用程序来说过大的证明规模（例如，超过1MB）。
• 为了证明所有以太坊主网的活动消费不到一百万美元反映了以太坊完整节点每年只执行约25美元的计算。

对于区块链之外的应用程序，这种开销显然太高。任何平行化或工程技术都无法弥补如此巨大的开销。

我们应该把慢速性能基准定在相对本地执行不少于100,000×作为基本基线——即使这样也是第一步。真正的主流采用可能要求开销接近于10,000×或更低。

性能衡量

SNARK性能有三个主要组件：

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

虽然（2）和（3）对于实际部署至关重要，但它们通常适用于任何证明系统，因此不一定反映出内在开销的基础进展。例如，给zkEVM添加GPU加速和预编译可以轻易使其比纯CPU、未预编译的方式快50倍——足以让一个内在效率较低的系统看起来优于一个仅仅未接受过同样精心修整的系统。

因此，本文侧重于衡量SNARK在不依赖专用硬件和预编译情况下的性能。这与当前基准方法存在差异，后者通常将三个因素合并为单一的“头条数字”。这就像用抛光的小时数来判断钻石，而不是根据其内在的清晰度。

这里的目标是隔离通用证明系统的内在开销——尽量降低未被充分探索的技术的准入门槛，让社区去掉混淆因素，专注于对证明系统设计的真正进展。

性能阶段

以下是我对性能的建议里程碑，分为五个阶段。首先，我们需要将CPU的证明者开销降低数个数量级。只有这样，才能进一步关注硬件方面的进一步减少。内存使用也必须改进。

在下面的所有阶段，开发者不应为了实现必要的性能而调整其代码以适应zkVM环境。开发者体验是zkVM的主要好处。为了满足性能基准而牺牲开发者体验违背了基准和zkVM本身的意义。

这些指标专注于证明者的成本。然而，任何证明者指标如果允许不受限制的验证者成本（即，没有对证明大小或验证时间的上限）就能轻易满足。因此，为了使一个系统符合所描述的阶段，有必要指定证明大小和验证时间的最大值。

阶段1要求：“合理的非琐碎验证成本”

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

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

阶段2及之后

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

这些限制是故意宽泛的，以容纳可能伴随更高验证成本的新鲜、快速证明技术。与此同时，它们也排除了过于昂贵的证明，几乎没有项目愿意在区块链上包含。

速度阶段1

单线程证明的速度必须不超过 100,000倍 本地执行速度，以跨越一系列应用程序进行测量（不仅仅是证明以太坊区块）和 不依赖预编译。

具体地说，想象一个RISC-V处理器以每秒约30亿周期运行在一台现代笔记本电脑上。实现阶段1意味着你可以在同一台笔记本上每秒证明大约30,000个RISC-V周期（单线程）。

验证者成本必须如之前定义的那样是“合理的非琐碎”。

速度阶段2

单线程证明的速度必须不超过 10,000倍 本地执行速度。

或者，由于一些有前景的SNARK方法（特别是那些基于二进制域的）被现有的CPU和GPU所阻碍，你可以使用FPGA（甚至ASIC）来达到这一阶段，具体比较：

• 一个FPGA可以以本地速度仿真多少个RISC-V核心， vs.
• 需要多少个FPGA来仿真和证明RISC-V执行（近）实时。

如果后一个数字至多是前一个数字的10,000倍，你就有资格进入阶段2。

标准CPU上，证明大小必须最多为256 KB，验证时间最多为16毫秒。

速度阶段3

除了实现速度阶段2外，还必须实现的证明开销在1000×以下（针对各种应用程序）使用自动合成和形式验证的预编译。基本上，为每个程序动态定制一个指令集以加速证明，但以一种易于使用和形式验证的方式来做到这一点。

（关于为何预编译是把双刃剑的更深入讨论——以及为何“手动预编译”并不是可持续方法——请见下一部分。）

内存阶段1

在达到阶段1速度的前提下，创造证明者所需的内存应少于2 GB（同时也实现零知识）。

这对于许多移动设备或浏览器至关重要，因此打开无数的客户端zkVM用例。客户端证明很重要，因为我们的手机是我们与现实世界的联系：它们跟踪我们的位置信息、凭证等。如果一个证明生成需要超过1-2 GB的内存，那么对于大多数现代移动设备来说，这就是不切实际的。达到2GB的阈值为从隐私保护位置检查到可移植、可验证的凭证等各类情况的实时设备SNARK证明打开了大门。

需要澄清以下两点：

1. 即便是对于大的陈述（那些运行时需要数万亿CPU周期的陈述），2 GB的空间限制应保持有效。仅仅对小型陈述实现空间限制的证明系统缺乏广泛适用性。
2. 如果证明者非常缓慢，保持证明者的空间低于2 GB内存自然很容易。因此，为了使内存阶段1不平凡，我要求速度阶段1必须在2GB空间限制内达成。

内存阶段2

在达到阶段1速度的前提下，创造证明者所需的内存使用应少于200 MB（比内存阶段1提高10倍）。

为什么要将内存使用推低到2GB？考虑一个非区块链的例子：每次访问HTTPS网站时，你都会下载用于认证和加密的证书。相反，网站可以发送这些证书的zk证明。大型网站可能会每秒发出数百万个这样的证明。如果每个证明都需要2 GB内存来生成，那么整个系统就需要PB级别的内存。将内存使用进一步降低，对于非区块链部署至关重要。

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

在zkVM设计中，_预编译_指的是一个特别的SNARK（或约束系统），针对特定的功能进行定制——例如Keccak/SHA散列或用于数字签名的椭圆曲线组操作。在以太坊中——大多数指令的重担涉及到Merkle散列和签名验证——少数手工制作的预编译能够减少证明者的开销。但依赖它们作为拐杖不会将SNARK引导到它需要去的地方。

为何预编译是拐杖

1. 对于大多数应用程序来说仍然太慢（区块链内外均如此）：即使有散列和签名的预编译，当前的zkVM仍然太慢——无论是在区块链背景下还是其他应用背景下，根本由于核心证明系统的深层低效率。
2. 安全性失败：未经过形式验证的手工编写的预编译几乎肯定会存在bug，可能导致灾难性的安全失败。
3. 次优的开发者体验：在当今大多数zkVM中，添加新的预编译意味着手动为每个功能编写约束系统——这本质上返回到了1960年代的工作流程。即使使用现有的预编译，开发者仍然不得不重构代码去调用每一个背后的预编译。我们应该优化安全性和开发者体验，而不是为了追求增量性能提升而牺牲这两者。这样做仅仅证明了性能并不在原本应有的高度。
4. 干扰基准测试：基于一小部分重复的加密操作的负荷进行基准测试，可能会选择那些在手动优化约束系统上的项目花费了最多时间的项目。这并不是推动SNARK设计科学向前发展的最佳路径。
5. I/O开销与内存不足：虽然预编译提升了大规模加密任务的性能，但对于更多样化的工作负载，它们可能无法提供有意义的加速，因为它们在输入/输出上会发生巨大的开销，且无法使用内存。

即便是在区块链环境中，一旦你超越像以太坊这样单一的L1——比如你想构建一堆跨链桥——就会面临不同的哈希函数和签名方案。不断为问题扔入预编译不会扩展，并引入大型的安全风险。

因此我们优先考虑应使底层zkVM的效率提高。无论哪些技术能生产出最佳的zkVM，都会产生出最佳的预编译。

我确实相信，预编译在长远中仍将至关重要，但仅限于它们被自动合成和形式验证。这样一来，我们就可以保持zkVM的开发者体验的好处，同时避免灾难性的安全风险。这一观点在速度阶段3中体现。

预计时间表

我预计在今年晚些时候会有少量zkVM达到速度阶段1和内存阶段1。我认为接下来两年内我们也能够达到速度阶段2，但尚不清楚我们是否能没有一些新想法取得这样的进展，这些新想法尚未出现在研究文献中。

我预计剩余的阶段（速度阶段3和内存阶段2）将需要若干年才能满足。

尽管我在本文中分开了zkVM安全性和性能阶段，但dkVM的这几个方面并非完全独立。随着在zkVM中发现更多漏洞，预计一些漏洞的修复将仅能以显著降低性能为代价。直至zkVM达到安全阶段2，有关性能的结果应视为暂时的。

\\*\

zkVM在使零知识证明真正普遍化方面具有巨大潜力，但它们仍然处于初期阶段——充满了安全挑战和沉重的性能开销。宣传和市场营销揿压使测量真正进展变得困难。通过清晰地阐述安全和性能里程碑，我希望提供一条突破噪音、助力大家关注真正进展的路线图。我们会达到目标，但这需要时间和持续的研究与工程努力。

\\*\

Justin Thaler是a16z的研究合伙人，并且是乔治城大学计算机科学系的副教授。他的研究兴趣包括可验证计算、复杂性理论和大数据集的算法。

\\*\

内容仅代表发布时的观点。所表达的任何预测、估计、预测、目标、前景和/或意见均可能会更改，恕不另行通知，并可能与其他人表达的意见不同或相反。详细信息请见 https://a16z.com/disclosures。

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