Твердая вера после кризиса безопасности: почему SUI по-прежнему обладает потенциалом для долгосрочного роста?
1. Цепная реакция, вызванная одной атакой
22 мая 2025 года ведущий AMM-протокол Cetus, развернутый в сети SUI, подвергся хакерской атаке. Злоумышленник использовал логическую уязвимость, связанную с "переполнением целого числа", чтобы провести точную манипуляцию, что привело к потере более 200 миллионов долларов активов. Это событие стало одной из крупнейших по масштабу аварий безопасности в области DeFi на сегодняшний день, а также самой разрушительной хакерской атакой с момента запуска основной сети SUI.
Согласно данным DefiLlama, TVL всей цепи SUI в день атаки в один момент упала более чем на 330 миллионов долларов, а сумма заблокированных средств самого протокола Cetus моментально испарилась на 84%, упав до 38 миллионов долларов. В результате, несколько популярных токенов на SUI упали на 76% до 97% всего за один час, что вызвало широкий интерес к безопасности SUI и стабильности экосистемы.
Но после этой волны потрясений экосистема SUI продемонстрировала сильную устойчивость и восстановительные способности. Несмотря на то, что событие Cetus краткосрочно вызвало колебания уверенности, средства на блокчейне и активность пользователей не столкнулись с длительным спадом, а наоборот, способствовали значительному повышению внимания всей экосистемы к безопасности, строительству инфраструктуры и качеству проектов.
Klein Labs будет рассматривать причины этого инцидента, механизм консенсуса узлов SUI, безопасность языка MOVE и развитие экосистемы SUI, анализируя текущую экосистему этой публичной цепочки, которая все еще находится на ранней стадии развития, и обсуждая ее потенциальное будущее развитие.
2. Анализ причин атаки на событие Cetus
2.1 Процесс реализации атаки
Согласно техническому анализу команды Slow Mist по инциденту с атакой на Cetus, хакеры успешно воспользовались ключевым арифметическим переполнением в протоколе, используя флеш-займы, точную манипуляцию ценами и недостатки контракта, за короткое время похитив более 200 миллионов долларов цифровых активов. Атакующий путь можно условно разделить на три этапа:
①Запускать闪电贷, манипулировать ценами
Хакеры сначала использовали максимальный проскальзывание для молниеносного обмена 100 миллиардов haSUI, взяв крупные суммы в займы для манипуляции ценами.
Мгновенные займы позволяют пользователям занимать и возвращать средства в рамках одной сделки, выплачивая только комиссию, обладая высокими плечами, низкими рисками и низкими затратами. Хакеры использовали этот механизм, чтобы в короткие сроки снизить рыночную цену и точно контролировать её в очень узком диапазоне.
Затем злоумышленник готовится создать крайне узкую позицию ликвидности, точно установив ценовой диапазон между минимальной ценой 300,000 и максимальной ценой 300,200, ширина ценового диапазона составляет всего 1.00496621%.
Таким образом, хакеры использовали достаточное количество токенов и огромную ликвидность, чтобы успешно манипулировать ценой haSUI. Затем они также начали манипулировать несколькими токенами, у которых нет реальной ценности.
②Добавить ликвидность
Атакующий создает узкие позиции ликвидности, заявляя о добавлении ликвидности, но из-за уязвимости функции checked_shlw в конечном итоге получает только 1 токен.
По сути, это связано с двумя причинами:
Широкая настройка маски: эквивалентно огромному лимиту добавления ликвидности, что делает проверку пользовательского ввода в контракте бессмысленной. Хакеры, устанавливая аномальные параметры, создают ввод, который всегда меньше этого лимита, тем самым обходя проверку переполнения.
2.Переполнение данных было усечено: при выполнении операции сдвига n << 64 над числом n, из-за превышения допустимой ширины бит (256 бит) типа данных uint256 произошло усечение данных. Часть высоких битов была автоматически отброшена, что привело к результату вычисления, значительно ниже ожидаемого, и в результате система недооценила количество haSUI, необходимое для обмена. В конечном итоге вычисленный результат оказался примерно меньше 1, но так как округление производилось в большую сторону, в итоге получилось равным 1, то есть хакеру достаточно было добавить 1 токен, чтобы получить огромную ликвидность.
③Вывод ликвидности
Провести погашение займов, сохраняя огромную прибыль. В конечном итоге из нескольких ликвидных пулов вывести токеновые активы общей стоимостью в несколько сотен миллионов долларов.
Ситуация с потерей средств серьезная, атака привела к краже следующих активов:
12,9 млн SUI (примерно $54 млн)
6000 миллионов долларов США USDC
4900000 долларов США Haedal Staked SUI
$19,5 млн ТУАЛЕТ
Другие токены, такие как HIPPO и LOFI, упали на 75--80%, ликвидность иссякла
2.2 Причины и особенности этой уязвимости
У этой уязвимости Cetus три особенности:
Очень низкие затраты на исправление: с одной стороны, коренная причина инцидента с Cetus заключается в недочете в математической библиотеке Cetus, а не в ошибках ценового механизма протокола или ошибках базовой архитектуры. С другой стороны, уязвимость ограничена только самим Cetus и не связана с кодом SUI. Корень уязвимости заключается в проверке граничных условий, достаточно изменить всего две строки кода, чтобы полностью устранить риск; после завершения исправления его можно немедленно развернуть в основной сети, чтобы гарантировать полную логику последующих контрактов и исключить эту уязвимость.
Высокая скрытность: контракт работает стабильно без сбоев в течение двух лет, протокол Cetus прошел несколько аудитов, но уязвимости не были обнаружены, основная причина заключается в том, что библиотека для математических вычислений Integer_Mate не была включена в область аудита.
Хакеры используют экстремальные значения для точной настройки торговых диапазонов, создавая крайне редкие сценарии с подачей исключительной ликвидности, что и вызывает аномальную логику, указывая на то, что такие проблемы трудно обнаружить при обычном тестировании. Эти проблемы часто находятся в слепых зонах человеческого восприятия, поэтому они оставались незамеченными в течение длительного времени.
Это не уникальная проблема Move:
Move превосходит множество языков смарт-контрактов в области безопасности ресурсов и проверки типов, встроенная нативная проверка на переполнение целых чисел в распространенных сценариях. Это переполнение произошло из-за того, что при добавлении ликвидности использовалось неправильное значение для проверки верхнего предела при вычислении необходимого количества токенов, а смещение было использовано вместо обычного умножения. Если бы использовались обычные операции сложения, вычитания, умножения и деления, в Move автоматически проверялось бы переполнение, и такая проблема с обрезанием старших разрядов не возникла бы.
Подобные уязвимости также возникали в других языках (таких как Solidity, Rust) и даже легче использовались из-за отсутствия защиты от переполнения целых чисел; перед обновлением версии Solidity проверка на переполнение была крайне слабой. В истории имели место случаи переполнения при сложении, вычитании, умножении и т.д., и непосредственной причиной этого всегда было превышение диапазона результата вычислений. Например, уязвимости в умных контрактах 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 в блокчейне полностью зависят от вклада крупных игроков. Для долгосрочного развития протокола необходимо в первую очередь гарантировать безопасность.
Для розничных инвесторов, активных участников экосистемы, сильных сторонников совместного строительства технологий и сообщества. Проект также надеется привлечь розничных инвесторов к совместному строительству, только так
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
12 Лайков
Награда
12
4
Поделиться
комментарий
0/400
GweiWatcher
· 08-01 19:47
Так что нужно покупать на最低点? Ужасно
Посмотреть ОригиналОтветить0
DefiPlaybook
· 08-01 19:44
Согласно анализу данных в блокчейне, уязвимость Cetus выявила врожденные риски смарт-контрактов, падение TVL на 83,7% подчеркивает слабость ликвидности.
Посмотреть ОригиналОтветить0
GigaBrainAnon
· 08-01 19:37
Невозможно исправить небо.
Посмотреть ОригиналОтветить0
0xSherlock
· 08-01 19:30
Да только и умеют, что спекулировать и на больших пампах и дампах.
Ярко проявляется экологическая устойчивость SUI, и после инцидентов с безопасностью она все еще обладает долгосрочным потенциалом роста.
Твердая вера после кризиса безопасности: почему SUI по-прежнему обладает потенциалом для долгосрочного роста?
1. Цепная реакция, вызванная одной атакой
22 мая 2025 года ведущий AMM-протокол Cetus, развернутый в сети SUI, подвергся хакерской атаке. Злоумышленник использовал логическую уязвимость, связанную с "переполнением целого числа", чтобы провести точную манипуляцию, что привело к потере более 200 миллионов долларов активов. Это событие стало одной из крупнейших по масштабу аварий безопасности в области DeFi на сегодняшний день, а также самой разрушительной хакерской атакой с момента запуска основной сети SUI.
Согласно данным DefiLlama, TVL всей цепи SUI в день атаки в один момент упала более чем на 330 миллионов долларов, а сумма заблокированных средств самого протокола Cetus моментально испарилась на 84%, упав до 38 миллионов долларов. В результате, несколько популярных токенов на SUI упали на 76% до 97% всего за один час, что вызвало широкий интерес к безопасности SUI и стабильности экосистемы.
Но после этой волны потрясений экосистема SUI продемонстрировала сильную устойчивость и восстановительные способности. Несмотря на то, что событие Cetus краткосрочно вызвало колебания уверенности, средства на блокчейне и активность пользователей не столкнулись с длительным спадом, а наоборот, способствовали значительному повышению внимания всей экосистемы к безопасности, строительству инфраструктуры и качеству проектов.
Klein Labs будет рассматривать причины этого инцидента, механизм консенсуса узлов SUI, безопасность языка MOVE и развитие экосистемы SUI, анализируя текущую экосистему этой публичной цепочки, которая все еще находится на ранней стадии развития, и обсуждая ее потенциальное будущее развитие.
2. Анализ причин атаки на событие Cetus
2.1 Процесс реализации атаки
Согласно техническому анализу команды Slow Mist по инциденту с атакой на Cetus, хакеры успешно воспользовались ключевым арифметическим переполнением в протоколе, используя флеш-займы, точную манипуляцию ценами и недостатки контракта, за короткое время похитив более 200 миллионов долларов цифровых активов. Атакующий путь можно условно разделить на три этапа:
①Запускать闪电贷, манипулировать ценами
Хакеры сначала использовали максимальный проскальзывание для молниеносного обмена 100 миллиардов haSUI, взяв крупные суммы в займы для манипуляции ценами.
Мгновенные займы позволяют пользователям занимать и возвращать средства в рамках одной сделки, выплачивая только комиссию, обладая высокими плечами, низкими рисками и низкими затратами. Хакеры использовали этот механизм, чтобы в короткие сроки снизить рыночную цену и точно контролировать её в очень узком диапазоне.
Затем злоумышленник готовится создать крайне узкую позицию ликвидности, точно установив ценовой диапазон между минимальной ценой 300,000 и максимальной ценой 300,200, ширина ценового диапазона составляет всего 1.00496621%.
Таким образом, хакеры использовали достаточное количество токенов и огромную ликвидность, чтобы успешно манипулировать ценой haSUI. Затем они также начали манипулировать несколькими токенами, у которых нет реальной ценности.
②Добавить ликвидность
Атакующий создает узкие позиции ликвидности, заявляя о добавлении ликвидности, но из-за уязвимости функции checked_shlw в конечном итоге получает только 1 токен.
По сути, это связано с двумя причинами:
2.Переполнение данных было усечено: при выполнении операции сдвига n << 64 над числом n, из-за превышения допустимой ширины бит (256 бит) типа данных uint256 произошло усечение данных. Часть высоких битов была автоматически отброшена, что привело к результату вычисления, значительно ниже ожидаемого, и в результате система недооценила количество haSUI, необходимое для обмена. В конечном итоге вычисленный результат оказался примерно меньше 1, но так как округление производилось в большую сторону, в итоге получилось равным 1, то есть хакеру достаточно было добавить 1 токен, чтобы получить огромную ликвидность.
③Вывод ликвидности
Провести погашение займов, сохраняя огромную прибыль. В конечном итоге из нескольких ликвидных пулов вывести токеновые активы общей стоимостью в несколько сотен миллионов долларов.
Ситуация с потерей средств серьезная, атака привела к краже следующих активов:
12,9 млн SUI (примерно $54 млн)
6000 миллионов долларов США USDC
4900000 долларов США Haedal Staked SUI
$19,5 млн ТУАЛЕТ
Другие токены, такие как HIPPO и LOFI, упали на 75--80%, ликвидность иссякла
2.2 Причины и особенности этой уязвимости
У этой уязвимости Cetus три особенности:
Очень низкие затраты на исправление: с одной стороны, коренная причина инцидента с Cetus заключается в недочете в математической библиотеке Cetus, а не в ошибках ценового механизма протокола или ошибках базовой архитектуры. С другой стороны, уязвимость ограничена только самим Cetus и не связана с кодом SUI. Корень уязвимости заключается в проверке граничных условий, достаточно изменить всего две строки кода, чтобы полностью устранить риск; после завершения исправления его можно немедленно развернуть в основной сети, чтобы гарантировать полную логику последующих контрактов и исключить эту уязвимость.
Высокая скрытность: контракт работает стабильно без сбоев в течение двух лет, протокол Cetus прошел несколько аудитов, но уязвимости не были обнаружены, основная причина заключается в том, что библиотека для математических вычислений Integer_Mate не была включена в область аудита.
Хакеры используют экстремальные значения для точной настройки торговых диапазонов, создавая крайне редкие сценарии с подачей исключительной ликвидности, что и вызывает аномальную логику, указывая на то, что такие проблемы трудно обнаружить при обычном тестировании. Эти проблемы часто находятся в слепых зонах человеческого восприятия, поэтому они оставались незамеченными в течение длительного времени.
Move превосходит множество языков смарт-контрактов в области безопасности ресурсов и проверки типов, встроенная нативная проверка на переполнение целых чисел в распространенных сценариях. Это переполнение произошло из-за того, что при добавлении ликвидности использовалось неправильное значение для проверки верхнего предела при вычислении необходимого количества токенов, а смещение было использовано вместо обычного умножения. Если бы использовались обычные операции сложения, вычитания, умножения и деления, в Move автоматически проверялось бы переполнение, и такая проблема с обрезанием старших разрядов не возникла бы.
Подобные уязвимости также возникали в других языках (таких как Solidity, Rust) и даже легче использовались из-за отсутствия защиты от переполнения целых чисел; перед обновлением версии Solidity проверка на переполнение была крайне слабой. В истории имели место случаи переполнения при сложении, вычитании, умножении и т.д., и непосредственной причиной этого всегда было превышение диапазона результата вычислений. Например, уязвимости в умных контрактах 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 в блокчейне полностью зависят от вклада крупных игроков. Для долгосрочного развития протокола необходимо в первую очередь гарантировать безопасность.
Для розничных инвесторов, активных участников экосистемы, сильных сторонников совместного строительства технологий и сообщества. Проект также надеется привлечь розничных инвесторов к совместному строительству, только так