Впевнена віра після кризи безпеки: чому SUI все ще має потенціал для довгострокового зростання?
1. Ланцюгова реакція, викликана однією атакою
22 травня 2023 року на головному AMM-протоколі Cetus, розгорнутому в мережі SUI, сталася хакерська атака. Зловмисники скористалися логічною вразливістю, пов'язаною з "проблемою переповнення цілих чисел", щоб здійснити точну маніпуляцію, що призвело до втрат активів на суму понад 200 мільйонів доларів. Цей інцидент не тільки є одним з найбільших інцидентів безпеки в галузі DeFi на сьогоднішній день, але й став найбільш руйнівною хакерською атакою з моменту запуску основної мережі SUI.
Згідно з даними DefiLlama, загальний TVL SUI впав понад 330 мільйонів доларів у день атаки, а сума, заблокована в протоколі Cetus, миттєво зменшилася на 84%, опустившись до 38 мільйонів доларів. Внаслідок цього кілька популярних токенів на SUI (включаючи Lofi, Sudeng, Squirtle тощо) впали на 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.
Динамічні вибори: після закінчення кожного циклу підрахунку голосів, згідно з вагою голосування, проводиться динамічна ротація, повторні вибори набору валідаторів, що забезпечує активність вузлів, узгодженість інтересів та децентралізацію.
Переваги 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 повністю залежать від внесків основних великих гравців. Для довгострокового розвитку протоколу, безумовно, пріоритетом буде забезпечення безпеки.
Для роздрібних інвесторів, активних учасників екосистеми, потужних прихильників спільного будівництва технологій та спільноти. Проектна команда також сподівається, що це
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
8 лайків
Нагородити
8
4
Поділіться
Прокоментувати
0/400
GetRichLeek
· 5год тому
Схоже, що я дуже програв. Рект, але все ж не можу стриматися купувати просадку sui.
Переглянути оригіналвідповісти на0
ShadowStaker
· 23год тому
випробування стійкості мережі фр... але ці експлойти переповнення цілих чисел вже застаріли, смх. де ж належна валідація?
Виявлення екологічної стійкості SUI Після кризи безпеки все ще має довгостроковий потенціал зростання
Впевнена віра після кризи безпеки: чому SUI все ще має потенціал для довгострокового зростання?
1. Ланцюгова реакція, викликана однією атакою
22 травня 2023 року на головному AMM-протоколі Cetus, розгорнутому в мережі SUI, сталася хакерська атака. Зловмисники скористалися логічною вразливістю, пов'язаною з "проблемою переповнення цілих чисел", щоб здійснити точну маніпуляцію, що призвело до втрат активів на суму понад 200 мільйонів доларів. Цей інцидент не тільки є одним з найбільших інцидентів безпеки в галузі DeFi на сьогоднішній день, але й став найбільш руйнівною хакерською атакою з моменту запуску основної мережі SUI.
Згідно з даними DefiLlama, загальний TVL SUI впав понад 330 мільйонів доларів у день атаки, а сума, заблокована в протоколі Cetus, миттєво зменшилася на 84%, опустившись до 38 мільйонів доларів. Внаслідок цього кілька популярних токенів на SUI (включаючи Lofi, Sudeng, Squirtle тощо) впали на 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.
Динамічні вибори: після закінчення кожного циклу підрахунку голосів, згідно з вагою голосування, проводиться динамічна ротація, повторні вибори набору валідаторів, що забезпечує активність вузлів, узгодженість інтересів та децентралізацію.
Переваги 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 повністю залежать від внесків основних великих гравців. Для довгострокового розвитку протоколу, безумовно, пріоритетом буде забезпечення безпеки.
Для роздрібних інвесторів, активних учасників екосистеми, потужних прихильників спільного будівництва технологій та спільноти. Проектна команда також сподівається, що це