Тверда віра після кризи безпеки: чому SUI все ще має потенціал для довгострокового зростання?
1. Ланцюгова реакція, спричинена атакою
22 травня 2025 року головний AMM протокол Cetus, розгорнутий на мережі SUI, зазнав хакерської атаки. Зловмисники скористалися логічною вразливістю, пов'язаною з "проблемою переповнення цілих чисел", що дозволило їм здійснити точну маніпуляцію, в результаті чого було втрачено понад 200 мільйонів доларів активів. Ця подія стала не лише найбільшою безпековою аварією в області DeFi на сьогодні, але й найруйнівнішою хакерською атакою з моменту запуску основної мережі SUI.
Згідно з даними, загальний TVL ланцюга SUI в день нападу впав більш ніж на 330 мільйонів доларів, а сума, зафіксована в протоколі Cetus, миттєво зникла на 84%, зменшившись до 38 мільйонів доларів. У зв'язку з цим, декілька популярних токенів на SUI (включаючи Lofi, Sudeng, Squirtle тощо) впали на 76% до 97% всього за годину, що викликало широкий інтерес до безпеки SUI та стабільності екосистеми.
Але після цієї ударної хвилі екосистема SUI продемонструвала потужну стійкість та відновлювальні здібності. Незважаючи на те, що подія Cetus короткостроково викликала коливання довіри, на ланцюгу капітал та активність користувачів не зазнали тривалого спаду, а, навпаки, сприяли суттєвому підвищенню уваги до безпеки, будівництва інфраструктури та якості проєктів.
Ми розглянемо причини цієї атаки, механізм консенсусу вузлів SUI, безпеку мови MOVE та екосистемний розвиток SUI, щоб проаналізувати екосистему цього публічного блокчейну, який наразі перебуває на ранній стадії розвитку, та обговорити його майбутній потенціал розвитку.
2. Аналіз причин атаки на подію Cetus
2.1 Процес реалізації атаки
Згідно з технічним аналізом події атаки на 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
1950 мільйонів доларів TOILET
Інші токени, такі як 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.
Динамічні вибори: після закінчення кожного циклу голосування, на основі ваги голосів, проводиться динамічна ротація та повторні вибори колекції валідаторів, що забезпечує життєздатність вузлів, узгодженість інтересів та децентралізацію.
Переваги 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 конфігураційним файлом, що завантажується локально кожним валідатором. Будь-яка особа, що запускає вузол, може редагувати цей файл, виконувати гаряче перезавантаження або перезапустити вузол та оновити список. На перший погляд, кожен валідатор, здається, вільно висловлює свої цінності.
Насправді, для узгодженості та ефективності політики безпеки оновлення таких ключових конфігурацій зазвичай є координованими. Оскільки це "термінове оновлення", то, по суті, Фонд (або його уповноважені розробники) встановлює та оновлює цей список відмов.
SUI опублікував чорний список, теоретично валідатори можуть вибрати, чи впроваджувати його ------ але насправді більшість людей за замовчуванням автоматично його впроваджують. Тому, хоча ця функція захищає кошти користувачів, її суть дійсно має певний рівень централізації.
3.2.3 сутність функції чорного списку
Функція чорного списку насправді не є логікою на рівні протоколу, вона більше схожа на додатковий рівень безпеки, що забезпечує безпеку коштів користувачів у випадку непередбачених ситуацій.
Це по суті механізм забезпечення безпеки. Подібно до "протизламного ланцюга", прикріпленого до дверей, він активується лише для тих, хто хоче вторгнутися до будинку, тобто для тих, хто має намір зловживати протоколом. Для користувачів:
Для великих учасників, основних постачальників ліквідності, протокол найбільше прагне забезпечити безпеку коштів, оскільки насправді дані в ланцюгу tvl повністю залежать від внесків основних великих учасників. Щоб протокол міг розвиватися надовго, безумовно, спочатку буде забезпечено безпеку.
Для роздрібних інвесторів, активних учасників екосистеми, потужних підтримувачів технологій та спільнот. Проект також сподівається залучити роздрібних інвесторів до спільної роботи, щоб поступово вдосконалити екосистему та посилити залишок.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
14 лайків
Нагородити
14
7
Поділіться
Прокоментувати
0/400
CodeZeroBasis
· 14год тому
Цей баг мене лякає.
Переглянути оригіналвідповісти на0
MoonMathMagic
· 14год тому
Добре, якщо втрачаємо, то втрачаємо. Хто ніколи не втрачав гроші?
Переглянути оригіналвідповісти на0
MeltdownSurvivalist
· 14год тому
Знову хакерська подія. Ще й таке велике.
Переглянути оригіналвідповісти на0
BearMarketBro
· 14год тому
Це лише марна слава, такі вразливості можуть виникнути.
Переглянути оригіналвідповісти на0
BridgeTrustFund
· 14год тому
sui насправді три хвилини вибуху
Переглянути оригіналвідповісти на0
0xSunnyDay
· 14год тому
коли sui впаде до 0?
Переглянути оригіналвідповісти на0
AirdropHarvester
· 14год тому
Падіння, падіння, падіння, екосистема SUI майже зникла.
Екосистема SUI демонструє стійкість: Безпека після атаки Cetus та перспективи розвитку
Тверда віра після кризи безпеки: чому SUI все ще має потенціал для довгострокового зростання?
1. Ланцюгова реакція, спричинена атакою
22 травня 2025 року головний AMM протокол Cetus, розгорнутий на мережі SUI, зазнав хакерської атаки. Зловмисники скористалися логічною вразливістю, пов'язаною з "проблемою переповнення цілих чисел", що дозволило їм здійснити точну маніпуляцію, в результаті чого було втрачено понад 200 мільйонів доларів активів. Ця подія стала не лише найбільшою безпековою аварією в області DeFi на сьогодні, але й найруйнівнішою хакерською атакою з моменту запуску основної мережі SUI.
Згідно з даними, загальний TVL ланцюга SUI в день нападу впав більш ніж на 330 мільйонів доларів, а сума, зафіксована в протоколі Cetus, миттєво зникла на 84%, зменшившись до 38 мільйонів доларів. У зв'язку з цим, декілька популярних токенів на SUI (включаючи Lofi, Sudeng, Squirtle тощо) впали на 76% до 97% всього за годину, що викликало широкий інтерес до безпеки SUI та стабільності екосистеми.
Але після цієї ударної хвилі екосистема SUI продемонструвала потужну стійкість та відновлювальні здібності. Незважаючи на те, що подія Cetus короткостроково викликала коливання довіри, на ланцюгу капітал та активність користувачів не зазнали тривалого спаду, а, навпаки, сприяли суттєвому підвищенню уваги до безпеки, будівництва інфраструктури та якості проєктів.
Ми розглянемо причини цієї атаки, механізм консенсусу вузлів SUI, безпеку мови MOVE та екосистемний розвиток SUI, щоб проаналізувати екосистему цього публічного блокчейну, який наразі перебуває на ранній стадії розвитку, та обговорити його майбутній потенціал розвитку.
2. Аналіз причин атаки на подію Cetus
2.1 Процес реалізації атаки
Згідно з технічним аналізом події атаки на 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
1950 мільйонів доларів TOILET
Інші токени, такі як 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.
Динамічні вибори: після закінчення кожного циклу голосування, на основі ваги голосів, проводиться динамічна ротація та повторні вибори колекції валідаторів, що забезпечує життєздатність вузлів, узгодженість інтересів та децентралізацію.
Переваги 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 конфігураційним файлом, що завантажується локально кожним валідатором. Будь-яка особа, що запускає вузол, може редагувати цей файл, виконувати гаряче перезавантаження або перезапустити вузол та оновити список. На перший погляд, кожен валідатор, здається, вільно висловлює свої цінності.
Насправді, для узгодженості та ефективності політики безпеки оновлення таких ключових конфігурацій зазвичай є координованими. Оскільки це "термінове оновлення", то, по суті, Фонд (або його уповноважені розробники) встановлює та оновлює цей список відмов.
SUI опублікував чорний список, теоретично валідатори можуть вибрати, чи впроваджувати його ------ але насправді більшість людей за замовчуванням автоматично його впроваджують. Тому, хоча ця функція захищає кошти користувачів, її суть дійсно має певний рівень централізації.
3.2.3 сутність функції чорного списку
Функція чорного списку насправді не є логікою на рівні протоколу, вона більше схожа на додатковий рівень безпеки, що забезпечує безпеку коштів користувачів у випадку непередбачених ситуацій.
Це по суті механізм забезпечення безпеки. Подібно до "протизламного ланцюга", прикріпленого до дверей, він активується лише для тих, хто хоче вторгнутися до будинку, тобто для тих, хто має намір зловживати протоколом. Для користувачів:
Для великих учасників, основних постачальників ліквідності, протокол найбільше прагне забезпечити безпеку коштів, оскільки насправді дані в ланцюгу tvl повністю залежать від внесків основних великих учасників. Щоб протокол міг розвиватися надовго, безумовно, спочатку буде забезпечено безпеку.
Для роздрібних інвесторів, активних учасників екосистеми, потужних підтримувачів технологій та спільнот. Проект також сподівається залучити роздрібних інвесторів до спільної роботи, щоб поступово вдосконалити екосистему та посилити залишок.