今年四月底，安全审计公司OtterSec公开了一份关于Dusk的漏洞报告，我这两天才补完细节，越看越觉得后怕。

问题出在dusk-plonk这个零知识证明库的验证环节。简单说，证明系统里prover（证明方）提交的证明包含几个多项式承诺的求值结果，正常流程验证方要把这些值跟受信任的verifier key做比对，确认没被篡改。但审计发现，验证方代码里有四个本该被校验的求值字段，实际上直接被拿去用在最终等式里，压根没做校验。这意味着理论上一个恶意prover可以伪造证明，绕开电路里所有约束条件，在Phoenix的机密转账路径下凭空铸造DUSK、伪造屏蔽交易，而链会把这些交易当成合法交易确认。

这不是Phoenix电路设计写错了，电路约束本身是对的，纯粹是证明系统底层验证逻辑漏掉了一步该做的校验——这种bug之所以容易被忽略，是因为大部分审计员脑子里对标准PLONK的心智模型是"选择器是验证方自己算的"，没意识到Dusk的实现里验证方开始直接消费prover提交的选择器求值，这个架构上的偏离才是漏洞真正藏身的地方。

这份报告让我对"审计过的项目=安全"这句话更谨慎了。dusk-plonk不是没审计过，是这类底层密码学库的bug，往往要等到有人换个角度、带着不同的心智模型重新审一遍才会暴露。目前这个问题已经被走了负责任披露流程处理，但它提醒我一件事：自研密码学库这条路,安全边界比表面上看到的要窄。

你们怎么看自研密码学栈这件事——是技术自主可控的必要投入，还是每条链都该尽量用经过更大规模实战检验的现成方案？
@Dusk_Foundation #dusk $DUSK