Тверда віра після кризової ситуації: чому SUI все ще має потенціал для довгострокового зростання?

TL; ДОКТОР

1.Вразливість Cetus походить з реалізації контракту, а не з SUI або мови Move:

Ця атака в основному пов'язана з відсутністю перевірки меж арифметичних функцій у протоколі Cetus------логічна вразливість, спричинена надто широкою маскою та переповненням зсуву, не пов'язана з моделлю безпеки ресурсів SUI-ланцюга або мови Move. Уразливість можна виправити "однорядною перевіркою меж", і це не вплине на основну безпеку екосистеми.

2.SUI механізм "раціональної централізації" в кризі виявляє цінність:

Хоча SUI має деякі ознаки легкого централізованого управління завдяки функціям, таким як цикли валідаторів DPoS і заморожування за чорними списками, це, безумовно, виявилося корисним у відповіді на подію CETUS: валідатори швидко синхронізували зловмисні адреси в Deny List, відмовляючись пакувати відповідні транзакції, що призвело до миттєвого заморожування понад 160 мільйонів доларів. Це, по суті, є активним "ланцюговим кейнсіанством", де ефективне макроекономічне регулювання справляє позитивний вплив на економічну систему.

3. Роздуми та рекомендації щодо технічної безпеки:

Математика та перевірка меж: введення стверджень про верхні та нижні межі для всіх ключових арифметичних операцій (таких як зсув, множення та ділення) та проведення крайових тестів і формальної верифікації. Крім того, необхідно посилити аудит і моніторинг: окрім загального аудиту коду, слід залучити спеціалізовану команду математичного аудиту та виявлення поведінки транзакцій в реальному часі на блокчейні, щоб своєчасно виявляти аномальні розподіли або великі миттєві позики;

4.Резюме та рекомендації щодо механізму забезпечення коштів:

Під час події Cetus SUI ефективно співпрацювала з командою проекту, успішно заморозивши понад 160 мільйонів доларів коштів та просунувши 100%-у програму компенсації, що демонструє потужну адаптивність на блокчейні та екологічну відповідальність. Фонд SUI також додатково виділив 10 мільйонів доларів на аудит, зміцнивши лінію безпеки. У майбутньому можна буде додатково просувати системи відстеження на блокчейні, інструменти безпеки, створені спільнотою, децентралізоване страхування та інші механізми, щоб удосконалити систему гарантій коштів.

5. Багатогранне зростання екосистеми SUI

SUI за менше ніж два роки швидко здійснив перехід від "нової мережі" до "сильної екосистеми", побудувавши різноманітну екосистему, що охоплює стабільні монети, DEX, інфраструктуру, DePIN, ігри та інші напрямки. Загальний обсяг стабільних монет перевищив 1 мільярд доларів, забезпечивши надійну ліквідність для модулів DeFi; TVL займає 8 місце у світі, активність торгівлі — 5 місце у світі, а серед не EVM мереж — 3 місце (після Bitcoin і Solana), що демонструє сильну участь користувачів та здатність до накопичення активів.

1. Ланцюгова реакція, викликана атакою

22 травня 2025 року, головний AMM протокол Cetus, розгорнутий на мережі SUI, зазнав хакерської атаки. Зловмисники використали логічну уразливість, пов'язану з "проблемою переповнення цілих чисел", щоб провести точні маніпуляції, що призвело до втрат активів на понад 200 мільйонів доларів. Ця подія стала не лише найбільшою безпековою аварією в DeFi за цей рік, але й найбільш руйнівною хакерською атакою з моменту запуску основної мережі SUI.

Згідно з даними DefiLlama, загальний TVL мережі SUI в день нападу впав більше ніж на 330 мільйонів доларів, а сума, заблокована в протоколі Cetus, миттєво зменшилася на 84%, до 38 мільйонів доларів. У зв'язку з цим, кілька популярних токенів на SUI (включаючи Lofi, Sudeng, Squirtle тощо) впали на 76% до 97% всього за одну годину, що викликало широку стурбованість на ринку щодо безпеки SUI та стабільності екосистеми.

Але після цього ударного хвилі екосистема SUI продемонструвала потужну стійкість та відновлювальну здатність. Незважаючи на те, що подія Cetus короткостроково викликала коливання довіри, на ланцюгу кошти та активність користувачів не зазнали тривалої рецесії, а навпаки, спонукали всю екосистему значно підвищити увагу до безпеки, будівництва інфраструктури та якості проектів.

