Тверда віра після кризису безпеки: чому SUI все ще має потенціал для довгострокового зростання?
1. Ланцюгова реакція, спричинена атакою
22 травня 2025 року, провідний AMM протокол Cetus, розгорнутий на мережі SUI, зазнав хакерської атаки. Зловмисник скористався логічною вразливістю, пов'язаною з "проблемою переповнення цілого числа", щоб здійснити точну маніпуляцію, що призвело до втрати активів на суму понад 200 мільйонів доларів. Ця подія стала не лише найбільшою безпековою катастрофою в сфері DeFi цього року, але й найруйнівнішою хакерською атакою з моменту запуску основної мережі SUI.
Згідно з даними DefiLlama, загальний TVL SUI впав на понад 330 мільйонів доларів у день нападу, а сума, заблокована в протоколі Cetus, миттєво зменшилася на 84%, досягнувши 38 мільйонів доларів. У зв'язку з цим кілька популярних токенів на SUI впали на 76% до 97% всього за годину, що викликало широке занепокоєння щодо безпеки SUI та стабільності екосистеми.
Але після цієї хвилі удару екосистема SUI продемонструвала потужну стійкість і здатність до відновлення. Незважаючи на те, що подія Cetus короткостроково викликала коливання довіри, кошти на ланцюгу та активність користувачів не зазнали тривалої рецесії, а навпаки, спонукали всю екосистему значно підвищити увагу до безпеки, будівництва інфраструктури та якості проєктів.
2. Аналіз причин атаки на подію Cetus
2.1 Процес реалізації атаки
Згідно з технічним аналізом команди SlowMist щодо атаки на Cetus, хакерам вдалося успішно використати критичний арифметичний переповнення у протоколі, скориставшись блискавичними кредитами, точним маніпулюванням цінами та дефектами контракту, за короткий час викравши понад 200 мільйонів доларів цифрових активів. Шлях атаки можна умовно поділити на три етапи:
①ініціювати миттєвий кредит, маніпулювати ціною
Хакери спочатку використали максимальний сліп для миттєвого обміну 10 мільярдів 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 повністю забезпечуються основними великими гравцями. Для того, щоб протокол міг розвиватися в довгостроковій перспективі, безпека обов'язково буде пріоритетом.
Для роздрібних інвесторів, активних учасників екосистеми, потужних прихильників спільного будівництва технологій та спільноти. Проект також сподівається залучити роздрібних інвесторів до спільного будівництва, щоб поступово вдосконалити екосистему і підвищити рівень утримання. Щодо сфери DeFi, першочерговим залишається питання безпеки коштів.
Ключовим для визначення "чи є централізованим" є те, чи має користувач контроль над активами. У цьому плані SUI за допомогою мови програмування Move втілює контроль користувачів над активами.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
11 лайків
Нагородити
11
5
Поділіться
Прокоментувати
0/400
SchrodingersPaper
· 10год тому
Знову одна хвиля Рект з вильотом SUI вбила мене тисячу разів... але я все ще не можу втриматися, щоб не слідувати відкату
Переглянути оригіналвідповісти на0
MEVHunterLucky
· 10год тому
суй惨归惨 反正 я пам'ятаю, що не зазнав збитків
Переглянути оригіналвідповісти на0
SchrodingersFOMO
· 10год тому
Цю оболонку повністю обгризли.
Переглянути оригіналвідповісти на0
EthMaximalist
· 10год тому
Ще один чорний сміттєвий L1, чекаю падіння до нуля
Екосистема SUI демонструє стійкість: аналіз безпекових роздумів після атаки Cetus та потенціалу для довгострокового розвитку
Тверда віра після кризису безпеки: чому SUI все ще має потенціал для довгострокового зростання?
1. Ланцюгова реакція, спричинена атакою
22 травня 2025 року, провідний AMM протокол Cetus, розгорнутий на мережі SUI, зазнав хакерської атаки. Зловмисник скористався логічною вразливістю, пов'язаною з "проблемою переповнення цілого числа", щоб здійснити точну маніпуляцію, що призвело до втрати активів на суму понад 200 мільйонів доларів. Ця подія стала не лише найбільшою безпековою катастрофою в сфері DeFi цього року, але й найруйнівнішою хакерською атакою з моменту запуску основної мережі SUI.
Згідно з даними DefiLlama, загальний TVL SUI впав на понад 330 мільйонів доларів у день нападу, а сума, заблокована в протоколі Cetus, миттєво зменшилася на 84%, досягнувши 38 мільйонів доларів. У зв'язку з цим кілька популярних токенів на SUI впали на 76% до 97% всього за годину, що викликало широке занепокоєння щодо безпеки SUI та стабільності екосистеми.
Але після цієї хвилі удару екосистема SUI продемонструвала потужну стійкість і здатність до відновлення. Незважаючи на те, що подія Cetus короткостроково викликала коливання довіри, кошти на ланцюгу та активність користувачів не зазнали тривалої рецесії, а навпаки, спонукали всю екосистему значно підвищити увагу до безпеки, будівництва інфраструктури та якості проєктів.
2. Аналіз причин атаки на подію Cetus
2.1 Процес реалізації атаки
Згідно з технічним аналізом команди SlowMist щодо атаки на Cetus, хакерам вдалося успішно використати критичний арифметичний переповнення у протоколі, скориставшись блискавичними кредитами, точним маніпулюванням цінами та дефектами контракту, за короткий час викравши понад 200 мільйонів доларів цифрових активів. Шлях атаки можна умовно поділити на три етапи:
①ініціювати миттєвий кредит, маніпулювати ціною
Хакери спочатку використали максимальний сліп для миттєвого обміну 10 мільярдів haSUI, щоб взяти в борг велику кількість коштів та здійснити маніпуляції з цінами.
Швидкий кредит дозволяє користувачам позичати та повертати кошти в одній угоді, сплачуючи лише комісію, має характеристики високого важеля, низького ризику та низьких витрат. Хакери використали цей механізм, щоб за короткий час знизити ринкову ціну та точно контролювати її в дуже вузькому діапазоні.
Потім злочинець готується створити надзвичайно вузьку ліквідність, точно встановивши ціновий діапазон між найнижчою ціною 300,000 і найвищою ціною 300,200, ширина якого становить лише 1.00496621%.
За допомогою вищезазначеного способу хакери використали достатню кількість токенів та величезну ліквідність, успішно контролюючи ціну haSUI. Потім вони знову націлились на кілька токенів без реальної вартості для маніпуляцій.
②Додати ліквідність
Зловмисник створює вузькі ліквідні позиції, оголошуючи про додавання ліквідності, але через вразливість функції checked_shlw в кінцевому підсумку отримує лише 1 токен.
В основному це через дві причини:
Неправильне налаштування маски: еквівалентно великому обмеженню на додавання ліквідності, що призводить до того, що перевірка введення користувача в контракті стає формальною. Хакери, налаштувавши аномальні параметри, створюють введення, яке завжди менше цього обмеження, тим самим обходячи перевірку на переповнення.
Вихід за межі даних обрізається: під час виконання операції зсуву n << 64 над числом n, через те, що зсув перевищує ефективну ширину біт uint256 (256 біт), відбулося обрізання даних. Високі біти, які виходять за межі, автоматично відсікаються, що призводить до того, що результат обчислення значно нижчий за очікуваний, внаслідок чого система недооцінює кількість haSUI, необхідну для обміну. Остаточний обчислений результат приблизно менше 1, але оскільки округлення відбувається вгору, в підсумку він дорівнює 1, тобто хакеру потрібно лише додати 1 токен, щоб отримати величезну ліквідність.
③Виведення ліквідності
Здійснити повернення блискавичного кредиту, зберігаючи величезний прибуток. Врешті-решт, забрати з декількох ліквідних пулів токенові активи загальною вартістю до кількох сотень мільйонів доларів.
Ситуація з втратою коштів є серйозною, атака призвела до викрадення наступних активів:
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 відносно низька, а поріг управління відносно високий, звичайним користувачам важко безпосередньо впливати на управління мережею.
Механізм процесу:
Делегування прав: звичайним користувачам не потрібно самостійно запускати вузли, достатньо лише зарезервувати 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 повністю забезпечуються основними великими гравцями. Для того, щоб протокол міг розвиватися в довгостроковій перспективі, безпека обов'язково буде пріоритетом.
Для роздрібних інвесторів, активних учасників екосистеми, потужних прихильників спільного будівництва технологій та спільноти. Проект також сподівається залучити роздрібних інвесторів до спільного будівництва, щоб поступово вдосконалити екосистему і підвищити рівень утримання. Щодо сфери DeFi, першочерговим залишається питання безпеки коштів.
Ключовим для визначення "чи є централізованим" є те, чи має користувач контроль над активами. У цьому плані SUI за допомогою мови програмування Move втілює контроль користувачів над активами.