a16z：探索 zkVM 的高效安全之路

作者：Justin Thaler 来源：a16z 翻译：善欧巴，金色财经

零知识虚拟机（zkVMs） 旨在“让 SNARKs 走向大众化”，使得即使没有 SNARK 专业知识的人，也能证明他们在特定输入（或见证）上正确运行了某个程序。其核心优势在于开发者体验，但当前 zkVMs 在 安全性 和 性能 方面仍面临巨大挑战。如果 zkVMs 想兑现承诺，设计者必须克服这些障碍。本文将探讨 zkVM 发展的可能阶段，整个过程可能需要 数年 才能完成——别听信任何人说这能很快实现。

面临的挑战

在 安全性 方面，zkVMs 是高度复杂的软件项目，仍然充满漏洞。

在 性能 方面，证明一个程序的正确执行可能比原生运行慢 数十万倍 ，使得大多数应用在现实世界的部署 暂不可行 。

尽管如此，区块链行业的许多声音仍然宣传 zkVMs 已经可以立即部署 ，甚至一些项目已经在支付高昂的计算成本，以生成链上活动的零知识证明。然而，由于 zkVMs 仍存在诸多漏洞，这种做法实际上只是 一种昂贵的伪装 ，让系统看起来像是由 SNARK 保护，而实际上它要么依赖 权限控制 ，要么更糟糕—— 暴露于攻击风险 。

现实情况是，我们距离构建真正安全且高效的 zkVM 仍有数年之遥。 本文提出了一系列 具体且分阶段 的目标，以帮助我们追踪 zkVM 的真实进展，削弱炒作，并引导社区关注真正的技术突破。

安全性发展阶段

背景

基于 SNARK 的 zkVMs 通常包含两个核心组件：

1. 多项式交互式预言机证明（Polynomial Interactive Oracle Proof, PIOP） ：用于证明多项式（或由多项式派生的约束）的交互式证明框架。

2. 多项式承诺方案（Polynomial Commitment Scheme, PCS） ：确保证明器无法伪造多项式评估结果而不被检测到。

zkVM通过 将有效的执行轨迹编码为约束系统 ，确保虚拟机的 寄存器 和 内存 的正确使用，然后利用 SNARK 证明这些约束的满足性。

在如此复杂的系统中，唯一能确保 zkVM 无漏洞的方法就是 形式化验证 。以下是 zkVM 安全性的不同阶段，其中 第一阶段关注协议正确性 ， 第二和第三阶段关注实现正确性 。

安全性阶段 1：正确的协议

1. PIOP 可靠性的正式验证证明；

2. PCS 在某些加密假设或理想模型下具有约束力的形式验证证明；

3. 如果使用 Fiat-Shamir，则通过结合 PIOP 和 PCS 获得的简洁论证在随机预言模型中是安全的正式验证证明（根据需要使用其他加密假设进行增强）；

4. PIOP 所应用的约束系统等同于 VM 的语义的形式验证证明；

5. 将以上所有这些部分全面「粘合」成一个单一的、经过形式化验证的安全 SNARK 证明，用于运行 VM 字节码指定的任何程序。如果协议打算实现零知识，则还必须对此属性进行形式化验证，以确保不会泄露有关见证人的敏感信息。

如果 zkVM 使用 递归 ，那么在递归过程中涉及的 PIOP、承诺方案和约束系统 都必须经过验证 ，否则该子阶段不能算作完成。

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

这一阶段要求对 zkVM 验证器 的实际实现（如 Rust、Solidity 等）进行 形式化验证 ，确保其符合第一阶段已经验证的协议。完成该阶段意味着 zkVM 的 实现 与 理论设计 是一致的，而不仅仅是一个 纸面上的安全协议 ，或一个使用 Lean 等语言编写的低效规范。

为什么 只关注验证器，而不关注证明者 主要有两个原因：首先， 确保验证器正确，即可保证 zkVM 证明系统的完备性 （即：确保验证器不会被欺骗，使其接受一个错误的证明）。其次， zkVM 的验证器实现比证明者实现简单一个数量级以上 ，验证器的正确性更容易在短期内得到保障。

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

