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

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

22 мая 2025 года, ведущий AMM-протокол Cetus, развернутый в сети SUI, подвергся хакерской атаке. Злоумышленники использовали логический уязвимость, связанную с "проблемой переполнения целого числа", чтобы осуществить точные манипуляции, что привело к убыткам более 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 Процесс реализации атаки

Согласно техническому анализу команды Slow Mist по инциденту с атакой на Cetus, хакеры успешно использовали уязвимость ключевого арифметического переполнения в протоколе, воспользовавшись флеш-кредитами, точным манипулированием ценами и дефектами контракта, они украли более 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

• 4,9 миллиона долларов США 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 проверки на переполнение были очень слабыми. В истории имели место случаи переполнения при сложении, вычитании, умножении и т. д., основной причиной которых было превышение диапазона результатов вычислений. Например, уязвимости в двух смарт-контрактах на языке Solidity, BEC и SMT, были использованы путем тщательно подобранных параметров, которые обходили проверочные операторы в контрактах, что позволяло осуществить атаки с избыточным переводом.

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

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