Твердая вера после кризиса безопасности: почему SUI все еще обладает потенциалом для долгосрочного роста?
1. Цепная реакция, вызванная атакой
22 мая 2023 года, ведущий AMM-протокол Cetus, развернутый в сети SUI, подвергся хакерской атаке. Злоумышленник использовал логическую уязвимость, связанную с "проблемой переполнения целого числа", чтобы провести точное манипулирование, что привело к потерям активов на сумму более 200 миллионов долларов. Этот инцидент стал не только крупнейшей безопасностью в DeFi за этот год, но и самой разрушительной хакерской атакой с момента запуска основной сети SUI.
Согласно данным DefiLlama, общая TVL сети SUI в день нападения упала более чем на 330 миллионов долларов, а собственные запасы протокола Cetus мгновенно испарились на 84%, упав до 38 миллионов долларов. В результате этого несколько популярных токенов на SUI за короткий промежуток времени упали на 76% до 97%, что вызвало широкое внимание к безопасности SUI и стабильности экосистемы.
Но после этой волны шока экосистема SUI продемонстрировала свою мощную устойчивость и способность к восстановлению. Несмотря на то, что событие Cetus в краткосрочной перспективе вызвало колебания доверия, средства на блокчейне и активность пользователей не столкнулись с продолжительным спадом, а наоборот, способствовали значительному повышению внимания всей экосистемы к безопасности, строительству инфраструктуры и качеству проектов.
Мы обсудим причины данного инцидента, механизм консенсуса узлов SUI, безопасность языка MOVE и развитие экосистемы SUI, чтобы проанализировать текущую экосистему этой публичной цепи, находящейся на ранней стадии развития, и обсудить ее потенциал для будущего развития.
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 Loan, сохранив огромную прибыль. В конечном итоге вывести токеновые активы общей стоимостью до нескольких сотен миллионов долларов из нескольких ликвидных пулов.
Ситуация с потерей средств серьезная, атака привела к краже следующих активов:
12,9 млн SUI (примерно $54 млн)
$60,000,000 USDC
490 миллионов долларов 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 в блокчейне полностью зависят от вклада крупных игроков. Для долгосрочного развития протокола необходимо в первую очередь гарантировать безопасность.
Для розничных инвесторов, активных участников экосистемы, сильных сторонников совместного строительства технологий и сообщества. Проектная команда также надеется привлечь розничных инвесторов к совместному строительству,
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
13 Лайков
Награда
13
5
Поделиться
комментарий
0/400
MEVHunterNoLoss
· 18ч назад
Эта волна хакерских атак меня не пугает сокращением потерь
Посмотреть ОригиналОтветить0
gas_fee_trauma
· 18ч назад
炒币亏完了就全在这
Ответить0
faded_wojak.eth
· 18ч назад
Как ты можешь говорить о гибкости, если тебя просто обобрали до нитки?
Посмотреть ОригиналОтветить0
LiquidationKing
· 18ч назад
sui не обязательно холодный, но с железом следует быть осторожным
Посмотреть ОригиналОтветить0
MEVSandwich
· 18ч назад
разыгрывайте людей как лохов ловушка痛 Кто поймет это
Экосистема SUI демонстрирует устойчивость, показывая долгосрочный рост после инцидента с безопасностью.
Твердая вера после кризиса безопасности: почему SUI все еще обладает потенциалом для долгосрочного роста?
1. Цепная реакция, вызванная атакой
22 мая 2023 года, ведущий AMM-протокол Cetus, развернутый в сети SUI, подвергся хакерской атаке. Злоумышленник использовал логическую уязвимость, связанную с "проблемой переполнения целого числа", чтобы провести точное манипулирование, что привело к потерям активов на сумму более 200 миллионов долларов. Этот инцидент стал не только крупнейшей безопасностью в DeFi за этот год, но и самой разрушительной хакерской атакой с момента запуска основной сети SUI.
Согласно данным DefiLlama, общая TVL сети SUI в день нападения упала более чем на 330 миллионов долларов, а собственные запасы протокола Cetus мгновенно испарились на 84%, упав до 38 миллионов долларов. В результате этого несколько популярных токенов на SUI за короткий промежуток времени упали на 76% до 97%, что вызвало широкое внимание к безопасности SUI и стабильности экосистемы.
Но после этой волны шока экосистема SUI продемонстрировала свою мощную устойчивость и способность к восстановлению. Несмотря на то, что событие Cetus в краткосрочной перспективе вызвало колебания доверия, средства на блокчейне и активность пользователей не столкнулись с продолжительным спадом, а наоборот, способствовали значительному повышению внимания всей экосистемы к безопасности, строительству инфраструктуры и качеству проектов.
Мы обсудим причины данного инцидента, механизм консенсуса узлов SUI, безопасность языка MOVE и развитие экосистемы SUI, чтобы проанализировать текущую экосистему этой публичной цепи, находящейся на ранней стадии развития, и обсудить ее потенциал для будущего развития.
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 Loan, сохранив огромную прибыль. В конечном итоге вывести токеновые активы общей стоимостью до нескольких сотен миллионов долларов из нескольких ликвидных пулов.
Ситуация с потерей средств серьезная, атака привела к краже следующих активов:
12,9 млн SUI (примерно $54 млн)
$60,000,000 USDC
490 миллионов долларов 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 в блокчейне полностью зависят от вклада крупных игроков. Для долгосрочного развития протокола необходимо в первую очередь гарантировать безопасность.
Для розничных инвесторов, активных участников экосистемы, сильных сторонников совместного строительства технологий и сообщества. Проектная команда также надеется привлечь розничных инвесторов к совместному строительству,