撰文：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 ：正确的协议

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

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

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

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

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

递归警告：如果 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 安全性和经过验证的字节码