Твердая вера после кризиса безопасности: почему 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 миллионов долларов цифровых активов. Путь атаки можно условно разделить на три этапа:

①Запускать кредитование через Flash, манипулировать ценой

Хакеры сначала использовали максимальный проскальзывание, чтобы мгновенно обменять 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

• 4900000 долларов США Haedal Staked SUI

• 1950 миллионов долларов TOILET

• Другие токены, такие как 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

• Средний период эпохи: 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 на блокчейне полностью зависят от вклада этих крупных игроков. Для долгосрочного развития протоколов необходимо в первую очередь обеспечить безопасность.

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