TL;DR
本文深入复盘两大密码学实现漏洞：Dusk Network的PLONK验证机制因未对选择器多项式进行KZG打开验证，导致攻击者可伪造证明并窃取约6000万美元资产；LaBRADOR后量子证明系统因NTT友好环参数选择不当，存在可靠性缺陷。这些漏洞再次警示我们，密码学协议的安全性不仅取决于理论设计，更依赖于工程实现的严谨性。
一、事件概述：从理论到实践的安全鸿沟
2026年4月，密码学安全研究领域接连爆出两起重磅漏洞事件。这两起事件的核心问题都指向了零知识证明系统在工程实现层面的缺陷——不是协议设计有问题，而是实现者对密码学原语的理解和实现存在偏差。
第一起是Dusk Network的PLONK实现漏洞，该漏洞导致约6000万美元市值的DUSK代币面临被非法铸造的风险。更令人震惊的是，类似的问题同样存在于Espresso Systems的Jellyfish实现中，这意味着整个PLONK生态的实现质量都需要重新审视。
第二起是LaBRADOR后量子证明系统的实现缺陷。与传统密码学系统不同，LaBRADOR采用了特殊的NTT友好环设计来优化计算性能，但正是这种优化导致了可靠性问题。
二、Dusk PLONK漏洞技术分析：缺失的KZG验证
2.1 PLONK协议中的承诺机制
理解这个漏洞需要先回顾PLONK协议的核心机制。PLONK（Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge）是一种通用的零知识证明协议，其核心思想是将算术电路的约束关系转化为多项式关系。
在PLONK中，验证者需要检查多项式承诺的正确性。KZG（Kate-Zaverucha-Goldberg）承诺是一种常用的多项式承诺方案，它允许证明者提前承诺某个多项式，稍后再在特定点打开证明。这个打开过程是验证多项式未被篡改的关键。
2.2 选择器多项式的特殊地位
PLONK协议中有四类关键的原始多项式：wire多项式、qw多项式、qm多项式、qc多项式。其中qw、qm、qc被称为选择器（selector）多项式，它们在约束验证中起着决定性作用。
验证者需要证明这些选择器多项式在承诺点和打开点的一致性。如果验证者只检查了wire多项式，而忽略了对选择器多项式的完整验证，就给了攻击者可乘之机。
2.3 漏洞的完整利用链
攻击者可以构造恶意的选择器多项式值，使其在承诺时使用合法的系数，但在打开时返回完全不同的值。由于验证者跳过了KZG打开验证，这个差异不会被发现。
具体而言，攻击者可以：
- 修改算术约束的系数，使得虚假计算通过验证
- 绕过复制约束的检查
- 伪造任意状态的转换证明
最终效果是：攻击者可以伪造有效的PLONK证明，声称自己拥有执行任意电路计算的证明权限。这意味着攻击者可以凭空铸造DUSK代币，或伪造任何交易为已被网络确认的状态。
三、LaBRADOR实现缺陷：NTT友好环的代价
3.1 什么是NTT友好环？
数论变换（Number Theoretic Transform, NTT）是加速多项式运算的关键技术，类似于傅里叶变换在信号处理中的作用。为了高效实现NTT，需要在特定的代数环上进行运算。
NTT友好环指的是那些具有良好代数结构、可以高效支持NTT运算的环。选择不同的环会直接影响计算效率和实现复杂度。
3.2 可靠性缺陷的根源
LaBRADOR的开发者选择了不适合其证明系统的NTT友好环参数。这个选择导致了以下问题：
首先是舍入误差累积。在格基密码学中，安全性依赖于格问题的困难性。当环参数选择不当时，协议中涉及的噪声和误差会在计算过程中异常累积，导致最终证明的正确性无法保证。
其次是参数不匹配。不同的环参数会影响密钥生成、证明生成和验证的所有阶段。当实现中的参数选择与理论设计不一致时，整个系统的安全边界都会发生变化。
虽然这个漏洞的技术细节与Dusk PLONK不同，但其本质类似：都是在追求工程优化时，偏离了理论安全假设。
四、生态影响与行业警示
4.1 对PLONK生态的冲击
Dusk漏洞的影响远超Dusk Network本身。PLONK作为一种通用的零知识证明协议，被广泛应用于各种隐私项目和扩容方案中。Espresso Systems的Jellyfish实现同样存在类似问题，证明了这个问题可能是PLONK实现中的常见陷阱。
这提醒我们：零知识证明系统的标准化和形式化验证是行业急需解决的问题。
4.2 后量子时代的隐忧
LaBRADOR的漏洞发生在后量子密码学快速发展的背景下。随着量子计算进展加速，后量子证明系统的安全性变得尤为重要。如果基础层的实现存在缺陷，整个后量子安全体系都会动摇。
五、修复措施与最佳实践
针对这两类漏洞，行业需要采取以下措施：
第一，完整性验证不可跳过。在密码学实现中，每一个验证步骤都是必要的。选择器多项式的验证在Dusk漏洞中被忽略，这不应该发生。实现者需要严格遵循协议的完整验证流程。
第二，标准化验证规范。行业需要制定PLONK验证的标准化文档，明确哪些检查是必须的，哪些可以优化，以及这些优化是否安全。
第三，参数选择的系统化方法。对于像LaBRADOR这样的系统，环参数的选择需要经过严格的安全分析，不能仅仅考虑计算效率。
第四，代码审计与形式化验证。密码学实现需要专业的安全审计，并尽可能使用形式化验证工具来证明实现的正确性。
六、结论
这两起安全事件揭示了零知识证明系统从理论研究到工程实现之间的巨大鸿沟。密码学协议的安全性取决于最薄弱的一环——可能是协议设计，可能是参数选择，也可能是代码实现。
对于整个Web3行业而言，我们需要建立更严格的密码学实现标准，加强代码审计流程，并在追求性能优化时不忘安全边界。只有这样，才能真正构建起安全、可靠的区块链基础设施。
FAQ
Q1: 普通用户需要担心这些漏洞吗？
如果Dusk Network和受影响的项目已经发布补丁并完成升级，用户资产应该是安全的。建议关注项目方的官方公告，确认升级状态。
Q2: PLONK和SNARK/STARKS有什么区别？
PLONK是一种通用型的零知识证明协议，其特点是可以预定义一组”公共参考字符串”，供多次证明使用。相比之下，Groth16等早期SNARK需要为每个电路生成独立的信任设置。
Q3: 后量子证明系统现在的成熟度如何？
目前大多数后量子证明系统仍处于研究阶段，生产级库较少，大规模实际部署案例更少。LaBRADOR的漏洞说明我们在实际部署前还需要更多的安全研究。
Q4: 开发者如何避免类似的实现错误？
建议遵循以下原则：完全实现协议规范而不做选择性省略；使用经过审计的密码学库；对关键实现进行形式化验证；建立完善的测试用例覆盖边界情况。
参考链接：
