Уверенная вера после кризиса безопасности: почему SUI все еще обладает потенциалом для долгосрочного роста?
1. Цепная реакция, вызванная одной атакой
22 мая 2025 года на главном AMM-протоколе Cetus, развернутом в сети SUI, произошло хакерское нападение. Злоумышленник использовал логическую уязвимость, связанную с "проблемой целочисленного переполнения", для проведения точного манипулирования, что привело к потере более 200 миллионов долларов активов. Этот инцидент стал одним из крупнейших по масштабам инцидентов безопасности в области DeFi на сегодняшний день и оказался самым разрушительным хакерским нападением с момента запуска основной сети SUI.
Согласно данным DefiLlama, TVL всей цепочки SUI в день атаки упала более чем на 330 миллионов долларов, а сумма заблокированных средств самого протокола Cetus мгновенно испарилась на 84%, упав до 38 миллионов долларов. В результате этого несколько популярных токенов на SUI (включая Lofi, Sudeng, Squirtle и др.) упали в цене на 76% до 97% всего за час, что вызвало широкое внимание рынка к безопасности и стабильности экосистемы SUI.
Но после этой волны шока экосистема SUI продемонстрировала мощную устойчивость и способность к восстановлению. Несмотря на то, что событие Cetus краткосрочно вызвало колебания доверия, средства на цепочке и активность пользователей не столкнулись с долговременным спадом, а наоборот, способствовали значительному повышению внимания всей экосистемы к безопасности, строительству инфраструктуры и качеству проектов.
2. Анализ причин атаки на событие Cetus
2.1 Процесс реализации атаки
Согласно техническому анализу команды Slow Mist по атаке на Cetus, хакеры успешно воспользовались критическим арифметическим переполнением в протоколе, используя 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
490 миллионов долларов Haedal Staked SUI
1950 миллионов долларов TOILET
Другие токены, такие как 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 или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
13 Лайков
Награда
13
6
Поделиться
комментарий
0/400
Web3ProductManager
· 07-25 10:49
изучая данные о удержании пользователей... этот хак может стать серьезной точкой трения для массового принятия, если честно
Посмотреть ОригиналОтветить0
MEVHunterWang
· 07-25 10:48
Такой большой уязвимость никто не заметил? Неожиданно, неожиданно.
Посмотреть ОригиналОтветить0
fren.eth
· 07-25 10:48
Печально, да и только, уже несколько раз в убытке.
Посмотреть ОригиналОтветить0
¯\_(ツ)_/¯
· 07-25 10:46
разыгрывайте людей как лохов одну порцию мяса. Когда должно быть рост, так и будет.
Посмотреть ОригиналОтветить0
MetaverseMigrant
· 07-25 10:26
Эта поездка закончилась, а те, кто все еще решаются войти в позицию, действительно герои.
Исследование экосистемы SUI: Устойчивость и долгосрочный рост после атаки на Cetus
Уверенная вера после кризиса безопасности: почему SUI все еще обладает потенциалом для долгосрочного роста?
1. Цепная реакция, вызванная одной атакой
22 мая 2025 года на главном AMM-протоколе Cetus, развернутом в сети SUI, произошло хакерское нападение. Злоумышленник использовал логическую уязвимость, связанную с "проблемой целочисленного переполнения", для проведения точного манипулирования, что привело к потере более 200 миллионов долларов активов. Этот инцидент стал одним из крупнейших по масштабам инцидентов безопасности в области DeFi на сегодняшний день и оказался самым разрушительным хакерским нападением с момента запуска основной сети SUI.
Согласно данным DefiLlama, TVL всей цепочки SUI в день атаки упала более чем на 330 миллионов долларов, а сумма заблокированных средств самого протокола Cetus мгновенно испарилась на 84%, упав до 38 миллионов долларов. В результате этого несколько популярных токенов на SUI (включая Lofi, Sudeng, Squirtle и др.) упали в цене на 76% до 97% всего за час, что вызвало широкое внимание рынка к безопасности и стабильности экосистемы SUI.
Но после этой волны шока экосистема SUI продемонстрировала мощную устойчивость и способность к восстановлению. Несмотря на то, что событие Cetus краткосрочно вызвало колебания доверия, средства на цепочке и активность пользователей не столкнулись с долговременным спадом, а наоборот, способствовали значительному повышению внимания всей экосистемы к безопасности, строительству инфраструктуры и качеству проектов.
2. Анализ причин атаки на событие Cetus
2.1 Процесс реализации атаки
Согласно техническому анализу команды Slow Mist по атаке на Cetus, хакеры успешно воспользовались критическим арифметическим переполнением в протоколе, используя 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
490 миллионов долларов Haedal Staked SUI
1950 миллионов долларов TOILET
Другие токены, такие как 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.