Тверда віра після кризису безпеки: чому SUI все ще має потенціал для довгострокового зростання?
1. Ланцюгова реакція, викликана атакою
22 травня 2023 року, головний AMM протокол Cetus, розгорнутий у мережі SUI, зазнав хакерської атаки. Зловмисники використали логічну уразливість, пов'язану з "проблемою переповнення цілого числа", для точного маніпулювання, що призвело до втрат активів на понад 200 мільйонів доларів. Ця подія стала не лише найбільшою за масштабами безпековою аварією у сфері DeFi цього року, але й найруйнівнішою хакерською атакою з моменту запуску основної мережі SUI.
Згідно з даними DefiLlama, загальний TVL SUI в ланцюзі в день атаки впав більш ніж на 330 мільйонів доларів, а сума, заблокована в протоколі Cetus, миттєво зникла на 84%, знизившись до 38 мільйонів доларів. У зв'язку з цим кілька популярних токенів SUI за короткий проміжок часу впали на 76% до 97%, що викликало широке занепокоєння щодо безпеки SUI та стабільності екосистеми.
Але після цього ударного імпульсу екосистема SUI продемонструвала потужну стійкість і здатність до відновлення. Незважаючи на те, що подія Cetus на короткий термін викликала коливання довіри, обсяги коштів на ланцюгу та активність користувачів не зазнали тривалої депресії, а навпаки, спонукали всю екосистему значно підвищити увагу до безпеки, будівництва інфраструктури та якості проєктів.
Ми розглянемо причини цього атакуючого інциденту, механізм консенсусу вузлів 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 повністю залежать від внесків основних великих гравців. Щоб забезпечити довгостроковий розвиток протоколу, безпека обов'язково буде пріоритетом.
Для роздрібних інвесторів, активних учасників екосистеми, сильних прихильників спільного будівництва технологій та спільноти. Команда проекту також сподівається залучити роздрібних інвесторів до спільного будівництва,
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
13 лайків
Нагородити
13
5
Поділіться
Прокоментувати
0/400
MEVHunterNoLoss
· 15год тому
Ця атака хакерів мені не страшна, я не боюся Скорочення втрат
Переглянути оригіналвідповісти на0
gas_fee_trauma
· 15год тому
炒币亏完了就全在这
відповісти на0
faded_wojak.eth
· 15год тому
На що ти ще наважуєшся говорити про стійкість, коли тебе просто висмикнули до гола?
Переглянути оригіналвідповісти на0
LiquidationKing
· 15год тому
sui не обов'язково холодний, але з залізом потрібно бути обережним
Переглянути оригіналвідповісти на0
MEVSandwich
· 15год тому
Скорочення втрат і зв'язаної болі, хто це розуміє?
Екологічна стійкість SUI проявляється, демонструючи довгостроковий потенціал зростання після безпекового інциденту
Тверда віра після кризису безпеки: чому SUI все ще має потенціал для довгострокового зростання?
1. Ланцюгова реакція, викликана атакою
22 травня 2023 року, головний AMM протокол Cetus, розгорнутий у мережі SUI, зазнав хакерської атаки. Зловмисники використали логічну уразливість, пов'язану з "проблемою переповнення цілого числа", для точного маніпулювання, що призвело до втрат активів на понад 200 мільйонів доларів. Ця подія стала не лише найбільшою за масштабами безпековою аварією у сфері DeFi цього року, але й найруйнівнішою хакерською атакою з моменту запуску основної мережі SUI.
Згідно з даними DefiLlama, загальний TVL SUI в ланцюзі в день атаки впав більш ніж на 330 мільйонів доларів, а сума, заблокована в протоколі Cetus, миттєво зникла на 84%, знизившись до 38 мільйонів доларів. У зв'язку з цим кілька популярних токенів SUI за короткий проміжок часу впали на 76% до 97%, що викликало широке занепокоєння щодо безпеки SUI та стабільності екосистеми.
Але після цього ударного імпульсу екосистема SUI продемонструвала потужну стійкість і здатність до відновлення. Незважаючи на те, що подія Cetus на короткий термін викликала коливання довіри, обсяги коштів на ланцюгу та активність користувачів не зазнали тривалої депресії, а навпаки, спонукали всю екосистему значно підвищити увагу до безпеки, будівництва інфраструктури та якості проєктів.
Ми розглянемо причини цього атакуючого інциденту, механізм консенсусу вузлів 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 повністю залежать від внесків основних великих гравців. Щоб забезпечити довгостроковий розвиток протоколу, безпека обов'язково буде пріоритетом.
Для роздрібних інвесторів, активних учасників екосистеми, сильних прихильників спільного будівництва технологій та спільноти. Команда проекту також сподівається залучити роздрібних інвесторів до спільного будівництва,