TL;DR
近期两大ZKP（零知识证明）实现相继爆出严重安全漏洞：LaBRADOR后量子证明系统因环参数选择不当存在可靠性缺陷，Dusk PLONK因未验证选择器多项式评估值导致可被伪造证明攻击。
这些漏洞暴露了ZKP库在工程实现层面的系统性风险，尤其当密码学理论正确但实现细节处理不当时，后果同样致命。
对于依赖PLONK等证明系统的DApp而言，标准化验证规范和更严格的代码审计已成当务之急。
引言：后量子时代的ZKP危机
随着量子计算进展不断突破传统认知边界，后量子密码学已成为当前密码学研究的焦点领域。NIST标准化工作为行业提供了明确指引，但与此同时，另一个常被忽视的领域——后量子证明系统——正面临严峻的现实检验。
2026年4月，zksecurity连续发布了两份重磅安全分析报告，揭露了LaBRADOR和Dusk PLONK两个实现中的严重漏洞。这些漏洞并非来自理论缺陷，而是源于工程实现中的细节疏忽，其危害程度丝毫不亚于理论层面的漏洞。
LaBRADOR：NTT友好环的可靠性陷阱
后量子证明系统的理论基础
LaBRADOR是一种基于格（Lattice）的后量子证明系统，属于近年来提出的众多新协议之一。与传统零知识证明系统不同，它专为后量子安全场景设计，旨在抵抗量子计算机的攻击。
然而，当前的生产级实现库数量稀少，大规模现实世界部署更是几乎不存在。论文中通常会详细描述参数选择，但实现者往往需要在效率与安全性之间做出权衡。
环参数选择的关键问题
zksecurity的分析指出，LaBRADOR的多种实现中使用了所谓的NTT（数论变换）友好环来优化计算性能。NTT是一种高效的多项式乘法加速技术，在ZKP验证中广泛使用。
但问题在于，当实现者为了性能而选择了「NTT友好」的环结构时，却可能在不经意间引入了可靠性缺陷。这些缺陷表现为：
- 环元素的表示在特定条件下产生歧义
- 边界条件处理不当导致验证失败
- 特定输入触发意外的数学性质
这些看似微小的实现细节问题，实际上可能导致整个证明系统产生错误验证结果。
Dusk PLONK：未验证评估的致命疏忽
6000万美元背后的信任基础
Dusk Network是一个隐私区块链项目，其隐私保护层依赖PLONK证明系统来确保安全性。在漏洞发现时，DUSK代币市值约6000万美元，数百万美元的数字资产安全完全系于一个证明检查。
然而，dusk-plonk的验证者存在一个灾难性的实现错误：从未验证证明者提交的四个选择器多项式（selector polynomials）的评估值。
PLONK约束系统的核心机制
要理解这个漏洞的危害，需要回顾PLONK的工作原理。PLONK是一种通用的零知识证明协议，其核心是使用约束系统来验证计算的正确性。
在PLONK中，选择器多项式用于控制约束的启用与禁用。例如，当你需要条件性地执行某个约束时，选择器会作为开关：如果某位为0，则跳过该约束；如果为1，则执行该约束。
理论上，这些选择器的值应该在约束系统中明确定义，验证者需要确保证明者提交的值与约束定义一致。
漏洞的完整利用链
zksecurity详细描述了攻击者如何利用这个漏洞：
第一步：构造恶意选择器值
攻击者可以在证明生成时，将四个选择器多项式的评估值设置为任意值，验证者会照单全收而不会进行任何验证。
第二步：绕过约束检查
通过操控选择器，攻击者可以「关闭」某些关键约束，使得即使输入不合法也能通过验证。例如，原本应该验证余额的非负性约束可以被关闭。
第三步：伪造任意证明
结合其他技术手段，攻击者可以生成完全有效的假证明，欺骗验证者相信任意计算已正确执行。
这意味着攻击者可以：
- 铸造任意数量的DUSK代币
- 伪造确认真实的屏蔽交易
- 绕过所有财务约束执行未授权操作
Espresso Systems Jellyfish的同类漏洞
更令人担忧的是，zksecurity同时发现Espresso Systems的Jellyfish实现中存在完全相同的漏洞模式。这表明这可能不是孤立的实现错误，而是对PLONK验证规范的普遍误解。
Jellyfish是Espresso提供的隐私协议核心组件，广泛应用于多个项目中。类似漏洞的存在意味着攻击面可能远超单一项目。
漏洞根因：理论与实现的鸿沟
密码学论文的隐含假设
这些漏洞揭示了一个深层问题：密码学论文通常会描述协议的数学基础，但实现细节往往留给开发者自行处理。论文中会说「验证者需要检查X」，但不会详细说明如何检查、在什么时机检查、以及边界情况的处理方式。
对于像PLONK这样复杂的协议，遗漏一个看似微小的检查步骤可能导致整个安全假设崩塌。
KZG承诺验证的完整流程
以Dusk的漏洞为例，PLONK验证通常使用KZG（Kate-Zaverucha-Goldberg）承诺方案。在验证过程中，验证者需要：
- 验证多项式承诺的正确性
- 确保评估点处的值与承诺一致
- 检查约束满足条件
Dusk的实现漏掉了第3步中对选择器多项式评估值的KZG打开验证，这是一个极其隐蔽但致命的安全缺陷。
行业影响与修复情况
已修复的漏洞
值得庆幸的是，两个漏洞目前均已被修复：
- Dusk Network：已发布安全补丁，修复了dusk-plonk中的验证漏洞
- Espresso Systems：已同步修复Jellyfish中的相同问题
- LaBRADOR实现者：正在根据zksecurity的建议调整环参数选择
潜在影响评估
尽管漏洞已修复，但其暴露的问题值得深思：
- 类似「未验证评估」的漏洞是否在其他ZKP库中存在？
- 开发者是否对PLONK验证规范存在系统性误解？
- 行业是否需要更严格的标准化验证流程？
对策与最佳实践
标准化PLONK验证规范
zksecurity的报告强调，行业迫切需要标准化的PLONK验证规范。目前，不同实现对验证流程的理解存在显著差异，这给安全审计带来巨大挑战。
一个清晰的规范应该明确：
- 每个验证步骤的输入输出格式
- 必须验证的数学条件
- 边界情况和错误处理
- 安全参数的选取建议
形式化验证的必要性
对于如此关键的系统，形式化验证方法可能是确保正确性的唯一途径。通过数学证明来验证实现与协议规范的一致性，可以消除人类审查可能遗漏的微妙错误。
代码审计的深度要求
传统的代码审计通常关注已知漏洞模式，但像Dusk漏洞这样的「协议级误解」难以通过模式匹配发现。这要求审计人员不仅具备代码审查能力，还需要深入理解密码学协议的设计意图。
结论：ZKP安全的新纪元
2026年发生的这两起事件标志着ZKP生态系统进入了一个新的安全阶段。早期，人们关注的是理论层面的密码学安全；现在，实现层面的工程安全同样重要。
对于Web3开发者而言，这意味着在集成ZKP库时，不能仅仅依赖「测试通过」或「广泛使用」的表象，而需要深入理解底层协议的实现细节。
对于项目方而言，与专业安全团队合作进行深度代码审计，应该是标准流程而非可选项。特别是当项目涉及大量资产时，一个看似微小的实现错误可能导致灾难性后果。
FAQ
Q1：LaBRADOR漏洞和Dusk PLONK漏洞有何本质区别？
A：LaBRADOR漏洞源于环参数选择不当，影响了证明系统的可靠性，可能导致验证结果出错；而Dusk PLONK漏洞是未验证选择器多项式评估值，属于完整性检查缺失，理论上允许攻击者伪造任意证明。前者更多影响系统的正确性，后者直接威胁安全性。
Q2：如果我是DUSK持有者，应该担心资产安全吗？
A：两个漏洞均已被修复，且在发现时并未报告有实际攻击发生。但这次事件提醒我们，作为持有者应该关注项目是否定期进行安全审计，以及对重大漏洞的响应速度如何。对于涉及大量资产的项目，多重签名和风险分散仍是必要的防护措施。
Q3：如何验证我使用的ZKP库是否存在类似漏洞？
A：建议采取以下步骤：1）检查项目是否有过独立的第三方安全审计；2）关注审计报告中的验证逻辑审查部分；3）查看GitHub等平台的Issue和Security Advisory；4）对于关键应用，考虑自建验证逻辑或使用多个独立的证明系统进行交叉验证。
Q4：行业应该如何防止类似漏洞再次发生？
A：zksecurity报告建议的核心对策包括：制定标准化的PLONK验证规范，明确每个验证步骤的要求；对ZKP库采用形式化验证方法，确保实现与协议规范的一致性；在部署前进行深入的密码学专项审计，而非仅依赖通用代码审计。
原文链接：
