ZKP Security Tools and Verification: Coverage, Effectiveness, Adoption, and Challenges
本文评估了零知识证明（ZKP）安全工具与形式化验证工作的现状，揭示了在实际代码库中覆盖范围与有效性方面的显著差距，并强调了将安全实践更好地整合进开发生命周期的必要性。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一个你可以证明自己知道某个秘密（比如密码或私人银行余额），却无需实际泄露该秘密的世界。这就是**零知识证明（Zero-Knowledge Proofs, ZKPs）**的魔力。这就像一位巫师向你展示魔术：他证明了自己能把一枚硬币变成一只兔子，但你从未见过他是如何操作的，也从未见过那只兔子在变戏法之前的样子。这些证明正在成为互联网未来的支柱，保护着数十亿美元的数字货币以及我们最敏感的个人数据。但问题在于：构建这些数字魔术极其困难。如果巫师在编写咒语书时哪怕出了一个小小的差错，整个魔术都可能失败，导致骗子伪造证明并窃取资金或伪造身份。正因为赌注如此之高，研究人员构建了一整套“安全卫士”工具箱——这些是旨在这些咒语书上线前扫描错误的软件程序。
但这些安全卫士真的有效吗？这正是这篇论文所要探讨的核心问题。作者们（来自顶尖机构的研究团队）决定对这些工具进行实测。他们不仅看了这些工具的营销手册，还收集了大量来自实际项目中的 70 个真实漏洞，并观察了这些工具能捕捉到多少。他们还采访了 48 位构建和审计这些系统的专家，以了解他们的真实看法。他们讲述的故事交织着希望与严肃的现实警示：这些工具是有用的，但远非完美，行业目前仍高度依赖人类的大脑来进行繁重的体力活。
景观：一个装满锤子的工具箱
研究人员首先审视了当前的“安全景观”。想象一个每个人都在试图修理特定类型锁具的工作室。他们发现，几乎所有的安全工具都是为了仅一种名为 Circom 的锁具语言而设计的。这就像是一个装满了锤子的车间，而世界正开始使用螺钉、螺栓和胶水。虽然 Circom 很流行，但更新的语言和系统（称为 zkVMs）几乎得不到支持。
大多数这些工具都在寻找一种特定类型的错误，叫做“约束不足”（underconstrainedness）。用类比来说，想象你正在建造一座桥。一座约束不足的桥，其蓝图写着：“这座桥必须承载一辆汽车”，但却忘了写道：“这座桥只能承载一辆汽车。”一个聪明的窃贼开着坦克驶过，而这座桥依然会显示：“是的，这是一辆有效的汽车！”这些工具擅长发现这些缺失的规则，但在处理复杂的逻辑错误或桥梁如何连接到其余道路的错误方面却显得力不从心。
路测：它们到底有多好？
接下来，团队对六种工具进行了严格的路测。他们向这些工具输入了 70 个在野外发现的真实漏洞。结果像是在坐过山车。
当工具孤立地观察这些漏洞时——就像从一台机器中拆出一个损坏的齿轮并单独测试它——它们捕捉到了大约 45.7% 的问题。这听起来很有前景！然而，当研究人员在完整的、混乱的现实世界代码库（整台机器）上测试这些工具时，其有效性骤降至仅 19.6%。
为什么会出现这种下降？论文指出，现实世界的代码是混乱的。工具经常会被复杂的依赖关系搞混，或者因为数学计算过于困难而无法快速求解，从而导致崩溃或超时。这就像一个拼写检查器，在处理单个句子时表现出色，但当你粘贴进一整部小说时就会死机。作者发现，虽然这些工具正在进步，但它们尚未准备好成为那种无需人工干预即可自动保障大规模项目安全的“一键式”解决方案。
魔镜：形式化验证
论文还探讨了一种更高级的技术，称为形式化验证（Formal Verification）。如果说安全工具是拼写检查器，那么形式化验证就像是试图通过数学方法证明这个咒语无论如何都不可能失败。这是安全性的金标准。
研究人员发现，虽然已经取得了进展，但这种进展大多发生在孤岛之中。专家们已成功证明了系统的某些部分（即“约束”或桥梁的规则）是稳固的。但整个系统呢？并不尽然。“见证生成器”（负责实际构建证明的部分）和“证明系统”（隐藏秘密的魔法）通常仍处于未经验证的状态。这就像是证明了桥梁本身很坚固，却忘了检查地基是否稳固，或者施工队是否遵循了设计图纸。论文指出，这些证明通常依赖于“可信假设”——基本上，我们必须相信用于编写证明的工具没有出错。
人类因素：专家怎么说
最后，团队调查了 48 位从业者——即那些实际构建和审计这些系统的人。结果非常有趣。即便随着 AI 和大语言模型（LLM）的兴起，这项工作仍然是由人类主导的。大约 85% 的开发者和 83% 的审计员使用 LLM 来协助他们，但他们将其作为助手而非替代品。
专家告诉研究人员，最大的问题不仅仅是发现漏洞，而是工具难以使用。它们通常需要过多的手动设置，无法适配较新的语言，且生成的报告令人困惑。从业者希望获得更容易集成、能跨不同语言工作，并能给出清晰、可靠答案的工具。他们特别担心“语义错误”——即代码完全按照指令执行，但并非程序员的本意。目前的工具在识别这类错误方面表现极差。
总结
这篇论文描绘了一个清晰的画面：零知识证明功能强大，但其安全性仍处于开发阶段。我们现有的自动化工具对于捕捉特定语言中的简单错误很有帮助，但在面对现实世界的复杂项目时却显得力不从心。目前的行业现状是自动化扫描与重度人工审查的混合体，并且日益依赖 AI 作为辅助而非英雄。
作者得出结论：我们需要更好的工具来处理整个系统，而不仅仅是局部。我们需要能够理解代码“含义”而非仅仅是语法工具，并且我们需要让形式化验证在日常开发中变得更加易用。在此之前，我们数字秘密的安全将依赖于一群人类巫师对咒语进行双重检查，同时辅以一些能捕捉明显拼写错误的辅助机器人。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。