最近发布的用于构建零知识应用程序的框架，例如 Zinc 和 Cairo，允许开发人员相对轻松地编写程序

最近发布的用于构建零知识应用程序的框架，例如 Zinc 和 Cairo，允许开发人员相对轻松地编写可以验证执行的程序，同时保持所有或部分输入私有。就开发人员友好性而言，这比编写零知识 电路更上一层楼，因为此类框架提供了一个单一的零知识虚拟机 (ZK VM) 电路，可以验证任何支持大小的程序。如果没有此选项，开发人员必须为每个应用程序编写新电路并处理唯一证明和验证密钥的复杂性。

尽管这种 ZK VM 有很多好处，但我认为开发人员应该认真考虑一些权衡。在这篇文章中，我从高层次上描述了 ZK 电路和 VM，并讨论了 ZK VM 的优点和缺点。虽然 ZK VM 提供了强大的优势，例如更容易开发、更简单的安全模型以及与其他 VM 更好的兼容性，但我认为市场上某些 ZK VM 的供应商锁定风险是微妙的，但被低估了。通过这篇博文，我的目标是开始讨论这个问题，以便开发人员能够更好地理解所涉及的全部权衡，如果他们选择在上述 ZK VM 平台上构建应用程序。

要了解 ZK VM，必须了解 ZK 电路，有时称为 算术电路 或 代数中间表示 (AIR)。在不深入研究技术细节的情况下，只需说电路是程序的表示即可。给定一个电路，证明者可以使用像 zk-SNARK 或 zk-STARK 这样的零知识结构来证明，在给定一组输入的情况下，他们已经正确地执行了这个程序，而不会泄露任何（或部分）输入。加密货币应用程序的常见电路包括防止从 zk-rollups 和 混合器中双重提取资金的电路，或者证明协调员正确计算了一组投票的 电路。反串通私人投票系统。

算术电路。资料来源：  Hartwig Mayer。

最近几个月，一些零知识应用框架通过零知识虚拟机将这种方法更进一步 。ZK VM 是执行字节码的电路。它允许证明者证明，给定一组输入以及一些字节码，他们已经正确地执行了所述输入上的程序代码。

值得注意的是，字节码（或程序）不是电路本身，而是其输入的一部分。因此，只要所述程序适合底层 ZK VM 电路，证明者就可以使用相同的电路为任意程序创建执行有效性证明。

ZK VM 并不新鲜。2013 年，Eli Ben-Sasson 等人 介绍了 TinyRAM：

为有效验证非确定性计算而量身定制的随机存取机器……该系统可用于证明 C 程序的正确执行，使用我们的 GCC 编译器的 TinyRAM 端口。

随着支持智能合约的区块链的兴起，研究人员发现了 ZK VM 的以隐私为中心的用例，例如 Hawk早在 2016 年就描述了“私人智能合约”：

Hawk 程序员可以以直观的方式编写 私有智能合约 ，而无需实施密码学，并且我们的编译器使用零知识证明等密码学原语自动生成有效的密码学协议，让合同方与区块链进行交互。（重点补充）

ZK VM 通过像 Aleo 这样的系统得到了进一步的发展 ，它遵循私有计算的 ZEXE 模型。Aleo 提供了一种语言 Leo来编写包含在事务中的程序；所述程序接受输入记录并产生输出记录：

每个 Leo .leo 文件都被编译成一个程序。每个程序都存在于一个记录中。每条记录都存在于一个事务中。Aleo 交易花费了两条旧记录：  old_record_0， old_record_1 并创建两条新记录：  new_record_0，  new_record_1。（来源）

最近，Starkware Industries 发布了 Cairo，一种基于 STARK 的图灵完备语言：

Cairo 是第一个实现图灵完备的冯诺依曼架构的生产级证明系统：每个 Cairo 程序 与由它处理P 的数据一起驻留在虚拟机的内存中 D 。Cairo 带有一个可以验证任何 Cairo 程序的 AIR（因此也有一个 Verifier——在智能合约、WebAssembly 等中）。即 Cairo AIR 验证在 上执行的计算完整性 P ， D以及系统执行后状态的正确性。（来源）

Matter Labs 还发布了 ZK VM 和 Zinc，这是一种编译成 VM 可以执行的字节码的语言：

Zinc 代码被编译成字节码，可以由 Zinc VM 运行。Zinc VM 是一个虚拟机，具有三个用途：执行任意计算、生成已执行计算的零知识证明以及在不知道输入数据的情况下验证所提供的证明。

此外，Matter Labs 表示，他们即将在零知识下实施以太坊虚拟机，这允许开发人员部署“现有的 EVM 代码库，修改最少”。

到目前为止，这篇文章纯粹是描述 ZK VM 的现有状态并描述了它们的历史。在下一节中，我将介绍针对 ZK VM 而不是针对特定应用电路的程序开发的优缺点。

本节从希望构建使用零知识证明的应用程序的开发人员的角度讨论支持和反对使用 ZK VM 的几个论点。我假设这个开发人员已经有编写电路的经验（例如使用 arkworks 或 circom语言），并且正在考虑转向编写针对 ZK VM 的代码。

易于开发

论据。ZK VM 抽象出编写电路或 AIR 的一些棘手方面。虽然出于安全原因，开发人员仍应了解其代码将在其上运行的底层系统，但理论上为 VM 编写代码比手动连接电路更容易。一个类比是，编写 Solidity 比编写 Yul更容易，尽管开发人员必须了解 EVM 的工作原理以避免安全问题。

反对。以 ZK VM 为目标的语言并不比以电路或 AIR 为目标的语言更容易使用。此外，对开发人员高度友好的电路构造语言可以提供相同的抽象和灵活性。

