Це свого роду баг, який не дає командам протоколів спати ночами. Експлойт на ZKSwap вартістю 5 мільйонів доларів, який вмикається однією заявою, залишеною в неправильному місці. Ось глибоке занурення в те, як це сталося і як моніторинг у мережі міг це зупинити. 🧵

1. 9 липня GMX було зламано на суму 42 мільйони доларів. Але в той день сталося інше і майже ніхто не помітив: міст ZKSwap тихо осушили за $5 млн. Що цікаво? Тут не йшлося про вигадливий подвиг. Просто критично важлива функція, яка зробила... ніщо.

2/ ZKSwap – це zk-rollup, побудований на Ethereum. Як і багато інших ролапів, він використовує міст для переміщення активів між L1 і L2. Як запобіжний захід, міст включає «Режим виходу», спосіб, за допомогою якого користувачі можуть повернути кошти без потреби в операторі. Теоретично це чудова ідея. На практиці...

3. Режим Exodus дозволяє користувачам вручну доводити, що вони володіли токенами в останньому підтвердженому стані L2. Це запасний механізм: недовірчий, самозберігаючий, неінтерактивний. Але реалізація ZKSwap мала один фатальний недолік: функція, яка відповідала за перевірку доказів, нічого не перевіряла. Буквально.

4/ Ось код, який повинен був зупинити атаку 👇 На перший погляд, він виглядає як справжній zk-proof верифікатор. Але подивіться уважно на перший рядок: return true; Ось і все. Більше нічого не працює.

5. До чого це призвело? Кожен «доказ» виведення коштів (яким би фальшивим він не був) проходив перевірку. Контракт приймав довільні вимоги щодо балансів токенів... і приписував їх так, ніби вони були справжніми. Він перетворив запасний механізм, що не підлягає довірі, на незахищений кран.

6. Зловмиснику не потрібні були вигадливі експлойти - лише повторні дзвінки до exit() з вигаданими даними. Вони обходили перевірки балансу, виводили кошти за кількома токенами та зловживали слабкою логікою нуліфікатора, щоб уникнути виявлення. При цьому в договорі було сказано: ✅

7/ Це не був якийсь незрозумілий крайній випадок. Це була основна логіка повернення активів, залишена повністю відкритою. А оскільки режим Exodus спрацьовує рідко, розбитий шлях залишився непоміченим... на місяці.

8/ Ось що повинно було спровокувати сигнали тривоги: • Режим Exodus спрацьовує після тривалого спокою • Десятки дзвінків на виведення коштів, що відбуваються одночасно • Різкий стрибок змін у балансахToOutput Все це було видно і можна було зупинити за допомогою моніторингу в режимі реального часу.

9/ То який же урок? • Аварійний код все ще залишається виробничим кодом • Резервні шляхи не допомагають, якщо вони не працюють • Моніторинг у реальному часі не є обов'язковим, він критично важливий для виживання