Твердая вера после кризиса безопасности: почему SUI по-прежнему обладает потенциалом для долгосрочного роста?
1. Цепная реакция, вызванная одной атакой
22 мая 2023 года ведущий AMM-протокол Cetus, развернутый в сети SUI, стал жертвой хакерской атаки. Злоумышленники воспользовались логической уязвимостью, связанной с "переполнением целого числа", для осуществления точного контроля, что привело к потерям более 200 миллионов долларов. Этот инцидент не только является одним из крупнейших инцидентов безопасности в области DeFi на сегодняшний день, но и стал самым разрушительным хакерским нападением с момента запуска основной сети SUI.
Согласно данным DefiLlama, общая TVL SUI в сети в день атаки упала более чем на 330 миллионов долларов, а сумма, заблокированная в протоколе Cetus, в瞬але уменьшилась на 84%, составив 38 миллионов долларов. В результате несколько популярных токенов на SUI (включая Lofi, Sudeng, Squirtle и др.) упали в цене на 76% до 97% всего за час, что вызвало широкое внимание к безопасности SUI и стабильности экосистемы.
Но после этой волны шока экосистема SUI продемонстрировала сильную устойчивость и способность к восстановлению. Хотя событие Cetus на короткий срок вызвало колебания доверия, средства на блокчейне и активность пользователей не столкнулись с постоянным спадом, а, наоборот, способствовали значительному повышению внимания всей экосистемы к безопасности, строительству инфраструктуры и качеству проектов.
В данной статье будут рассмотрены причины этой атакующей ситуации, механизм консенсуса узлов SUI, безопасность языка MOVE и развитие экосистемы SUI, а также будет проанализирована текущая экосистема этой публичной цепи, которая все еще находится на ранней стадии развития, и обсужден ее потенциальный рост в будущем.
2. Анализ причин атаки на событие Cetus
2.1 Процесс реализации атаки
Согласно техническому анализу команды Slow Mist по инциденту с атакой на Cetus, хакеры успешно использовали ключевую уязвимость переполнения арифметических вычислений в протоколе, воспользовавшись мгновенными займами, точным манипулированием ценами и недостатками контракта, в течение короткого времени похитив более 200 миллионов долларов цифровых активов. Путь атаки можно условно разделить на следующие три этапа:
Хакеры сначала использовали максимальный проскальзывание для мгновенного обмена 100 миллиардов haSUI, чтобы взять огромные средства в кредит и провести манипуляции с ценами.
Долгосрочный кредит позволяет пользователям занимать и возвращать средства в одной транзакции, оплачивая только комиссию, обладая такими характеристиками, как высокий рычаг, низкий риск и низкие затраты. Хакеры использовали этот механизм, чтобы за короткий период времени снизить рыночную цену и точно контролировать её в очень узком диапазоне.
Затем злоумышленник готовится создать крайне узкую ликвидную позицию, устанавливая ценовой диапазон точно между самой низкой ценой 300,000 и самой высокой ценой 300,200, ширина которого составляет всего 1.00496621%.
С помощью вышеупомянутых методов хакеры использовали достаточное количество токенов и огромную ликвидность для успешного манипулирования ценой haSUI. Затем они также манипулировали несколькими токенами без реальной ценности.
②Добавить ликвидность
Атакующий создает узкие позиции ликвидности, заявляя о добавлении ликвидности, но из-за уязвимости функции checked_shlw в конечном итоге получает только 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. Корень уязвимости заключается в одном условии границы, для его полного устранения достаточно изменить всего две строки кода; после завершения исправления его можно немедленно развернуть в основной сети, чтобы обеспечить полноту логики последующих контрактов и исключить эту уязвимость.
Высокая скрытность: Контракт работает стабильно без сбоев в течение двух лет, протокол 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
Средний период Epoch: 24 часа
Механизм процесса:
Делегирование прав: Обычным пользователям не нужно самостоятельно запускать узлы, достаточно заложить SUI и делегировать его кандидату на валидацию, чтобы участвовать в обеспечении безопасности сети и распределении вознаграждений. Эта механика может снизить порог участия для обычных пользователей, позволяя им участвовать в консенсусе сети через "наем" доверенных валидаторов. Это также является одним из основных преимуществ DPoS по сравнению с традиционным PoS.
Представляет собой раунд выпуска блока: небольшое количество выбранных валидаторов выпускает блоки в фиксированном или случайном порядке, что повышает скорость подтверждения и увеличивает TPS.
Динамические выборы: после завершения каждого этапа голосования, на основе веса голосов, проводится динамическая ротация и переизбрание набора валидаторов, чтобы обеспечить активность узлов, согласованность интересов и децентрализацию.
Преимущества DPoS:
Высокая эффективность: благодаря контролируемому количеству узлов генерации блоков сеть может завершать подтверждение за миллисекунды, удовлетворяя требованиям к высокой пропускной способности.
Низкая стоимость: меньше узлов, участвующих в консенсусе, значительно снижает необходимые сетевые ресурсы и вычислительные мощности для синхронизации информации и агрегирования подписей. Таким образом, снижаются затраты на оборудование и эксплуатацию, а требования к вычислительной мощности также снижаются, что приводит к более низким затратам. В конечном итоге это позволяет добиться более низких пользовательских комиссий.
Высокая безопасность: механизмы стейкинга и делегирования синхронизируют затраты и риски атак; в сочетании с механизмом конфискации на блокчейне эффективно сдерживают злонамеренные действия.
В то же время в механизме консенсуса 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 или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
8 Лайков
Награда
8
4
Поделиться
комментарий
0/400
GetRichLeek
· 7ч назад
炒惨咯 Рект 但还是忍不住 покупайте паденияsui
Посмотреть ОригиналОтветить0
ShadowStaker
· 07-26 06:40
тестируется устойчивость сети fr... но эти уязвимости переполнения целых чисел устарели smh. где надлежащая проверка?
Является проявлением устойчивости экосистемы SUI, которая по-прежнему обладает долгосрочным потенциалом роста после кризиса безопасности.
Твердая вера после кризиса безопасности: почему SUI по-прежнему обладает потенциалом для долгосрочного роста?
1. Цепная реакция, вызванная одной атакой
22 мая 2023 года ведущий AMM-протокол Cetus, развернутый в сети SUI, стал жертвой хакерской атаки. Злоумышленники воспользовались логической уязвимостью, связанной с "переполнением целого числа", для осуществления точного контроля, что привело к потерям более 200 миллионов долларов. Этот инцидент не только является одним из крупнейших инцидентов безопасности в области DeFi на сегодняшний день, но и стал самым разрушительным хакерским нападением с момента запуска основной сети SUI.
Согласно данным DefiLlama, общая TVL SUI в сети в день атаки упала более чем на 330 миллионов долларов, а сумма, заблокированная в протоколе Cetus, в瞬але уменьшилась на 84%, составив 38 миллионов долларов. В результате несколько популярных токенов на SUI (включая Lofi, Sudeng, Squirtle и др.) упали в цене на 76% до 97% всего за час, что вызвало широкое внимание к безопасности SUI и стабильности экосистемы.
Но после этой волны шока экосистема SUI продемонстрировала сильную устойчивость и способность к восстановлению. Хотя событие Cetus на короткий срок вызвало колебания доверия, средства на блокчейне и активность пользователей не столкнулись с постоянным спадом, а, наоборот, способствовали значительному повышению внимания всей экосистемы к безопасности, строительству инфраструктуры и качеству проектов.
В данной статье будут рассмотрены причины этой атакующей ситуации, механизм консенсуса узлов SUI, безопасность языка MOVE и развитие экосистемы SUI, а также будет проанализирована текущая экосистема этой публичной цепи, которая все еще находится на ранней стадии развития, и обсужден ее потенциальный рост в будущем.
2. Анализ причин атаки на событие Cetus
2.1 Процесс реализации атаки
Согласно техническому анализу команды Slow Mist по инциденту с атакой на Cetus, хакеры успешно использовали ключевую уязвимость переполнения арифметических вычислений в протоколе, воспользовавшись мгновенными займами, точным манипулированием ценами и недостатками контракта, в течение короткого времени похитив более 200 миллионов долларов цифровых активов. Путь атаки можно условно разделить на следующие три этапа:
①Запускать молниеносный кредит, манипулировать ценами
Хакеры сначала использовали максимальный проскальзывание для мгновенного обмена 100 миллиардов haSUI, чтобы взять огромные средства в кредит и провести манипуляции с ценами.
Долгосрочный кредит позволяет пользователям занимать и возвращать средства в одной транзакции, оплачивая только комиссию, обладая такими характеристиками, как высокий рычаг, низкий риск и низкие затраты. Хакеры использовали этот механизм, чтобы за короткий период времени снизить рыночную цену и точно контролировать её в очень узком диапазоне.
Затем злоумышленник готовится создать крайне узкую ликвидную позицию, устанавливая ценовой диапазон точно между самой низкой ценой 300,000 и самой высокой ценой 300,200, ширина которого составляет всего 1.00496621%.
С помощью вышеупомянутых методов хакеры использовали достаточное количество токенов и огромную ликвидность для успешного манипулирования ценой haSUI. Затем они также манипулировали несколькими токенами без реальной ценности.
②Добавить ликвидность
Атакующий создает узкие позиции ликвидности, заявляя о добавлении ликвидности, но из-за уязвимости функции checked_shlw в конечном итоге получает только 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. Корень уязвимости заключается в одном условии границы, для его полного устранения достаточно изменить всего две строки кода; после завершения исправления его можно немедленно развернуть в основной сети, чтобы обеспечить полноту логики последующих контрактов и исключить эту уязвимость.
Высокая скрытность: Контракт работает стабильно без сбоев в течение двух лет, протокол 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
Средний период Epoch: 24 часа
Механизм процесса:
Делегирование прав: Обычным пользователям не нужно самостоятельно запускать узлы, достаточно заложить SUI и делегировать его кандидату на валидацию, чтобы участвовать в обеспечении безопасности сети и распределении вознаграждений. Эта механика может снизить порог участия для обычных пользователей, позволяя им участвовать в консенсусе сети через "наем" доверенных валидаторов. Это также является одним из основных преимуществ DPoS по сравнению с традиционным PoS.
Представляет собой раунд выпуска блока: небольшое количество выбранных валидаторов выпускает блоки в фиксированном или случайном порядке, что повышает скорость подтверждения и увеличивает TPS.
Динамические выборы: после завершения каждого этапа голосования, на основе веса голосов, проводится динамическая ротация и переизбрание набора валидаторов, чтобы обеспечить активность узлов, согласованность интересов и децентрализацию.
Преимущества DPoS:
Высокая эффективность: благодаря контролируемому количеству узлов генерации блоков сеть может завершать подтверждение за миллисекунды, удовлетворяя требованиям к высокой пропускной способности.
Низкая стоимость: меньше узлов, участвующих в консенсусе, значительно снижает необходимые сетевые ресурсы и вычислительные мощности для синхронизации информации и агрегирования подписей. Таким образом, снижаются затраты на оборудование и эксплуатацию, а требования к вычислительной мощности также снижаются, что приводит к более низким затратам. В конечном итоге это позволяет добиться более низких пользовательских комиссий.
Высокая безопасность: механизмы стейкинга и делегирования синхронизируют затраты и риски атак; в сочетании с механизмом конфискации на блокчейне эффективно сдерживают злонамеренные действия.
В то же время в механизме консенсуса 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 на блокчейне полностью зависят от вкладов крупных участников. Чтобы протокол мог развиваться долгое время, ему обязательно нужно в первую очередь обеспечить безопасность.
Для розничных инвесторов, активных участников экосистемы, сильных сторонников совместного строительства технологий и сообщества. Проектная команда также надеется на...