#dusk $DUSK @Dusk 说实话,当我姐姐指向那里时,我本来想在暮色(dusk)的隐私模型里找个“更顺”的角度,结果发现了更好的东西——一份真正的安全审计报告
OtterSec 在 dusk-plonk 里发现了一个可靠性(soundness)漏洞:这是 phoenix 盾(shielded transactions)背后的证明系统。验证者本应检查每份证明里的四个特定值,却根本没有检查——它只是把这些值直接用于最终计算,而没有拿它们去验证可信承诺(trusted commitments)
从理论上讲,这可能带来的东西很疯狂:有人可以构造一份看起来完全有效的证明,但却在“它代表的含义”上撒谎。凭空铸造暮色(mint dusk),或把一笔伪造的盾牌交易(shielded spend)塞进去。并且因为是 phoenix,如果在被盾池(shielded pool)里伪造了输出,几乎不可能被察觉——你无法像看公钥余额那样“用肉眼”判断一条私密备注(private note)
修复已在 2026 年 2 月 14 日的提交 645265b7 中上线。值得注意:这是 OtterSec 的披露,我自己没有找到暮色官方对应的匹配说明——如果有人见过,请把链接/内容发出来
人们在讨论 zk 隐私链时经常跳过的一点:隐私本身并不是最危险的,危险的是验证器(verifier)。moonlight 的公开交易(public txs)只依赖一个简单的签名校验,因此很好理解。phoenix 的盾交易(shielded txs)则完全取决于某一次证明检查是否足够“严丝合缝”。更大的信任面存在着,但它是“数学层面”的问题,所以在界面上看不出来
这也不只是 dusk 的问题——另一个独立的 plonk 实现(jellyfish 的 ultraplonk)也有同类漏洞,且在 3 月 18 日晚一个月后才修补。相同的错误,两支团队,间隔几个月
2022 年 dusk 还曾出现过另一种 plonk 可靠性相关问题:也被 trail of bits 指出、公开披露并修复。两起彼此独立的问题,相隔数年、触发机制不同,由两家不同机构发现
这让我觉得,真正的问题可能不是“它能不能隐藏交易”,而是:一个证明系统在被机构用于真实证券之前,需要多少个独立的视角(审计/验证)来确保可信。
#Web3Security