Тверда віра після криз безпеки: чому 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 Процес реалізації атаки
Згідно з технічним аналізом команди 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 токен, щоб отримати величезну ліквідність.
③Виведення ліквідності
Здійснити повернення кредиту через Flash Loan, зберігши величезний прибуток. Врешті-решт, вилучити токенові активи загальною вартістю кілька сотень мільйонів доларів з кількох ліквідних пулів.
Ситуація з втратами капіталу серйозна, атака призвела до викрадення наступних активів:
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
8
Репост
Поділіться
Прокоментувати
0/400
ForkLibertarian
· 4год тому
Моментальне падіння на 97, Скорочення втрат, як лохів.
Переглянути оригіналвідповісти на0
WenAirdrop
· 5год тому
Цей ставок був вичерпаний hk.
Переглянути оригіналвідповісти на0
RektRecorder
· 08-10 22:17
Перший ряд місця великої втрати
Переглянути оригіналвідповісти на0
LiquidityNinja
· 08-10 22:08
Дивлюсь вниз, вже закрив позицію з прибутком.
Переглянути оригіналвідповісти на0
MevHunter
· 08-10 22:04
Сидіти і чекати на дамп, попереду ще багато часу.
Переглянути оригіналвідповісти на0
NeverVoteOnDAO
· 08-10 22:03
Це ж не вперше, коли нас хакнули, звикніть до цього.
Переглянути оригіналвідповісти на0
BtcDailyResearcher
· 08-10 21:56
Скорочення втрат виходить gg
Переглянути оригіналвідповісти на0
consensus_whisperer
· 08-10 21:54
З таким станом ще хочуть обманювати людей зловити падаючий ніж?
Екосистема 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 Процес реалізації атаки
Згідно з технічним аналізом команди 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 токен, щоб отримати величезну ліквідність.
③Виведення ліквідності
Здійснити повернення кредиту через Flash Loan, зберігши величезний прибуток. Врешті-решт, вилучити токенові активи загальною вартістю кілька сотень мільйонів доларів з кількох ліквідних пулів.
Ситуація з втратами капіталу серйозна, атака призвела до викрадення наступних активів:
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 повністю складаються з внесків основних великих гравців. Щоб забезпечити тривале розвиток протоколу, безумовно, буде пріоритетом забезпечити безпеку.
Для роздрібних інвесторів, активних учасників екосистеми, сильних прихильників технологій та спільнот. Проект також сподівається залучити роздрібних інвесторів до спільного будівництва, щоб поступово вдосконалювати екосистему та підвищувати рівень утримання. А для сфери DeFi найголовніше - це безпека коштів.
Ключовим критерієм для визначення "чи є централізованим" є те, чи має користувач контроль над активами. У цьому відношенні SUI демонструє це за допомогою мови програмування Move.