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

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

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

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

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

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

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

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

Згідно з технічним аналізом команди безпеки щодо атаки на 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 токен, щоб отримати величезну ліквідність.

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

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

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

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

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

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

• ТУАЛЕТ ВАРТІСТЮ 19,5 мільйонів доларів

• Інші токени, такі як 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.

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

Переваги DPoS:

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

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

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

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

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

3.2 Продуктивність SUI під час цієї атаки

3.2.1 Робота механізму замороження

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

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

SUI本身内built了拒拒列表（deny list）механізм, це чорний список, який може заборонити будь-які транзакції, що стосуються адрес, зазначених у списку. Оскільки ця функція вже існує в клієнті, коли відбувається атака,

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

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

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

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

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

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

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

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

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

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