Тверда віра після кризи безпеки: чому 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 токен.

Вessentialно через дві причини:

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

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

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