Тверда віра після кризи безпеки: чому SUI все ще має потенціал для довгострокового зростання?
1. Ланцюгова реакція, викликана атакою
22 травня 2025 року, провідний AMM протокол Cetus, розгорнутий на мережі SUI, зазнав хакерської атаки. Зловмисники скористалися логічною вразливістю, пов'язаною з "проблемою переповнення цілого числа", щоб здійснити точну маніпуляцію, що призвело до втрати більше 200 мільйонів доларів активів. Ця подія стала не лише однією з найбільших за масштабом безпекових інцидентів у сфері DeFi цього року, але й найруйнівнішою хакерською атакою з моменту запуску основної мережі SUI.
Згідно з даними, загальний TVL SUI впав на понад 330 мільйонів доларів у день атаки, а сума, заблокована в протоколі Cetus, миттєво зникла на 84%, знизившись до 38 мільйонів доларів. У зв'язку з цим, кілька популярних токенів на SUI впали в ціні на 76% до 97% всього за годину, що викликало широкий інтерес до безпеки SUI та стабільності екосистеми.
Але після цієї хвилі удару екосистема SUI продемонструвала сильну стійкість і здатність до відновлення. Незважаючи на те, що подія Cetus призвела до коливань довіри в короткостроковій перспективі, наявність коштів на ланцюзі та активність користувачів не зазнали тривалої спадщини, а навпаки, спонукала всю екосистему значно підвищити увагу до безпеки, будівництва інфраструктури та якості проектів.
У цій статті розглядаються причини цього атаки, механізм консенсусу вузлів SUI, безпека мови MOVE та екологічний розвиток SUI, аналізуючи екосистему цієї публічної блокчейн-мережі, яка поки що знаходиться на ранніх стадіях розвитку, і обговорюється її потенціал для майбутнього зростання.
2. Аналіз причин атаки на подію Cetus
2.1 Процес реалізації атаки
Згідно з технічним аналізом інциденту з атакою на Cetus від команди безпеки, хакер успішно скористався ключовою арифметичною переповненням у протоколі, використовуючи миттєвий кредит, точні маніпуляції з цінами та дефекти контракту, протягом короткого часу викравши понад 2 мільярди доларів цифрових активів. Шлях атаки можна умовно розділити на три етапи:
Хакери спочатку використали максимальний спред для миттєвого обміну 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. Джерело вразливості полягає в одному з умовних перевірок на межі, лише змінивши два рядки коду, можна повністю усунути ризик; після виправлення його можна негайно впровадити в основну мережу, щоб забезпечити цілісність логіки подальших контрактів і виключити цю вразливість.
Висока прихованість: контракт стабільно працює без збоїв протягом двох років, пройшов кілька аудитів, але вразливості не були виявлені, основною причиною цього є те, що бібліотека 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 валідаторів, було б важко в короткий термін скоординувати всіх валідаторів для поетапної реакції.
3.2.2 Хто має право змінювати чорний список?
TransactionDenyConfig є YAML/TOML конфігураційним файлом, який завантажується локально кожним валідатором. Будь-хто, хто запускає вузол, може редагувати цей файл, гаряче перезавантажити або перезапустити вузол та оновити список. На поверхні здається, що кожен валідатор вільно висловлює свої цінності.
Насправді, для забезпечення узгодженості та ефективності політики безпеки оновлення цієї ключової конфігурації зазвичай є координованими. Оскільки це "термінове оновлення, ініційоване командою", то, по суті, цей список відмов є встановленим та оновленим фондом (або його уповноваженими розробниками).
Опублікувати чорний список, теоретично валідатори можуть вибрати, чи використовувати його ------ але насправді більшість людей за замовчуванням автоматично його приймають. Тому, хоча ця функція захищає кошти користувачів, її суть дійсно має певний рівень централізації.
3.2.3 Суть функції чорного списку
Функція чорного списку насправді не є логікою нижнього рівня протоколу, вона більше схожа на додатковий рівень безпеки, призначений для реагування на надзвичайні ситуації та забезпечення безпеки коштів користувачів.
Це в основному механізм забезпечення безпеки. Схоже на "замковий ланцюг", прикріплений до дверей, який активується лише для тих, хто хоче вдертися до дому, тобто для тих, хто зловживає протоколом. Для користувача:
Для великих гравців, основних постачальників ліквідності, протокол в першу чергу прагне забезпечити безпеку капіталу, оскільки насправді дані в мережі tvl повністю складаються з внесків основних великих гравців. Щоб протокол міг тривало розвиватися, він обов'язково буде в першу чергу забезпечувати безпеку.
Для роздрібних інвесторів, активних учасників екосистеми, потужних прихильників технологій та спільноти. Проект також сподівається залучити роздрібних інвесторів до спільної роботи, щоб поступово вдосконалити екосистему та підвищити рівень утримання. А щодо сфери DeFi, найважливіше
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
14 лайків
Нагородити
14
4
Поділіться
Прокоментувати
0/400
LiquidityOracle
· 12год тому
падіння...коли все це закінчиться?
Переглянути оригіналвідповісти на0
SatoshiNotNakamoto
· 08-04 12:21
І знову чорний і йде з вітром
Переглянути оригіналвідповісти на0
PuzzledScholar
· 08-04 12:14
Не хвилюйтеся, це називається ліквідація шортів із зростанням.
Екологічна стійкість SUI: аналіз атаки Cetus та обговорення потенціалу майбутнього розвитку
Тверда віра після кризи безпеки: чому SUI все ще має потенціал для довгострокового зростання?
1. Ланцюгова реакція, викликана атакою
22 травня 2025 року, провідний AMM протокол Cetus, розгорнутий на мережі SUI, зазнав хакерської атаки. Зловмисники скористалися логічною вразливістю, пов'язаною з "проблемою переповнення цілого числа", щоб здійснити точну маніпуляцію, що призвело до втрати більше 200 мільйонів доларів активів. Ця подія стала не лише однією з найбільших за масштабом безпекових інцидентів у сфері DeFi цього року, але й найруйнівнішою хакерською атакою з моменту запуску основної мережі SUI.
Згідно з даними, загальний TVL SUI впав на понад 330 мільйонів доларів у день атаки, а сума, заблокована в протоколі Cetus, миттєво зникла на 84%, знизившись до 38 мільйонів доларів. У зв'язку з цим, кілька популярних токенів на SUI впали в ціні на 76% до 97% всього за годину, що викликало широкий інтерес до безпеки SUI та стабільності екосистеми.
Але після цієї хвилі удару екосистема SUI продемонструвала сильну стійкість і здатність до відновлення. Незважаючи на те, що подія Cetus призвела до коливань довіри в короткостроковій перспективі, наявність коштів на ланцюзі та активність користувачів не зазнали тривалої спадщини, а навпаки, спонукала всю екосистему значно підвищити увагу до безпеки, будівництва інфраструктури та якості проектів.
У цій статті розглядаються причини цього атаки, механізм консенсусу вузлів SUI, безпека мови MOVE та екологічний розвиток SUI, аналізуючи екосистему цієї публічної блокчейн-мережі, яка поки що знаходиться на ранніх стадіях розвитку, і обговорюється її потенціал для майбутнього зростання.
2. Аналіз причин атаки на подію Cetus
2.1 Процес реалізації атаки
Згідно з технічним аналізом інциденту з атакою на Cetus від команди безпеки, хакер успішно скористався ключовою арифметичною переповненням у протоколі, використовуючи миттєвий кредит, точні маніпуляції з цінами та дефекти контракту, протягом короткого часу викравши понад 2 мільярди доларів цифрових активів. Шлях атаки можна умовно розділити на три етапи:
①ініціювати блискавичний кредит, маніпулювати ціною
Хакери спочатку використали максимальний спред для миттєвого обміну 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. Джерело вразливості полягає в одному з умовних перевірок на межі, лише змінивши два рядки коду, можна повністю усунути ризик; після виправлення його можна негайно впровадити в основну мережу, щоб забезпечити цілісність логіки подальших контрактів і виключити цю вразливість.
Висока прихованість: контракт стабільно працює без збоїв протягом двох років, пройшов кілька аудитів, але вразливості не були виявлені, основною причиною цього є те, що бібліотека 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 валідаторів, було б важко в короткий термін скоординувати всіх валідаторів для поетапної реакції.
3.2.2 Хто має право змінювати чорний список?
TransactionDenyConfig є YAML/TOML конфігураційним файлом, який завантажується локально кожним валідатором. Будь-хто, хто запускає вузол, може редагувати цей файл, гаряче перезавантажити або перезапустити вузол та оновити список. На поверхні здається, що кожен валідатор вільно висловлює свої цінності.
Насправді, для забезпечення узгодженості та ефективності політики безпеки оновлення цієї ключової конфігурації зазвичай є координованими. Оскільки це "термінове оновлення, ініційоване командою", то, по суті, цей список відмов є встановленим та оновленим фондом (або його уповноваженими розробниками).
Опублікувати чорний список, теоретично валідатори можуть вибрати, чи використовувати його ------ але насправді більшість людей за замовчуванням автоматично його приймають. Тому, хоча ця функція захищає кошти користувачів, її суть дійсно має певний рівень централізації.
3.2.3 Суть функції чорного списку
Функція чорного списку насправді не є логікою нижнього рівня протоколу, вона більше схожа на додатковий рівень безпеки, призначений для реагування на надзвичайні ситуації та забезпечення безпеки коштів користувачів.
Це в основному механізм забезпечення безпеки. Схоже на "замковий ланцюг", прикріплений до дверей, який активується лише для тих, хто хоче вдертися до дому, тобто для тих, хто зловживає протоколом. Для користувача:
Для великих гравців, основних постачальників ліквідності, протокол в першу чергу прагне забезпечити безпеку капіталу, оскільки насправді дані в мережі tvl повністю складаються з внесків основних великих гравців. Щоб протокол міг тривало розвиватися, він обов'язково буде в першу чергу забезпечувати безпеку.
Для роздрібних інвесторів, активних учасників екосистеми, потужних прихильників технологій та спільноти. Проект також сподівається залучити роздрібних інвесторів до спільної роботи, щоб поступово вдосконалити екосистему та підвищити рівень утримання. А щодо сфери DeFi, найважливіше