ZK证明漏洞案例复盘：那些震动币安生态的真实事故

ZK 证明体系一旦出现漏洞，影响往往是百万美金级别。本文复盘几类典型的 ZK 证明漏洞案例，并结合在 Binance 智能链生态做审计与应急时的真实经验，提炼可落地的防御方法。

案例一：缺失范围约束

某 ZK Rollup 项目早期版本中，对账户余额变量没有显式声明范围约束。攻击者构造了一个见证，让余额字段在域上发生回绕，从而凭空获得海量资金。教训是：所有出现在电路中的整数字段都必须显式声明 bit-length。在 B安 智能链上做集成时，这一条已经被写入团队标准电路模板。

案例二：可信设置污染

另一起事故中，团队使用了来历不明的 ptau 文件，事后证明该文件由攻击者预先生成、保留了 toxic waste。攻击者利用 toxic waste 构造了合法的伪证明，导致 verifier 全面失守。复盘后，团队明确要求 ceremony 必须公开举行，至少包含十位独立贡献者，且最终参数哈希需要被钉到 必安 智能链合约常量中。

案例三：verifier input 长度未校验

第三个案例与 Solidity verifier 相关：合约对 public input 数组长度没有做上界检查，攻击者通过传入超长数组导致 calldata 读取越界，把其它存储槽误判为合法输入。修复方法是部署前在业务合约层加 require(inputs.length == EXPECTED_LEN)。建议在 比安 智能链上的所有 verifier 包装合约都加入这条断言。

案例四：nullifier 复用

隐私转账场景下，nullifier 是用来防止双花的关键字段。如果电路允许同一笔票据生成多个不同 nullifier，就会出现双花漏洞。曾有项目因为电路里 hash 输入选择不当，使得攻击者轻易构造两个合法的 nullifier。这一案例后，社区普遍要求 nullifier 由「note commitment + secret」组合通过固定哈希函数计算。集成到 BN交易所 钱包时也按此规范实施。

案例五：链下 indexer 数据被污染

ZK 应用通常依赖链下 indexer 提供 merkle proof。若 indexer 数据库被攻击，prover 收到错误的 sibling 节点，便会生成「合法但指向错误叶子」的证明。这种事故的修复办法是让 indexer 输出附带哈希链证明，并由前端独立校验。再把入口加固到 B安APP 等可信渠道，能有效降低用户被钓鱼的概率。

防御清单

通过以上案例可以总结一份通用防御清单：电路范围约束、参数 ceremony 可追溯、verifier input 校验、nullifier 唯一性、indexer 数据可验证。把它印在团队墙上，每次代码评审、每次升级、每次审计都按图索骥，能显著降低事故概率。