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

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

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

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

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

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

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

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

Згідно з технічним аналізом команди SlowMist щодо атаки на 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

• 19500000 доларів США TOILET

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

2.2 Причини та особливості цієї вразливості

Ця вразливість Cetus має три характеристики:

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

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

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

3. Не тільки проблема Move:

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

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

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

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

Огляд:

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

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

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

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

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

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

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

Переваги DPoS:

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

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

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

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

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

3.2 У цьому нападі SUI показав себе

3.2.1 механізм заморожування

У цій події SUI швидко заморозила адреси, пов'язані з атакувальником.

З точки зору коду, це унеможливлює упаковку трансакцій на ланцюг. Верифікаційні вузли є ключовими компонентами блокчейну SUI, які відповідають за верифікацію трансакцій та виконання протоколів. Ігноруючи трансакції, пов'язані з атакуючими, ці верифікатори фактично впроваджують на рівні консенсусу механізм, подібний до 'замороження рахунків' у традиційних фінансах.

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

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

3.2.2 Хто має право змінювати чорний список?

TransactionDenyConfig є YAML/TOML конфігураційним файлом, що завантажується локально кожним валідатором. Будь-хто, хто запускає вузол, може редагувати цей файл, здійснювати гаряче перезавантаження або перезапустити вузол і оновити список. На перший погляд, здається, що кожен валідатор вільно виражає свої цінності.

Насправді, для забезпечення узгодженості та ефективності політики безпеки оновлення цієї ключової конфігурації зазвичай є координованим. Оскільки це "термінове оновлення, ініційоване командою SUI", фактично SUI фонду (або його уповноваженими розробниками) належить встановлювати та оновлювати цей список відмов.

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

3.2.3 Суть функції чорного списку

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

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

• Для великих гравців, основних постачальників ліквідності, протокол прагне забезпечити безпеку коштів, оскільки насправді дані в ланцюгу tvl повністю складаються з внесків основних великих гравців. Для довгострокового розвитку протоколу, безумовно, буде пріоритетом забезпечення безпеки.

• Для роздрібних інвесторів, активних учасників екосистеми, потужних прихильників технологій та спільної побудови спільноти. Проект також сподівається залучити роздрібних інвесторів до спільної побудови.