这就是让协议团队夜不能寐的那种漏洞。 在ZKSwap上发生了500万美元的漏洞，原因是一个语句放错了地方。 以下是对事件发生经过的深入分析，以及链上监控如何能够阻止它的探讨。 🧵

1/ 在7月9日，GMX被黑客攻击，损失了4200万美元。 但那天发生了其他事情，几乎没有人注意到：ZKSwap的桥接被悄悄抽走了500万美元。 有趣的是？没有涉及任何复杂的利用。只是一个关键功能什么也没做。

2/ ZKSwap 是一个基于以太坊的 zk-rollup。 像许多 rollup 一样，它使用桥接在 L1 和 L2 之间移动资产。 作为一种保护措施，桥接包括一个“出埃及模式”，用户可以在不需要操作员的情况下找回资金。 理论上，这是个好主意。在实践中…

3/ Exodus模式允许用户手动证明他们在最后验证的L2状态中拥有代币。 这是一种后备机制：无信任、自我保管、非交互式。 但ZKSwap的实现有一个致命的缺陷：负责验证证明的功能没有验证任何内容。 字面意思。

4/ 这是本该阻止攻击的代码 👇 乍一看，它看起来像一个真正的 zk-proof 验证器。 但仔细看看第一行：return true; 就这样。没有其他代码运行。

5/ 结果是什么？每个提款“证明”（无论多么虚假）都通过了验证。 合同接受了关于代币余额的任意声明……并将其记入账目，就好像它们是真实的。 它将一个无信任的后备机制变成了一个无防备的水龙头。

6/ 攻击者不需要复杂的漏洞利用——只需对 exit() 进行重复调用，使用虚构的数据。 他们绕过了余额检查，跨多个代币进行提款，并利用弱的无效化逻辑来避免被检测。 这一切都在合约声明的同时进行：✅

7/ 这并不是某个晦涩的边缘案例。 这是资产恢复的核心逻辑，完全开放。 而且由于 Exodus 模式很少被触发，这条破损的路径几个月来都未被注意到…

8/ 这里是应该引发警报的事项： • 在长时间不活动后触发的 Exodus 模式 • 同时发生的数十个提款请求 • 提款余额突然激增 所有这些都是可见的，并且可以通过实时链上监控来阻止。

9/ 那么教训是什么？ • 紧急代码仍然是生产代码 • 如果备用路径不起作用，那就没有帮助 • 实时监控不是可选的，而是生存关键