Твердая вера после кризиса безопасности: почему SUI все еще обладает потенциалом для долгосрочного роста?
1.Цепная реакция, вызванная одной атакой
22 мая 2025 года ведущий AMM-протокол Cetus, развернутый на сети SUI, подвергся хакерской атаке. Злоумышленники использовали логическую уязвимость, связанную с "проблемой переполнения целого числа", для проведения точного манипулирования, что привело к потерям более 200 миллионов долларов активов. Этот инцидент стал не только одной из крупнейших по масштабу безопасностных аварий в области DeFi на сегодняшний день, но и самой разрушительной хакерской атакой с момента запуска основной сети SUI.
Согласно данным, TVL всей цепочки SUI в день атаки в одночасье упала более чем на 330 миллионов долларов, а сумма, заблокированная в协议 Cetus, мгновенно испарилась на 84%, упав до 38 миллионов долларов. Под воздействием этого, несколько популярных токенов на SUI упали на 76% до 97% всего за час, что вызвало широкий интерес к безопасности SUI и стабильности его экосистемы.
Но после этой волны ударов экосистема SUI продемонстрировала мощную устойчивость и способность к восстановлению. Несмотря на то, что событие Cetus краткосрочно вызвало колебания доверия, средства на блокчейне и активность пользователей не столкнулись с длительным спадом, а наоборот, способствовали значительному повышению внимания всей экосистемы к безопасности, строительству инфраструктуры и качеству проектов.
В данной статье будут рассмотрены причины данного инцидента, механизмы консенсуса узлов SUI, безопасность языка MOVE и развитие экосистемы SUI, а также проанализирована текущая экосистема этой публичной цепочки, находящейся на ранних стадиях развития, и обсуждены её будущие перспективы.
2. Анализ причин атаки на событие Cetus
2.1 Процесс реализации атаки
Согласно техническому анализу инцидента атаки на Cetus, проведённому командой безопасности, хакеры успешно использовали уязвимость ключевого арифметического переполнения в протоколе, воспользовавшись flash-кредитами, точным манипулированием ценами и недостатками контракта, за короткое время похитив более 200 миллионов долларов цифровых активов. Путь атаки можно условно разделить на три этапа:
Хакеры сначала использовали максимальный проскальзывание, чтобы мгновенно обменять 10 миллиардов haSUI с помощью кредитов под залог, заимствуя огромные суммы денег для манипуляции ценами.
Доступ к займу на мгновенной основе позволяет пользователям заимствовать и возвращать средства в рамках одной сделки, оплачивая только комиссию, обладая характеристиками высокого плеча, низкого риска и низких затрат. Хакеры использовали этот механизм, чтобы в короткие сроки снизить рыночную цену и точно контролировать её в очень узком диапазоне.
Затем злоумышленник готовится создать крайне узкую ликвидную позицию, точно установив ценовой диапазон между самой низкой ценой 300,000 и самой высокой ценой 300,200, ширина которой составляет всего 1.00496621%.
Таким образом, хакеры с помощью достаточного количества токенов и огромной ликвидности успешно манипулировали ценой haSUI. Затем они снова начали манипулировать несколькими токенами без реальной ценности.
②Добавить ликвидность
Атакующий создает узкие позиции ликвидности, заявляя о добавлении ликвидности, но из-за уязвимости функции checked_shlw в конечном итоге получает только 1 токен.
В сущности, это связано с двумя причинами:
1.Широкие настройки маски: эквивалентны огромному лимиту добавления ликвидности, что приводит к тому, что проверка пользовательского ввода в контракте становится формальностью. Хакеры, установив аномальные параметры, создают ввод, который всегда меньше этого лимита, тем самым обходя проверку на переполнение.
Переполнение данных было обрезано: при выполнении операции сдвига n << 64 для числового значения n произошло обрезание данных из-за выхода за пределы эффективной ширины бит uint256 (256 бит). Высокоразрядная часть переполнения была автоматически отброшена, что привело к тому, что результат вычисления оказался значительно ниже ожидаемого, в результате чего система недооценила количество haSUI, необходимое для обмена. В конечном итоге вычисленный результат оказался примерно меньше 1, но поскольку он округляется вверх, в итоге получается 1, то есть хакеру нужно добавить всего 1 токен, чтобы обменять на огромную ликвидность.
③Вывод ликвидности
Произведите погашение кредитов на молниеносной основе, сохраняя огромные прибыли. В конечном итоге из нескольких ликвидных пулов извлеките токеновые активы на общую сумму в несколько сотен миллионов долларов.
Ситуация с потерей средств серьезная, атака привела к краже следующих активов:
12,9 миллиона SUI (около 54 миллионов долларов США)
6000 миллионов долларов USDC
490 долларов США Haedal Staked SUI
$19,5 млн ТУАЛЕТ
Другие токены, такие как HIPPO и LOFI, упали на 75--80%, ликвидность иссякла
2.2 Причины и особенности данного уязвимости
У уязвимости Cetus три характеристики:
Стоимость исправления крайне низка: с одной стороны, основная причина инцидента с Cetus заключается в ошибке в математической библиотеке Cetus, а не в ошибке ценового механизма протокола или ошибки в базовой архитектуре. С другой стороны, уязвимость ограничивается только самим Cetus и не имеет отношения к коду SUI. Корень уязвимости заключается в одном условии границы, которое можно полностью устранить, изменив всего две строки кода; после завершения исправления его можно немедленно развернуть в основной сети, чтобы гарантировать, что логика последующих контрактов будет полной и исключить эту уязвимость.
Высокая степень скрытности: контракт работает стабильно без сбоев в течение двух лет, прошел множество аудитов, но уязвимости не были обнаружены, основная причина заключается в том, что библиотека Integer_Mate, используемая для математических расчетов, не была включена в область аудита.
Хакеры используют экстремальные значения для точного построения торговых диапазонов, создавая редкие ситуации с подачей крайне высокой ликвидности, что и вызывает аномальную логику, указывая на то, что подобные проблемы трудно выявить обычным тестированием. Эти проблемы часто находятся в слепой зоне человеческого восприятия, поэтому они остаются незамеченными длительное время.
Не только проблема Move:
Move превосходит многие языки смарт-контрактов в вопросах безопасности ресурсов и проверки типов, встроенная нативная проверка на проблемы с переполнением целых чисел в распространенных ситуациях. Это переполнение произошло из-за того, что при добавлении ликвидности для расчета необходимого количества токенов сначала использовалось неправильное значение для проверки верхнего предела, и замены обычного умножения на побитовые операции. В то время как при обычных арифметических операциях сложения, вычитания, умножения и деления в Move автоматически проверяется переполнение, что предотвращает такие проблемы с отсечением старших разрядов.
Подобные уязвимости также встречались в других языках (например, Solidity, Rust), и даже из-за отсутствия защиты от переполнения целых чисел они легче поддаются эксплуатации; до обновления версии Solidity проверка на переполнение была очень слабой. В истории имели место случаи переполнения при сложении, вычитании, умножении и т.д., непосредственной причиной которых является то, что результат вычислений выходил за пределы диапазона. Например, уязвимости в смарт-контрактах BEC и SMT на языке Solidity были использованы для атаки через превышение перевода, обходя операторы проверки в контракте с помощью тщательно подобранных параметров.
3. Консенсусный механизм SUI
3.1 Введение в механизм консенсуса SUI
Обзор:
SUI использует механизм делегированного доказательства доли (DeleGated Proof of Stake, сокращенно DPoS)). Хотя механизм DPoS может повысить пропускную способность транзакций, он не может обеспечить такой же высокий уровень децентрализации, как PoW (доказательство работы). Поэтому уровень децентрализации SUI относительно низок, а порог для управления сравнительно высок, обычные пользователи едва ли могут напрямую влиять на управление сетью.
Среднее количество валидаторов: 106
Средний период Epoch: 24 часа
Механизм процесса:
Делегирование прав: обычным пользователям не нужно самостоятельно запускать узлы, достаточно заложить SUI и委托给候选ным валидаторам, чтобы участвовать в обеспечении безопасности сети и распределении вознаграждений. Этот механизм может снизить порог участия для обычных пользователей, позволяя им участвовать в консенсусе сети, "нанимая" доверенных валидаторов. Это также является одним из основных преимуществ DPoS по сравнению с традиционным PoS.
Представляет собой раунд выпуска блока: небольшое количество выбранных валидаторов выпускает блоки в фиксированном или случайном порядке, что повышает скорость подтверждения и увеличивает TPS.
Динамические выборы: по окончании каждого периода голосования, на основе веса голосов, происходит динамическая ротация и повторные выборы набора валидаторов, чтобы обеспечить активность узлов, согласованность интересов и децентрализацию.
Преимущества DPoS:
Высокая эффективность: благодаря контролируемому количеству узлов, сеть может завершать подтверждение за миллисекунды, удовлетворяя потребности в высоком TPS.
Низкие затраты: меньше узлов участвуют в консенсусе, что значительно снижает необходимую сетевую пропускную способность и вычислительные ресурсы для синхронизации информации и агрегации подписей. В результате снижаются затраты на оборудование и эксплуатацию, требования к вычислительной мощности уменьшаются, что приводит к более низким расходам. В конечном итоге это приводит к снижению сборов для пользователей.
Высокая безопасность: механизмы стейкинга и делегирования синхронизируют увеличение стоимости и риска атак; в сочетании с механизмом конфискации на цепочке эффективно сдерживают злонамеренные действия.
В то же время, в механизме консенсуса SUI используется алгоритм на основе BFT (байесовская ошибка), который требует, чтобы более двух третей голосов среди валидаторов согласились для подтверждения транзакции. Этот механизм обеспечивает безопасность и эффективную работу сети, даже если небольшое количество узлов ведет себя неправомерно. Для любых обновлений или важных решений также требуется более двух третей голосов для их реализации.
Суть заключается в том, что DPoS на самом деле является компромиссным решением для невозможного треугольника, осуществляя компромисс между децентрализацией и эффективностью. DPoS в "невозможном треугольнике" безопасности-децентрализации-масштабируемости выбирает уменьшение количества активных узлов, создающих блоки, в обмен на более высокую производительность, отказываясь от определенной степени полной децентрализации по сравнению с чистым PoS или PoW, но значительно повышая пропускную способность сети и скорость транзакций.
3.2 В ходе этой атаки SUI показал себя
3.2.1 Механизм заморозки
В этом инциденте SUI быстро заморозил адреса, связанные с атакующим.
С точки зрения кода, это делает невозможным упаковку транзакций перевода в блокчейн. Узлы проверки являются ключевыми компонентами блокчейна SUI, отвечающими за проверку транзакций и выполнение правил протокола. Игнорируя транзакции, связанные с атакующими, эти валидаторы фактически внедряют на уровне консенсуса механизм, аналогичный 'заморозке счета' в традиционных финансах.
SUI сам имеет встроенный механизм списка отказов (deny list), это функция черного списка, которая может блокировать любые транзакции, связанные с перечисленными адресами. Поскольку эта функция уже существует в клиенте, когда происходит атака
SUI может немедленно заморозить адреса хакеров. Если этой функции нет, даже если у SUI только 113 валидаторов, будет сложно в короткие сроки скоординировать всех валидаторов, чтобы они ответили один за другим.
3.2.2 Кто имеет право изменять черный список?
TransactionDenyConfig — это YAML/TOML файл конфигурации, который загружается локально каждым валидатором. Любой, кто управляет узлом, может редактировать этот файл, выполнять горячую перезагрузку или перезапуск узла и обновлять список. На первый взгляд, каждый валидатор, кажется, свободно выражает свои ценности.
На самом деле, для обеспечения согласованности и эффективности стратегий безопасности обновления этой ключевой конфигурации обычно координируются. Поскольку это "срочное обновление, инициированное командой", в основном фонд (или его уполномоченные разработчики) устанавливает и обновляет этот список отказов.
Публикация черного списка, теоретически валидаторы могут выбирать, использовать его или нет------но на практике большинство людей по умолчанию будут автоматически использовать его. Таким образом, хотя эта функция защищает средства пользователей, по своей сути она действительно имеет определенную степень централизации.
3.2.3 Суть функции черного списка
Функция черного списка на самом деле не является логикой на уровне протокола, она больше похожа на дополнительную меру безопасности, предназначенную для реагирования на непредвиденные ситуации и обеспечения безопасности средств пользователей.
По сути, это механизм обеспечения безопасности. Похоже на "защитную цепь", привязанную к двери, которая активируется только для тех, кто хочет проникнуть в дом, то есть для тех, кто намерен нарушить протокол. Для пользователя:
Для крупных игроков, основных поставщиков ликвидности, протоколы в первую очередь стремятся обеспечить безопасность средств, так как на самом деле данные о TVL в блокчейне полностью предоставлены основными крупными игроками. Для долгосрочного развития протокола необходимо в первую очередь гарантировать безопасность.
Для розничных инвесторов, активных участников экосистемы, сильных сторонников совместного строительства технологий и сообщества. Проектная команда также надеется привлечь розничных инвесторов к совместному строительству, чтобы постепенно улучшить экосистему и повысить уровень удержания. А для области defi, самое важное
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
14 Лайков
Награда
14
4
Поделиться
комментарий
0/400
LiquidityOracle
· 12ч назад
падение... когда это закончится?
Посмотреть ОригиналОтветить0
SatoshiNotNakamoto
· 08-04 12:21
Сильный и уверенный в себе
Посмотреть ОригиналОтветить0
PuzzledScholar
· 08-04 12:14
Не волнуйтесь, это называется ликвидация шортов с ростом.
Экологическая устойчивость SUI: анализ инцидента с атакой Cetus и обсуждение потенциала будущего развития
Твердая вера после кризиса безопасности: почему SUI все еще обладает потенциалом для долгосрочного роста?
1.Цепная реакция, вызванная одной атакой
22 мая 2025 года ведущий AMM-протокол Cetus, развернутый на сети SUI, подвергся хакерской атаке. Злоумышленники использовали логическую уязвимость, связанную с "проблемой переполнения целого числа", для проведения точного манипулирования, что привело к потерям более 200 миллионов долларов активов. Этот инцидент стал не только одной из крупнейших по масштабу безопасностных аварий в области DeFi на сегодняшний день, но и самой разрушительной хакерской атакой с момента запуска основной сети SUI.
Согласно данным, TVL всей цепочки SUI в день атаки в одночасье упала более чем на 330 миллионов долларов, а сумма, заблокированная в协议 Cetus, мгновенно испарилась на 84%, упав до 38 миллионов долларов. Под воздействием этого, несколько популярных токенов на SUI упали на 76% до 97% всего за час, что вызвало широкий интерес к безопасности SUI и стабильности его экосистемы.
Но после этой волны ударов экосистема SUI продемонстрировала мощную устойчивость и способность к восстановлению. Несмотря на то, что событие Cetus краткосрочно вызвало колебания доверия, средства на блокчейне и активность пользователей не столкнулись с длительным спадом, а наоборот, способствовали значительному повышению внимания всей экосистемы к безопасности, строительству инфраструктуры и качеству проектов.
В данной статье будут рассмотрены причины данного инцидента, механизмы консенсуса узлов SUI, безопасность языка MOVE и развитие экосистемы SUI, а также проанализирована текущая экосистема этой публичной цепочки, находящейся на ранних стадиях развития, и обсуждены её будущие перспективы.
2. Анализ причин атаки на событие Cetus
2.1 Процесс реализации атаки
Согласно техническому анализу инцидента атаки на Cetus, проведённому командой безопасности, хакеры успешно использовали уязвимость ключевого арифметического переполнения в протоколе, воспользовавшись flash-кредитами, точным манипулированием ценами и недостатками контракта, за короткое время похитив более 200 миллионов долларов цифровых активов. Путь атаки можно условно разделить на три этапа:
①Инициировать мгновенный заем, манипулировать ценами
Хакеры сначала использовали максимальный проскальзывание, чтобы мгновенно обменять 10 миллиардов haSUI с помощью кредитов под залог, заимствуя огромные суммы денег для манипуляции ценами.
Доступ к займу на мгновенной основе позволяет пользователям заимствовать и возвращать средства в рамках одной сделки, оплачивая только комиссию, обладая характеристиками высокого плеча, низкого риска и низких затрат. Хакеры использовали этот механизм, чтобы в короткие сроки снизить рыночную цену и точно контролировать её в очень узком диапазоне.
Затем злоумышленник готовится создать крайне узкую ликвидную позицию, точно установив ценовой диапазон между самой низкой ценой 300,000 и самой высокой ценой 300,200, ширина которой составляет всего 1.00496621%.
Таким образом, хакеры с помощью достаточного количества токенов и огромной ликвидности успешно манипулировали ценой haSUI. Затем они снова начали манипулировать несколькими токенами без реальной ценности.
②Добавить ликвидность
Атакующий создает узкие позиции ликвидности, заявляя о добавлении ликвидности, но из-за уязвимости функции checked_shlw в конечном итоге получает только 1 токен.
В сущности, это связано с двумя причинами:
1.Широкие настройки маски: эквивалентны огромному лимиту добавления ликвидности, что приводит к тому, что проверка пользовательского ввода в контракте становится формальностью. Хакеры, установив аномальные параметры, создают ввод, который всегда меньше этого лимита, тем самым обходя проверку на переполнение.
③Вывод ликвидности
Произведите погашение кредитов на молниеносной основе, сохраняя огромные прибыли. В конечном итоге из нескольких ликвидных пулов извлеките токеновые активы на общую сумму в несколько сотен миллионов долларов.
Ситуация с потерей средств серьезная, атака привела к краже следующих активов:
12,9 миллиона SUI (около 54 миллионов долларов США)
6000 миллионов долларов USDC
490 долларов США Haedal Staked SUI
$19,5 млн ТУАЛЕТ
Другие токены, такие как HIPPO и LOFI, упали на 75--80%, ликвидность иссякла
2.2 Причины и особенности данного уязвимости
У уязвимости Cetus три характеристики:
Стоимость исправления крайне низка: с одной стороны, основная причина инцидента с Cetus заключается в ошибке в математической библиотеке Cetus, а не в ошибке ценового механизма протокола или ошибки в базовой архитектуре. С другой стороны, уязвимость ограничивается только самим Cetus и не имеет отношения к коду SUI. Корень уязвимости заключается в одном условии границы, которое можно полностью устранить, изменив всего две строки кода; после завершения исправления его можно немедленно развернуть в основной сети, чтобы гарантировать, что логика последующих контрактов будет полной и исключить эту уязвимость.
Высокая степень скрытности: контракт работает стабильно без сбоев в течение двух лет, прошел множество аудитов, но уязвимости не были обнаружены, основная причина заключается в том, что библиотека Integer_Mate, используемая для математических расчетов, не была включена в область аудита.
Хакеры используют экстремальные значения для точного построения торговых диапазонов, создавая редкие ситуации с подачей крайне высокой ликвидности, что и вызывает аномальную логику, указывая на то, что подобные проблемы трудно выявить обычным тестированием. Эти проблемы часто находятся в слепой зоне человеческого восприятия, поэтому они остаются незамеченными длительное время.
Move превосходит многие языки смарт-контрактов в вопросах безопасности ресурсов и проверки типов, встроенная нативная проверка на проблемы с переполнением целых чисел в распространенных ситуациях. Это переполнение произошло из-за того, что при добавлении ликвидности для расчета необходимого количества токенов сначала использовалось неправильное значение для проверки верхнего предела, и замены обычного умножения на побитовые операции. В то время как при обычных арифметических операциях сложения, вычитания, умножения и деления в Move автоматически проверяется переполнение, что предотвращает такие проблемы с отсечением старших разрядов.
Подобные уязвимости также встречались в других языках (например, Solidity, Rust), и даже из-за отсутствия защиты от переполнения целых чисел они легче поддаются эксплуатации; до обновления версии Solidity проверка на переполнение была очень слабой. В истории имели место случаи переполнения при сложении, вычитании, умножении и т.д., непосредственной причиной которых является то, что результат вычислений выходил за пределы диапазона. Например, уязвимости в смарт-контрактах BEC и SMT на языке Solidity были использованы для атаки через превышение перевода, обходя операторы проверки в контракте с помощью тщательно подобранных параметров.
3. Консенсусный механизм SUI
3.1 Введение в механизм консенсуса SUI
Обзор:
SUI использует механизм делегированного доказательства доли (DeleGated Proof of Stake, сокращенно DPoS)). Хотя механизм DPoS может повысить пропускную способность транзакций, он не может обеспечить такой же высокий уровень децентрализации, как PoW (доказательство работы). Поэтому уровень децентрализации SUI относительно низок, а порог для управления сравнительно высок, обычные пользователи едва ли могут напрямую влиять на управление сетью.
Среднее количество валидаторов: 106
Средний период Epoch: 24 часа
Механизм процесса:
Делегирование прав: обычным пользователям не нужно самостоятельно запускать узлы, достаточно заложить SUI и委托给候选ным валидаторам, чтобы участвовать в обеспечении безопасности сети и распределении вознаграждений. Этот механизм может снизить порог участия для обычных пользователей, позволяя им участвовать в консенсусе сети, "нанимая" доверенных валидаторов. Это также является одним из основных преимуществ DPoS по сравнению с традиционным PoS.
Представляет собой раунд выпуска блока: небольшое количество выбранных валидаторов выпускает блоки в фиксированном или случайном порядке, что повышает скорость подтверждения и увеличивает TPS.
Динамические выборы: по окончании каждого периода голосования, на основе веса голосов, происходит динамическая ротация и повторные выборы набора валидаторов, чтобы обеспечить активность узлов, согласованность интересов и децентрализацию.
Преимущества DPoS:
Высокая эффективность: благодаря контролируемому количеству узлов, сеть может завершать подтверждение за миллисекунды, удовлетворяя потребности в высоком TPS.
Низкие затраты: меньше узлов участвуют в консенсусе, что значительно снижает необходимую сетевую пропускную способность и вычислительные ресурсы для синхронизации информации и агрегации подписей. В результате снижаются затраты на оборудование и эксплуатацию, требования к вычислительной мощности уменьшаются, что приводит к более низким расходам. В конечном итоге это приводит к снижению сборов для пользователей.
Высокая безопасность: механизмы стейкинга и делегирования синхронизируют увеличение стоимости и риска атак; в сочетании с механизмом конфискации на цепочке эффективно сдерживают злонамеренные действия.
В то же время, в механизме консенсуса SUI используется алгоритм на основе BFT (байесовская ошибка), который требует, чтобы более двух третей голосов среди валидаторов согласились для подтверждения транзакции. Этот механизм обеспечивает безопасность и эффективную работу сети, даже если небольшое количество узлов ведет себя неправомерно. Для любых обновлений или важных решений также требуется более двух третей голосов для их реализации.
Суть заключается в том, что DPoS на самом деле является компромиссным решением для невозможного треугольника, осуществляя компромисс между децентрализацией и эффективностью. DPoS в "невозможном треугольнике" безопасности-децентрализации-масштабируемости выбирает уменьшение количества активных узлов, создающих блоки, в обмен на более высокую производительность, отказываясь от определенной степени полной децентрализации по сравнению с чистым PoS или PoW, но значительно повышая пропускную способность сети и скорость транзакций.
3.2 В ходе этой атаки SUI показал себя
3.2.1 Механизм заморозки
В этом инциденте SUI быстро заморозил адреса, связанные с атакующим.
С точки зрения кода, это делает невозможным упаковку транзакций перевода в блокчейн. Узлы проверки являются ключевыми компонентами блокчейна SUI, отвечающими за проверку транзакций и выполнение правил протокола. Игнорируя транзакции, связанные с атакующими, эти валидаторы фактически внедряют на уровне консенсуса механизм, аналогичный 'заморозке счета' в традиционных финансах.
SUI сам имеет встроенный механизм списка отказов (deny list), это функция черного списка, которая может блокировать любые транзакции, связанные с перечисленными адресами. Поскольку эта функция уже существует в клиенте, когда происходит атака
SUI может немедленно заморозить адреса хакеров. Если этой функции нет, даже если у SUI только 113 валидаторов, будет сложно в короткие сроки скоординировать всех валидаторов, чтобы они ответили один за другим.
3.2.2 Кто имеет право изменять черный список?
TransactionDenyConfig — это YAML/TOML файл конфигурации, который загружается локально каждым валидатором. Любой, кто управляет узлом, может редактировать этот файл, выполнять горячую перезагрузку или перезапуск узла и обновлять список. На первый взгляд, каждый валидатор, кажется, свободно выражает свои ценности.
На самом деле, для обеспечения согласованности и эффективности стратегий безопасности обновления этой ключевой конфигурации обычно координируются. Поскольку это "срочное обновление, инициированное командой", в основном фонд (или его уполномоченные разработчики) устанавливает и обновляет этот список отказов.
Публикация черного списка, теоретически валидаторы могут выбирать, использовать его или нет------но на практике большинство людей по умолчанию будут автоматически использовать его. Таким образом, хотя эта функция защищает средства пользователей, по своей сути она действительно имеет определенную степень централизации.
3.2.3 Суть функции черного списка
Функция черного списка на самом деле не является логикой на уровне протокола, она больше похожа на дополнительную меру безопасности, предназначенную для реагирования на непредвиденные ситуации и обеспечения безопасности средств пользователей.
По сути, это механизм обеспечения безопасности. Похоже на "защитную цепь", привязанную к двери, которая активируется только для тех, кто хочет проникнуть в дом, то есть для тех, кто намерен нарушить протокол. Для пользователя:
Для крупных игроков, основных поставщиков ликвидности, протоколы в первую очередь стремятся обеспечить безопасность средств, так как на самом деле данные о TVL в блокчейне полностью предоставлены основными крупными игроками. Для долгосрочного развития протокола необходимо в первую очередь гарантировать безопасность.
Для розничных инвесторов, активных участников экосистемы, сильных сторонников совместного строительства технологий и сообщества. Проектная команда также надеется привлечь розничных инвесторов к совместному строительству, чтобы постепенно улучшить экосистему и повысить уровень удержания. А для области defi, самое важное