Klein Labs розгляне причини цієї атаки, механізм консенсусу вузлів SUI, безпеку мови MOVE та екосистемний розвиток SUI, щоб окреслити поточну екосистемну структуру цього публічного блокчейну, який все ще перебуває на ранній стадії розвитку, та обговорити його потенціал для майбутнього зростання.

2. Аналіз причин атаки на подію Cetus

2.1 Процес реалізації атаки

Згідно з технічним аналізом команди Slow Mist щодо атаки на Cetus, хакерам вдалося скористатися критичною вразливістю арифметичного переповнення в протоколі, використовуючи миттєві позики, точне маніпулювання цінами та дефекти контракту, за короткий проміжок часу вкрасти цифрові активи на суму понад 200 мільйонів доларів. Шлях атаки приблизно можна поділити на такі три етапи:

①ініціювати миттєвий кредит, маніпулювати ціною

Хакери спочатку використали максимальний слідковий обмін 100 мільярдів haSUI блискавичного кредиту, позичивши велику кількість коштів для маніпуляції цінами.

Швидкі кредити дозволяють користувачам позичати та повертати кошти в рамках однієї транзакції, сплачуючи лише комісію, маючи високе зростання, низький ризик та низькі витрати. Хакери використовували цей механізм, щоб у короткі терміни знизити ринкову ціну та точно контролювати її в дуже вузькому діапазоні.

Потім зловмисник готується створити вкрай вузьку ліквідність, точно встановлюючи ціновий діапазон між найнижчою ціною 300,000 (та найвищою ціною 300,200), ширина ціни складає лише 1.00496621%.

За допомогою вищезазначених методів, хакери використали достатню кількість токенів і величезну ліквідність, щоб успішно маніпулювати ціною haSUI. Потім вони знову почали маніпулювати кількома токенами без реальної вартості.

②Додати ліквідність

Зловмисник створює вузьку ліквіднісну позицію, заявляючи про додавання ліквідності, але через вразливість функції checked_shlw врешті-решт отримує лише 1 токен.

В основному це сталося з двох причин:

1.Широке налаштування маски: еквівалентно надзвичайно великому обмеженню на додавання ліквідності, що призводить до того, що перевірка введення користувача в контракті стає формальною. Хакери, налаштувавши аномальні параметри, конструюють введення, яке завжди менше за це обмеження, таким чином обходячи перевірку на переповнення.

2. Витік даних був обрізаний: під час виконання операції зсуву n << 64 над числом n, через те, що зсув виходить за межі ефективної ширини біт uint256 (256 біт), сталося обрізання даних. Високі розряди виходу автоматично відкидаються, що призводить до того, що результати обчислень значно нижчі за очікувані, внаслідок чого система недооцінює кількість haSUI, необхідну для обміну. Остаточний результат обчислень приблизно менше 1, але оскільки це округлення вгору, в результаті виходить 1, тобто хакер може додати лише 1 токен і отримати величезну ліквідність.

③Виведення ліквідності

Здійснити повернення миттєвого кредиту, зберегти величезний прибуток. Врешті-решт вивести токенові активи загальною вартістю до кількох мільярдів доларів з кількох ліквідних пулів.

Ситуація з втратою коштів серйозна, атака призвела до крадіжки наступних активів:

• 12,9 мільйона SUI (близько 54 мільйонів доларів)

• 60 000 000 доларів США

• 490 мільйонів доларів Haedal Staked SUI

• 1950 мільйонів доларів США TOILET

• Інші токени, такі як HIPPO та LOFI, впали на 75--80%, ліквідність вичерпана.

2.2 Причини та характеристики цього уразливості

У цього漏洞 Cetus є три характеристики:

1. Вартість виправлення дуже низька: з одного боку, основною причиною інциденту Cetus є недолік у математичній бібліотеці Cetus, а не помилка цінового механізму протоколу або помилка підкладки. З іншого боку, вразливість обмежена лише Cetus і не пов'язана з кодом SUI. Джерело вразливості полягає в одній перевірці граничних умов, для повного усунення ризику потрібно лише змінити два рядки коду; після виправлення можна негайно розгорнути на основній мережі, щоб гарантовано забезпечити повноту логіки контракту в подальшому та усунути цю вразливість.