这一阶段要求对 zkVM 证明者 的实际实现进行 形式化验证 ，确保它能够 正确生成 第一、二阶段中已经验证的证明系统的证明。这一阶段的目标是 完备性 ，即：任何使用 zkVM 的系统都不会因为无法证明某个合法语句而 卡死 。如果 zkVM 需要具备零知识属性，则必须提供形式化验证，以确保证明不会泄露关于见证的任何信息。

预计时间表

第 1 阶段进展 ：我们可以期待明年取得一些进展（例如，ZKLib就是这样一项努力）。但至少两年内没有一个 zkVM 能够完全满足第 1

阶段的要求。

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

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

一个主要的复杂性问题是， Fiat-Shamir 变换的安全性仍然存在未解的研究问题 。所有三个安全阶段都将 Fiat-Shamir 和随机预言机视为绝对安全，但实际上整个范式可能存在漏洞。这是由于 随机预言机的理想化模型与实际使用的哈希函数之间存在差异 。

在最坏的情况下，一个已经达到 安全性阶段 2 的系统，可能 因 Fiat-Shamir 相关问题而被发现完全不安全 。这值得我们高度关注，并持续进行研究。我们可能需要 修改 Fiat-Shamir 变换本身，以更好地防御此类漏洞 。

不使用递归的系统在理论上更安全 ，因为已知的一些攻击涉及的电路类似于递归证明中使用的电路。但这一风险仍然是一个 未解决的基本问题 。

另一个需要注意的问题是，即使 zkVM 证明了某个计算程序（由字节码指定）被 正确执行 ，但如果 字节码本身存在缺陷 ，那么这个证明的价值 极其有限 。因此，zkVM 的实用性在很大程度上依赖于 如何生成经过形式化验证的字节码 ，而这一挑战 极其巨大 ，并且 超出了本文的讨论范围 。

关于抗量子安全性

在未来至少 5 年（甚至更长时间）内，量子计算机不会构成严重威胁，而软件漏洞则是一个生死攸关的问题。 因此，目前的首要任务应该是实现本文所提出的安全性和性能目标。如果非抗量子安全的 SNARKs 能够更快满足这些目标，我们应该优先使用它们。等到抗量子 SNARKs 赶上发展，或者有迹象表明具备实际威胁的量子计算机即将出现时，再考虑切换。

具体的安全级别

100-bit 经典安全性 是任何 SNARK 用于保护有价值资产的 最低标准 （但仍然有一些系统 未达到这一低标准 ）。即便如此，这仍然 不应被接受 ，标准密码学实践通常要求 128-bit 安全性及以上 。 如果 SNARK 的性能真正达标，我们不应该为了提升性能而降低安全性 。

性能阶段

当前情况

目前，zkVM 证明器 的计算开销大约是 原生执行的 100 万倍 。换句话说，如果一个程序的原生执行需要 X 个 CPU 周期 ，那么 生成正确执行的证明 大约需要 X × 1,000,000 个 CPU 周期 。这一情况在 一年前如此，今天仍然如此 （尽管存在一些误解）。

当前行业中的一些流行说法可能会造成误导，例如：

1. “为整个以太坊主网生成证明的成本低于每年 100 万美元。”

2. “我们几乎实现了以太坊区块的实时证明生成，只需要几十张 GPU。”

3. “我们的最新 zkVM 比前代快 1000 倍。”

然而，这些说法在没有上下文的情况下可能具有误导性：

• 比旧版 zkVM 快 1000 倍，仍然可能非常慢 ，这更能说明 过去有多糟糕，而不是现在有多好 。

• 以太坊主网的计算量可能在未来增加 10 倍 ，这将使当前 zkVM 的性能远远跟不上需求。

• 所谓的“几乎实时” 证明生成，在许多区块链应用的需求下仍然 过于缓慢 （例如 Optimism 的区块时间为 2 秒，比以太坊的 12 秒快得多 ）。

• “几十张 GPU 长时间 24/7 运行” 并不能提供 足够的活性保证 。

• 这些 证明生成时间通常是针对超过 1MB 的证明大小 ，而这对于许多应用来说 过大 。

• “每年不足 100 万美元的成本” 只是因为 以太坊完整节点一年仅执行约 25 美元的计算 。

