Главная
Добро пожаловать на форум сообщества Sui
Заработай свою долю из 1000 Sui
Зарабатывай очки репутации и получай награды за помощь в развитии сообщества Sui.
Посты с вознаграждением
+10
Экспертные Вопросы и ОтветыMay 29, 2025Почему BCS требует точного порядка полей для десериализации, когда структуры Move содержат именованные поля?
Почему BCS требует точного порядка полей для десериализации, если структуры Move содержат именованные поля? Я углубился в кодирование/декодирование BCS в Move, особенно в том, что касается межсетевой связи и обработки данных вне сети. Изучая примеры из документации Sui Move, я обнаружил, что некоторые действия кажутся мне нелогичными, и я пытаюсь понять основные проектные решения. Согласно спецификации BCS, «в BCS нет структур (поскольку нет типов); структура просто определяет порядок сериализации полей». Это означает, что при десериализации мы должны использовать peel_*функции в том же порядке, в котором указано определение поля структуры. Мои конкретные вопросы: Обоснование проектирования: почему BCS требует точного сопоставления порядка полей, если в структурах Move есть именованные поля? Не лучше ли сериализовать имена полей вместе со значениями, подобно JSON или другим форматам самоописания? Взаимодействие универсальных типов: в документации упоминается, что «типы, содержащие поля универсальных типов, могут быть проанализированы вплоть до первого поля универсального типа». Рассмотрим следующую структуру: struct ComplexObject has drop, copy { id: ID, owner: address, metadata: Metadata, generic_data: T, more_metadata: String, another_generic: U } Как именно здесь работает частичная десериализация? Можно ли десериализовать до more_metadata и игнорировать оба общих поля или первое универсальное поле (generic_data) полностью заблокирует дальнейшую десериализацию? Межъязыковая согласованность: при испо��ьзовании библиотеки JavaScript @mysten /bcs для сериализации данных, которые будут использоваться контрактами Move, что произойдет, если: Я случайно изменил порядок полей в объекте JavaScript? Определение структуры Move меняет порядок полей при обновлении контракта? У меня есть вложенные структуры со своими общими параметрами? Практические последствия: как команды справляются с эволюцией схем BCS в производственных системах? Вы редактируете свои схемы BCS или ожидаете, что порядок полей структуры после развертывания останется неизменным?
- Sui
- Move
51+10
Экспертные Вопросы и ОтветыMar 05, 2025«Ошибки проверки нескольких источников» в публикациях модуля Sui Move — автоматическое устранение ошибок
При публикации или обновлении модулей разработчики, работающие с Sui Move, часто сталкиваются с проблемой «Обнаружено несколько ошибок проверки исходного кода». Эти ошибки возникают из-за несоответствия между локальными зависимостями и их аналогами в блокчейне, что приводит к неудачным публикациям и проблемам с развертыванием. Ниже приведен сводный пример ошибок, с которыми сталкиваются разработчики: Failed to publish the Move module(s), reason: [warning] Multiple source verification errors found: Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::vec_set Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::vec_map Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000001::MoveStdlib::bit_vector Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000001::MoveStdlib::ascii Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::hex Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::zklogin_verified_id Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::prover Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::coin Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::dynamic_field Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::transfer On-chain version of dependency Sui::zklogin_verified_id was not found. On-chain version of dependency Sui::zklogin_verified_issuer was not found. Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::tx_context Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::transfer_policy Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::kiosk Эта проблема часто возникает из-за: Несовпадающие версии между локальной средой разработки (например, Sui CLI) и состоянием сети. Различия в конфигурациях пакетов в разных сетях (например, Mainnet и Testnet). Отсутствующие или устаревшие зависимости в ончейн-среде. Ключевые вопросы Как автоматизировать выявление и устранение этих несоответствий зависимостей в процессе публикации? Какие инструменты или скрипты можно разработать, чтобы локальные зависимости всегда соответствовали их аналогам в блокчейне? Есть ли способ упростить этот процесс, интегрировав проверки зависимостей в существующие конвейеры CI/CD или улучшив Sui SDK? Ваша задача — предложить решение, позволяющее решить эти проблемы и обеспечить более плавное и надежное развертывание для разработчиков Sui Move. Обязательно опубликуйте свое решение ниже.
- Sui
- SDKs and Developer Tools
41Лучший ответ

