ZK程序的可编程性增加了一个全新的担忧层面 - ZK安全性

零知识 (ZK) 程序是开发者们一个强大的新工具。它允许你编写可以证明其执行过程，而无需泄露任何底层数据的程序。这具有广泛的潜在应用，包括保护隐私的计算、安全的数据共享和欺诈预防。

然而，ZK 的可编程性也带来了新的安全挑战。在这篇博文中，我们将探讨 ZK 程序的安全含义，并讨论开发者如何降低这些风险。

从开发者的角度来看，ZK 系统通常只是编写可以被证明的程序。为此，通常可以使用一些高级库或语言。至少要有一种抽象，使得编写 ZK 程序更容易。

这些 ZK 程序仍然是程序，因此它们可能存在逻辑错误，就像任何类型的程序都可能存在逻辑错误一样。这里没有什么新鲜事，自从以太坊引入智能合约以来，这在加密领域一直是一个众所周知的问题。

一个使用 snarkyJS 库的 ZK 程序示例。

同样的一套解决方案适用。作为提醒，在以太坊中，你通常可以访问以下内容：

• 改进语言或库 - 例如 solidity，为其语言引入了许多概念和语法，以解决众所周知的错误。
• 改进虚拟机本身 - 这通常更困难，因为你通常需要保持向后兼容性，因此虚拟机不够灵活。
• 更安全的库 - 鉴于以太坊中发生的整数溢出错误数量，如今的最佳实践是使用 OpenZeppelin 发布的库（如 safemath）。
• 可更新的智能合约 - 虽然不是很理想，但可更新的智能合约允许管理员修复原本无法修复的错误。现在似乎很常见的做法是将你的智能合约作为可更新合约启动，至少在最初几年是这样，直到对实现方式有足够的信心为止。
• 安全审计 - 这些通常影响很大，因为智能合约通常是独立的并且大小受到限制。聘请安全公司就像发送电子邮件至 hello@zksecurity.xyz 一样简单。
• 形式化分析 - 虽然有时很容易简单地运行静态分析器并查看它发现的内容，但许多解决方案更加高级，需要你编写高级规范以帮助分析（例如，Move 语言 提供了此功能）。开销通常非常复杂，以至于很少有人在实践中使用它。

此外，ZK 程序引入了一些需要牢记的新概念：它们允许 私有输入 和 非确定性计算。

私有输入意味着应该注意不要泄露不应该公开的数据。一般来说，私有输入不应该是容易猜测的东西，或者不应该最终公开。例如，在 y = private + 1 中公开 y 将很容易导致 private 的泄露。

非确定性计算意味着 ZK 程序有时可以决定只接受任意数据。这对于优化电路和避免一些计算非常有用。著名的例子是除法，可以通过让用户自己计算结果（比如 c = a / b）并将结果提供给 ZK 程序来计算，ZK 程序可以约束它是正确的（例如 a = b * c）。

关键在于“约束”这个词。如果你不约束任意值，那么它可能就是任何值，这里会有潜在的危险。

现在让我们下降一个级别。开发者编写的高级 ZK 程序会发生什么？它通常会经过一个编译阶段。输出是 zkVM 的指令列表，或者是算术电路的门和线路（参见 什么是 zkVM，它与 zkEVM 有什么区别？）。

注意：ZK 系统的这部分通常被称为“前端”，与任何程序一样，这部分也可能存在错误！前端通常由 gadget 组成，这些 gadget 也是 ZK 程序（根据定义），它们为开发者抽象组件。想想：它就像编程语言中的一个库。

为了确保以高级方式编写的内容与要证明的最终电路或程序相对应，调试工具将非常重要。特别是对于习惯于检查其程序生成的汇编代码的低级程序员而言。

现在我们进入了精彩的部分：一旦编译完成，ZK 电路将被发送到证明系统。很可能，如果你使用的是预处理 SNARK（如果你不知道它是什么，请不要太担心），你将经历另一个编译阶段。

注意：这部分通常被称为后端，因为前端可以编译到不同的后端（证明系统），并且后端可以有多个前端。

证明系统是大部分繁重逻辑所在的地方。它们的协议通常没有明确规定，并且遵循（不是完全按照字面意思）通常以理论和含糊的方式（在实现细节方面）编写的论文。这没什么新鲜的，现实世界中的大多数加密协议最终都会这样。在我的书 Real-World Cryptography 中，我写了以下内容：

不幸的是，更多时候，当你的问题遇到主流原语或协议未解决的边缘情况，或者当你的问题与标准化解决方案不匹配时，你就会遇到麻烦，密码学家也愿意承认这一点。因此，开发人员创建自己的迷你协议或迷你标准非常常见。这时麻烦就开始了。

在实践中有很多细节需要正确处理，并且已经发生了破坏性的证明系统错误。例如：

• 2019 年发生的灾难性 Zcash 漏洞。
• 值 0 最终成为有效证明的 00 漏洞。
• Trail of Bits 发现的 PlonK 中的 Frozen Heart 漏洞。

在证明系统中，你有更多的电路和算术运算，看起来像我之前提到的 ZK 电路。在像 Plonk 这样的系统中，它看起来像加速运算（通常称为自定义门），在像 zkVM 这样的系统中，VM 本身被编码为一个电路。

关于这一层没有什么有趣的事情可说，可以发现与开发者方面的电路相同的问题。“不健全”的逻辑意味着攻击者可以产生错误的结果，而“不完整”的逻辑意味着随机的自我 拒绝服务攻击 可能会发生，仅仅是因为合法的逻辑无法运行。

值得注意的是：一些证明系统依赖于“可信设置”假设。有关可信设置的解释，请参阅 ZK 常见问题解答：什么是可信设置？什么是结构化参考字符串？什么是毒性废物？。

可信设置通常组织为仪式，参与者使用多方计算协作生成危险值。它们通常不好玩，组织起来也很麻烦，如果未正确完成或未正确实施，可能会导致极其严重的漏洞。

在两种方法（zkVM 或 ZK 电路）中，都必须将程序部署在某个地方。在区块链中，ZK 程序部署在链上，因此很可能无法更新（除非你允许可更新的智能合约，就像在以太坊中一样）。

一旦部署，仍然会出现问题，并且修补会导致复杂的情况......

如果前端存在错误怎么办？你必须重新编译并重新部署。并非总是可以为系统中的每个人自动“修补”东西，对于指令来说更容易，但是在区块链环境中，你无论如何都不希望这样做。

如果后端存在错误怎么办？这取决于错误在哪里。你可能不必重新部署你的程序（尽管在递归零知识证明系统中，你的证明系统就是你的程序......）

最后，应用程序级别的隐私也可能成为一个问题。看看 Tornado Cash（一种以太坊混合器），它不仅在其应用程序逻辑中存在 逻辑错误，本可能 造成毁灭性打击（更多内容将在以后的文章中介绍），而且还因未能阻止洗钱而受到 美国财政部制裁。

ZK 证明是开发人员的强大新工具，但正如我们所见，它们也在堆栈的不同层引入了新的安全挑战。因此，不要等到最后一刻才考虑安全性，请通过 hello@zksecurity.xyz 与我们联系！

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