Твердая вера после кризиса безопасности: почему 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, хакеры успешно использовали уязвимость переполнения арифметического типа в протоколе, воспользовавшись кредитами на мгновенных займах, точной манипуляцией ценами и дефектами контракта, за короткий промежуток времени похитив более 200 миллионов долларов цифровых активов. Путь атаки можно условно разделить на следующие три этапа:
Хакеры сначала использовали максимальный проскальзывание, чтобы провести обмен 10 миллиардов haSUI с помощью срочного займа, заняв большое количество средств для манипуляции ценами.
Доступные займы позволяют пользователям заимствовать и возвращать средства в одной и той же сделке, платя только комиссию, обладая высокими плечами, низким риском и низкими затратами. Хакеры использовали этот механизм, чтобы в кратчайшие сроки снизить рыночную цену и точно контролировать её в очень узком диапазоне.
Затем злоумышленник готовится создать крайне узкую ликвидностную позицию, точно установив ценовой диапазон между самой низкой ставкой 300,000 и самой высокой ставкой 300,200, ширина которого составляет всего 1.00496621%.
С помощью вышеуказанных методов хакеры использовали достаточное количество токенов и огромную ликвидность, чтобы успешно манипулировать ценой haSUI. Затем они также манипулировали несколькими токенами без реальной ценности.
②Добавить ликвидность
Атакующий создает узкие позиции ликвидности, заявляет о добавлении ликвидности, но из-за уязвимости функции checked_shlw в конечном итоге получает только 1 токен.
Суть в том, что это вызвано двумя причинами:
Установка слишком широкого маски: эквивалентно очень большому пределу добавления ликвидности, что делает проверки пользовательского ввода в контракте бесполезными. Хакеры, устанавливая аномальные параметры, создают ввод, который всегда меньше этого предела, тем самым обходя проверку на переполнение.
Переполнение данных было обрезано: при выполнении операции сдвига n << 64 над числовым значением n произошло обрезание данных из-за превышения допустимой ширины битов типа данных uint256 (256 бит). Часть старших битов была автоматически отброшена, что привело к тому, что результат вычислений оказался значительно ниже ожидаемого, в результате чего система недооценила количество haSUI, необходимое для обмена. В конечном итоге расчетный результат оказался меньше 1, но так как было округление вверх, в итоге он оказался равным 1, то есть хакеру нужно было всего лишь добавить 1 токен, чтобы получить огромную ликвидность.
③Вывод ликвидности
Погашение.flash-займа, сохранение огромной прибыли. В конечном итоге из нескольких ликвидных пулов было выведено токенов на общую сумму в несколько сотен миллионов долларов.
Ситуация с потерей средств серьезная, атака привела к краже следующих активов:
12,9 млн SUI (примерно $54 млн)
6000 миллионов долларов США USDC
4,9 миллиона долларов 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
Средний период эпохи: 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 или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
11 Лайков
Награда
11
5
Поделиться
комментарий
0/400
SchrodingersPaper
· 07-21 04:20
Снова волна Рект, SUI убивает меня тысячу раз... но я все равно не могу удержаться от отката.
Экосистема 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, хакеры успешно использовали уязвимость переполнения арифметического типа в протоколе, воспользовавшись кредитами на мгновенных займах, точной манипуляцией ценами и дефектами контракта, за короткий промежуток времени похитив более 200 миллионов долларов цифровых активов. Путь атаки можно условно разделить на следующие три этапа:
①Запускать молниеносные займы, манипулировать ценами
Хакеры сначала использовали максимальный проскальзывание, чтобы провести обмен 10 миллиардов haSUI с помощью срочного займа, заняв большое количество средств для манипуляции ценами.
Доступные займы позволяют пользователям заимствовать и возвращать средства в одной и той же сделке, платя только комиссию, обладая высокими плечами, низким риском и низкими затратами. Хакеры использовали этот механизм, чтобы в кратчайшие сроки снизить рыночную цену и точно контролировать её в очень узком диапазоне.
Затем злоумышленник готовится создать крайне узкую ликвидностную позицию, точно установив ценовой диапазон между самой низкой ставкой 300,000 и самой высокой ставкой 300,200, ширина которого составляет всего 1.00496621%.
С помощью вышеуказанных методов хакеры использовали достаточное количество токенов и огромную ликвидность, чтобы успешно манипулировать ценой haSUI. Затем они также манипулировали несколькими токенами без реальной ценности.
②Добавить ликвидность
Атакующий создает узкие позиции ликвидности, заявляет о добавлении ликвидности, но из-за уязвимости функции checked_shlw в конечном итоге получает только 1 токен.
Суть в том, что это вызвано двумя причинами:
Установка слишком широкого маски: эквивалентно очень большому пределу добавления ликвидности, что делает проверки пользовательского ввода в контракте бесполезными. Хакеры, устанавливая аномальные параметры, создают ввод, который всегда меньше этого предела, тем самым обходя проверку на переполнение.
Переполнение данных было обрезано: при выполнении операции сдвига n << 64 над числовым значением n произошло обрезание данных из-за превышения допустимой ширины битов типа данных uint256 (256 бит). Часть старших битов была автоматически отброшена, что привело к тому, что результат вычислений оказался значительно ниже ожидаемого, в результате чего система недооценила количество haSUI, необходимое для обмена. В конечном итоге расчетный результат оказался меньше 1, но так как было округление вверх, в итоге он оказался равным 1, то есть хакеру нужно было всего лишь добавить 1 токен, чтобы получить огромную ликвидность.
③Вывод ликвидности
Погашение.flash-займа, сохранение огромной прибыли. В конечном итоге из нескольких ликвидных пулов было выведено токенов на общую сумму в несколько сотен миллионов долларов.
Ситуация с потерей средств серьезная, атака привела к краже следующих активов:
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 относительно низок, а порог управления относительно высок, и обычным пользователям трудно напрямую влиять на управление сетью.
Механизм процесса:
Делегирование прав: обычным пользователям не нужно самостоятельно запускать узлы, достаточно заложить 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.