Твердая вера после кризиса безопасности: почему SUI все еще обладает потенциалом для долгосрочного роста?

1. Цепная реакция, вызванная одной атакой

22 мая 2025 года одно из ведущих AMM-протоколов, развернутое в сети SUI, Cetus, подверглось хакерской атаке. Злоумышленник воспользовался логической уязвимостью, связанной с "проблемой переполнения целого числа", чтобы осуществить точное управление, что привело к убыткам более чем на 200 миллионов долларов. Этот инцидент стал не только крупнейшей в этом году аварией в области DeFi, но и самой разрушительной хакерской атакой с момента запуска основной сети SUI.

Согласно данным DefiLlama, общий TVL SUI на блокчейне в день атаки в одночасье упал более чем на 330 миллионов долларов, а сумма, заблокированная в протоколе Cetus, мгновенно испарилась на 84%, опустившись до 38 миллионов долларов. В результате этого несколько популярных токенов на SUI (включая Lofi, Sudeng, Squirtle и др.) за короткий промежуток времени упали на 76% до 97%, вызвав широкое беспокойство на рынке по поводу безопасности SUI и стабильности экосистемы.

Но после этой волны шоков экосистема SUI продемонстрировала сильную устойчивость и способность к восстановлению. Несмотря на то, что событие Cetus на короткий срок вызвало колебания доверия, средства на блокчейне и активность пользователей не испытали длительного спада, а наоборот, способствовали значительному повышению внимания всей экосистемы к безопасности, строительству инфраструктуры и качеству проектов.

Klein Labs будет рассматривать причины данного инцидента, механизм консенсуса узлов SUI, безопасность языка MOVE и развитие экосистемы SUI, анализируя текущую экосистему этой публичной цепочки, которая все еще находится на ранней стадии развития, и обсуждая ее будущий потенциал.

2. Анализ причин атаки на событие Cetus

2.1 Процесс реализации атаки

Согласно техническому анализу инцидента с атакой на Cetus от команды Slow Mist, хакеры успешно использовали уязвимость ключевого арифметического переполнения в протоколе, воспользовавшись.flash-кредитами, точным манипулированием ценами и дефектами контракта, в кратчайшие сроки похитив более 200 миллионов долларов цифровых активов. Путь атаки можно условно разделить на три этапа:

①Запускать闪电贷, манипулировать ценами

Хакеры сначала использовали максимальный проскальзывание для молниеносного обмена 100 миллиардов haSUI, чтобы занять большие средства и манипулировать ценами.

Долгосрочный кредит позволяет пользователям заимствовать и возвращать средства в одной и той же сделке, оплачивая только комиссию, обладая характеристиками высокого плеча, низкого риска и низкой стоимости. Хакеры использовали этот механизм, чтобы в короткий срок снизить рыночную цену и точно контролировать её в очень узком диапазоне.

Затем злоумышленник готовится создать крайне узкую ликвидную позицию, точно установив ценовой диапазон между минимальной ставкой 300,000 и максимальной ценой 300,200, ширина которой составляет всего 1.00496621%.

С помощью вышеуказанных методов хакеры использовали достаточное количество токенов и огромную ликвидность для успешного манипулирования ценой haSUI. Затем они также манипулировали несколькими токенами, не имеющими реальной ценности.

②Добавить ликвидность

Злоумышленник создает узкие позиции ликвидности, заявляет о добавлении ликвидности, но из-за уязвимости функции checked_shlw в конечном итоге получает только 1 токен.

В сущности, это связано с двумя причинами:

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 есть три характеристики:

1. Стоимость исправления крайне низка: с одной стороны, основной причиной инцидента с Cetus является недочет в математической библиотеке Cetus, а не ошибка ценового механизма протокола или ошибка базовой архитектуры. С другой стороны, уязвимость ограничена только Cetus и не имеет отношения к коду SUI. Корень уязвимости заключается в проверке одного граничного условия, достаточно изменить две строки кода, чтобы полностью устранить риск; после завершения исправления его можно немедленно развернуть в основной сети, чтобы обеспечить полное завершение логики контрактов и исключить данную уязвимость.

2. Высокая скрытность: контракт работает стабильно без сбоев на протяжении двух лет, протокол Cetus прошел несколько аудитов, но уязвимости не были обнаружены, основная причина заключается в том, что библиотека Integer_Mate, используемая для математических вычислений, не была включена в область аудита.

Хакеры используют экстремальные значения для точного построения торговых диапазонов, создавая крайне редкие сценарии с подачей чрезвычайно высокой ликвидности, что и вызывает аномальную логику, указывая на то, что такие проблемы трудно обнаружить с помощью обычного тестирования. Эти проблемы обычно находятся в слепой зоне восприятия людей, поэтому они долгое время остаются незамеченными.

3. Не только проблема 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 валидаторов, Cetus будет трудно в короткие сроки координировать всех валидаторов для поочередного реагирования.

3.2.2 Кто имеет право изменять черный список?

TransactionDenyConfig — это YAML/TOML конфигурационный файл, загружаемый локально каждым валидатором. Любой, кто запускает узел, может редактировать этот файл, производить горячую перезагрузку или перезапустить узел и обновить список. На первый взгляд, каждый валидатор, кажется, свободно выражает свои ценности.

На самом деле, для обеспечения согласованности и эффективности политики безопасности обновление этой ключевой конфигурации обычно является скоординированным. Поскольку это "срочное обновление, инициированное командой SUI", в основном SUI фонд (или его уполномоченные разработчики) устанавливает и обновляет этот список отказов.

SUI опубликовал черный список, теоретически валидаторы могут выбирать, использовать его или нет ------ но на практике большинство людей по умолчанию будет автоматически его использовать. Поэтому, хотя эта функция защищает средства пользователей, она по своей сути действительно имеет определённую степень централизации.

3.2.3 Суть функции черного списка

Функция черного списка на самом деле не является логикой на уровне протокола, она скорее похожа на дополнительную меру безопасности, предназначенную для реагирования на чрезвычайные ситуации и обеспечения безопасности средств пользователей.

По сути, это механизм обеспечения безопасности. Похож на "охранную цепочку", прикреплённую к двери, которая активируется только для тех, кто хочет проникнуть в дом, то есть для тех, кто намерен злоупотребить протоколом. Для пользователей:

• Для крупных участников, основных поставщиков ликвидности, протоколы стремятся обеспечить безопасность средств, поскольку фактически данные о TVL в сети в основном предоставляются крупными участниками. Для долгосрочного развития протоколов необходимо в первую очередь гарантировать безопасность.

• Для розничных инвесторов, активных участников экосистемы, сильная поддержка совместного строительства технологий и сообщества