对于区块链之外的应用场景，这种计算开销显然过高。无论多少并行计算或工程优化，都无法弥补如此巨大的计算开销。

我们应该设定的基本目标是：性能开销不超过原生执行的 100,000 倍。但即便如此，这仍然只是第一步。如果要实现真正的大规模主流应用，我们可能需要将开销降低到原生执行的 10,000 倍或更少。

性能测量

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

1. 底层证明系统的固有效率 。

2. 针对特定应用的优化 （例如预编译）。

3. 工程和硬件加速 （例如 GPU、FPGA 或多核 CPU）。

虽然（2）和（3）对于实际部署至关重要，但它们适用于任何证明系统，因此 不一定能反映基本开销的改进 。例如，给 zkEVM 添加 GPU 加速和预编译可以轻松比单纯依赖 CPU 提高 50 倍的速度——这可能会让一个固有效率较低的系统看起来优于另一个未经过相同优化的系统。

因此，本文重点衡量 在没有专用硬件和预编译的情况下，SNARK 的基本性能 。这与当前的基准测试方法不同，后者通常将所有三个因素合并为一个“总体数值”。这就像 通过抛光时间来评判钻石，而不是评估其固有的清晰度 。

我们的目标是 隔离通用证明系统的固有开销 ，降低尚未深入研究的技术的进入门槛，并帮助社区排除干扰因素，从而聚焦于 证明系统设计的真正进展 。

性能阶段

以下是我提出的五个性能阶段的里程碑。首先，我们需要在 CPU 上大幅降低证明者开销，之后才能进一步依靠硬件减少开销。同时，内存使用也必须得到改善。

在所有阶段中， 开发者不应为了 zkVM 的性能而调整代码 。开发者体验是 zkVM 的核心优势。如果为了满足性能基准而牺牲 DevEx，那不仅失去了基准测试的意义，也违背了 zkVM 的初衷。

这些指标主要关注 证明者成本 。然而，如果允许验证器 成本无限制增长 （即无上限的证明大小或验证时间），那么任何证明者指标都可以轻松满足。因此，要满足下述阶段的要求， 必须同时限定最大证明大小和最大验证时间 。

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

• 证明大小 ：必须小于见证大小。

• 验证时间 ：验证证明的速度不得比程序的原生执行慢（即，不得比直接执行计算慢）。

这些是 最低限度的简洁性要求 ，确保 证明大小和验证时间不会比直接发送见证给验证器并让其直接检查更糟糕 。

阶段 2 及以上

• 最大证明大小 ：256 KB。

• 最大验证时间 ：16 毫秒。

这些上限有意设置得较为宽松，以适应新颖的快速证明技术，即使它们可能带来更高的验证成本。同时，这些上限排除了成本高昂到几乎没有项目愿意在区块链上使用的证明。

速度阶段 1

单线程证明速度不得比原生执行慢超过 100,000 倍 （适用于多种应用，而不仅仅是以太坊区块证明），且不得依赖预编译。

具体而言 ，假设一台现代笔记本上的 RISC-V 处理器运行速度约为 30 亿周期/秒 ，那么达到阶段 1 意味着该笔记本能够以 30,000 RISC-V 周期/秒 的速度生成证明（单线程）。

验证器成本必须满足之前定义的“合理的非平凡验证成本”标准。

速度阶段 2

单线程证明速度不得比原生执行慢超过 10,000 倍 。

或者 ，由于某些有前景的 SNARK 方法（特别是二进制域 SNARK）受当前 CPU 和 GPU 限制，可以通过 FPGA（甚至 ASIC）来满足此阶段：

1. 计算 FPGA 以原生速度模拟的 RISC-V 内核数量。

2. 计算模拟和证明 RISC-V 执行（接近实时）所需的 FPGA 数量。

3. 如果（2）的数量 不超过（1）的 10,000 倍 ，则满足阶段 2。

• 证明大小 ：最大 256 KB。

• 验证时间 ：标准 CPU 上最大 16 毫秒。

速度阶段 3

在达到 速度阶段 2 的基础上，实现 1000× 以内的证明开销 （适用于多种应用），并且必须使用 自动合成和形式化验证的预编译 。本质上， 动态定制每个程序的指令集，以加速证明生成 ，但必须保证 易用性和形式化验证 。（关于 预编译为何是一把双刃剑 ，以及为什么“手写” 预编译不是可持续的方法，请参阅下一部分。）

