Это тот самый баг, который не дает командам протоколов спать по ночам. Эксплойт на $5M в ZKSwap, вызванный одной единственной инструкцией, оставленной не на своем месте. Вот подробный анализ того, как это произошло, и как мониторинг в цепочке мог бы это остановить. 🧵

1/ 9 июля GMX был взломан на 42 миллиона долларов. Но в тот день произошло еще кое-что, и почти никто не заметил: мост ZKSwap был тихо опустошен на 5 миллионов долларов. Интересная часть? Не было никакого сложного эксплойта. Просто критическая функция, которая… ничего не делала.

2/ ZKSwap — это zk-rollup, построенный на Ethereum. Как и многие роллапы, он использует мост для перемещения активов между L1 и L2. В качестве меры предосторожности мост включает в себя "Режим Исхода", способ для пользователей вернуть средства без необходимости в операторе. В теории это отличная идея. На практике…

3/ Режим Exodus позволяет пользователям вручную подтвердить, что они владели токенами в последнем проверенном состоянии L2. Это механизм резервного копирования: без доверия, само-хранение, неинтерактивный. Но реализация ZKSwap имела одну фатальную ошибку: Функция, отвечающая за проверку доказательств, ничего не проверяла. Буквально.

4/ Вот код, который должен был остановить атаку 👇 На первый взгляд, это выглядит как настоящий zk-доказательство верификатор. Но посмотрите внимательно на первую строку: return true; Вот и всё. Больше ничего не выполняется.

5/ Результат? Каждое "доказательство" вывода (независимо от того, насколько оно фальшивое) прошло проверку. Контракт принимал произвольные заявления о балансах токенов... и зачислял их так, как будто они были реальными. Это превратило механизм бездоверительной резервной копии в незащищенный кран.

6/ Нападающему не нужны были сложные эксплойты - достаточно было повторных вызовов exit() с вымышленными данными. Они обошли проверки баланса, выводили средства через несколько токенов и использовали слабую логику нулевателей, чтобы избежать обнаружения. Все это происходило, пока контракт говорил: ✅

7/ Это не был какой-то неясный крайний случай. Это была основная логика для восстановления активов, оставленная совершенно открытой. И поскольку режим Exodus редко активируется, сломанный путь оставался незамеченным... в течение месяцев.

8/ Вот что должно было вызвать тревогу: • Активация режима Exodus после длительного бездействия • Десятки запросов на вывод средств происходят одновременно • Внезапный скачок в изменениях балансаToWithdraw Все это было видно и могло быть остановлено с помощью мониторинга в реальном времени на блокчейне.

9/ Итак, какой урок? • Код экстренной ситуации все еще является производственным кодом • Резервные пути не помогают, если они не работают • Мониторинг в реальном времени не является опциональным, это критически важно для выживания