回复。在开发人员效率方面，如果系统的零知识部分足够简单，一些中小型程序如果以 ZK VM 为目标，将受益最大。

更简单的证明和验证密钥管理

论据。由于 ZK VM 是接受任意程序字节码的单一电路，因此开发人员在编写特定应用电路时无需处理验证和验证密钥。假设电路的维护者已经安全且正确地生成了这些密钥并将它们公开可用，则可以根据 ZK VM 电路对它们进行验证。然后，开发人员可以只使用一组证明和验证密钥，而无需编写额外的代码来管理它们。

反对。为 ZK VM 编写的程序的安全性将继承 ZK VM 电路的任何潜在安全漏洞。这会产生单点故障，这在某些情况下或某些用例中可能是不可接受的。

回复。最好拥有一个设计良好且经过彻底审计的 ZK VM，它支持广泛的 ZK 应用程序，而不是拥有大量可能存在各种安全漏洞的 ZK 应用程序。因此，如果应用足够的资源来增强所述 ZK VM 的安全性，则可以克服上述反对意见。

与其他虚拟机的兼容性

论据。可以共享为另一个 VM 和 ZK VM 编写的代码。这使得开发人员可以相对轻松地将智能合约等应用程序从例如 EVM 移植到 ZK VM，从而通过 zk-rollup 结构享受更高的可扩展性。

反对。将 EVM 移植到零知识电路非常重要。即使 ZK VM 的作者完成了这项任务，他们也可能必须处理跟上 EVM 升级的艰巨任务，例如新的预编译或新的操作码。因此，开发人员可能更喜欢编写直接针对电路或 AIR 的代码，而不是编写可能需要时间才能成熟的 ZK VM。

回复。可以达成妥协，使得 ZK VM 只实现 EVM 的一个子集，因此它可以满足大多数用例。

我认为开发人员应该根据自己的需要和偏好来决定是否应该使用 ZK VM，而不是编写特定于应用程序的电路。然而，还有一个微妙且未被充分讨论的缺点：供应商锁定的风险。

当应用程序的开发人员依赖第三方严格控制以致开发人员无法轻易切换的工具、框架或平台时，就会发生供应商锁定。只要开发人员在开源平台上构建，他们应该不会面临这个问题。然而，目前可用的 ZK VM 的选择很少，一些 ZK VM 的作者表示他们可能对自己的平台进行更大程度的控制，而不是通常出现在完全开源的项目中。例如，由 Aztec 和 Starkware 发布的 Polaris  license指出：

[公司/基金会名称] 授予您（“被许可人”）使用、修改和重新分发 Prover 的许可，但仅限 (a) 用于非商业用途，或 (b) 仅在由证明者仅提交给北极星验证者。

根据  有关许可证的博客文章：

… StarkWare 计划发布其 STARK 证明器的源代码；Aztec 将为其 PLONK 证明者使用相同的 Polaris 许可证…… 非正式地，Polaris 许可证表示任何人都可以使用和修改证明者代码，包括用于商业用途，只要将其生成的证明提交给列入白名单的 Polaris 之一验证者。列入白名单的验证者是出现在仅附加列表中的智能合约地址，这意味着 StarkWare 只能将验证者添加到该列表中，但永远不会删除它们。

Starkware 声称该许可证有助于消除平台风险：

对于依赖 Prover 代码的开发人员，此许可消除了 StarkWare 和 Aztec 等技术提供商带来的平台风险。平台风险是开发者最关心的问题，无论这些平台是准垄断者还是技术新贵：Facebook、谷歌、Facebook 和 Twitter 等主导平台对开发者构成平台风险，因为他们可能单方面修改其平台的使用条款，或完全关闭它。

Polaris 许可证大大降低了平台风险，因为验证者的使用条款是不可变的：

Polaris 验证器不仅保证无限期存在——它们的使用条款，无论是否类似于气体，也将通过区块链变得不可变，从而为开发人员提供稳定的业务基础。

根据许可证，只要链上存在 Polaris Verifier，任何人都可以自由地使用它来验证证明。由于这些智能合约是不可变的，只要所述验证者的条款是可以接受的，平台用户就可以相信平台所有者（例如 Starkware 或 Aztec）不能将团队踩在脚下并拒绝他们访问验证者。

然而，假设只有平台所有者有能力将验证者添加到链上列表中，仍然存在一定程度的中心化。如果必须升级证明者和验证者（例如添加优化或修复安全漏洞），团队仍然 完全 依赖平台所有者来这样做。此外，没有什么可以阻止平台所有者为使用升级的验证者征收新的费用。鉴于零知识技术的快速发展、利基和复杂性，我认为这种升级很可能是必要的，因此团队必须相信平台所有者会采取合理的行动。

我了解 ZK VM 的平台所有者可能有理由创建此许可证以确保业务可持续性，并且我可以看到它是如何在完全锁定和完全软件自由之间进行折衷的。我的观点很简单，团队应该意识到 完全 消除平台风险的唯一方法是依赖完全开源的 ZK VM。总之，如果应用程序开发人员充分意识到所涉及的权衡，无论多么微妙，他们都会得到最好的服务。

2021 年 6 月 10 日更新：  Aztec 宣布 他们将在 Apache 2.0 许可下开源他们的软件。

近年来，ZK VM 发展迅速。如今，开发人员在编写零知识电路时有更多选择，尤其是 ZK VM。虽然它们带来了许多好处，但它们也带来了某些权衡。讨论最少的问题之一是供应商锁定。虽然像 Polaris 许可证这样的许可证声称是平台维持自身而不会使应用程序开发人员过度暴露于平台风险/锁定的一种方式，但应用程序开发人员在选择如何将零知识电路集成到他们的堆栈。

最后请注意，本帖仅包含本人对该话题的个人看法，不代表其他组织或个人的观点。