Твердая вера после кризиса безопасности: почему 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 Реализация процесса атаки
Согласно техническому анализу инцидента с атакой на Cetus, проведенному командой Slow Mist, хакеры успешно воспользовались ключевым арифметическим переполнением в протоколе, используяflash-loan, точное манипулирование ценами и недостатки контракта, в кратчайшие сроки похитив более 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 млн)
6000 миллионов долларов США USDC
4900000 долларов США 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 проверка на переполнение была очень слабой. В истории происходили переполнения при сложении, вычитании, умножении и т.д., и непосредственной причиной всего этого было то, что результат вычислений выходил за пределы диапазона. Например, уязвимости в двух смарт-контрактах на языке Solidity, BEC и SMT, были реализованы с помощью тщательно подобранных параметров, которые обходили проверочные операторы в контракте, что позволяло осуществлять избыточные переводы.
3. Консенсусный механизм SUI
3.1 Введение в механизм консенсуса SUI
Обзор:
SUI использует механизм делегированного доказательства доли (DeleGated Proof of Stake, сокращенно DPoS)). Хотя механизм DPoS может повысить пропускную способность транзакций, он не может обеспечить такой же высокий уровень децентрализации, как PoW (доказательство работы). Следовательно, уровень децентрализации SUI относительно низок, а порог управления относительно высок, обычным пользователям сложно напрямую влиять на управление сетью.
Среднее количество валидаторов: 106
Средний период эпохи: 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 в блокчейне полностью зависят от вкладов крупных участников. Для долгосрочного развития протокола безопасность обязательно будет в приоритете.
Для розничных инвесторов, активных участников экосистемы, сильных сторонников совместного строительства технологий и сообщества. Команда проекта также надеется привлечь розничных инвесторов к совместному строительству, чтобы постепенно улучшить экосистему и увеличить уровень удержания. Что касается области DeFi, то на первом месте всё же стоит безопасность средств.
Ключевым моментом в определении "централизованности" является наличие у пользователя контроля над активами. В этом отношении SUI с помощью языка программирования Move демонстрирует это.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
10 Лайков
Награда
10
6
Репост
Поделиться
комментарий
0/400
RektRecorder
· 5ч назад
Первая линия места крупных потерь
Посмотреть ОригиналОтветить0
LiquidityNinja
· 5ч назад
Смотрим вниз, уже закрыли позиции.
Посмотреть ОригиналОтветить0
MevHunter
· 5ч назад
Сижу и жду дамп, впереди еще много времени
Посмотреть ОригиналОтветить0
NeverVoteOnDAO
· 6ч назад
Не в первый раз подвергаюсь хакерским атакам, привыкнуть к этому.
Посмотреть ОригиналОтветить0
BtcDailyResearcher
· 6ч назад
Сокращение потерь вышел gg
Посмотреть ОригиналОтветить0
consensus_whisperer
· 6ч назад
Взорвавшись так, вы все еще хотите обмануть людей, чтобы ловить падающий нож?
Экосистема 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 Реализация процесса атаки
Согласно техническому анализу инцидента с атакой на Cetus, проведенному командой Slow Mist, хакеры успешно воспользовались ключевым арифметическим переполнением в протоколе, используяflash-loan, точное манипулирование ценами и недостатки контракта, в кратчайшие сроки похитив более 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 млн)
6000 миллионов долларов США USDC
4900000 долларов США Haedal Staked SUI
$19,5 млн ТУАЛЕТ
Другие токены, такие как HIPPO и LOFI, упали на 75-80%, ликвидность иссякла
2.2 Причины и особенности данного уязвимости
Уязвимость Cetus имеет три характеристики:
Стоимость исправления крайне низка: с одной стороны, коренная причина инцидента с Cetus заключается в упущении в математической библиотеке Cetus, а не в ошибках ценового механизма протокола или ошибок базовой архитектуры. С другой стороны, уязвимость ограничена только Cetus и не связана с кодом SUI. Корень уязвимости заключается в одной проверке граничного условия, и достаточно изменить всего две строки кода, чтобы полностью устранить риск; после завершения исправления его можно сразу развернуть в основной сети, чтобы обеспечить завершенность логики последующих контрактов и исключить данную уязвимость.
Высокая скрытность: контракт работает стабильно без сбоев уже два года, протокол Cetus прошел несколько аудитов, но уязвимостей не было найдено, основная причина этого заключается в том, что библиотека Integer_Mate, используемая для математических вычислений, не была включена в область аудита.
Хакеры используют экстремальные значения для точной настройки диапазона сделок, создавая крайне редкие сценарии с подачей очень высокой ликвидности, что и вызывает аномальную логику. Это указывает на то, что подобные проблемы трудно обнаружить с помощью обычного тестирования. Эти проблемы часто находятся в слепой зоне восприятия людей, поэтому долгое время остаются незамеченными.
Move превосходит многие языки смарт-контрактов в вопросах безопасности ресурсов и проверки типов, встроенная нативная проверка на переполнение целых чисел в распространенных ситуациях. Данное переполнение произошло из-за того, что при добавлении ликвидности для расчета необходимого количества токенов сначала использовалось неправильное значение для проверки верхнего предела, и сдвиговые операции были использованы вместо обычных арифметических операций, в то время как обычные операции сложения, вычитания, умножения и деления в Move автоматически проверяют переполнение, что предотвращает такие проблемы с усечением старших разрядов.
Аналогичные уязвимости также возникали в других языках (таких как Solidity, Rust), и даже из-за отсутствия защиты от переполнения целых чисел их было легче эксплуатировать; до обновления версии Solidity проверка на переполнение была очень слабой. В истории происходили переполнения при сложении, вычитании, умножении и т.д., и непосредственной причиной всего этого было то, что результат вычислений выходил за пределы диапазона. Например, уязвимости в двух смарт-контрактах на языке Solidity, BEC и SMT, были реализованы с помощью тщательно подобранных параметров, которые обходили проверочные операторы в контракте, что позволяло осуществлять избыточные переводы.
3. Консенсусный механизм SUI
3.1 Введение в механизм консенсуса SUI
Обзор:
SUI использует механизм делегированного доказательства доли (DeleGated Proof of Stake, сокращенно DPoS)). Хотя механизм DPoS может повысить пропускную способность транзакций, он не может обеспечить такой же высокий уровень децентрализации, как PoW (доказательство работы). Следовательно, уровень децентрализации SUI относительно низок, а порог управления относительно высок, обычным пользователям сложно напрямую влиять на управление сетью.
Среднее количество валидаторов: 106
Средний период эпохи: 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 в блокчейне полностью зависят от вкладов крупных участников. Для долгосрочного развития протокола безопасность обязательно будет в приоритете.
Для розничных инвесторов, активных участников экосистемы, сильных сторонников совместного строительства технологий и сообщества. Команда проекта также надеется привлечь розничных инвесторов к совместному строительству, чтобы постепенно улучшить экосистему и увеличить уровень удержания. Что касается области DeFi, то на первом месте всё же стоит безопасность средств.
Ключевым моментом в определении "централизованности" является наличие у пользователя контроля над активами. В этом отношении SUI с помощью языка программирования Move демонстрирует это.