Уверенная вера после кризиса безопасности: почему SUI по-прежнему обладает потенциалом для долгосрочного роста?
1.Цепная реакция, вызванная одной атакой
22 мая 2025 года ведущий AMM-протокол Cetus, развернутый в сети SUI, стал жертвой хакерской атаки. Нападающий использовал логическую уязвимость, связанную с "проблемой переполнения целого числа", чтобы провести точное манипулирование, что привело к потере активов на сумму более 200 миллионов долларов. Этот инцидент не только является одной из крупнейших по масштабам инцидентов безопасности в области DeFi на данный момент в этом году, но также стал самой разрушительной хакерской атакой с момента запуска основной сети SUI.
Согласно данным, TVL всей цепи SUI в день атаки в одночасье упал более чем на 330 миллионов долларов, а сумма заблокированных средств самого протокола Cetus瞬间 испарилась на 84%, упав до 38 миллионов долларов. В результате этого, несколько популярных токенов на SUI (включая Lofi, Sudeng, Squirtle и другие) за короткий период времени упали на 76% до 97%, что вызвало широкое внимание к безопасности SUI и стабильности экосистемы.
Но после этой волны потрясений экосистема SUI продемонстрировала выдающуюся устойчивость и способность к восстановлению. Несмотря на то, что событие Cetus привело к колебаниям доверия в краткосрочной перспективе, средства и активность пользователей на блокчейне не столкнулись с продолжительным спадом, а наоборот, способствовали значительному повышению внимания всей экосистемы к безопасности, строительству инфраструктуры и качеству проектов.
Мы рассмотрим причины данного инцидента, механизм консенсуса узлов SUI, безопасность языка MOVE и развитие экосистемы SUI, проанализируем текущую экосистему этой публичной цепочки, находящейся на ранней стадии развития, и обсудим её потенциал для будущего развития.
2. Анализ причин атаки на событие Cetus
2.1 Процесс реализации атаки
Согласно техническому анализу инцидента с атакой на Cetus, хакеры успешно использовали уязвимость критического арифметического переполнения в протоколе, воспользовавшись флеш-кредитами, точным манипулированием ценами и недостатками контракта, за короткое время похитив более 200 миллионов долларов цифровых активов. Атакующий путь можно условно разделить на три этапа:
Хакеры сначала использовали максимальный проскальзывание, чтобы мгновенно обменять 10 миллиардов haSUI через кредитование, занимая большие суммы денег для манипуляции ценами.
Мгновенные кредиты позволяют пользователям занимать и возвращать средства в рамках одной сделки, оплачивая только комиссию, обладая характеристиками высокого плеча, низкого риска и низкой стоимости. Хакеры использовали этот механизм, чтобы в короткий срок снизить рыночную цену и точно контролировать её в очень узком диапазоне.
Затем злоумышленник готовится создать крайне узкую ликвидную позицию, точно установив ценовой диапазон между минимальной ценой 300,000 и максимальной ценой 300,200, ширина цены составит всего 1.00496621%.
Таким образом, хакеры, используя достаточное количество токенов и огромную ликвидность, успешно манипулировали ценой haSUI. Затем они также манипулировали несколькими токенами без реальной ценности.
②Добавить ликвидность
Атакующий создает узкие позиции ликвидности, заявляя о добавлении ликвидности, но из-за уязвимости функции checked_shlw в конечном итоге получает только 1 токен.
В основном это связано с двумя причинами:
Широкая настройка маски: эквивалентно огромному лимиту добавления ликвидности, что приводит к тому, что проверка пользовательского ввода в контракте становится бессмысленной. Хакеры, устанавливая аномальные параметры, создают ввод, который всегда меньше этого лимита, тем самым обходя проверку на переполнение.
2.Переполнение данных было обрезано: при выполнении операции сдвига n << 64 для числового значения n, из-за того что сдвиг превышает эффективную ширину бит uint256 (256 бит), произошло обрезание данных. Высокие биты переполнения были автоматически отброшены, что привело к тому, что результат вычисления оказался значительно ниже ожидаемого, что заставило систему недооценить количество haSUI, необходимое для обмена. В конечном итоге вычисленный результат оказался примерно меньше 1, но из-за округления вверх он в итоге оказался равным 1, то есть хакеру нужно было добавить всего 1 токен, чтобы получить огромную ликвидность.
③Вывод ликвидности
Произведите погашение Flash Loan, сохраняя значительную прибыль. В конечном итоге выведите токеновые активы общей стоимостью в несколько сотен миллионов долларов из нескольких пулов ликвидности.
Ситуация с потерей средств серьезная, атака привела к краже следующих активов:
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 конфигурационный файл, который загружается локально каждым валидатором. Любой, кто управляет узлом, может редактировать этот файл, выполнять горячую перезагрузку или перезапуск узла и обновлять список. На первый взгляд, каждый валидатор, похоже, свободно выражает свои ценности.
На самом деле, для обеспечения согласованности и эффективности политики безопасности обновления такой ключевой конфигурации обычно являются координированными. Поскольку это "принудительное срочное обновление", по сути, Фонд (или его уполномоченные разработчики) устанавливает и обновляет этот список отказов.
SUI выпустил черный список, теоретически валидаторы могут выбрать, использовать его или нет ------ но на практике большинство людей по умолчанию будут автоматически его использовать. Таким образом, хотя эта функция защищает средства пользователей, по своей сути она действительно имеет определенную степень централизации.
3.2.3 Суть функции черного списка
Функция черного списка на самом деле не является логикой базового протокола, она скорее предназначена для реагирования на непредвиденные ситуации, обеспечивая дополнительную безопасность для защиты средств пользователей.
В сущности это механизм обеспечения безопасности. Это похоже на "противоугонную цепь", прикрепленную к двери, которая активируется только для тех, кто пытается проникнуть в дом, то есть для тех, кто злоупотребляет протоколом. Для пользователя:
Для крупных участников, основных поставщиков ликвидности, протоколы стремятся обеспечить безопасность средств, так как на самом деле данные о TVL в блокчейне в основном предоставлены крупными участниками. Чтобы протокол мог развиваться в долгосрочной перспективе, безопасность обязательно будет иметь приоритет.
Для розничных инвесторов, активных участников экосистемы, сильных сторонников совместного строительства технологий и сообщества. Проектная команда также надеется привлечь розничных инвесторов к совместному строительству, чтобы постепенно улучшить экосистему и усилить удержание.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
15 Лайков
Награда
15
7
Поделиться
комментарий
0/400
CodeZeroBasis
· 17ч назад
Этот баг меня пугает.
Посмотреть ОригиналОтветить0
MoonMathMagic
· 17ч назад
Ладно, если потерять, так потерять. Кто не терял деньги?
Посмотреть ОригиналОтветить0
MeltdownSurvivalist
· 17ч назад
Снова хакерское событие, и такое масштабное!
Посмотреть ОригиналОтветить0
BearMarketBro
· 17ч назад
Это всего лишь пустая слава, такие уязвимости тоже могут появляться.
Экосистема SUI демонстрирует стойкость: безопасность после атаки Cetus и перспективы развития
Уверенная вера после кризиса безопасности: почему SUI по-прежнему обладает потенциалом для долгосрочного роста?
1.Цепная реакция, вызванная одной атакой
22 мая 2025 года ведущий AMM-протокол Cetus, развернутый в сети SUI, стал жертвой хакерской атаки. Нападающий использовал логическую уязвимость, связанную с "проблемой переполнения целого числа", чтобы провести точное манипулирование, что привело к потере активов на сумму более 200 миллионов долларов. Этот инцидент не только является одной из крупнейших по масштабам инцидентов безопасности в области DeFi на данный момент в этом году, но также стал самой разрушительной хакерской атакой с момента запуска основной сети SUI.
Согласно данным, TVL всей цепи SUI в день атаки в одночасье упал более чем на 330 миллионов долларов, а сумма заблокированных средств самого протокола Cetus瞬间 испарилась на 84%, упав до 38 миллионов долларов. В результате этого, несколько популярных токенов на SUI (включая Lofi, Sudeng, Squirtle и другие) за короткий период времени упали на 76% до 97%, что вызвало широкое внимание к безопасности SUI и стабильности экосистемы.
Но после этой волны потрясений экосистема SUI продемонстрировала выдающуюся устойчивость и способность к восстановлению. Несмотря на то, что событие Cetus привело к колебаниям доверия в краткосрочной перспективе, средства и активность пользователей на блокчейне не столкнулись с продолжительным спадом, а наоборот, способствовали значительному повышению внимания всей экосистемы к безопасности, строительству инфраструктуры и качеству проектов.
Мы рассмотрим причины данного инцидента, механизм консенсуса узлов SUI, безопасность языка MOVE и развитие экосистемы SUI, проанализируем текущую экосистему этой публичной цепочки, находящейся на ранней стадии развития, и обсудим её потенциал для будущего развития.
2. Анализ причин атаки на событие Cetus
2.1 Процесс реализации атаки
Согласно техническому анализу инцидента с атакой на Cetus, хакеры успешно использовали уязвимость критического арифметического переполнения в протоколе, воспользовавшись флеш-кредитами, точным манипулированием ценами и недостатками контракта, за короткое время похитив более 200 миллионов долларов цифровых активов. Атакующий путь можно условно разделить на три этапа:
①Инициировать молниеносный кредит, манипулировать ценой
Хакеры сначала использовали максимальный проскальзывание, чтобы мгновенно обменять 10 миллиардов haSUI через кредитование, занимая большие суммы денег для манипуляции ценами.
Мгновенные кредиты позволяют пользователям занимать и возвращать средства в рамках одной сделки, оплачивая только комиссию, обладая характеристиками высокого плеча, низкого риска и низкой стоимости. Хакеры использовали этот механизм, чтобы в короткий срок снизить рыночную цену и точно контролировать её в очень узком диапазоне.
Затем злоумышленник готовится создать крайне узкую ликвидную позицию, точно установив ценовой диапазон между минимальной ценой 300,000 и максимальной ценой 300,200, ширина цены составит всего 1.00496621%.
Таким образом, хакеры, используя достаточное количество токенов и огромную ликвидность, успешно манипулировали ценой haSUI. Затем они также манипулировали несколькими токенами без реальной ценности.
②Добавить ликвидность
Атакующий создает узкие позиции ликвидности, заявляя о добавлении ликвидности, но из-за уязвимости функции checked_shlw в конечном итоге получает только 1 токен.
В основном это связано с двумя причинами:
2.Переполнение данных было обрезано: при выполнении операции сдвига n << 64 для числового значения n, из-за того что сдвиг превышает эффективную ширину бит uint256 (256 бит), произошло обрезание данных. Высокие биты переполнения были автоматически отброшены, что привело к тому, что результат вычисления оказался значительно ниже ожидаемого, что заставило систему недооценить количество haSUI, необходимое для обмена. В конечном итоге вычисленный результат оказался примерно меньше 1, но из-за округления вверх он в итоге оказался равным 1, то есть хакеру нужно было добавить всего 1 токен, чтобы получить огромную ликвидность.
③Вывод ликвидности
Произведите погашение Flash Loan, сохраняя значительную прибыль. В конечном итоге выведите токеновые активы общей стоимостью в несколько сотен миллионов долларов из нескольких пулов ликвидности.
Ситуация с потерей средств серьезная, атака привела к краже следующих активов:
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 конфигурационный файл, который загружается локально каждым валидатором. Любой, кто управляет узлом, может редактировать этот файл, выполнять горячую перезагрузку или перезапуск узла и обновлять список. На первый взгляд, каждый валидатор, похоже, свободно выражает свои ценности.
На самом деле, для обеспечения согласованности и эффективности политики безопасности обновления такой ключевой конфигурации обычно являются координированными. Поскольку это "принудительное срочное обновление", по сути, Фонд (или его уполномоченные разработчики) устанавливает и обновляет этот список отказов.
SUI выпустил черный список, теоретически валидаторы могут выбрать, использовать его или нет ------ но на практике большинство людей по умолчанию будут автоматически его использовать. Таким образом, хотя эта функция защищает средства пользователей, по своей сути она действительно имеет определенную степень централизации.
3.2.3 Суть функции черного списка
Функция черного списка на самом деле не является логикой базового протокола, она скорее предназначена для реагирования на непредвиденные ситуации, обеспечивая дополнительную безопасность для защиты средств пользователей.
В сущности это механизм обеспечения безопасности. Это похоже на "противоугонную цепь", прикрепленную к двери, которая активируется только для тех, кто пытается проникнуть в дом, то есть для тех, кто злоупотребляет протоколом. Для пользователя:
Для крупных участников, основных поставщиков ликвидности, протоколы стремятся обеспечить безопасность средств, так как на самом деле данные о TVL в блокчейне в основном предоставлены крупными участниками. Чтобы протокол мог развиваться в долгосрочной перспективе, безопасность обязательно будет иметь приоритет.
Для розничных инвесторов, активных участников экосистемы, сильных сторонников совместного строительства технологий и сообщества. Проектная команда также надеется привлечь розничных инвесторов к совместному строительству, чтобы постепенно улучшить экосистему и усилить удержание.