Статьи

Образовательные материалы и учебные пособия о Sui

Заработай свою долю из 1000 Sui

Зарабатывай очки репутации и получай награды за помощь в развитии сообщества Sui.

Посты

Owen15
Jun 01, 2025
Статья
Взлом DeFi Sui Cetus: глобальные последствия для экосистемы
В мае 2025 года блокчейн-экосистема Sui столкнулась с серьезным нарушением безопасности, которое потрясло мир децентрализованных финансов (DeFi).Протокол Cetus, флагманская децентрализованная биржа (DEX) на бирже Sui, была использована в результате разрушительного взлома, в результате которого было уничтожено более 220 миллионов долларов**цифровых активов. Этот инцидент не только вызвал серьезные опасения по поводу безопасности протоколов DeFi в сети Sui, но и выявил более широкие уязвимости во всем мире DeFi. Что произошло во время взлома Cetus? Протокол Cetus— ведущий протокол DEX и ликвидности на Sui, служащий ключевой инфраструктурой для обмена токенами, сбора прибыли и концентрированного предоставления ликвидности. Созданный с использованием языка программированияMove, он получил высокую оценку за высокопроизводительную архитектуру и глубокую интеграцию с нативными токенами SUI. 22 мая 2025 годааномальная активность в пулах ликвидности Cetus вызвала тревогу. Глубина пула быстро упала, и вскоре было подтверждено, что платформа подверглась хакерской атаке. Злоумышленники вывели активы из резервов ликвидности на сумму от 220 до 260 миллионов**. Хотя точная уязвимость все еще расследуется, ранний анализ позволяет предположить, что эксплойт мог быть связан с: Манипулирование расчетами пула ликвидности Обход механизмов государственного контроля Команда Cetus быстро приостановила торговлю и приступила к восстановлению, тесно сотрудничая с валидаторамиSui и фирмами, занимающимися аналитикой блокчейна, для отслеживания и замораживания украденных средств. Немедленные последствия для пользователей Sui и Cetus Последствия были мгновенными и серьезными: Крах токена CETUS: собственный токен управления платформой потерял более 60% своей ценности**в течение нескольких часов. Убытки поставщиков ликвидности**: депонированные активы многих LP были уничтожены. Паника по всей экосистеме**: несколько других платформ DeFi на Sui временно приостановили свою деятельность или прошли экстренные аудиты. Несмотря на это, не обошлось и без добра: сообществу валидаторовSui удалось заморозить украденные средства на сумму до 160 миллионов, что вселило надежду на частичное восстановление. Что означает взлом Cetus для экосистемы Sui 1.Выявление пробелов в безопасности смарт-контрактов Move Smart Хотя язык программированияMoveразработан с надежными гарантиями безопасности, включая более эффективное управление памятью и ресурсами по сравнению с Solidity, взлом Cetus показал, что даже хорошо структурированные системы могут иметь серьезные недостатки при работе со сложной логикой DeFi, такой как межконтрактные вызовы, модули управления или механизмы динамического ценообразования. Это событие послужило тревожным сигналом для разработчиков Sui: Инвестируйте больше средств вформальную верификацию и сторонние аудиты Внедритеболее строгие механизмы управления и модернизации Повыситьпрозрачность раскрытия информации о рисках 2.Потенциал ужесточения контроля со стороны регулирующих органов Поскольку DeFi продолжает расти во всем мире, регулирующие органы внимательно следят за этим. Подобный резонансный взлом может повлечь за собой повышенное внимание к протоколам DeFi, особенно к протоколам, работающим на новых блокчейнах, таких как Sui. Власти могут настаивать на следующем: обязательное сообщение о взломах Система ответственности проектных групп Соответствующие требования к платформам DeFi 3.Переоценка доверия к развивающимся экосистемам DeFI Sui позиционирует себя как масштабируемый и высокопроизводительный блокчейн уровня 1, привлекая значительное внимание разработчиков и инвесторов DeFi. Однако инцидент с компанией Cetus выявил риски, связанные с появлением новых экосистем, в которых инструменты и методы аудита смарт-контрактов все еще находятся на стадии становления. Инвесторы и разработчики теперь переосмысливают свой подход к оценке рисков, и многие призывают: децентрализованные механизмы страхования Хранение фондов с несколькими подписями Инструменты мониторинга в реальном времени Уроки для мировой индустрии DeFi 1.Сложность повышает риск Протоколы DeFi часто используют новые экономические модели и алгоритмические конструкции, которые могут привести к непредвиденным последствиям. Взлом Cetus показывает, что даже хорошо спроектированные системы могут быть скомпрометированы, если ключевые компоненты, такие как ценообразование или управление, не будут тщательно протестированы и проверены. 2.Прозрачность укрепляет доверие Во время кризиса команду Cetus хвалили за своевременную коммуникацию и активное сотрудничество с экосистемой Sui. Прозрачные обновления помогли уменьшить дополнительный ущерб и стабилизировать доверие пользователей. 3.Выздоровление возможно, но доверие требует времени Хотя значительная часть украденных средств была заморожена и может быть возвращена, восстановление доверия потребует времени. Пользователи, скорее всего, потребуют более строгих гарантий, прежде чем снова вносить средства в протоколы DeFi. Это может привести к более широкому внедрению: Ончейн-страхование Инструменты мониторинга в реальном времени Кодовые базы с открытым исходным кодом для обеспечения публичного аудита Взгляд в будущее: что ждет Sui и DeFi в будущем? Несмотря на неудачу, экосистема Sui остается устойчивой. Способность валидаторов замораживать и, возможно, возвращать украденные средства свидетельствует о преимуществах скоординированного управления сетью и механизмов быстрого реагирования. В будущем мы можем ожидать следующих результатов: Уделение повышенного вниманияаудиту безопасности и формальной проверкеконтрактов, заключенных на основе MOVE Более тесное сотрудничество между командами DeFi и блокчейн-сетями**для расширения возможностей реагирования на инциденты Развитиеинструментов снижения рисков, включая децентрализованное страхование и многозначное управление казначейством Заключение: тяжелый урок для DeFi ВзломSui Cetus DeFiстал болезненным, но необходимым моментом обучения для всей блокчейн-индустрии. По мере развития DeFi должны развиваться и наши подходы к безопасности, управлению и управлению рисками. Только благодаря постоянному совершенствованию, прозрачности и совместной ответственности экосистема может стать более безопасной и заслуживающей доверия для всех участников.
- Sui
0
harry phan421
May 31, 2025
Статья
Рассмотрение эксплойта Протокола Кетуса по иску
22 мая 2025 года была использована крупная уязвимость, направленная против протокола Cetus в блокчейне Sui, в результате чего ущерб составил, по оценкам, 223 миллиона долларов. Из-за необычной механики этот инцидент сразу же привлек внимание всей экосистемы, особенно технических наблюдателей. Ниже представлен всесторонний анализ атаки: от обмена флэш-памятью и манипуляций с галочками до скрытой уязвимости в логике обнаружения переполнения. https://suiscan.xyz/mainnet/tx/DVMG3B2kocLEnVMDuQzTYRgjwuuFSfciawPvXXheB3x Настройка Злоумышленник инициировал эксплойт, используя flash_swap для заимствования большого количества токенов SUI в обмен на HasUI. В отличие от традиционных флэш-займов, flash_swap в Cetus позволяет пользователю получить token1 (в данном случае SUI) авансом, а затем погасить токен0 (hasUI) в рамках той же транзакции. Этот механизм занимает центральное место в настройке злоумышленника. В данном конкретном случае злоумышленник успешно приобрел 5,76 миллиона SUI и был обязан выплатить 10,02 миллиона HASUI. Но во время этого обмена цена HasUI в пуле ликвидности была сильно изменена. Цена пула была снижена с такта, равного 1,056, до такого низкого значения, что цена составила всего 0,0000009977, что стало огромным падением цены до 0,00009% от первоначальной цены. Ценовой диапазон, соответствующий диапазону тиков, составляет: Стратегическое вливание ликвидности После падения цен злоумышленник использовал open_position для создания позиции ликвидности с узким диапазоном, выбрав строго определенный диапазон тиков (TickLower: 300000, TickUpper: 300200). В этой манипулированной среде они вложили астрономический объем ликвидности: более 10^34 единиц, причем все они находились в сверхсжатом ценовом диапазоне, возникшем в результате обвала тиков. Это стало возможным благодаря, казалось бы, безобидной функции: get_amount_by_liquidity. В обычных условиях эта функция вычисляет, сколько токенов A и токенов B необходимо для достижения определенного уровня ликвидности. Для этого используются вспомогательные функции, такие как get_delta_a, использующие get_sqrt_price_at_tick. Однако из-за того, что текущий тик, которым манипулируют, составляет -138185, а выбранный диапазон тиков находится далеко за его пределами (начиная с 300000), логический путь в get_amount_by_liquidity обеспечивал прохождение вычислений через уязвимый участок кода, где была задействована операция сдвига влево (checked_shlw). Переполнение и усечение: основная уязвимость Здесь эксплойт становится по-настоящему техническим. Функция checked_shlw должна обрабатывать сдвиг 256-битного числа влево на 64 бита. В средах, подобных Solidity, такая операция рискованна, так как она может переполниться. В этой конкретной реализации была предпринята попытка обнаружить переполнение путем проверки того, превышают ли входные данные заранее заданное пороговое значение: 0xfffffffffffffffffff << 192. Фактическое пороговое значение для обнаружения безопасного сдвига на 64 бита должно быть равно 2^ (256—64) — 1. Однако значение (0xfffffffffffffffffffff << 192) больше 2^192. Это означает, что тщательно подобранные входные данные могут обойти проверку на переполнение, поскольку они будут ниже порогового значения, используемого в коде, но при этом будут достаточно большими, чтобы вызвать переполнение во время выполнения. Злоумышленник ввел такие входные данные, в результате чего прирост ликвидности и разницы в цене переполнился бесшумно, в результате чего было получено гораздо меньшее значение, чем предполагалось, — фактически, почти нулевое. В результате протокол подсчитал, что злоумышленнику достаточно заплатить незначительное количество токенов (по сути, одну единицу), чтобы увеличить объем ликвидности в пуле. Этот просчет позволил злоумышленнику вливать огромные объемы ликвидности без реальных затрат. Впоследствии злоумышленник удалил добавленную ликвидность с помощью remove_liquidity и завершил атаку, выплатив неоплаченные токены flash_swap через repay_flash_swap. Злоумышленник получил прибыль в размере 5 765 124 SUI и 10 024 321 HASUI. Наконец, команда Cetus устранила уязвимость с помощью двух PR: https://github.com/CetusProtocol/integer-mate/pull/6/files Компания Cetus быстро выпустила патч для своего репозитория с целыми числами: первым запросом на перенос была предпринята попытка усовершенствовать функцию обнаружения переполнения. Однако этого первоначального исправления оказалось недостаточно. Использовалась маска размером 1 << 192, которая по-прежнему позволяла пропускать значения в крайних регистрах. Затем последовал второй запрос на перенос данных, после чего последовало более строгое сравнение: проверялось, что входные данные больше или равны 2^192, что позволило обеспечить надлежащие границы для безопасного смещения влево. Только благодаря этому исправлению уязвимость была эффективно устранена. https://github.com/CetusProtocol/integer-mate/pull/7/files
- Sui
2
0xduckmove308
May 31, 2025
Статья
Превращение кошельков в программируемые, компонуемые смарт-агенты.
Account.tech — это платформа с открытым исходным кодом на блокчейне Sui, которая широко внедряет смарт-счета Гибкие, безопасные и настраиваемые объекты учетных записей, которые могут выполнять действия в блокчейне с помощью модульной архитектуры, основанной на намерениях. Представьте себе программируемые кошельки с встроенной поддержкой мультиподписи, логики DAO, выполнения по расписанию, динамического контроля доступа и многого другого. Почему смарт-аккаунты? Традиционные учетные записи — это просто пассивные контейнеры. Они хранят активы и подписывают транзакции. Смарт-счета — это активные программируемые объекты, которые могут определять логику владения, автоматизировать рабочие процессы и управлять активами на основе правил. В Account.Tech эти правила действуют в блокчейне, их можно настраивать с помощью модулей Move, а применять их можно с помощью Intents. Ключевые понятия Структура смарт-аккаунта public struct Account has key, store { id: UID, metadata: Metadata, deps: Deps, intents: Intents, config: Config, } Смарт-аккаунт — это общий объект, содержащий: Метаданные: описательная информация Deps — используемые пакеты зависимостей Намерения — отложенные или активные запросы на выполнение действий Конфигурация — настраиваемый набор правил (например, мультиподпись, логика на основе ролей, логика DAO) Каждая учетная запись имеет уникальный модуль Config, который определяет, как решаются намерения. Выполнение на основе намерений Намерение — это структурированный запрос на выполнение одного или нескольких действий в блокчейне. Он состоит из трех этапов: [ ] Запрос: пользователь создает намерение с помощью действий [ ] Разрешение — модуль конфигурации проверяет, соблюдены ли условия [ ] Исполнение — любой может выполнить намерение, если оно действительно Пример: намерение перевести средства с несколькими подписями будет реализовано только после его одобрения достаточным количеством участников. Действия = модульные исполнительные блоки Каждое действие представляет собой отдельную структуру Move, например: struct WithdrawAction { object_id: ID } struct TransferAction { recipient: address } В одном намерении можно создать несколько действий. Например: Withdraw → Transfer → Withdraw → Transfer Это позволяет использовать расширенные рабочие процессы, такие как атомарные свопы, пакетные передачи, выпуск хранилищ по времени и т. д. Конфигурация: настраиваемая логика владения Тип конфигурации определяет способ разрешения намерений. Вы можете подключить такую логику, как: ✅ Мультиподпись с взвешенными голосами 🔐 Управление доступом на основе ролей 🗳 Логика голосования в DAO ⏳ Временные задержки или повторяющиеся задачи 💾 Потоки восстановления Каждое намерение отслеживает результат, отражающий статус решения (например, количество полученных голосов, одобрение и т. д.). Узнайте больше 🔗 Документация: https://account-tech.gitbook.io/docs 🧑‍💻 GitHub: https://github.com/account-tech
- Sui
1
0xduckmove308
May 30, 2025
Статья
Кодирование BCS в Sui: что это такое и почему это важно
Если вы работаете на Sui или возитесь с Move, вы, вероятно, слышали термин BCS. Это сокращение от слова «машина для форматирования бинарной канонической сериализации», изначально созданная для блокчейна Diem, а теперь ставшая краеугольным камнем экосистем на основе Move, таких как Sui, Aptos, Starcoin и 0L. Так что да, вам лучше освоиться, если вы серьезно относитесь к строительству в этом пространстве. Что такое BCS? Бинарная каноническая сериализация (BCS) — это формат, используемый для сериализации (кодирования) и десериализации (декодирования) структурированных данных в байты. Вы увидите, что он используется в следующих случаях: Кодирование транзакций перед подписанием. Отправка или анализ событий из блокчейна. Взаимодействие со смарт-контрактами Move вне сети с помощью JavaScript. Но BCS не включает информацию о типе в байты. Это означает, что при декодировании необходимо заранее знать структуру, в отличие от таких форматов, как JSON или Protocol Buffers, которые описывают себя более легко. Ключевые особенности BCS Метаданные типа отсутствуют Сериализованные выходные данные не содержат подсказок о типах полей. Вы должны знать, с чем имеете дело при декодировании. Сериализация, зависящая от заказа Структуры кодируются в точном порядке полей. Измените порядок, и десериализация прервется. Вот почему функции peel_* в Move должны соответствовать макету структуры 1:1. Универсальный тип В такой структуре, как: struct BCSObject has drop, copy { id: ID, owner: address, meta: Metadata, generic: T } Вы можете надежно десериализовать только до метаполя. Универсальные типы затрудняют синтаксический анализ BCS, поэтому всегда ставьте их в последнюю очередь, если хотите безопасно декодировать данные. Использование BCS в JavaScript Благодаря библиотеке @mysten /bcs вы можете работать с BCS на JS как профессионал. npm i @mysten/bcs и базовый пример: import { BCS, getSuiMoveConfig } from "@mysten/bcs"; const bcs = new BCS(getSuiMoveConfig()); const ser = bcs.ser(BCS.U16, 10); console.log(ser.toBytes()); // [0x0a, 0x00] const des = bcs.de(BCS.U16, ser.toBytes()); console.log(des); // 10 Можно также сериализовать векторы и строки: bcs.ser("vector", [1, 2, 3, 4]); // 04 01 02 03 04 bcs.ser(BCS.STRING, "test string"); // 0b7465737420737472696e67 Регистрация пользовательских типов Допустим, у вас есть следующие структуры Move: struct Metadata has drop, copy { name: std::ascii::String } struct BCSObject has drop, copy { id: ID, owner: address, meta: Metadata } Вы можете зарегистрировать их следующим образом в JS: bcs.registerStructType("Metadata", { name: BCS.STRING, }); bcs.registerStructType("BCSObject", { id: BCS.ADDRESS, owner: BCS.ADDRESS, meta: "Metadata", }); Пример сериализации и десериализации Сериализация JavaScript: const bytes = bcs .ser("BCSObject", { id: "0x0000000000000000000000000000000000000005", owner: "0x000000000000000000000000000000000000000a", meta: { name: "aaa" } }) .toString("hex"); console.log("Hex:", bytes); Вывод может быть: 0x0000000000000000000000000000000000000005000000000000000000000000000000000000000a03616161 Теперь это можно перенести в контракт Move или даже протестировать вручную в интерфейсе командной строки Sui. Система BCS может показаться низкоуровневой и требует большого количества байтов, но как только вы поймете, как она кодирует данные, вы сможете глубже понять, как работают смарт-контракты Move и как безопасно объединять оффчейн-системы onchain ↔. А если вы отлаживаете байты BCS в Sui Explorer (как показано ниже): Кодировка BCS Бинарная каноническая сериализация, или BCS, — это формат сериализации, разработанный в контексте блокчейна Diem и в настоящее время широко используемый в большинстве блокчейнов, основанных на Move (Sui, Starcoin, Aptos, 0L). BCS используется не только в виртуальной машине Move, но и для кодирования транзакций и событий, например для сериализации транзакций перед подписанием или анализа данных событий. Знание принципов работы BCS крайне важно, если вы хотите глубже понять, как работает Move, и стать экспертом по Move. Давайте углубимся в процесс. Спецификация и свойства BCS В оставшейся части урока следует помнить о некоторых высокоуровневых свойствах кодирования BCS: BCS — это формат сериализации данных, в котором полученные выходные байты не содержат никакой информации о типе; поэтому стороне, получающей закодированные байты, необходимо знать, как десериализовать данные В BCS нет структур (поскольку нет типов); структура просто определяет порядок сериализации полей Типы оболочек игнорируются, поэтому OuterType и unnestedType будут иметь одинаковое представление BCS: структура OuterType { владелец: innerType } структура innerType { адрес: адрес } структура unnestedType { адрес: адрес } Типы, содержащие поля универсального типа, можно анализировать вплоть до первого поля универсального типа. Поэтому рекомендуется помещать поля универсального типа в последнюю очередь, если это пользовательский тип, который будет задан или расшифрован. структура BCSObject удалена, скопируйте { идентификатор: ID, владелец: адрес, метаданные: метаданные, общий: T } В этом примере мы можем десериализовать все, вплоть до метаполя. Примитивные типы, такие как целые числа без знака, кодируются в формате Little Endian Вектор сериализуется в виде длины ULEB128 (с максимальной длиной до u32), за которой следует содержимое вектора. Полную спецификацию BCS можно найти в репозитории BCS. Использование библиотеки JavaScript @mysten /bcs Установка Для этой части вам нужно будет установить библиотеку @mysten /bcs. Вы можете установить ее, введя в корневой каталог нодового проекта: npm i @mysten /bcs Базовый пример Давайте сначала воспользуемся библиотекой JavaScript для сериализации и десериализации некоторых простых типов данных: импортируйте {BCS, GetSuimoveConfig} из "@mysten /bcs «; //инициализируем сериализатор с использованием стандартных конфигураций Sui Move константные блоки = новая BCS (getSuimoveConfig ()); //Определение некоторых типов тестовых данных целое число констант = 10; массив констант = [1, 2, 3, 4]; константная строка = «тестовая строка» //используйте bcs.ser () для сериализации данных константа ser_integer = bcs.ser (BCS.U16, целое число); константа ser_array = bcs.ser («вектор», массив); константа ser_string = bcs.ser (строка BCS.STRING); //используйте bcs.de () для десериализации данных константа de_integer = bcs.de (BCS.U16, ser_integer.toBytes ()); константа de_array = bcs.de («вектор», ser_array.toBytes ()); константа de_string = bcs.de (BCS.STRING, ser_string.toBytes ()); Мы можем инициализировать экземпляр сериализатора с помощью встроенной настройки по умолчанию для Sui Move, используя приведенный выше синтаксис, новую BCS (GetSuimoveConfig ()). Существуют встроенные перечисления, которые можно использовать для типов Sui Move, таких как BCS.U16, BCS.STRING и т. д. Для универсальных типов их можно определить, используя тот же синтаксис, что и в Sui Move, например, вектор в приведенном выше примере. Давайте подробнее рассмотрим сериализованные и десериализованные поля: ints — это шестнадцатеричные числа с прямым порядком байтов 0a00 10 первый элемент вектора указывает на общую длину, тогда это просто те элементы, которые есть в векторе 0401020304 1,2,3,4 Строки # — это просто векторы чисел u8, первый элемент которых равен длине строки 0b7465737420737472696e67 тестовая строка Регистрация типа Мы можем зарегистрировать настраиваемые типы, с которыми будем работать, используя следующий синтаксис: импортируйте {BCS, GetSuimoveConfig} из "@mysten /bcs «; константная база данных = новая база данных (getSumiMoveConfig ()); //Зарегистрируйте тип метаданных BCS.registerStructType («Метаданные», { имя: BCS.STRING, }); //То же самое для основного объекта, который мы собираемся прочитать Тип структуры BCS.register («Объект BCS», { //BCS.ADDRESS используется как для типов идентификаторов, так и для типов адресов идентификатор: BCS.ADDRESS, владелец: BCS.ADDRESS, метаданные: «Метаданные», }); Использование bcs в смарт-контрактах Sui Давайте продолжим приведенный выше пример со структурами. Определение структуры Начнем с соответствующих определений структур в контракте Sui Move. { //.. структура Metadata удалена, скопируйте { имя: std: :ascii: :Строка } структура BCSObject удалена, скопируйте { идентификатор: ID, владелец: адрес, метаданные: метаданные } //.. } Десериализация Теперь давайте напишем функцию десериализации объекта в контракте Sui. общедоступный объект from_bytes (bcs_bytes: вектор): bcsObject { //Инициализирует экземпляр bcs bytes пусть bcs = bcs: :new (bcs_bytes); //Используйте peel_*функции для удаления значений из сериализованных байтов. //Порядок должен быть таким же, каким мы пользовались при сериализации! let (id, владелец, мета) = ( bcs: :peel_address (&mut bcs), bcs: :peel_address (&mut bcs), bcs: :peel_vec_u8 (&mut bcs) ); //Упаковываем структуру BCSObject с результатами сериализации BCSObject {id: объект: :id_from_address (id), владелец, метаданные: Metadata {имя: std: :ascii: :string (meta)}}} Различные методы peel_* в модуле Sui Frame bcs используются для «очистки» каждого отдельного поля от сериализованных байтов BCS. Обратите внимание, что порядок удаления полей должен точно совпадать с порядком полей в определении структуры. Тест: Почему результаты первых двух вызовов peel_address для одного и того же объекта bcs разные? Также обратите внимание, как мы преобразуем типы из адреса в идентификатор и из вектора в std: :ascii: :string с помощью вспомогательных функций. Тест: Что произойдет, если BSCObject будет использовать тип UID вместо типа идентификатора? Полный пример пользователя и разработчика Полные примеры кодов JavaScript и Sui Move можно найти в папке example_projects. Сначала мы сериализуем тестовый объект с помощью программы JavaScript: //Мы создаем тестовый объект для сериализации, обратите внимание, что мы можем указать формат вывода в шестнадцатеричном формате пусть _bytes = bcs .ser («объект BCS», { идентификатор: «0x00000000000000000000000000000000000000000005", владелец: «0x00000000000000000000000000000000000000000000000a», метаданные: {имя: «aaa"} }) .toString («шестнадцатеричное число»); Мы хотим, чтобы на этот раз выходные данные редактора BCS были в шестнадцатеричном формате, который можно указать, как указано выше. Прикрепите шестнадцатеричную строку результата сериализации к префиксу 0x и экспортируйте в переменную окружения: экспорт объекта object_hexstring=0x0000000000000000000000000000000000000000000000000000000000000000000000000000000a03616161 Теперь мы можем запустить соответствующие модульные тесты Move, чтобы проверить правильность: sui move test Вы должны увидеть следующее в консоли: СБОРКА bcs_move Запуск модульных тестов Move [PASS] 0x0: :bcs_object: :test_десериализация Результат теста: ОК. Всего тестов: 1; пройдено: 1; не удалось: 0 Или мы можем опубликовать модуль (экспортировать PACKAGE_ID) и вызвать метод emit_object, используя приведенную выше сериализованную шестнадцатеричную строку BCS: клиент sui вызывает функцию emit_object --module bcs_object --package $PACKAGE_ID --args $OBJECT_HEXSTRING Затем мы можем проверить вкладку «События» транзакции в Sui Explorer и убедиться, что мы создали правильно десериализованный объект BCSObject:
- Sui
- SDKs and Developer Tools
1
Vens.sui134
May 29, 2025
Статья
Взлом протокола Cetus — крупнейший эксплойт DeFi на Sui
В мае 2025 года мир DeFi потрясло одно из самых серьезных нарушений безопасности в новейшей истории. Cetus Protocol, ведущая децентрализованная биржа (DEX) и протокол ликвидности на блокчейне Sui, стал жертвой изощренного взлома, в результате которого убытки превысили 200 миллионов долларов. Этот инцидент не только потряс сообщество DeFi, но и вызвал серьезные опасения по поводу безопасности смарт-контрактов и надежности протоколов, созданных на основе новых блокчейнов, таких как Sui. Протокол Cetus зарекомендовал себя как главный протокол DEX в сети Sui, предлагающий пользователям платформу для обмена токенами и обеспечения ликвидности. Являясь ключевым компонентом инфраструктуры экосистемы Sui, Cetus сыграл важную роль в содействии децентрализованной торговле и повышении общей ликвидности сети. Благодаря своей известности она стала привлекательной мишенью для злоумышленников, стремящихся использовать уязвимости в кодовой базе этой платформы. Разворачивается хакерская атака Cetus Взлом произошел 22 мая 2025 года, когда злоумышленники обнаружили и использовали критический недостаток в логике смарт-контрактов Cetus. В частности, уязвимость была вызвана незаметной арифметической ошибкой, которая позволила хакеру манипулировать внутренними механизмами бухгалтерского учета протокола. Используя поддельные токены и манипулируя ценовыми кривыми в пулах ликвидности, злоумышленник смог вывести огромные суммы средств без запуска систем мгновенного обнаружения. Примерно в 3:52 утра по московскому времени (11:52 UTC) наблюдатели блокчейна начали обнаруживать нерегулярные транзакции в нескольких пулах ликвидности на Cetus. Уже через несколько часов масштаб ущерба стал ясен — из протокола было изъято активы на сумму более 260 миллионов долларов. Украденные средства были быстро обменены и переведены в другие блокчейны, что усложнило процесс восстановления. Влияние на рынок и экосистему Sui Последствия взлома были быстрыми и серьезными. Торговля Cetus была немедленно остановлена, поскольку разработчики пытались оценить ситуацию и минимизировать дальнейшие убытки. Тем временем стоимость нативных токенов, связанных с платформой, резко упала, а стоимость некоторых токенов за считанные часы упала до 80%. Инвесторы и пользователи понесли огромные убытки, а доверие к экосистеме Sui пошатнулось. Одно из особенно тревожных событий произошло, когда сеть Sui предприняла противоречивую контрмеру: проголосовала за блокировку кошелька злоумышленника, в котором хранились похищенные средства на сумму 160 миллионов долларов. Хотя этот шаг продемонстрировал проактивный подход к возвращению активов, он также вызвал споры о принципах децентрализации и о том, подрывают ли такие действия доверие к неизменности транзакций в блокчейне. В одночасье курс SUI упал на 5%, а CETUS — на 40%. Этот скачок был одновременно невероятным и ужасающим. Технические подробности уязвимости протокола Cetus Согласно анализу, проведенному компанией Halborn, занимающейся кибербезопасностью, основная причина уязвимости заключается в том, как компания Cetus проверяла определенные арифметические операции во время обмена токенами. Недосмотр при обработке больших чисел привел к ситуации переполнения, которой злоумышленник умело манипулировал, создавая искусственные дисбалансы в пулах ликвидности. Затем эти дисбалансы были использованы для извлечения реальных активов из системы без предоставления надлежащей компенсации поставщикам ликвидности. Этот тип уязвимости особенно опасен, поскольку он не всегда проявляется в нормальных рабочих условиях; напротив, для срабатывания таких уязвимостей требуются определенные крайние случаи, связанные с очень большими суммами или необычными последовательностями транзакций. Такие ошибки, как известно, трудно обнаружить на стандартных этапах аудита и тестирования, поэтому их чаще всего могут использовать злоумышленники, располагающие достаточными ресурсами. Усилия по реагированию и восстановлению от Cetus и Sui Foundation (также известного как Mysten Labs) По сообщениям, во время атаки было заморожено около 160 миллионов долларов, которые будут возвращены в пулы Cetus. Вот почему фонд All Sui инициировал голосование за размораживание этих токенов. После атаки команда Cetus опубликовала публичные заявления, в которых признала нарушение и изложила шаги по его устранению. Они тесно сотрудничали с компаниями, занимающимися аналитикой блокчейна, такими как Elliptic и Chainalysis, чтобы отслеживать перемещение украденных средств и выявлять потенциальные пути их восстановления. Кроме того, обсуждался вопрос о внедрении экстренных обновлений для устранения существующих уязвимостей и повышения устойчивости к аналогичным атакам в будущем. Члены сообщества неоднозначно отреагировали на эти события. В то время как многие высоко оценили прозрачность, продемонстрированную руководством Cetus после взлома, другие подвергли критике неготовность к подобным сценариям и усомнились в том, что до запуска были приняты достаточные меры безопасности.
- Sui
- Security Protocols
1
HaGiang164
May 25, 2025
Статья
Моя первая статья zKat: аутентификация с сохранением конфиденциальности для публичных блокчейнов
Потому что прозрачность не должна означать раскрытие секретов. Сегодня в большинстве публичных блокчейнов каждая транзакция и идентификация пользователя общедоступны. Хотя прозрачность — одна из самых сильных сторон блокчейна, она достигается в ущерб конфиденциальности, особенно когда речь идет об аутентификации. ZKat (сокращение от «аутентификаторы с нулевым уровнем знаний») — это новый криптографический примитив, который привносит в мир блокчейнов аутентификацию с сохранением конфиденциальности. С помощью ZKat пользователи могут доказать, что они уполномочены выполнять транзакцию, не раскрывая правил или политик, лежащих в основе этой авторизации. ##Проблема традиционных подходов Предыдущие попытки обеспечить конфиденциальность при аутентификации, такие как использованиепороговых подписей, могли скрыть лишь ограниченную информацию. Например, они могли скрыть, какие пользователи подписали транзакцию, но не более того. Они также столкнулись с более сложными политиками аутентификации**(например, комбинациями ролей, идентификаторов или правил). ZKat меняет правила игры следующим образом: Поддержкасколь угодно сложныхполитик Предоставление гибких структур, таких каккомбинации подписей с несколькими схемами Сокрытие всей политики в сокрытии**от общественности ##Как работает ZKAT Для создания ZKat авторы разработаликомпилятор, который превращает широко используемую системуGroth16zk-SNARK в новый тип доказательстваНеинтерактивного нулевого уровня знаний (NIZK), поддерживающийдвусмысленные ключи верификации. Что это значит? Это означает, что проверяющийне может определить, какая политика используется, но доказательства все же убеждают его в ее правильности. Это совершенно новое криптографическое свойство, представленное в статье, и оно лежит в основе того, как ZKat обеспечиваетполитику конфиденциальности. Но авторы не остановились на ZKat. Они пошли еще дальше, выпустивzKat, версию, которая поддерживаетзабываемые обновления. Вкратце: Эмитент политики может обновить политику аутентификации не раскрывая ничего нового Это очень эффективно в реальных блокчейн-системах, где, возможно, придется изменить политику — например, DAO, обновляющие правила голосования, или учреждения, меняющие ключи. Они также изучают возможность использованиярекурсивных zk-proofs, чтобы сделать ZKAT2 масштабируемой и пригодной для интеграции блокчейна. Исследователи внедрили zKat в прототип аутентификации на основе пороговых значений. Их оценка показывает: Производительность не уступает традиционным пороговым значениям ZKat поддерживаетгораздо более сложные политики И все это с минимальными накладными расходами**
- Sui
- Architecture
1
0xduckmove308
May 19, 2025
Статья
Что такое IKA? «Не просто ажиотаж 👀»
(p/s: Это не одно из тех «обновлений web3», которые дают вам три пуха и называют это альфа-версией 😮‍💨) Полный текст статьи читайте на сайте https://x.com/InternSui81687/status/1897309368644985108 Вы когда-нибудь перемещали активы между сетями и чувствовали себя Индианой Джонсом, который избегает ловушек? Да. Это связано с тем, что совместимость в настоящее время = рискованные мосты + центральные точки отказа. Ика говорит: «Нет, мы закончили с этим». Они создают надежную и быструю систему автофокусировки, в которой ваши ключи никому не передаются. Созданная на основе Sui, она использует шифрование Threshold и 2PC-MPC В видео здесь Дэвид Лэш (соучредитель Ika) прямо говорит о том, о чем все думают: совместимость — это нарушение автофокусировки. И вместо того, чтобы написать еще один блог «нам нужно решение», как это делают большинство команд, они потратили два года на то, чтобы привлечь экспертов по безопасности, фанатов искусственного интеллекта и ученых к его созданию. Что они придумали? Система, использующая двухпроцессорный MPC и пороговое шифрование — причудливые слова, которые в принципе означают следующее: ключи остаются у вас, ваши активы не будут переупакованы, как рождественский подарок 2017 года, и все движется чертовски быстро. Например, Ika защищает не только ваши вещи. Она обрабатывает транзакции с задержкой менее секунды и при этом остается децентрализованной. А пока мосты уже не за 8 минут, а вам остается только подтвердить обмен. Они построили его на Суе. И если вы до сих пор спали на Суй, то сон закончился. Объектно-ориентированная модель Суи, невероятно быстрая завершенность и Mysticeti Consensus (да, в том-то и дело, но всё ещё не выдумано) идеально подходят для того, что пытается сделать Айка. Дэвид даже сказал, что выбор Суи был очевиден: в криптографии, где каждый инструмент для разработки выглядит как древний свиток, это редкость. Но что меня действительно впечатлило, так это их взгляд на UX. Лучшая криптовалюта? Такая, которая скучна. Не в плохом смысле, но в духе «просто работает». Айка снимается в будущем, в котором вы даже не подозреваете, что занимаетесь кроссчейном. Никаких всплывающих окон, мостов и поддельных токенов. Просто откройте свой кошелек, одалживайте биткоины в исходном режиме, совершайте обмен между цепочками и продолжайте зарабатывать деньги. Именно об этом мы и просили, но почему-то забыли потребовать. И не думайте, что это только для деджен-братьев. Ika позволяет операторам, работающим в сфере информационных технологий, независимым разработчикам и компаниям внедрять собственные решения по хранению информации (например, «Fireblocks Startpack»), но на стероидах и действительно доступные. Для создания защищенной инфраструктуры больше не требуется установка стоимостью 500 тысяч долларов. Просто Суй, Айка и немного смелости. О, и давайте не будем спать на биткойнах. BTC уже много лет сидит в стороне, как тот чувак, который отказывается присоединиться к игре. Но Ika делает игру доступной для игры. DeFi без упаковки и перемещения — просто заблокируйте игру как исходное программное обеспечение и приступайте к работе. Учреждениям это понравится, потому что оно обеспечивает соответствие требованиям и эффективность. Никаких налоговых пошлин, никаких ловушек для содержания под стражей. Просто чистый капитал. Итак, если вас спросят: «Что ждет криптовалюту в будущем?» не отправляйте им твиты с надписью «Интероперабельность — это будущее»
- Sui
1
RogueRig134
May 13, 2025
Статья
Что такое IKA и почему такой ажиотаж?
@ikadotxyz, сверхбыстрая параллельная сеть MPC на блокчейне Sui, вызывает серьезную озабоченность в связи с ее потенциалом революционизировать безопасность и совместимость Web3. Недавние публикации на X подчеркивают оптимистичные настроения: по сообщениям, IKA торгуется по цене от 4,90 до 10 долларов на предпродажных платформах, таких как Whales, несмотря на предложение токенов в 1 миллиард долларов. Это говорит о возможной рыночной капитализации в миллиарды долларов, если эта динамика сохранится, чему способствовали стратегические инвестиции Фонда Sui в размере 21 миллиона долларов и рекордная художественная кампания SUI NFT в размере 1,4 миллиона долларов. Задержка Ika составляет менее секунды, а также возможность масштабирования на сотни подписавших узлов кардинально ��еняют правила игры в сфере DeFi, децентрализованного хранения данных и межсетевых приложений. Ожидается, что предстоящий запуск токенов IKA на платформе Sui откроет новую утилиту и поспособствует ее дальнейшему внедрению. Пользователи X в восторге от роли IKA в программе лояльности @GiveRep, а некоторые называют ее одной из крупнейших возможностей для раздачи подарков на Sui. Тем не менее, предрыночные цены могут быть нестабильными и спекулятивными, поэтому не гарантируется, что диапазон 4,90—10 долларов сохранится после запуска. Всегда вникайте в основные принципы проекта — обращайтесь к официальным каналам Ika для получения более подробной информации и взвешивайте риски, прежде чем приступать к ним. Экосистема Sui набирает обороты, но в криптовалюте нет ничего надежного
- Sui
- Architecture
1
Rogue129
May 13, 2025
Статья
Настройка узла SUI — подробное руководство
Чтобы настроить узел Sui, вам необходимо установить двоичные файлы Sui, клонировать репозиторий Sui и настроить узел. Вы можете создавать файлы из исходного кода или использовать Docker. После запуска узла вы можете отслеживать его состояние и ход синхронизации. Подробные шаги: Установите двоичные файлы Sui: Следуйте инструкциям в документации Sui для установки двоичных файлов Sui. Если вы используете Docker, следуйте инструкциям в файле Readme для Docker с полным узлом Sui. Если вы создаете файлы из исходного кода, вам необходимо клонировать репозиторий Sui и скомпилировать его. Настройте узел: Полный узел: вы можете настроить узел Sui Full с помощью Docker или путем сборки из исходного кода в соответствии с документацией Sui. Узел валидатора: следуйте инструкциям в разделе «Конфигурация узла валидатора Sui», чтобы настроить узел валидатора. Сюда входят установка и настройка Sui, управление ключами и конфигурация хранилища. Полная конфигурация узла: Выключите любой работающий узел Full. Удалите базу данных и файл genesis.blob. Загрузите исходный код из последней версии. Перезагрузите ветку. Загрузите последнюю версию блоба genesis. При необходимости обновите конфигурационный файл fullnode.yaml. Перезапустите узел Sui Full. Запустите узел: Запустите узел Sui, используя команду, соответствующую вашему способу настройки (например, команды sui-node или Docker). Следите за узлом: Отслеживайте состояние узла, ход синхронизации и журналы, чтобы убедиться в его правильной работе. Используйте такие инструменты, как ведение журнала, отслеживание и метрики, для мониторинга узла. По умолчанию используется порт метрик 9184, но его можно изменить в файле fullnode.yaml. Дополнительные шаги: Регистрация в комитете: если вы используете узл-валидатор, вам необходимо зарегистрироваться в комитете. Ликвидный стейкинг: если вы управляете нодой, вы также можете участвовать в ликвидном стейкинге. Синхронизируйте форк: если вы участвуете в проекте Sui, вам необходимо синхронизировать форк с основным репозиторием. Выполнив следующие действия, вы сможете успешно настроить и запустить узел Sui.
- Sui
1
HaGiang164
May 12, 2025
Статья
«Расшифровка трилогии Sui: создание будущего инфраструктуры Web3
При освоении мира Web3, помимо общепринятого стремления к повышению скорости транзакций и снижению комиссий, все чаще возникают более глубокие структурные проблемы. Как экономично хранить огромные объемы данных? Как надежно защитить конфиденциальную информацию в децентрализованной среде? Можно ли эффективно выполнять сложные вычисления вне сети, сохраняя при этом проверку результатов и доверие к ним в блокчейне? Многие проекты пытаются решить эти проблемы путем объединения различных сторонних сервисов. Однако такой путь часто сопряжен со сложностями интеграции, потенциальными проблемами доверия и фрагментированным пользовательским интерфейсом. Столкнувшись с этими проблемами на уровне инфраструктуры, блокчейн Sui и его основная команда разработчиков Mysten Labs предложили более интегрированное решение. Вместо того чтобы полагаться на множество внешних инструментов, они разработали блокчейн с уникальной архитектурой, включающей объектно-ориентированную модель и язык программирования Move, и одновременно создали три тесно связанных компонента нативной инфраструктуры: Walrus, Seal и Nautilus. В этой статье мы рассмотрим концепции проектирования, лежащие в основе этих трех компонентов, рассмотрим, как они работают, как они связаны друг с другом и какие реальные изменения они могут внести в приложения Web3. Уникальная архитектура Суи Чтобы понять, как эти три инструмента работают на Sui, мы должны сначала рассмотреть некоторые ключевые характеристики самой платформы Sui. Одним из основных нововведений Sui является объектно-ориентированная модель, которая представляет собой фундаментальный отход от традиционной архитектуры на основе учетных записей. Sui рассматривает токены, NFT и даже сложные структуры данных как отдельные «объекты». Представьте, что вы управляете каждым активом в отдельном поле вместо того, чтобы регистрировать все в одном реестре. Такая конструкция позволяет параллельно обрабатывать несвязанные действия, такие как обработка двух несвязанных NFT, что повышает пропускную способность. Такая детализация объектов обеспечивает естественное взаимодействие с Walrus и Seal: Walrus рассматривает сохраненные данные как объекты, а Seal может привязывать правила разрешений непосредственно к отдельным объектам. Кроме того, Sui использует язык программирования Move, разработанный специально для управления цифровыми активами. Move делает упор на безопасность и нацелен на устранение многих распространенных уязвимостей смарт-контрактов на языковом уровне. Эта прочная основа делает его подходящим для создания надежных компонентов инфраструктуры. Объединяя проектирование цепочки и разработку инфраструктуры под одной крышей (Mysten Labs), компания Sui стремится обеспечить более эффективную и синергетическую работу разработчиков. Walrus: экономичное программируемое децентрализованное хранилище Как известно, хранение больших файлов (изображений, видео, моделей искусственного интеллекта, которые в совокупности называются блобами) непосредственно в блокчейне обходится дорого. Каждое из существующих решений для децентрализованного хранения данных имеет свои компромиссы, но компания Walrus стремится найти новый баланс между экономичностью и интерактивностью смарт-контрактов, напрямую устраняя ценовые барьеры, связанные с большими объемами данных в сети. В основе технологии Walrus лежит технология Erasure Coding — хитроумная технология, позволяющая «разделять» файл на части и добавлять «ключи к восстановлению», благодаря чему файл можно восстановить даже в случае потери его частей. Уолрус называет эти лишние фрагменты «красным материалом». Подумайте об этом так: если у вас есть два числа, скажем, 3 и 5, и вы храните оба числа, а также их сумму (8), потеря 3 не является катастрофой — вы можете восстановить их, используя 8—5 = 3. Дополнительные фрагменты восстановления играют аналогичную роль и математически привязаны к оригиналам. После фрагментации и кодирования Walrus распределяет эти осколки по многим узлам. Даже если некоторые фрагменты пропадут, система может восстановить исходный файл до тех пор, пока будет извлечено пороговое количество фрагментов, что значительно экономит место по сравнению с полной репликацией файлов. Такой подход значительно снижает затраты на хранение и может приблизить цены на децентрализованные хранилища к ценам поставщиков централизованных облачных услуг. Что еще более интересно, Walrus использует объектную модель Sui: каждый сохраненный файл становится программируемым сетевым объектом. Разработчики могут использовать Move для написания смарт-контрактов для управления этими объектами хранения (настройка правил доступа, автоматическое обновление метаданных и т. д. Хранилище теперь не просто пассивное, оно становится ресурсом, программируемым по умолчанию). Существует также полезный уровень токенов: для работы с данными Walrus на Sui требуются токены SUI для записи метаданных (таких как имена файлов, их размеры, места хранения) и потенциальной блокировки токенов в качестве платы за хранение. Если распространение Walrus будет расти, спрос на SUI может возрасти, что приведет к сокращению предложения. Печать: децентрализованное хранилище и шлюз доступа Многие приложения Web3 работают с конфиденциальными данными: идентификаторами пользователей, финансовыми данными, платным контентом. Как безопасно хранить секреты и контролировать доступ к ним в децентрализованном контексте? Seal — это решение для децентрализованного управления секретами (DSM), предназначенное для ответа на этот вопрос. Одна из основных технологий — пороговое шифрование. Представьте себе хранилище, для открытия которого требуется два ключа, каждый из которых находится у другого человека. Аналогичным образом, пороговое шифрование разделяет ключи дешифрования на несколько частей и распределяет их между независимыми серверами ключей. Данные можно расшифровать только в том случае, если заданное количество пользователей взаимодействует друг с другом (пороговое значение). Ни один сервер не сможет сделать это в одиночку, что способствует росту доверия и повышению отказоустойчивости. Другая хитроумная особенность Seal заключается в том, что логика управления доступом написана в виде смарт-контрактов Move onchain. Разработчики могут устанавливать четкие правила: например, только пользователи, владеющие определенным NFT или заплатившие определенную плату, могут получить доступ к определенным данным. Эта прозрачность и проверяемость отличают Seal от традиционных централизованных систем доступа. Когда пользователь или приложение хочет расшифровать секрет, оно отправляет запрос на ключевые серверы. Эти серверы проверяют правила блокчейна. Только при соблюдении условий они выпускают свои фрагменты ключей. Фактическое дешифрование происходит на клиентском устройстве, поэтому ключевые серверы никогда не обрабатывают исходные данные. Seal может защитить данные, хранящиеся где угодно — в Walrus, других децентрализованных сетях или даже в централизованных облаках. Это делает его идеальным решением для безопасного обмена сообщениями, конфиденциальных пользовательских данных, сбора платного контента, конфиденциального голосования и многого другого. Nautilus: как сделать внесетевые вычисления проверяемыми в сети Блокчейн не очень хорошо справляется со сложными или ресурсоемкими задачами. Их выполнение в блокчейне занимает много времени, требует больших затрат и ставит под угрозу конфиденциальность. Такие решения, как Layer 2 или Oracles, помогают, но Nautilus ищет другой путь: внедряет надежные внесетевые вычисления. Nautilus использует аппаратное решение под названием Trusted Execution Environments (TEE). Представьте себе TEE как безопасную изолированную зону внутри процессора. Код и данные в этой зоне защищены от остальной части системы, включая саму операционную систему. Базовый рабочий процесс выглядит следующим образом: Разработчик передает вычислительную задачу (например, финансовые модели, искусственный интеллект, игровую логику) контролируемому им TEE. По завершении задачи TEE выдает криптографическую справку — своего рода защищенную от несанкционированного доступа «квитанцию», подтверждающую следующее: задание выполнено в формате TEE код не был подделан процесс успешно завершен. Это свидетельство и результаты передаются в смарт-контракт Move on Sui. Контракт подтверждает сертификацию (например, действительность подписи и хэш кода). Только после прохождения проверки контракт принимает результат и переходит к действиям в сети. Nautilus объединяет высокопроизводительные внесетевые вычисления с возможностью проверки и доверия в сети, не раскрывая конфиденциальных данных. «Наутилус» в действии: случай голубого тунца Конкретный пример — децентрализованная платформа для бессрочной торговли Bluefin. Большинство высокопроизводительных торговых платформ сталкиваются с дилеммой: полное хранение книг ордеров в сети обеспечивает прозрачность, но требует больших затрат и времени; перенос их из сети повышает скорость, но создает проблемы с доверием. Чтобы преодолеть этот разрыв, Bluefin использует Nautilus: • Сопоставление заказов выполняется в TEE, что обеспечивает безопасную и изолированную обработку. • Nautilus предоставляет криптографическое доказательство того, что логика сопоставления работала правильно. • Доказательства и результаты представляются в блокчейне, где смарт-контракты проверяют их перед выполнением расчетов. Такой подход позволяет компании Bluefin предлагать быстрые и надежные внутрисетевые инструменты, гарантирующие доверие, что делает ее пригодной для торговли деривативами с высоким уровнем производительности, например деривативами. Конечно, это в некоторой степени смещает доверие с консенсуса, основанного исключительно на блокчейне, на аппаратное обеспечение и внедрение TEE.
- Sui
- Architecture
1