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

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 у "неможливому трикутнику" безпеки-демократизації-масштабованості обирає зменшення кількості активних вузлів для видобутку блоків в обмін на вищу продуктивність, відмовляючись від певного ступеня повної децентралізації порівняно з чистим 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 повністю залежать від внесків основних великих учасників. Щоб протокол міг довгостроково розвиватися, він обов'язково буде пріоритезувати безпеку.

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