これは、プロトコル チームを夜も眠らせない種類のバグです。 ZKSwap での $5M のエクスプロイトで、間違った場所に放置された 1 つのステートメントによって可能になりました。 ここでは、それがどのように起こったのか、そしてオンチェーン監視がどのようにしてそれを阻止できたのかを深く掘り下げます。 🧵

1/ 7月9日、GMXが$42Mでハッキングされました。 しかし、その日は別のことが起こり、ほとんど誰も気づかなかった:ZKSwapの橋は$5Mで静かに排水された。 興味深い部分は?派手なエクスプロイトは含まれていませんでした。重要な機能にすぎません...何もない。

2/ ZKSwap は、イーサリアム上に構築された zk-rollup です。 多くのロールアップと同様に、ブリッジを使用して L1 と L2 の間で資産を移動します。 安全対策として、ブリッジには、ユーザーがオペレーターを必要とせずに資金を取り戻す方法である「エクソダス モード」が含まれています。 理論的には、それは素晴らしいアイデアです。実際に。。。

3/ Exodus モードでは、ユーザーは最後に検証された L2 状態でトークンを所有していることを手動で証明できます。 これはフォールバックメカニズムであり、トラストレス、セルフカストディアル、非インタラクティブです。 しかし、ZKSwapの実装には致命的な欠陥が1つありました:証明の検証を担当する関数は何も検証しませんでした。 文字通り。

4/ 攻撃👇を止めるべきだったコードは次のとおりです 一見すると、本物の zk プルーフ検証ツールのように見えます。 しかし、最初の行をよく見てください:trueを返します。 それです。他には何も走らない。

5/ 結果は?すべての出金「証拠」(どんなに偽物であっても)は検証に合格しました。 この契約は、トークン残高に関する恣意的な主張を受け入れました...そして、あたかも本物であるかのようにクレジットしました。 トラストレスなフォールバックメカニズムが無防備な蛇口に変わりました。

6/ 攻撃者は派手なエクスプロイトを必要としませんでした - でっち上げデータで exit() を繰り返し呼び出すだけでした。 彼らは残高チェックを回避し、複数のトークンにまたがって出金し、検出を回避するために弱い無効化ロジックを悪用しました。 その間ずっと、契約書には次のように書かれていました。 ✅

7/ これはあいまいなエッジケースではありませんでした。 これが資産回収の核となるロジックであり、完全に開いたままでした。 そして、エクソダスモードが発動されることがほとんどないため、壊れた道は気づかれませんでした...何ヶ月も。

8/アラームをトリガーするはずだったものは次のとおりです。 • 長い休眠後にトリガーされるエクソダスモード •一度に発生する数十の出金呼び出し • 残高の突然の急増ToWithdrawの変更 そのすべてが目に見えるものであり、リアルタイムのオンチェーン監視で止めることができたでしょう。

9/ それで、教訓は何ですか? •緊急コードは依然として本番コードです • フォールバックパスは機能しない場合、役に立ちません • リアルタイム監視はオプションではなく、存続にかかわるものです