- 0xduckmove... SUI+68
1
- MiniBob... SUI+57
2
- harry phan... SUI+51
3
- ... SUIRogue+47
- ... SUIRogueRig+44
- ... SUIHaGiang+36
- ... SUIPeera Admin+25
- ... SUIVens.sui+20
- ... SUIMarlKey+20
- ... SUIdudley_smith+16
Новые статьи
- Превращение кошельков в программируемые, компонуемые смарт-агенты.Статья0xduckmove288May 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
1 - Кодирование BCS в Sui: что это такое и почему это важноСтатья0xduckmove288May 30, 2025
Если вы работаете на 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:
1 - Взлом протокола Cetus — крупнейший эксплойт DeFi на SuiСтатьяVens.sui134May 29, 2025
В мае 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 после взлома, другие подвергли критике неготовность к подобным сценариям и усомнились в том, что до запуска были приняты достаточные меры безопасности.
1 - Моя первая статья zKat: аутентификация с сохранением конфиденциальности для публичных блокчейновСтатьяHaGiang144May 25, 2025
Потому что прозрачность не должна означать раскрытие секретов. Сегодня в большинстве публичных блокчейнов каждая транзакция и идентификация пользователя общедоступны. Хотя прозрачность — одна из самых сильных сторон блокчейна, она достигается в ущерб конфиденциальности, особенно когда речь идет об аутентификации. ZKat (сокращение от «аутентификаторы с нулевым уровнем знаний») — это новый криптографический примитив, который привносит в мир блокчейнов аутентификацию с сохранением конфиденциальности. С помощью ZKat пользователи могут доказать, что они уполномочены выполнять транзакцию, не раскрывая правил или политик, лежащих в основе этой авторизации. ##Проблема традиционных подходов Предыдущие попытки обеспечить конфиденциальность при аутентификации, такие как использованиепороговых подписей, могли скрыть лишь ограниченную информацию. Например, они могли скрыть, какие пользователи подписали транзакцию, но не более того. Они также столкнулись с более сложными политиками аутентификации**(например, комбинациями ролей, идентификаторов или правил). ZKat меняет правила игры следующим образом: Поддержкасколь угодно сложныхполитик Предоставление гибких структур, таких каккомбинации подписей с несколькими схемами Сокрытие всей политики в сокрытии**от общественности ##Как работает ZKAT Для создания ZKat авторы разработаликомпилятор, который превращает широко используемую системуGroth16zk-SNARK в новый тип доказательстваНеинтерактивного нулевого уровня знаний (NIZK), поддерживающийдвусмысленные ключи верификации. Что это значит? Это означает, что проверяющийне может определить, какая политика используется, но доказательства все же убеждают его в ее правильности. Это совершенно новое криптографическое свойство, представленное в статье, и оно лежит в основе того, как ZKat обеспечиваетполитику конфиденциальности. Но авторы не остановились на ZKat. Они пошли еще дальше, выпустивzKat, версию, которая поддерживаетзабываемые обновления. Вкратце: Эмитент политики может обновить политику аутентификации не раскрывая ничего нового Это очень эффективно в реальных блокчейн-системах, где, возможно, придется изменить политику — например, DAO, обновляющие правила голосования, или учреждения, меняющие ключи. Они также изучают возможность использованиярекурсивных zk-proofs, чтобы сделать ZKAT2 масштабируемой и пригодной для интеграции блокчейна. Исследователи внедрили zKat в прототип аутентификации на основе пороговых значений. Их оценка показывает: Производительность не уступает традиционным пороговым значениям ZKat поддерживаетгораздо более сложные политики И все это с минимальными накладными расходами**
1 - Что такое IKA? «Не просто ажиотаж 👀»Статья0xduckmove288May 19, 2025
(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 без упаковки и перемещения — просто заблокируйте игру как исходное программное обеспечение и приступайте к работе. Учреждениям это понравится, потому что оно обеспечивает соответствие требованиям и эффективность. Никаких налоговых пошлин, никаких ловушек для содержания под стражей. Просто чистый капитал. Итак, если вас спросят: «Что ждет криптовалюту в будущем?» не отправляйте им твиты с надписью «Интероперабельность — это будущее»
1 - Что такое IKA и почему такой ажиотаж?СтатьяRogueRig134May 13, 2025
@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 набирает обороты, но в криптовалюте нет ничего надежного
1 - Настройка узла SUI — подробное руководствоСтатьяRogue129May 13, 2025
Чтобы настроить узел 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.
1 - «Расшифровка трилогии Sui: создание будущего инфраструктуры Web3СтатьяHaGiang144May 12, 2025
При освоении мира 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.
1 - В киоске Sui: как создать безопасные торговые площадки NFTСтатьяHaGiang144May 01, 2025
Что такое киоск Суи? Kiosk — это встроенный модуль смарт-контрактов на блокчейне Sui, предназначенный для стандартизации и упрощения хранения, управления и торговли NFT. Он представляет собой программируемую витрину NFT, идеально подходящую для разработчиков, которые хотят не изобретать велосипед для каждого проекта, связанного с NFT. Независимо от того, создаете ли вы торговую площадку, биржу игровых активов или цифровую галерею коллекционных предметов, Kiosk предлагает вам безопасные настраиваемые строительные блоки. 🛠️ Основные характеристики киоска 📦 Хранение и отображение NFT: пользователи могут вкладывать NFT в смарт-контракты Kiosk, чтобы хранить их, выставлять напоказ или торговать ими 🔐 Безопасная передача прав собственности: все процессы покупки/продажи стандартизированы и поддаются проверке — прощайте, сомнительные свопы 👋 🎛️ Подробные разрешения: Kiosk позволяет разработчикам точно определять, кто и что может делать с каждым NFT. 📈 Расширяемость возможностей разработчиков: подключайте аукционы, пакетные списки, пакеты и многое другое. 🤔 Зачем строить с помощью киоска? Представьте, что вы запускаете приложение NFT. Скорее всего, вам понадобится способ безопасного хранения активов пользователями. Способ размещения и покупки активов. Kiosk сделает все это за вас. Вместо того чтобы писать все эти процессы с нуля (и рисковать ошибками 🐛 или эксплойтами), вы используете проверенный в боях API Kiosk. 🧪 Пример приложения: здание с киоском Давайте перейдем к реальному примеру. Вы создадите базовый модуль NFT, затем с помощью модуля Kiosk внесите его на депозит, разместите его и разрешите другим приобрести его. Пошаговая разбивка кода module 0xNFT::simple_nft { use sui::object::{UID}; use sui::tx_context::TxContext; struct SimpleNFT has key { id: UID, name: String, description: String, url: String, } public entry fun mint( name: String, description: String, url: String, ctx: &mut TxContext ): SimpleNFT { SimpleNFT { id: UID::new(ctx), name, description, url, } } } Команды (для интерфейса командной строки) Compile your package sui move build Deploy to network sui client publish --gas-budget 10000 Mint NFT sui client call --function mint --module simple_nft \ --args "My NFT" "Desc" "https://example.com/img.png" --gas-budget 1000 Initialize Kiosk sui client call --function init_kiosk --module kiosk_example --gas-budget 1000 Deposit NFT to Kiosk sui client call --function deposit_nft --module kiosk_example \ --args --gas-budget 1000 List for sale sui client call --function list_nft_for_sale --module kiosk_example \ --args 100 --gas-budget 1000 Purchase NFT sui client call --function purchase_nft --module kiosk_example \ --args --gas-budget 1000 Kiosk — один из самых мощных примитивов в экосистеме Sui для разработчиков NFT. Он абстрагирует повторяющуюся логику и привносит безопасность и модульность в ваш стек приложений. Всего за несколько строк кода вы создаете полноценные торговые потоки NFT, готовые к запуску и прошедшие боевые испытания.
2 - Язык программирования Move: историяСтатьяMiniBob406Apr 30, 2025
В постоянно меняющемся мире блокчейн-технологий языки программирования смарт-контрактов стали основой децентрализованных приложений (dApps). Среди них Move стал революционной инновацией, предлагающей уникальные функции, отличающие его от традиционных языков, таких как Solidity или Vyper. Разработанный с учетом требований безопасности и масштабируемости, Move был создан для устранения многих уязвимостей и недостатков, присущих предыдущим блокчейн-экосистемам. В этой статье рассказывается об истоках, особенностях и влиянии языка программирования Move, а также о том, как он превратился в один из самых перспективных инструментов для создания надежных децентрализованных систем. Истоки переезда: решение проблем блокчейна Язык программирования Move был впервые представлен компанией Meta (ранее Facebook) в рамках амбициозного проекта Diem (первоначально называвшегося Libra). Целью Diem было создание глобальной цифровой валюты и финансовой инфраструктуры на основе технологии блокчейн. Однако команда быстро поняла, что существующих языков смарт-контрактов недостаточно для их видения. В традиционных языках часто отсутствовали механизмы предотвращения распространенных уязвимостей, таких как повторные атаки, переполнение целых чисел и несанкционированное дублирование ресурсов. Эти проблемы уже нанесли значительный ущерб другим экосистемам, в частности печально известному взлому Ethereum с помощью DAO. Чтобы преодолеть эти трудности, команда инженеров Meta разработала Move, новый язык, специально разработанный для ресурсоориентированного программирования. В отличие от традиционных языков программирования, Move рассматривает цифровые ресурсы как первоклассные ресурсы, гарантирующие, что их нельзя дублировать, непреднамеренно удалять или использовать не по назначению. В основе этого подхода лежала линейная логика — математическая структура, обеспечивающая строгие правила владения ресурсами. Внедрив эти принципы в ядро языка, компания Move изменила парадигму взаимодействия разработчиков с цифровыми активами в блокчейне. Хотя проект Diem в конечном итоге был отложен из-за пристального внимания со стороны регулирующих органов, компания Move нашла новую жизнь в независимых блокчейн-проектах, таких как Aptos и Sui. Эти платформы выбрали Move в качестве основного языка смарт-контрактов, осознав, что этот язык может революционизировать способы создания и защиты децентрализованных приложений. Ключевые особенности Move: чем он выделяется 1. Ресурсно-ориентированное программирование Одной из отличительных черт Move является ориентация на ресурсоориентированное программирование. В Move цифровые активы, такие как токены, NFT или даже специальные объекты, рассматриваются как ресурсы, обладающие строгими правилами владения. Созданный ресурс нельзя копировать или уничтожать без явного разрешения модуля. Это обеспечивает безопасное и надежное выполнение важных операций с активами, таких как переводы или обновление состояния. Например, рассмотрим простую функцию передачи токенов, написанную на языке Move: примеры модулей: :token { используйте sui: :object:: {Self, UID}; используйте sui: :transfer; struct: токен имеет ключ, store { идентификатор: UID, значение: u64, } публичный развлекательный монетный двор (ctx: &mut txContext, значение: u64): токен { Токен { идентификатор: объект: :новый (ctx), значение, } } public fun transfer_token (токен: токен, получатель: адрес) { перевод: :public_transfer (токен, получатель); } } Здесь Token структура представляет собой ресурс, который можно передать только с помощью функции public_transfer. Любая попытка дублировать токен или манипулировать им за пределами этой функции приведет к ошибке компиляции. Этот дизайн устраняет целые классы ошибок и эксплойтов, обычно встречающихся на других языках. 2. Модульность и инкапсуляция Move продвигает модульную конструкцию, позволяя разработчикам инкапсулировать функциональность в автономные модули. Каждый модуль определяет свои типы, функции и средства управления доступом, обеспечивая четкое разделение между различными компонентами смарт-контракта. Например, разработчик может создать отдельные модули для создания токенов, торговых пар и логики управления. Такая модульность повышает читаемость, ремонтопригодность и возможность повторного использования кода. 3. Поддержка формальной верификации Еще одной отличительной особенностью Move является поддержка формальной верификации — процесса, используемого для математического доказательства правильности программы. Формальная верификация помогает выявлять незначительные ошибки и крайние случаи, которые не могут быть обнаружены традиционными методами тестирования. Хотя не все проекты на основе Move требуют формальной проверки, структура языка упрощает применение этого метода при необходимости. 4. Объектно-ориентированный дизайн (специальные усовершенствования) В блокчейне Sui технология Move была дополнительно усовершенствована с помощью объектно-ориентированной модели. Каждый ресурс в Sui Move имеет глобальный уникальный идентификатор (UID), позволяющий напрямую ссылаться на объекты и взаимодействовать с ними. Такая конструкция упрощает сложные рабочие процессы, такие как управление NFT или отслеживание пользовательских данных, сохраняя при этом высокую производительность и масштабируемость. Реальные приложения Move С момента своего внедрения Aptos и Sui приложение Move использовалось для создания широкого спектра децентрализованных приложений. Вот некоторые примечательные примеры: 1. Протоколы децентрализованного финансирования (DeFi) Компания Move уделяет большое внимание безопасности, поэтому она идеально подходит для приложений DeFi, где на карту поставлены активы на миллиарды долларов. Такие проекты, как Cetus — децентрализованная биржа (DEX), построенная на базе SUI, — используют ориентированное на ресурсы программирование Move для внедрения передовых торговых функций и минимизации рисков, связанных с манипуляциями с активами. 2. Невзаимозаменяемые токены (NFT) Торговые площадки NFT значительно выигрыва��т от способности Move определять уникальные цифровые активы и управлять ими. Разработчики могут создавать сложные стандарты NFT с детальным контролем владения, гонораров и метаданных. Кроме того, объектно-ориентированные усовершенствования Sui позволяют беспрепятственно интегрировать динамические NFT, которые могут развиваться в зависимости от заранее определенных условий. 3. Игровые платформы и платформы метавселенной Игры на блокчейне требуют эффективной обработки внутриигровых активов, взаимодействия с игроками и обновлений в реальном времени. Модульная архитектура Move и исполнение с малой задержкой делают игру подходящей для создания иммерсивных игровых процессов. Такие платформы, как Blockus, игровая экосистема Web3, используют Move для поддержки своих децентрализованных игр и экономики. Сравнение перехода с другими языками смарт-контрактов Хотя Move имеет некоторое сходство с другими языками смарт-контрактов, его уникальные функции обеспечивают ему конкурентное преимущество: Надежность: Solidity, являющийся основным языком Ethereum, широко используется, но имеет ряд устаревших проблем, таких как уязвимость к атакам с повторным входом в систему. Компания Move устраняет эти недостатки, используя модель, ориентированную на ресурсы, и повышая безопасность типов. Rust (используется в Solana): Rust обеспечивает отличную производительность и безопасность памяти, но в Move отсутствует встроенная поддержка управления ресурсами и формальной верификации. Кроме того, по сравнению с более интуитивно понятным синтаксисом Rust новичков может отпугнуть новичков. Четкость (используется в Stacks): Clarity подчеркивает прозрачность и предсказуемость, но действует в ограниченном объеме, связанном с экосистемой Биткойна. С другой стороны, Move поддерживает более широкие варианты использования в нескольких блокчейнах. Будущее Move: внедрение и эволюция По мере развития технологии блокчейн спрос на безопасные и масштабируемые языки смарт-контрактов будет только расти. Благодаря инновационному дизайну и растущей поддержке сообщества компания Move готова сыграть ключевую роль в формировании децентрализованных приложений нового поколения. Такие проекты, как Aptos и Sui, активно инвестируют в обучение разработчиков, инструменты и инфраструктуру, чтобы ускорить внедрение Move. Такие инициативы, как платформа электронного обучения Move, предоставляют начинающим разработчикам исчерпывающие учебные пособия и ресурсы, что снижает барьер для входа на рынок. Кроме того, сотрудничество с академическими учреждениями и лидерами отрасли стимулирует исследования по таким сложным темам, как формальная верификация и межсетевая совместимость. Заглядывая в будущее, можно ожидать, что компания Move выйдет за рамки своих текущих сценариев использования и внедрит все: от решений для управления цепочками поставок корпоративного уровня до децентрализованных социальных сетей. Его адаптируемость и надежность гарантируют его актуальность во все более разнообразной и взаимосвязанной блокчейн-экосистеме.
3
Посты
304- Статья0xduckmove288May 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 - Экспертные Вопросы и ОтветыOwen15May 31, 2025
Ошибка проверки типов при использовании настраиваемой структуры в качестве параметра типа в монете Sui Move: :Coin?
Вопрос: Я обнаружил ошибку при проверке типов в моем коде Sui Move, которую я не понимаю. Вот упрощенная версия моего кода: module my_module::mymodule { use sui::coin; use sui::wallets; struct MyCoin has drop {} public fun create_coin(): coin::Coin { coin::mint(1000) } } Когда я пытаюсь скомпилировать, я получаю следующую ошибку: Invalid type parameter instantiation. Expected type 'phantom type T' but found 'MyCoin' Что я делаю не так? Почему я не могу использовать его MyCoinв качестве параметра типа coin::Coinи как решить эту проблему с проверкой типов?
- Sui
- Architecture
01 - Статья0xduckmove288May 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 - ОбсуждениеDRAMA32May 30, 2025
Как управлять доступом к dApp в SUI Wallet без функции отзыва?
Я использовал кошелек SUI и заметил, что нет возможности отозвать доступ к dApps, как в случае с цепочками EVM. Как запретить dApps иметь постоянный доступ к моему кошельку, если в расширении Chrome нет четкой системы отзыва?
- Sui
02 +10
Экспертные Вопросы и ОтветыMay 29, 2025Почему BCS требует точного порядка полей для десериализации, когда структуры Move содержат именованные поля?
Почему BCS требует точного порядка полей для десериализации, если структуры Move содержат именованные поля? Я углубился в кодирование/декодирование BCS в Move, особенно в том, что касается межсетевой связи и обработки данных вне сети. Изучая примеры из документации Sui Move, я обнаружил, что некоторые действия кажутся мне нелогичными, и я пытаюсь понять основные проектные решения. Согласно спецификации BCS, «в BCS нет структур (поскольку нет типов); структура просто определяет порядок сериализации полей». Это означает, что при десериализации мы должны использовать peel_*функции в том же порядке, в котором указано определение поля структуры. Мои конкретные вопросы: Обоснование проектирования: почему BCS требует точного сопоставления порядка полей, если в структурах Move есть именованные поля? Не лучше ли сериализовать имена полей вместе со значениями, подобно JSON или другим форматам самоописания? Взаимодействие универсальных типов: в документации упоминается, что «типы, содержащие поля универсальных типов, могут быть проанализированы вплоть до первого поля универсального типа». Рассмотрим следующую структуру: struct ComplexObject has drop, copy { id: ID, owner: address, metadata: Metadata, generic_data: T, more_metadata: String, another_generic: U } Как именно здесь работает частичная десериализация? Можно ли десериализовать до more_metadata и игнорировать оба общих поля или первое универсальное поле (generic_data) полностью заблокирует дальнейшую десериализацию? Межъязыковая согласованность: при использовании библиотеки JavaScript @mysten /bcs для сериализации данных, которые будут использоваться контрактами Move, что произойдет, если: Я случайно изменил порядок полей в объекте JavaScript? Определение структуры Move меняет порядок полей при обновлении контракта? У меня есть вложенные структуры со своими общими параметрами? Практические последствия: как команды справляются с эволюцией схем BCS в производственных системах? Вы редактируете свои схемы BCS или ожидаете, что порядок полей структуры после развертывания останется неизменным?
- Sui
- Move
51- ОбсуждениеMay 29, 2025
Как найти идентификатор объекта казначейского лимита для того или иного типа монеты?
Я хочу узнать, как получить идентификатор объекта казначейской кепки для монеты, указав только название типа монеты. В настоящее время я извлекаю объект метаданных и проверяю предыдущие транзакции, чтобы найти объект ограничения казначейства, но этот метод кажется неэффективным. Я ищу более простой и эффективный способ определить, заморожен ли монетный двор, используя название типа монеты. Есть предложения?
- Sui
04 - ОбсуждениеTheoremus175May 29, 2025
Как легко скопировать адрес кошелька, который нельзя копировать?
Мне трудно скопировать адрес своего кошелька, потому что его нельзя скопировать напрямую. Я не уверен, что мне не хватает быстрого способа или скрытой функции. Может ли кто-нибудь посоветовать мне, как это сделать?
- Sui
02 - СтатьяVens.sui134May 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 - Экспертные Вопросы и Ответыderiss159May 28, 2025
Завершится ли моя транзакция, если лимит приблизится?
Я получил уведомление с надписью «Приближается глобальный лимит транзакций». Если я начну транзакцию сейчас, будет ли она обработана в течение 24 часов?
- Move
03 - Обсуждениеcod31May 27, 2025
Проблема с обменом кошелька Sui на Cetus и Turbo Finance
Я пытаюсь обменять свой кошелек Sui с помощью Cetus и Turbo Finance, но это не работает. У меня есть около 0,002 SUI в качестве газа. Какие шаги мне следует предпринять для решения этой проблемы?
- Transaction Processing
03
Sui is a Layer 1 protocol blockchain designed as the first internet-scale programmable blockchain platform.
- Sui
- Architecture
- SDKs and Developer Tools
- Move
- Security Protocols
- NFT Ecosystem
- Transaction Processing