Роздуми після екологічної кризи SUI: важливість раціональної централізації та безпеки.

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

ТЛ; ДОКТОР

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

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

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

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

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

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

  1. Підсумок та рекомендації щодо механізму забезпечення фінансування:

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

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

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

Тверда віра після кризи безпеки: чому 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, хакери успішно використали одну з ключових вразливостей арифметичного переповнення в протоколі, скориставшись миттєвими кредитами, точним маніпулюванням цінами та дефектами контракту, в короткий час вкрали понад 2 мільярди доларів цифрових активів. Шлях атаки можна умовно поділити на три етапи:

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

Хакери спочатку використовують максимальний сліп для миттєвого обміну 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%, ліквідність виснажена

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

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

У цього вразливості Cetus є три особливості:

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

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

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

  1. Не лише проблема 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.

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

Переваги DPoS:

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

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

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

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

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

![Тверда віра після кризису безпеки:

Переглянути оригінал
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • Нагородити
  • 5
  • Поділіться
Прокоментувати
0/400
PuzzledScholarvip
· 17год тому
Це вже занадто, ми ж ці роздрібні інвестори не розуміємо в контрактах.
Переглянути оригіналвідповісти на0
BlockchainDecodervip
· 17год тому
З технічної точки зору, цей漏洞 дійсно не є приводом для занепокоєння. Варто підписатися на механізм реагування DPOS.
Переглянути оригіналвідповісти на0
MEVEyevip
· 17год тому
Знову зловживання в контракті вийшло з-під контролю.
Переглянути оригіналвідповісти на0
ZKProofstervip
· 17год тому
технічно... ці перевірки меж повинні були бути очевидними, блін
Переглянути оригіналвідповісти на0
StakeWhisperervip
· 17год тому
З ланцюгом все гаразд, просто у команди проєкту дещо водянистий підхід.
Переглянути оригіналвідповісти на0
  • Закріпити