2. Висока прихованість: контракт працює стабільно без збоїв протягом двох років з моменту запуску, протокол Cetus пройшов кілька аудитів, але вразливості не були виявлені, головна причина в тому, що бібліотека Integer_Mate, яка використовується для математичних розрахунків, не була включена в обсяг аудиту.

Хакери використовують екстремальні значення для точного конструювання торгових діапазонів, створюючи надзвичайно рідкісні сценарії подачі надвисокої ліквідності, які викликають аномальну логіку, що свідчить про те, що такі проблеми важко виявити за допомогою звичайних тестів. Ці проблеми часто знаходяться в сліпій зоні людського сприйняття, тому вони залишаються непоміченими протягом тривалого часу.

3. Не лише проблема Move:

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

Схожі вразливості також виникали в інших мовах (наприклад, Solidity, Rust) і навіть були легшими для використання через відсутність захисту від переповнення цілих чисел; до оновлення версії Solidity перевірка на переповнення була дуже слабкою. В історії траплялися переповнення при додаванні, відніманні, множенні тощо, прямою причиною яких було те, що результати обчислень виходили за межі діапазону. Наприклад, у мовах Solidity вразливості на смарт-контрактах BEC і SMT були реалізовані шляхом ретельного складання параметрів, щоб обійти перевірочні оператори в контракті, що дозволяло виконувати атаки через надмірні перекази.

3. Консенсусна механіка SUI

3.1 Вступ до механізму консенсусу SUI

Огляд:

SUI використовує рамки делегованого підтвердження частки (DeleGated Proof of Stake, скорочено DPoS)). Хоча механізм DPoS може підвищити пропускну здатність транзакцій, він не може забезпечити таку ж високу ступінь децентралізації, як PoW (доказ роботи). Тому ступінь децентралізації SUI є відносно низькою, а поріг управління є відносно високим, звичайним користувачам важко безпосередньо впливати на управління мережею.

• Середня кількість валідаторів: 106

• Середній період Epoch: 24 години

Механізм процесу:

• Делегування прав: звичайним користувачам не потрібно самостійно запускати вузли, достатньо лише заставити SUI і делегувати його кандидатам-валідаторам, щоб взяти участь у забезпеченні безпеки мережі та розподілі винагород. Цей механізм може знизити бар'єри участі для звичайних користувачів, дозволяючи їм брати участь у мережевому консенсусі через "найм" довірених валідаторів. Це також є великою перевагою DPoS у порівнянні з традиційним PoS.

• Представлення етапу видобутку: невелика кількість обраних валідаторів видобуває блоки в фіксованому або випадковому порядку, що підвищує швидкість підтвердження та збільшує TPS.

• Динамічні вибори: після закінчення кожного циклу голосування, відповідно до ваги голосування, проводиться динамічна ротація, повторні вибори набору Validator, щоб забезпечити життєздатність вузлів, узгодженість інтересів та децентралізацію.

Переваги DPoS:

• Висока ефективність: завдяки контролю за кількістю вузлів, що формують блоки, мережа здатна завершувати підтвердження за мілісекунди, задовольняючи високі вимоги до TPS.

• Низька вартість: менше вузлів, що беруть участь у консенсусі, значно зменшує необхідну мережеву пропускну здатність та обчислювальні ресурси для синхронізації інформації та агрегації підписів. Це призводить до зниження витрат на апаратуру та експлуатацію, зменшення вимог до обчислювальної потужності та нижчих витрат. В кінцевому підсумку це забезпечує нижчі комісії для користувачів.

• Висока безпека: механізм стейкінгу та делегування синхронізує витрати на атаки та ризики; у поєднанні з механізмом конфіскації в мережі, ефективно стримує злочинні дії.

Одночасно в механізмі консенсусу SUI використовується алгоритм на основі BFT (байєсівської стійкості), який вимагає, щоб більше ніж дві третини голосів валідаторів досягли згоди для підтвердження транзакції. Цей механізм забезпечує безпеку та ефективність роботи мережі, навіть якщо меншість вузлів чинить шкоду. Для будь-якого оновлення або важливого рішення також необхідно, щоб більше ніж дві третини голосів були за, щоб їх реалізувати.

По суті, DPoS є компромісом, що представляє собою неможливий трикутник, в якому відбувається баланс між децентралізацією та ефективністю. DPoS у "неможливому трикутнику" безпеки-децентралізації-масштабованості обирає зменшити кількість активних вузлів для видобутку блоків в обмін на вищу продуктивність.