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

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

①Инициировать мгновенный заем, манипулировать ценой

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

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

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

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

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

Атакующий создает узкие позиции ликвидности, заявляет о добавлении ликвидности, но из-за уязвимости функции checked_shlw в конечном итоге получает только 1 токен.

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

1. Широкая установка маски: эквивалентно огромному пределу добавления ликвидности, что делает проверку пользовательского ввода в контракте формально бессмысленной. Хакеры, устанавливая аномальные параметры, создают ввод, который всегда меньше этого предела, тем самым обходя проверку на переполнение.

2. Переполнение данных было обрезано: при выполнении операции сдвига n << 64 для числового значения n, из-за того, что сдвиг превышает эффективную ширину бит uint256 (256 бит), произошло обрезание данных. Высшая часть переполнения была автоматически отброшена, что привело к тому, что результат вычисления оказался значительно ниже ожидаемого, в результате чего система недооценивала количество haSUI, необходимое для обмена. В конечном итоге вычисленный результат оказался меньше 1, но так как округление происходило вверх, в итоге он равен 1, что означает, что хакеру достаточно добавить 1 токен, чтобы получить огромную ликвидность.

③Вывод ликвидности

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

Ситуация с потерей средств серьезная, атака привела к краже следующих активов:

• 12,9 млн SUI (примерно $54 млн)

• 6000 миллионов долларов USDC

• 4900000 долларов США 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

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

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