22 травня протокол DEX Cetus, що є провідним у екосистемі Sui, зазнав хакерської атаки, внаслідок якої в основному контракті протоколу виявлено вразливість, і зловмисник скористався нею, щоб вивести велику кількість активів. Інцидент за короткий час викликав широкий резонанс, торкнувшись не лише відповідних користувачів, але й змусив кілька проектів Sui перейти в режим екстреного реагування.
Але те, що прийшло слідом, не було повернення ланцюга або втручання суперповноважень, а швидкий запуск: голосування валідаторів, активне зупинення проекту, заморожування активів на ланцюгу, самоінспекція протоколу та оновлення... Весь процес став справжньою репетицією фінансової безпеки на ланцюгу.
Станом на кінець цієї статті минуло п'ять днів з моменту хакерського інциденту, який мав широкий резонанс і викликав бурхливі дискусії в спільноті про «безпеку в мережі», «децентралізоване управління» та «реагування на надзвичайні ситуації протоколу».
Ця стаття намагається з'ясувати: що насправді сталося цього разу? Де відповідальність? Як екосистема Sui реагує на це? Що ми повинні з цього винести?
Як відбувається атака?
Атака сталася вранці 22 травня 2025 року та була націлена на пул ліквідності CLMM Cetus. Зловмисник виявив вразливість у контракті та арбітражив активи в кількох раундах операцій за допомогою побудови транзакцій.
Конкретний процес такий:
Приблизно о 10:30 UTC розпочалася атака. Хакери через аномальні угоди знизили ціну в пулі, одночасно відкриваючи позиції ліквідності в зоні високих цін і використовуючи логічні вразливості контрактів, щоб впровадити велику кількість "підробленої" ліквідності з дуже малою кількістю токенів.
Потім хакер багаторазово виконує «додавання/видалення ліквідності», щоб видалити фактичні активи з пулу.
Атака тривала близько 20 хвилин, і деякі системи моніторингу почали бити на сполох.
40 хвилин після атаки
О 10:40 UTC система моніторингу Cetus виявила аномальну поведінку басейну.
10:53 UTC, команда Cetus підтвердила джерело атаки та передала інформацію іншим проєктам екосистеми Sui.
10:57 UTC, Cetus першими закрили основний ліквідний пул, щоб запобігти подальшим втратам.
11:20 UTC, повне припинення використання відповідних контрактів.
Ця реакція була дуже швидкою, але хакери вкрали велику кількість коштів.
Як вдалося заморозити кошти хакера?
Після того, як інцидент розширився, екосистема запустила більш широке реагування на надзвичайні ситуації:
Верифікатори Sui швидко почали співпрацювати в мережі, голосуючи за відмову від пакування транзакцій з адрес хакерів;
Після досягнення порогу стейкінгу в 33% адреса хакера була ефективно заморожена, і торгові операції не можуть продовжувати оброблятися в ланцюгу.
Це не відкат системи і не фонове втручання, а дія, зроблена валідатором через механізм консенсусу. Стан ланцюжка не змінився, транзакції користувачів не були підроблені, і все робиться на основі існуючих правил ончейну.
Під так званим «відкатом системи» мається на увазі повернення стану всієї мережі блокчейн до певного моменту перед атакою, як повернення в минуле. Зазвичай це означає, що вже підтверджені транзакції стираються, а історія ланцюжка переписується. «Внутрішнє втручання» означає прямий контроль над вузлами або коштами централізованим органом влади (наприклад, стороною проекту або фондом), в обхід звичайного процесу прийняття рішень щодо обробки.
В даному випадку нічого з цього не сталося. Валідатори заморожують відповідно до правил ланцюжка за допомогою публічного голосування, автономного прийняття рішень і децентралізації, яка є втіленням децентралізованого управління.
Яка наразі ситуація з фінансами?
Дані, оприлюднені Cetus, такі:
Хакери вкрали активи на суму близько 230 мільйонів доларів;
З них активи на суму 160 мільйонів доларів залишилися на двох заморожених адресах Sui, і їх уже не можна перевести;
60 мільйонів доларів активів були кросчейн перенесені на Ethereum, наразі відомо про дві адреси, які все ще відстежуються.
Угода сприяє голосуванню громади для визначення способів повернення активів та компенсації.
Чому сталася проблема? Це проблема самої ланки? Чи це проблема вразливості на рівні застосунків?
Згідно зі звітом SlowMist та аналізом технічних інфлюенсерів, усі вони вказують на одну й ту саму проблему: першопричиною інциденту є проблема з логікою відкритого коду, яка використовується в контракті Cetus. Зловмисник скористався помилкою в контракті на прикладному рівні, пов'язаною з перевіркою переповнення даних, яка не завдала б шкоди, якби її виявили та виправили раніше. Тому це не є вразливістю самої мови програмування Move.
Також важливо зазначити, що сама мережа Sui не зазнала атаки і не виникло системних ризиків.
Це стандартна "інцидент безпеки на рівні протоколу", а не проблема безпеки на рівні ланцюга.
!
Після атаки, як інші проекти в екосистемі Sui повинні діяти?
Після відключення Cetus ряд проєктів на Sui почали проводити самоперевірки безпеки, і ми спостерігали, що протокол Momentum також призупиняв транзакції, як тільки сталася атака, завершував повний аудит коду ланцюга та перевірку ризиків, і відновлювався після заморожування вкрадених коштів.
Як нинішній лідер Dex в екосистемі Sui, протокол Momentum якнайшвидше припинив торгівлю та співпрацював із Sui Foundation, щоб заблокувати вкрадені кошти, щоб запобігти поширенню хакерами на більшу кількість облікових записів торгових активів через торгівлю Dex. При цьому була проведена ретельна самоперевірка, і після того, як результати самоперевірки виявилися вірними, і після підтвердження того, що вкрадені кошти були успішно заморожені Sui Foundation, функція транзакції була відновлена в першу чергу.
Які подальші дії після події?
Наразі:
Cetus завершив виправлення критичних вразливостей і наразі співпрацює з командою аудитів для повторної перевірки коду;
План компенсації користувачів розробляється, частково залежить від голосування за пропозиції з екологічного управління;
Інші проєкти Sui також поступово відновлюють роботу або завершують посилення безпеки.
Уся екосистема не зупинилася, а навпаки, після події більш систематично переглянула механізми безпеки.
Що нам говорить цей інцидент?
Цього разу Cetus зазнав атаки, що змусило всіх будівельників і користувачів знову зіткнутися з актуальною проблемою:
На чому, зрештою, базується безпека угод?
Відповідь стає все більш чіткою:
Покладаючись на колективну мудрість, яку приносить децентралізація, а не використовуючи децентралізацію як виправдання для бездіяльності;
Завдяки постійним системним вкладенням, а не кількома звітами аудиту;
Завдяки звичайній підготовці та побудові механізмів, а не лише післявиправним заходам;
Це залежить від готовності кожного учасника брати на себе відповідальність і діяти активно, а не перекладати проблеми на "ланцюг" або "технології".
Ми бачимо, що хакери дійсно завдали шкоди, але не знищили систему;
Також видно, що децентралізація - це не просто сидіти осторонь і спостерігати за правилами, а спонтанно об'єднуватися, щоб захистити основні цінності та користувачів.
Заключення
Справжня децентралізація — це не гасло, а відповідальність.
У цій бурі немає рятівника.
Суї валідатори проголосували за заморожування ризикових операцій; інші протоколи завершили самоперевірку безпеки, деякі швидко відновили роботу; користувачі також продовжують слідкувати та стимулювати покращення.
Децентралізація - це не безконтрольність, а співпраця з межами, принципами та відповідальністю.
У системі без бекенду довіра має базуватися на кожному рядку коду, кожному механізмі, кожному рішенні.
Ця подія є кризою, а також випробуванням і дзеркалом.
Воно говорить нам:
Децентралізація не є метою, а є способом, метою є побудова довіри; децентралізація приносить колективну мудрість.
Децентралізація, безумовно, важлива, але ефективність капіталу та безпека протоколу важливіші.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Після того, як Cetus був зламаний: що ми повинні побачити в цій метушні?
Вступ
22 травня протокол DEX Cetus, що є провідним у екосистемі Sui, зазнав хакерської атаки, внаслідок якої в основному контракті протоколу виявлено вразливість, і зловмисник скористався нею, щоб вивести велику кількість активів. Інцидент за короткий час викликав широкий резонанс, торкнувшись не лише відповідних користувачів, але й змусив кілька проектів Sui перейти в режим екстреного реагування.
Але те, що прийшло слідом, не було повернення ланцюга або втручання суперповноважень, а швидкий запуск: голосування валідаторів, активне зупинення проекту, заморожування активів на ланцюгу, самоінспекція протоколу та оновлення... Весь процес став справжньою репетицією фінансової безпеки на ланцюгу.
Станом на кінець цієї статті минуло п'ять днів з моменту хакерського інциденту, який мав широкий резонанс і викликав бурхливі дискусії в спільноті про «безпеку в мережі», «децентралізоване управління» та «реагування на надзвичайні ситуації протоколу».
Ця стаття намагається з'ясувати: що насправді сталося цього разу? Де відповідальність? Як екосистема Sui реагує на це? Що ми повинні з цього винести?
Як відбувається атака?
Атака сталася вранці 22 травня 2025 року та була націлена на пул ліквідності CLMM Cetus. Зловмисник виявив вразливість у контракті та арбітражив активи в кількох раундах операцій за допомогою побудови транзакцій.
Конкретний процес такий:
Приблизно о 10:30 UTC розпочалася атака. Хакери через аномальні угоди знизили ціну в пулі, одночасно відкриваючи позиції ліквідності в зоні високих цін і використовуючи логічні вразливості контрактів, щоб впровадити велику кількість "підробленої" ліквідності з дуже малою кількістю токенів.
Потім хакер багаторазово виконує «додавання/видалення ліквідності», щоб видалити фактичні активи з пулу.
Атака тривала близько 20 хвилин, і деякі системи моніторингу почали бити на сполох.
40 хвилин після атаки
О 10:40 UTC система моніторингу Cetus виявила аномальну поведінку басейну.
10:53 UTC, команда Cetus підтвердила джерело атаки та передала інформацію іншим проєктам екосистеми Sui.
10:57 UTC, Cetus першими закрили основний ліквідний пул, щоб запобігти подальшим втратам.
11:20 UTC, повне припинення використання відповідних контрактів.
Ця реакція була дуже швидкою, але хакери вкрали велику кількість коштів.
Як вдалося заморозити кошти хакера?
Після того, як інцидент розширився, екосистема запустила більш широке реагування на надзвичайні ситуації:
Верифікатори Sui швидко почали співпрацювати в мережі, голосуючи за відмову від пакування транзакцій з адрес хакерів;
Після досягнення порогу стейкінгу в 33% адреса хакера була ефективно заморожена, і торгові операції не можуть продовжувати оброблятися в ланцюгу.
Це не відкат системи і не фонове втручання, а дія, зроблена валідатором через механізм консенсусу. Стан ланцюжка не змінився, транзакції користувачів не були підроблені, і все робиться на основі існуючих правил ончейну.
Під так званим «відкатом системи» мається на увазі повернення стану всієї мережі блокчейн до певного моменту перед атакою, як повернення в минуле. Зазвичай це означає, що вже підтверджені транзакції стираються, а історія ланцюжка переписується. «Внутрішнє втручання» означає прямий контроль над вузлами або коштами централізованим органом влади (наприклад, стороною проекту або фондом), в обхід звичайного процесу прийняття рішень щодо обробки.
В даному випадку нічого з цього не сталося. Валідатори заморожують відповідно до правил ланцюжка за допомогою публічного голосування, автономного прийняття рішень і децентралізації, яка є втіленням децентралізованого управління.
Яка наразі ситуація з фінансами?
Дані, оприлюднені Cetus, такі:
Хакери вкрали активи на суму близько 230 мільйонів доларів;
З них активи на суму 160 мільйонів доларів залишилися на двох заморожених адресах Sui, і їх уже не можна перевести;
60 мільйонів доларів активів були кросчейн перенесені на Ethereum, наразі відомо про дві адреси, які все ще відстежуються.
Угода сприяє голосуванню громади для визначення способів повернення активів та компенсації.
Чому сталася проблема? Це проблема самої ланки? Чи це проблема вразливості на рівні застосунків?
Згідно зі звітом SlowMist та аналізом технічних інфлюенсерів, усі вони вказують на одну й ту саму проблему: першопричиною інциденту є проблема з логікою відкритого коду, яка використовується в контракті Cetus. Зловмисник скористався помилкою в контракті на прикладному рівні, пов'язаною з перевіркою переповнення даних, яка не завдала б шкоди, якби її виявили та виправили раніше. Тому це не є вразливістю самої мови програмування Move.
Також важливо зазначити, що сама мережа Sui не зазнала атаки і не виникло системних ризиків.
Це стандартна "інцидент безпеки на рівні протоколу", а не проблема безпеки на рівні ланцюга.
!
Після атаки, як інші проекти в екосистемі Sui повинні діяти?
Після відключення Cetus ряд проєктів на Sui почали проводити самоперевірки безпеки, і ми спостерігали, що протокол Momentum також призупиняв транзакції, як тільки сталася атака, завершував повний аудит коду ланцюга та перевірку ризиків, і відновлювався після заморожування вкрадених коштів.
Як нинішній лідер Dex в екосистемі Sui, протокол Momentum якнайшвидше припинив торгівлю та співпрацював із Sui Foundation, щоб заблокувати вкрадені кошти, щоб запобігти поширенню хакерами на більшу кількість облікових записів торгових активів через торгівлю Dex. При цьому була проведена ретельна самоперевірка, і після того, як результати самоперевірки виявилися вірними, і після підтвердження того, що вкрадені кошти були успішно заморожені Sui Foundation, функція транзакції була відновлена в першу чергу.
Які подальші дії після події?
Наразі:
Cetus завершив виправлення критичних вразливостей і наразі співпрацює з командою аудитів для повторної перевірки коду;
План компенсації користувачів розробляється, частково залежить від голосування за пропозиції з екологічного управління;
Інші проєкти Sui також поступово відновлюють роботу або завершують посилення безпеки.
Уся екосистема не зупинилася, а навпаки, після події більш систематично переглянула механізми безпеки.
Що нам говорить цей інцидент?
Цього разу Cetus зазнав атаки, що змусило всіх будівельників і користувачів знову зіткнутися з актуальною проблемою:
На чому, зрештою, базується безпека угод?
Відповідь стає все більш чіткою:
Покладаючись на колективну мудрість, яку приносить децентралізація, а не використовуючи децентралізацію як виправдання для бездіяльності;
Завдяки постійним системним вкладенням, а не кількома звітами аудиту;
Завдяки звичайній підготовці та побудові механізмів, а не лише післявиправним заходам;
Це залежить від готовності кожного учасника брати на себе відповідальність і діяти активно, а не перекладати проблеми на "ланцюг" або "технології".
Ми бачимо, що хакери дійсно завдали шкоди, але не знищили систему;
Також видно, що децентралізація - це не просто сидіти осторонь і спостерігати за правилами, а спонтанно об'єднуватися, щоб захистити основні цінності та користувачів.
Заключення
Справжня децентралізація — це не гасло, а відповідальність.
У цій бурі немає рятівника.
Суї валідатори проголосували за заморожування ризикових операцій; інші протоколи завершили самоперевірку безпеки, деякі швидко відновили роботу; користувачі також продовжують слідкувати та стимулювати покращення.
Децентралізація - це не безконтрольність, а співпраця з межами, принципами та відповідальністю.
У системі без бекенду довіра має базуватися на кожному рядку коду, кожному механізмі, кожному рішенні.
Ця подія є кризою, а також випробуванням і дзеркалом.
Воно говорить нам:
Децентралізація не є метою, а є способом, метою є побудова довіри; децентралізація приносить колективну мудрість.
Децентралізація, безумовно, важлива, але ефективність капіталу та безпека протоколу важливіші.