内存阶段 1

在少于 2 GB 内存的情况下 达到 速度阶段 1 ，并同时满足 零知识要求 。这一阶段对于 移动设备或浏览器 至关重要，并为 大量客户端 zkVM 用例 打开了大门。例如，智能手机用于 位置隐私、身份凭证等 。如果证明生成需要超过 1-2 GB 内存，大多数移动设备将无法运行。

两点重要说明：

1. 即使是大规模计算（需要数万亿 CPU 周期的原生执行），证明系统也必须维持 2 GB 内存上限，否则适用性将受限。

2. 如果证明速度极慢，则保持 2 GB 内存上限很容易。因此，为了让内存阶段 1 有意义，必须在 2 GB 内存限制内达到速度阶段 1。

内存阶段 2

在少于 200 MB 内存的情况下 达到 速度阶段 1 （比内存阶段 1 提高 10 倍）。

为什么要降低到 200 MB？考虑一个 非区块链场景 ：当你访问 HTTPS 网站时，会下载认证和加密证书。如果网站改为发送这些证书的 zk 证明，大型网站每秒可能需要生成 数百万个证明 。如果每个证明需要 2 GB 内存，计算资源需求将达到 PB 级别 ，显然不可行。因此，进一步降低内存使用对 非区块链应用 至关重要。

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

预编译 指的是 专门为特定函数（如哈希、椭圆曲线签名）优化的 SNARK 约束系统 。在以太坊中，预编译能降低 Merkle 哈希和签名验证的开销，但过度依赖预编译并不能真正提升 SNARK 的核心效率。

预编译的问题

1.仍然过慢 ：即使使用哈希和签名预编译，zkVM 在区块链内外仍然存在核心证明系统的低效问题。

2.安全漏洞 ：手写预编译如果未经形式化验证，几乎必然存在漏洞，可能导致灾难性安全失败。

3.开发者体验差 ：目前，许多 zkVM 需要开发者 手写约束系统 ，类似 1960 年代的编程方式，严重影响开发体验。

4.基准测试误导 ：如果基准测试依赖于优化特定预编译，可能会误导人们关注优化手工约束系统，而非提升 SNARK 设计本身。

5.I/O 开销和无 RAM 访问 虽然预编译可以提高繁重加密任务的性能，但它们可能无法为更多样化的工作负载提供有意义的加速，因为它们在传递输入/输出时会产生大量开销，并且它们不能使用 RAM。

即使在区块链环境中，只要你超越了像以太坊这样的单一 L1（比如，你想建立一系列跨链桥），你就会面临不同的哈希函数和签名方案。为了解决这个问题而不断进行预编译，这既不可扩展，又会带来巨大的安全风险。

我确实相信预编译从长远来看仍然至关重要，但只有在它们自动合成并经过正式验证后才会如此。这样，我们可以保持 zkVM 的开发人员体验优势，同时避免灾难性的安全风险。这一观点反映在阶段3 中。

预期时间表

我预计少数 zkVM 将在今年晚些时候达到 速度阶段 1 和 内存阶段 1 。我认为在接下来的两年内，我们也能实现 速度阶段 2 ，但目前尚不清楚能否在没有新的研究思路的情况下达到这一目标。

我预计其余阶段（ 速度阶段 3 和 内存阶段 2 ）将需要数年时间才能达成。

尽管本文分别列出了 zkVM 的安全性和性能阶段，但这两者并非完全独立。随着 zkVM 中的漏洞不断被发现，我预计其中一些漏洞的修复将不可避免地导致性能大幅下降。因此，在 zkVM 达到 安全阶段 2 之前，其性能测试结果都应被视为暂定数据。

zkVM 在让零知识证明真正普及方面具有巨大潜力，但目前仍处于早期阶段——充满安全挑战，并且存在严重的性能瓶颈。市场炒作和营销宣传让衡量真正的进展变得困难。通过明确的安全性和性能里程碑，我希望提供一条能够拨开迷雾的路线图。我们终将到达目标，但这需要时间，以及在研究和工程上的持续努力。