TL;DR
本周零知识证明领域接连爆发两起严重安全事件：一是LaBRADOR后量子证明系统在NTT友好环参数选择上存在致命缺陷，导致可靠性无法保证；二是Dusk Network的PLONK实现中验证者完全未对四个选择器多项式进行KZG打开验证，攻击者可凭空铸造DUSK代币并伪造隐私交易，两起事件累计影响资产规模超6000万美元。
事件背景：后量子密码学与零知识证明的危与机
量子计算领域的最新进展正在将后量子密码学推向聚光灯下。根据NIST的后量子密码学标准化工作指引，密码学工程师必须正视这一范式转变。然而，在公钥加密领域如火如荼开展标准化工作的同时，其他领域如后量子证明系统却仍是有待深入探索的“灰色地带”。
基于格（Lattice）的零知识证明系统正是这一领域的典型代表。近年来学术研究层面涌现出大量新协议，但在生产级实现层面，可用的成熟库仍然凤毛麟角，更遑论大规模真实世界部署。这种“论文繁荣、实现贫瘠”的局面，恰恰为安全漏洞的滋生提供了温床。
漏洞一：LaBRADOR的NTT友好环参数陷阱
协议架构与环选择的理论基础
LaBRADOR作为后量子零知识证明系统的代表方案，其安全性建立在格密码学的计算硬度假设之上。在具体实现中，为了提升性能，开发者通常会选用具有特殊代数结构的环——这些环使得数论变换（NTT）得以高效执行，从而大幅加速多项式运算。
然而，zkSecurity的分析揭示了一个致命问题：当实现者选择”NTT友好”的环参数时，他们无意中引入了额外的代数结构，这些结构与协议的安全性证明之间存在微妙的不兼容性。更直白地说，为了追求计算效率而选择的环参数，可能使得原本在通用环上可证安全的协议，在特定NTT友好环上变得不再可靠。
可靠性缺陷的技术根源
深入分析表明，LaBRADOR的可靠性证明依赖于对格中困难问题（如LWE和SIS）的某些温和变体假设。当环参数被限制为NTT友好形式时，这些假设的适用范围发生了微妙变化。具体而言：
- 结构化格问题加剧：NTT友好环具有特殊的代数结构，这使得格问题可能退化为更易求解的特定形式
- 验证者承诺空间缩小：为了适配NTT而选择的循环多项式环，其承诺空间与原始协议设计存在偏差
- 模拟论证失效：零知识证明的安全性通常通过模拟范式证明，而特殊环结构可能破坏模拟器的 extractor 功能
影响评估与修复方向
尽管目前尚未出现基于此漏洞的实际攻击案例，但这种”理论上的不可靠”对于追求极致安全性的应用场景而言是不可接受的。修复方向包括：回归通用环实现（性能代价巨大）、开发针对NTT友好环的专用安全归约、或探索新型高效环结构以兼顾性能与安全。
漏洞二：Dusk PLONK的选择器多项式验证缺失
Dusk Network的安全架构与隐私承诺
Dusk Network定位为隐私公链，其核心价值主张建立在PLONK零知识证明系统之上。该网络保护着约6000万美元市值的DUSK代币，其隐私交易功能依赖于零知识证明的正确性验证。从架构设计来看，Dusk的隐私层本应固若金汤——只要PLONK验证通过，系统即可保证交易的合法性与隐私性。
然而，正是这种”信任假设”被一枚深埋的技术债务炸弹彻底击碎。
漏洞技术细节：四个未验证的选择器多项式
在深入分析dusk-plonk实现代码后，安全研究人员发现了一个令人震惊的事实：验证者从未对证明者提交的四个选择器多项式（selector polynomials）进行KZG承诺打开验证。这四个选择器多项式在PLONK协议中扮演着至关重要的角色——它们决定了电路约束的具体形式，直接影响谁能通过验证、谁会被拒绝。
PLONK的验证流程本应包含以下关键步骤：
- 验证承诺一致性：确保各多项式承诺与打开值匹配
- 约束验证：通过配对检查验证电路约束满足
- 选择器激活：确保正确的选择器在正确的位置生效
问题出在第3步。Dusk的实现完全跳过了选择器多项式的承诺-打开一致性验证。这意味着攻击者可以：提交任意值作为选择器多项式的”打开结果”，而验证者只检查了多项式承诺的存在性，却未验证该承诺对应的真实多项式系数与提交的打开值是否一致。
攻击向量与实际危害
利用此漏洞，攻击者可以构造特殊的”伪选择器”，使得：任意虚假见证满足电路约束（DUSK随意铸造）、本不该通过的验证流程成功通过（隐私交易可伪造）、验证者完全无法察觉任何异常（完美绕过链上检查）。
这意味着攻击者可以在不掌握任何秘密的情况下，为完全虚假的交易生成有效证明，将DUSK代币凭空铸造到自己的地址。更可怕的是，由于零知识证明的隐私特性，这种攻击不会暴露攻击者的身份。
横向扩展：Jellyfish的同类问题
值得注意的是，Espresso Systems的Jellyfish实现中也发现了相同性质的漏洞。这表明”未验证选择器多项式”并非Dusk独有的 coding mistake，而可能是当前PLONK实现生态中的一个系统性盲点。Jellyfish与Dusk均已发布修复版本，但此次漏洞的存在时间窗口仍是一个未知数。
两起事件的共性教训：实现与理论的鸿沟
标准化的紧迫性
两起事件共同指向一个严峻事实：零知识证明领域缺乏统一的实现标准与安全验证规范。PLONK协议本身有详细的论文描述，但各实现者对”验证者应检查什么”的理解存在显著差异。Dusk的教训表明，即使协议核心逻辑正确实现，细枝末节的验证缺失也可能导致灾难性后果。
形式化验证的必要性
对于涉及数千万美元资产的零知识证明系统，形式化验证不再是可选项而是必选项。必须通过数学证明确保实现与规范的一致性，而非仅依赖代码审计与功能测试。
安全审计的常态化
zkSecurity能在代码库中发现这些漏洞，正是专业安全审计价值的体现。建议所有零知识证明项目方建立持续、专业的第三方安全评估机制，而非仅在项目上线前做一次性审计。
行业反思：零知识证明的工业化之路
零知识证明技术正从学术前沿走向工业级应用，但”论文可用”≠”实现安全”。LaBRADOR与Dusk PLONK的教训提醒我们：后量子时代的安全挑战不仅来自算法本身，更来自工程实现的每一个细节。
对于项目方而言，需要建立完整的验证清单，确保每一个协议参与者都完成了应有的检查；对于开发者而言，需要深入理解协议安全证明的前提假设，不可在性能优化时轻易突破理论边界；对于整个行业而言，尽快推进零知识证明实现的标准化与安全认证，将是2026年乃至更长时期内的核心课题。
结语
6000万美元的教训代价沉重，但它也为整个行业敲响了警钟。零知识证明的隐私保护承诺必须建立在严谨的工程实践之上，否则所谓的”隐私”不过是建立在沙基上的大厦。当量子计算的脚步声越来越近，我们比任何时候都更需要扎实的密码学工程，而非空中楼阁式的理论许诺。
FAQ
Q1：LaBRADOR的环参数缺陷会影响已部署的系统吗？
目前尚未发现基于该漏洞的实际攻击案例。LaBRADOR本身尚未有大规模生产部署，但此缺陷意味着若直接采用NTT友好环实现，存在理论上的安全性退化风险。建议项目方在采用基于格的零知识证明方案时，务必确认其环参数选择与安全归约的一致性，或等待官方发布针对此问题的明确修复指引。
Q2：Dusk PLONK漏洞为何能存在这么久才被发现？
该漏洞的隐蔽性在于：验证逻辑从表象上”完整”——它检查了承诺的存在性、约束的满足性，但恰恰忽略了选择器多项式的承诺-打开一致性。这种遗漏不产生任何运行时错误，测试用例也不会自然触发，因此极易在常规代码审查中被忽视。这恰恰说明零知识证明的验证逻辑必须逐条对应协议的数学定义，而非仅保证”能跑通”。
Q3：普通用户应该如何评估零知识证明项目的安全性？
三个维度值得关注：一是项目是否经过专业安全机构的代码审计，审计范围是否覆盖零知识证明实现；二是项目是否采用了经过广泛测试的成熟密码学库（如bellman、gnark等），而非自研实现；三是可以关注项目是否参与了像ZKF或ZkMonitor这样的零知识证明安全标准倡议，以及是否公开了形式化验证的相关证明。
Q4：后量子时代，零知识证明系统的选择应该考虑哪些因素？
首要因素是安全性假设与实际部署环境的一致性——某些协议在通用参数下安全，但在特殊环结构下可能退化；其次是实现成熟度，经过越多安全审计和实际部署检验的方案越可靠；最后是性能与可审计性的平衡，过于复杂的协议虽然功能强大，但验证成本高、出错概率也更大。
相关链接：
