针对实时 ZK 电路的前两个已知漏洞刚刚发生，它们并不是微妙的约束不足的错误。 它们是未完成可信设置仪式的 Groth16 验证器。其中一个被白帽救回，价值约 150 万美元，另一个被抽走了 5 ETH。 🧵

这两个协议使用了 Circom + snarkjs，这是 Groth16 部署中最常见的技术栈。 问题是什么？他们跳过了受信任设置的第 2 阶段：电路特定的贡献步骤。 没有它，验证密钥的 γ 和 δ 参数都被设置为相同的值：G2 生成器。

为什么 γ = δ 会破坏一切？ Groth16 验证检查： e(-A, B) · e(α, β) · e(vk_x, γ) · e(C, δ) = 1 当 γ = δ 时，攻击者可以设置 C = -vk_x 来抵消这两个项，然后设置 A = α，B = β 来抵消其余部分。方程变为 1 · 1 = 1。无需见证。

Foom协议（~140万美元）是一个在Base和以太坊上的彩票dApp。@duha_real和另一名独立白帽的白帽救援行动在恶意行为者之前清理了合同，循环伪造证明以提取99.97%至99.99%的代币。

Veil Protocol（约$5K）是基于Base的Tornado Cash分叉。攻击者在一次交易中抽走了整个池子，使用像0xdead0000这样的虚假无效器进行了29次伪造提款，提取了池子的全部2.9 ETH余额。

这是 snarkjs 按照设计工作。当你运行 groth16 setup 时，它将 γ 和 δ 初始化为 G2 生成器作为占位符。你需要运行 zkey contribute 来随机化 δ。跳过这一步，你的验证器将接受任何证明。

可怕的是：这并不是一个深层的加密缺陷或微妙的电路错误。这是一个部署错误：缺少一个CLI命令。它在生产环境中存在，真实资金面临风险。

要点： - 始终审查部署脚本，而不仅仅是电路代码 - 检查你的验证密钥：如果 vk_gamma_2 == vk_delta_2，你的证明是可伪造的 - 我们与 @DedaubSecurity 合作扫描 EVM 链以查找其他受影响的合约，未发现高价值合约，但确实存在一些