Тверда віра після кризи безпеки: чому 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 викликала коливання довіри в короткостроковій перспективі, обсяги коштів на ланцюгу та активність користувачів не зазнали тривалої депресії, а навпаки, сприяли значному зростанню уваги всього екосистеми до безпеки, будівництва інфраструктури та якості проектів.
2. Аналіз причин атаки події Cetus
2.1 Процес реалізації атаки
Згідно з технічним аналізом команди Slow Mist щодо атаки на Cetus, хакери успішно використали критичну арифметичну помилку в протоколі, за допомогою.flash loan, точного маніпулювання цінами та дефектів контракту, в короткий термін вкрали більше 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
1950万 доларів США TOILET
Інші токени, такі як 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.
Динамічні вибори: після закінчення кожного циклу голосування, на основі ваги голосування, проводиться динамічна ротація, повторні вибори набору валідаторів, щоб забезпечити активність вузлів, узгодженість інтересів та децентралізацію.
Переваги 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
Web3ProductManager
· 22год тому
дивлячись на дані утримання користувачів... цей хак може бути основною точкою тертя для масового впровадження, якщо чесно
Переглянути оригіналвідповісти на0
MEVHunterWang
· 22год тому
Такі великі вразливості, і ніхто не помітив? Це несподівано.
Переглянути оригіналвідповісти на0
fren.eth
· 22год тому
жахливо, як і раніше жахливо, вже кілька разів втратив.
Переглянути оригіналвідповісти на0
¯\_(ツ)_/¯
· 22год тому
обдурювати людей, як лохів однією刀少块肉呗 Щоразу, коли потрібно, зростання, зростання.
Переглянути оригіналвідповісти на0
MetaverseMigrant
· 22год тому
Цей поїзд більше не курсує, а ті, хто все ще хоче увійти в позицію, справжні герої.
Аналіз екосистеми SUI: стійкість та довгостроковий потенціал зростання після атаки Cetus
Тверда віра після кризи безпеки: чому 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 викликала коливання довіри в короткостроковій перспективі, обсяги коштів на ланцюгу та активність користувачів не зазнали тривалої депресії, а навпаки, сприяли значному зростанню уваги всього екосистеми до безпеки, будівництва інфраструктури та якості проектів.
2. Аналіз причин атаки події Cetus
2.1 Процес реалізації атаки
Згідно з технічним аналізом команди Slow Mist щодо атаки на Cetus, хакери успішно використали критичну арифметичну помилку в протоколі, за допомогою.flash loan, точного маніпулювання цінами та дефектів контракту, в короткий термін вкрали більше 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
1950万 доларів США TOILET
Інші токени, такі як 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.
Динамічні вибори: після закінчення кожного циклу голосування, на основі ваги голосування, проводиться динамічна ротація, повторні вибори набору валідаторів, щоб забезпечити активність вузлів, узгодженість інтересів та децентралізацію.
Переваги 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.