Рішуча віра після кризи безпеки: чому 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 Процес реалізації атаки
Згідно з технічним аналізом команди Slow Mist щодо атаки на Cetus, хакери успішно використали ключову арифметичну переповнювальну уразливість у протоколі, скориставшись闪电贷, точним маніпулюванням цінами та дефектами контракту, за короткий проміжок часу викрали понад 200 мільйонів доларів цифрових активів. Шлях атаки можна умовно поділити на три етапи:
Хакери спочатку використали максимальний проскок, щоб миттєво обміняти 100 мільярдів haSUI, позичивши велику кількість коштів для маніпуляції цінами.
Швидкі кредити дозволяють користувачам позичати та повертати кошти в рамках однієї транзакції, сплачуючи лише комісію, маючи високий важіль, низький ризик і низькі витрати. Хакери використали цей механізм, щоб за короткий час знизити ринкову ціну і точно контролювати її в дуже вузькому діапазоні.
Потім зловмисник готується створити вкрай вузьку ліквіднісну позицію, точно встановивши ціновий діапазон між найнижчою пропозицією 300,000 і найвищою ціною 300,200, ширина якої становить лише 1.00496621%.
Через вищезгаданий спосіб хакери використали достатню кількість токенів та величезну ліквідність, успішно маніпулюючи ціною haSUI. Потім вони також маніпулювали кількома токенами без реальної вартості.
②додавання ліквідності
Зловмисник створює вузькі ліквідні позиції, стверджуючи, що додає ліквідність, але через вразливість функції checked_shlw в кінцевому підсумку отримує лише 1 токен.
В основному це з двох причин:
Занадто широкий маска: еквівалентно надзвичайно великому ліміту додавання ліквідності, що призводить до того, що перевірка вводу користувача в контракті є формальною. Хакери, встановлюючи аномальні параметри, конструюють ввід, який завжди менше цього ліміту, таким чином обходячи перевірку на переповнення.
Витік даних був обрізаний: під час виконання зсуву n << 64 для числового n, через те, що зсув перевищує ефективну ширину біт uint256 (256 біт), відбувається обрізка даних. Частина старшого розряду, що переповнює, автоматично відкидається, що призводить до того, що результат обчислення значно нижчий за очікуваний, внаслідок чого система недооцінює кількість haSUI, необхідну для обміну. Остаточний обчислений результат приблизно менше 1, але оскільки округлення відбувається вгору, в результаті отримуємо рівно 1, тобто хакеру потрібно лише додати 1 токен, щоб отримати величезну ліквідність.
③Виведення ліквідності
Здійснити повернення миттєвого кредиту, зберігши величезний прибуток. Врешті-решт забрати з кількох пулів ліквідності токенові активи загальною вартістю кілька мільярдів доларів.
Ситуація з втратами коштів серйозна, атака призвела до викрадення наступних активів:
12,9 мільйона SUI (приблизно 54 мільйони доларів)
60 000 000 доларів США
490 мільйонів доларів Haedal Staked SUI
ТУАЛЕТ ВАРТІСТЮ 19,5 мільйонів доларів
Інші токени, такі як HIPPO та LOFI, впали на 75--80%, ліквідність вичерпалася
2.2 Причини та особливості цього вразливості
Ця уразливість Cetus має три характеристики:
Виправлення має дуже низьку вартість: з одного боку, основною причиною інциденту з Cetus є помилка в математичній бібліотеці Cetus, а не помилка цінового механізму протоколу чи помилка в основній архітектурі. З іншого боку, вразливість обмежується лише Cetus і не має жодного відношення до коду SUI. Джерело вразливості полягає в одному з умовних операторів на межі, для повного усунення ризику потрібно лише змінити два рядки коду; після виправлення його можна одразу розгорнути в основній мережі, щоб забезпечити повноту логіки подальших контрактів і виключити цю вразливість.
Висока прихованість: контракт працює без збоїв протягом двох років з моменту запуску, протокол Cetus пройшов кілька аудитів, але вразливостей не було виявлено, основною причиною цього є те, що бібліотека Integer_Mate, що використовується для математичних обчислень, не була включена до аудиторської перевірки.
Хакери використовують екстремальні значення для точного конструювання торгових інтервалів, створюючи рідкісні сценарії з подачею надзвичайно високої ліквідності, які викликають аномальну логіку, що свідчить про те, що такі проблеми важко виявити за допомогою звичайного тестування. Ці проблеми зазвичай знаходяться в сліпих зонах сприйняття людей, тому вони залишаються непоміченими протягом тривалого часу.
Не проблема лише 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 має вбудований механізм списку відмов (deny list), що є функцією чорного списку, яка може блокувати будь-які транзакції, пов'язані зі списком адрес. Оскільки ця функція вже існує в клієнті, то коли відбувається атака
SUI може негайно заморозити адреси хакерів. Якщо цієї функції немає, навіть якщо у SUI лише 113 валідаторів, Cetus важко буде в короткий термін координувати всіх валідаторів по одному.
3.2.2 Хто має право змінювати чорний список?
TransactionDenyConfig є YAML/TOML конфігураційним файлом, який завантажується локально кожним валідатором. Будь-хто, хто запускає вузол, може редагувати цей файл, виконувати гарячу перезагрузку або перезапустити вузол та оновити список. На перший погляд, кожен валідатор, здається, вільно висловлює свої цінності.
Насправді, для забезпечення узгодженості та ефективності політики безпеки, оновлення цієї ключової конфігурації зазвичай є координованим. Оскільки це "термінове оновлення, ініційоване командою SUI", фактично це список відмов, що встановлюється та оновлюється SUI фондом (або його уповноваженими розробниками).
SUI опублікував чорний список, теоретично валідатори можуть вибрати, чи використовувати його ------ але насправді більшість людей за замовчуванням автоматично його використовують. Тому, хоча ця функція захищає кошти користувачів, вона насправді має певний рівень централізації.
3.2.3 Суть функції чорного списку
Функція чорного списку насправді не є логікою на рівні протоколу, вона більше схожа на додатковий рівень безпеки, створений для реагування на надзвичайні ситуації та забезпечення безпеки коштів користувачів.
Це по суті механізм гарантії безпеки. Схоже на "антивандальний ланцюг", який прив'язується до дверей і активується лише для тих, хто намагається проникнути до будинку, тобто для тих, хто має намір зловживати протоколом. Для користувача:
Для великих інвесторів, основних постачальників ліквідності, протокол намагається забезпечити безпеку коштів, адже насправді дані в ланцюгу tvl повністю залежать від внесків основних великих інвесторів. Щоб протокол міг довго розвиватися, він обов'язково повинен спочатку забезпечити безпеку.
Для роздрібних інвесторів, активних учасників екосистеми, потужних підтримувачів технологій та спільнот. Проект також сподівається залучити роздрібних інвесторів до спільного розвитку, лише так
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
12 лайків
Нагородити
12
4
Поділіться
Прокоментувати
0/400
GweiWatcher
· 11год тому
Тож ще потрібно купувати на найнижчій точці? Жахливо
Переглянути оригіналвідповісти на0
DefiPlaybook
· 11год тому
Відповідно до аналізу даних у блокчейні, вразливість Cetus виявила вроджені ризики смартконтрактів, падіння TVL на 83,7% підкреслює ліквідність.
Переглянути оригіналвідповісти на0
GigaBrainAnon
· 11год тому
Немає способу виправити небо.
Переглянути оригіналвідповісти на0
0xSherlock
· 11год тому
Справді, тільки й можуть що спекулювати та на великому пампі і великому дампі.
Екосистема SUI демонструє стійкість, має довгостроковий потенціал зростання навіть після інцидентів безпеки.
Рішуча віра після кризи безпеки: чому 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 Процес реалізації атаки
Згідно з технічним аналізом команди Slow Mist щодо атаки на Cetus, хакери успішно використали ключову арифметичну переповнювальну уразливість у протоколі, скориставшись闪电贷, точним маніпулюванням цінами та дефектами контракту, за короткий проміжок часу викрали понад 200 мільйонів доларів цифрових активів. Шлях атаки можна умовно поділити на три етапи:
①ініціювати блискавичний кредит, маніпулювати ціною
Хакери спочатку використали максимальний проскок, щоб миттєво обміняти 100 мільярдів haSUI, позичивши велику кількість коштів для маніпуляції цінами.
Швидкі кредити дозволяють користувачам позичати та повертати кошти в рамках однієї транзакції, сплачуючи лише комісію, маючи високий важіль, низький ризик і низькі витрати. Хакери використали цей механізм, щоб за короткий час знизити ринкову ціну і точно контролювати її в дуже вузькому діапазоні.
Потім зловмисник готується створити вкрай вузьку ліквіднісну позицію, точно встановивши ціновий діапазон між найнижчою пропозицією 300,000 і найвищою ціною 300,200, ширина якої становить лише 1.00496621%.
Через вищезгаданий спосіб хакери використали достатню кількість токенів та величезну ліквідність, успішно маніпулюючи ціною haSUI. Потім вони також маніпулювали кількома токенами без реальної вартості.
②додавання ліквідності
Зловмисник створює вузькі ліквідні позиції, стверджуючи, що додає ліквідність, але через вразливість функції checked_shlw в кінцевому підсумку отримує лише 1 токен.
В основному це з двох причин:
Занадто широкий маска: еквівалентно надзвичайно великому ліміту додавання ліквідності, що призводить до того, що перевірка вводу користувача в контракті є формальною. Хакери, встановлюючи аномальні параметри, конструюють ввід, який завжди менше цього ліміту, таким чином обходячи перевірку на переповнення.
Витік даних був обрізаний: під час виконання зсуву n << 64 для числового n, через те, що зсув перевищує ефективну ширину біт uint256 (256 біт), відбувається обрізка даних. Частина старшого розряду, що переповнює, автоматично відкидається, що призводить до того, що результат обчислення значно нижчий за очікуваний, внаслідок чого система недооцінює кількість haSUI, необхідну для обміну. Остаточний обчислений результат приблизно менше 1, але оскільки округлення відбувається вгору, в результаті отримуємо рівно 1, тобто хакеру потрібно лише додати 1 токен, щоб отримати величезну ліквідність.
③Виведення ліквідності
Здійснити повернення миттєвого кредиту, зберігши величезний прибуток. Врешті-решт забрати з кількох пулів ліквідності токенові активи загальною вартістю кілька мільярдів доларів.
Ситуація з втратами коштів серйозна, атака призвела до викрадення наступних активів:
12,9 мільйона SUI (приблизно 54 мільйони доларів)
60 000 000 доларів США
490 мільйонів доларів Haedal Staked SUI
ТУАЛЕТ ВАРТІСТЮ 19,5 мільйонів доларів
Інші токени, такі як HIPPO та LOFI, впали на 75--80%, ліквідність вичерпалася
2.2 Причини та особливості цього вразливості
Ця уразливість Cetus має три характеристики:
Виправлення має дуже низьку вартість: з одного боку, основною причиною інциденту з Cetus є помилка в математичній бібліотеці Cetus, а не помилка цінового механізму протоколу чи помилка в основній архітектурі. З іншого боку, вразливість обмежується лише Cetus і не має жодного відношення до коду SUI. Джерело вразливості полягає в одному з умовних операторів на межі, для повного усунення ризику потрібно лише змінити два рядки коду; після виправлення його можна одразу розгорнути в основній мережі, щоб забезпечити повноту логіки подальших контрактів і виключити цю вразливість.
Висока прихованість: контракт працює без збоїв протягом двох років з моменту запуску, протокол Cetus пройшов кілька аудитів, але вразливостей не було виявлено, основною причиною цього є те, що бібліотека Integer_Mate, що використовується для математичних обчислень, не була включена до аудиторської перевірки.
Хакери використовують екстремальні значення для точного конструювання торгових інтервалів, створюючи рідкісні сценарії з подачею надзвичайно високої ліквідності, які викликають аномальну логіку, що свідчить про те, що такі проблеми важко виявити за допомогою звичайного тестування. Ці проблеми зазвичай знаходяться в сліпих зонах сприйняття людей, тому вони залишаються непоміченими протягом тривалого часу.
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 має вбудований механізм списку відмов (deny list), що є функцією чорного списку, яка може блокувати будь-які транзакції, пов'язані зі списком адрес. Оскільки ця функція вже існує в клієнті, то коли відбувається атака
SUI може негайно заморозити адреси хакерів. Якщо цієї функції немає, навіть якщо у SUI лише 113 валідаторів, Cetus важко буде в короткий термін координувати всіх валідаторів по одному.
3.2.2 Хто має право змінювати чорний список?
TransactionDenyConfig є YAML/TOML конфігураційним файлом, який завантажується локально кожним валідатором. Будь-хто, хто запускає вузол, може редагувати цей файл, виконувати гарячу перезагрузку або перезапустити вузол та оновити список. На перший погляд, кожен валідатор, здається, вільно висловлює свої цінності.
Насправді, для забезпечення узгодженості та ефективності політики безпеки, оновлення цієї ключової конфігурації зазвичай є координованим. Оскільки це "термінове оновлення, ініційоване командою SUI", фактично це список відмов, що встановлюється та оновлюється SUI фондом (або його уповноваженими розробниками).
SUI опублікував чорний список, теоретично валідатори можуть вибрати, чи використовувати його ------ але насправді більшість людей за замовчуванням автоматично його використовують. Тому, хоча ця функція захищає кошти користувачів, вона насправді має певний рівень централізації.
3.2.3 Суть функції чорного списку
Функція чорного списку насправді не є логікою на рівні протоколу, вона більше схожа на додатковий рівень безпеки, створений для реагування на надзвичайні ситуації та забезпечення безпеки коштів користувачів.
Це по суті механізм гарантії безпеки. Схоже на "антивандальний ланцюг", який прив'язується до дверей і активується лише для тих, хто намагається проникнути до будинку, тобто для тих, хто має намір зловживати протоколом. Для користувача:
Для великих інвесторів, основних постачальників ліквідності, протокол намагається забезпечити безпеку коштів, адже насправді дані в ланцюгу tvl повністю залежать від внесків основних великих інвесторів. Щоб протокол міг довго розвиватися, він обов'язково повинен спочатку забезпечити безпеку.
Для роздрібних інвесторів, активних учасників екосистеми, потужних підтримувачів технологій та спільнот. Проект також сподівається залучити роздрібних інвесторів до спільного розвитку, лише так