С августа развитие экосистемы SUI прошло стремительно. Согласно DefiLlama, TVL SUI превысил 1 миллиард долларов, увеличившись на 200% за последние два месяца, и в настоящее время объем торговли Cetus, децентрализованной биржи, построенной на SUI, превышает 160 миллионов долларов в день.

9 октября на основной сети SUI был запущен местный токен USDC, что будет продолжать привлекать больше средств в экосистему SUI. В качестве важного участника экосистемы Move, SUI стремится обеспечить быстрые и безопасные транзакционные услуги для различных сценариев блокчейн-приложений.

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

Безопасность контрактов

Sui использует Move в качестве языка программирования для смарт-контрактов. Move был разработан как исполняемый язык байткода с встроенными алгоритмами безопасности и верификатором байткода, а также использует статические вызовы при вызове контрактов.

Этот дизайн позволяет Move обращаться к распространенным уязвимостям в смарт-контрактах, таким как атаки повторного входа, переполнение целых чисел, двойные траты и потенциальные проблемы с компилятором, но разработчики все же могут случайно внести уязвимости при разработке контрактов. В ответ на это Beosin в 2023 году представил Move Lint - инструмент статического обнаружения, который автоматизирует обнаружение потенциальных угроз безопасности в контрактах и находит уязвимости.

Кроме инструментов обнаружения, следующие проблемы безопасности, на которые разработчикам необходимо обратить дополнительное внимание при разработке контрактов Move для повышения безопасности:

1) Переполнение целого числа

По сравнению с другими языками смарт-контрактов, Move автоматически проверяет проблемы переполнения по умолчанию при выполнении операций целочисленной математики, что может предотвратить большое количество проблем с переполнением, но все же есть две важные точки, на которые следует обратить внимание:

Побитовые операции в языке Move не выполняют автоматическую проверку переполнения, потому что побитовые операции являются в основном операциями на уровне битов с данными, которые ведут себя по-разному от операций с целыми числами.

Когда вступает в силу автоматическая проверка переполнения Move, выполнение функции вызывает исключение, которое, если оно неправильно разработано, может привести к невыполнению проектного бизнеса в ожидаемом виде, что приводит к DoS-атакам.

2) Управление разрешениями и доступом

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

Разработчики могут использовать Move Prover для проверки того, что программа соблюдает явную политику контроля доступа. Например, в std.offer мы видим, что функция завершается, когда получатель не находится в белом списке:

3) Проблема зависимости от порядка транзакции

Зависимость от порядка транзакций (TOD) означает, что поведение контракта может иметь разные результаты в зависимости от порядка выполнения транзакций, особенно в децентрализованной среде, где майнер или проверяющий могут выбирать порядок транзакций. Это может создавать риски, такие как атаки фронтраннинга.

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

4) Проблема потребления газа

В цепочке Sui проблема газа смарт-контрактов Move в основном отражается в расчетах и затратах на хранение, необходимых для выполнения контракта. С увеличением сложности контрактов и изменениями состояния соответственно возрастает и потребление газа. Разработчикам необходимо сосредоточиться на оптимизации логики контракта, сокращении ненужных вычислений и обновлений статуса, чтобы снизить транзакционные издержки для пользователей, и особенно избежать ситуации неконтролируемых итераций в контракте, которые могут быть связаны с нехваткой газа и невозможностью выполнить бизнес должным образом.

5) Точность вычислений

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

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

6) Управление объектами

В смарт-контрактах Move на блокчейне Sui управление объектами является ключевой задачей, охватывающей несколько аспектов жизненного цикла объекта, владение, одновременный доступ, сериализацию и затраты на хранение. Разработчики должны точно управлять созданием, обновлением и уничтожением объектов, чтобы предотвратить ресурсные потери и несогласованность состояний. В то же время разумное проектирование логики контракта для контроля владения и прав доступа к объектам, а также работа с одновременным доступом нескольких пользователей к одному и тому же объекту, являются важными факторами для обеспечения безопасной и эффективной работы смарт-контрактов.

7) Проблемы проектирования и реализации бизнес-логики

Например, с внедрением молниеносного кредита в проекте Sui DeFi, злоумышленники могут использовать мгновенные кредиты для осуществления атак с большими суммами средств, таких как манипуляции с ценами.

В функции обмена токенов общего типа AMM разработчики могут использовать Move Prover для проверки правильности изменения количества токенов:

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

Проблемы в экосистеме SUI

В настоящее время децентрализованные финансы (DeFi) и Memecoins SUI цветут, и объем торговли и TVL привлекают взрывной рост. Впоследствии появляется все больше мошенничества и спам-торговли, от которых пользователи должны избегать.

Фишинг

В этом году появилась афера с воздушной капелью под названием Suisses в Sui Eco, что позволило многим пользователям быть обокраденными. Когда пользователь подключается к кошельку на веб-сайте Suisses и нажимает Claim, появляется запрос на трансфер активов пользователя. Если пользователь подписывает транзакцию, он обнаружит, что все активы его кошелька были переведены.

Из-за характеристик SUI: все объекты, а не только токены в кошельке пользователя, NFT - объект, а также участие пользователя в добыче DeFi, залоге ликвидности и других сертификатах. Если произойдет фишинговая атака, все активы пользователя в экосистеме SUI могут быть переведены хакером одновременно.

Мошенничество с токенами

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

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

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

MEV Challenge

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

Sui использует Narwhal в качестве пула памяти для незавершенных транзакций, назначая их узлам, и использует алгоритм Bullshark в качестве механизма консенсуса для сортировки транзакций.

Правило оформления Sui для транзакций основано на комиссии за газ. Кроме того, поскольку Sui принимает схему выполнения транзакций, сочетающую параллельное и последовательное выполнение, транзакции, которые используют одно и то же состояние пула транзакций AMM, могут быть выполнены только последовательно. Поэтому атака-сэндвич / транзакция фронтраннинга является возможной. Злоумышленник может запустить атаку-сэндвич с помощью более высокой комиссии за газ, чтобы пользователи, участвующие в торговле DeFi, понесли убытки.

Отказ от ответственности:

1. Эта статья перепечатана из [beosin]. Все авторские права принадлежат оригинальному автору [beosin]. Если есть возражения против этой перепечатки, пожалуйста, свяжитесь с Gate Learnкоманда, и они быстро справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно мнением автора и не являются инвестиционными советами.
3. Переводы статьи на другие языки выполняются командой gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.