В тренде
Откройте для себя самые популярные посты.
Посты
679Бот AMM в экосистеме Sui
Каковы ключевые особенности и функциональные возможности ботов AMM в экосистеме Sui? Как они улучшают традиционные торговые механизмы и какие преимущества они предлагают пользователям, использующим протоколы DeFi в сети Sui? Нужно ли мне его создавать или я могу использовать, например, Turbos Finance
- Sui
82Лучший ответ- Статья0xduckmove618ДляSuiApr 08, 2025
👀 SEAL - Я думаю, что конфиденциальность данных Web3 скоро изменится
👀 SEAL запущен в тестовой сети Sui Testnet — я думаю, что конфиденциальность данных Web3 скоро изменится В Web3 часто можно услышать такие фразы, как* «пользователи владеют своими данными»* или* «децентрализованы по замыслу»*. Но если присмотреться повнимательнее, многие приложения по-прежнему полагаются на централизованную инфраструктуру для обработки конфиденциальных данных — для управления ключами используются такие сервисы, как AWS или Google Cloud. Это приводит к противоречию: децентрализация на первый взгляд, централизация — под ней. Но что, если бы существовал способ безопасного управления секретами, не отказываясь от децентрализации? Представляем SEAL — децентрализованное управление секретами (DSM), которое теперь доступно в Sui Testnet. SEAL призвана исправить одно из самых больших лицемерий Web3: крики о децентрализации при тайном использовании AWS Вы можете спросить меня: что такое SEAL? SEAL — это протокол, который позволяет безопасно идецентрализованноуправлять конфиденциальными данными. Он создан специально для мира Web3. Воспринимайте его как уровень контроля доступа, ориентированный на конфиденциальность и подключаемый к вашему приложению dApp. Вы можете рассматривать SEAL как своего рода программируемую блокировку ваших данных. Вы не просто блокируете и разблокируете данные вручную — вывписываете политики прямо в смарт-контракты, используя Move on Sui. Допустим, вы создаете приложение dApp, в котором: Только владельцы NFT могут разблокировать учебное пособие премиум-класса Или, может быть, DAO должна проголосовать, прежде чем конфиденциальные файлы будут опубликованы Или вы хотите, чтобы метаданные были привязаны к времени и были доступны только после определенной даты SEAL делает все это возможным. Контроль доступа работает «в сетевом режиме», полностью автоматизирован, управление им не требуется со стороны администратора. Просто логика, встроенная прямо в блокчейн. SEAL делает все это возможным. Контроль доступа работает «в сетевом режиме», полностью автоматизирован, управление им не требуется со стороны администратора. Просто логика, встроенная прямо в блокчейн. Еще одна интересная статья — как SEAL обрабатывает шифрование. Он использует так называемоепороговое шифрование**, что означает, что ни один узел не может расшифровать данные. Для совместной работы требуется группа серверов — как в случае с несколькими подписями, но для разблокировки секретов. Это распределяет доверие и позволяет избежать обычной проблемы, возникающей в случае сбоя в одной точке. А чтобы сохранить конфиденциальность информации, SEAL шифрует и дешифрует все, что находится на стороне клиента**. Ваши данные никогда не видны ни одному серверу. Они в буквальном смысле остаются в ваших руках на вашем устройстве. и SEAL безразлично, где вы храните свои данные. Будь то IPFS, Arweave, Walrus или какая-либо другая платформа, SEAL не пытается контролировать эту часть. Основное внимание уделяется только тому, кому разрешено что-либо видеть**, а не тому, где хранятся вещи. Так что да, это не просто библиотека или API — это уровень для вашего dApp, работающий по умолчанию в сети, контролируемый доступом и конфиденциальность**. SEAL заполняет довольно серьезный пробел. Давайте разберемся в этом подробнее. Если вы создаете приложение dApp, которое работает с любыми конфиденциальными данными**— закрытым контентом, пользовательскими документами, зашифрованными сообщениями и даже метаданными NFT, заблокированными по времени, — вы столкнетесь с той же проблемой: ➡️ Как безопасно управлять доступом, не полагаясь на централизованный сервис? Без такого решения, как SEAL, большинство команд тоже: Используйте централизованные инструменты, такие как AWS KMS или Firebase, что явно противоречит децентрализации Или попробуйте самостоятельно исправить недоработанную логику шифрования, которая обычно оказывается хрупкой и трудно поддающейся аудиту https://x.com/EmanAbio/status/1908240279720841425?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1908240279720841425%7Ctwgr%5E697f93dc65359d0c8c7d64ddede66c0c4adeadf1%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.notion.so%2Fharryph%2FSEAL-Launches-on-Sui-Testnet-1cc4f8e09bb380969c0dcc627b96cc22 Ни то, ни другое не очень хорошо масштабируется. Особенно если вы пытаетесь создавать надежные приложения в нескольких сетях или сообществах. SEAL делает весь процесс модульным и программируемым. Вы определяете правила доступа в смарт-контрактах Move, а SEAL берет на себя все остальное — генерацию ключей, одобрение расшифровки и контроль доступа — и все это без необходимости вручную выдавать ключи или проводить внутренние проверки. Более того, эти правилапроверяемы и неизменные— как только они внедряются в блокчейн, они подчиняются контракту, а не администратору-человеку. Поэтому вместо того, чтобы спрашивать: «Кто должен управлять доступом к этим данным?» вы просто спрашиваете: «Какая логика должна определять доступ?» > ... и пусть цепь справится с этим. Чистый и масштабируемый. Именно поэтому SEAL подходит не только для «инструментов безопасности». Это базовый уровень для любого приложения dApp, которое заботится о конфиденциальности, соответствии нормативным требованиям или динамической логике доступа.** Это небольшое изменение, но оно сильно меняет наше представление о данных в Web3. Вместо того чтобы шифровать данные после развертывания или полагаться на внешние сервисы,вы начинаете со встроенных функций обеспечения конфиденциальности, а доступ к ним осуществляется исключительно с помощью логики смарт-контрактов. И это именно то, что сейчас нужно Web3. Как на самом деле работает SEAL? Мы рассмотреличто такое SEALизачем он нужен Web3, давайте посмотрим, как он на самом деле устроен под капотом. В этой части все становится более техническим, но в хорошем смысле. Архитектура выглядит элегантно, как только вы видите, как все элементы сочетаются друг с другом. На высоком уровне SEAL объединяетлогику доступа в блокчейнес управлением ключамивне блокчейна, используя методШифрование на основе идентификационных данных (IBE). Это позволяет разработчикам шифровать данные в виде личности, а затем использовать смарт-контракты для определения того, кому разрешено их расшифровывать. Шаг 1. Правила доступа к смарт-контрактам (на языке Sui) Все начинается со смарт-контракта. Когда вы используете SEAL, вы определяете функцию seal_approve в контракте Move. Здесь вы пишете условия для расшифровки. Например, вот простое правило блокировки времени, написанное в Move: entry fun seal_approve(id: vector, c: &clock::Clock) { let mut prepared: BCS = bcs::new(id); let t = prepared.peel_u64(); let leftovers = prepared.into_remainder_bytes(); assert!((leftovers.length() == 0) && (c.timestamp_ms() >= t), ENoAccess); } После развертывания этот контракт выступает в роли привратника. Всякий раз, когда кто-то захочет расшифровать данные, его запрос будет проверен в соответствии с этой логикой. Если ответ будет принят, ключ будет освобожден. В противном случае они заблокированы. Никто не должен вмешиваться. ##Шаг 2: шифрование на основе личных данных (IBE) Вот где происходит волшебство. Вместо шифрования данных определенного адреса кошелька (например, в PGP или RSA) SEAL используетидентификационные строки, то есть вы шифруете что-то вроде: 0x адрес кошелька dao_voted:proposal_xyz pkGid_2025_05_01 (правило, основанное на отметках времени) или даже game_user_nft_holder Когда данные зашифрованы, они выглядят следующим образом: Encrypt(mpk, identity, message) mpk = мастер-публичный ключ (известный всем) личность = логически определенный получатель сообщение = фактические данные Позже, если кто-то захочет расшифровать данные, сервер ключей проверяет, соответствуют ли они политике (с помощью вызова seal_approve onchain). Если запрос одобрен, он возвращает производный закрытый ключ для этого удостоверения. Derive(msk, identity) → sk Decrypt(sk, encrypted_data) Затем пользователь может локально расшифровать содержимое. Таким образом, шифрование выполняется без необходимости заранее знать, кто будет расшифровывать данные. Вы просто определяете условия, а SEAL выяснит остальное позже. Это динамично. ##Шаг 3: Сервер ключей — вне блокчейна, но не централизован Возможно, вы задаетесь вопросом: у кого эти мастер-ключи? Здесь на помощь приходитСервер ключей SEAL. Думайте об этом как о бэкенде, который: Содержит главный секретный ключ (msk) Следит за контрактами в блокчейне (например, за вашей логикой seal_approve) Выпускает производные ключи только при соблюдении условий Но — и это главное — SEAL не полагается только на один* сервер ключей. Вы можете запустить его в режимеthreshold, когда перед выдачей ключа дешифрования необходимо согласование нескольких независимых серверов. Например: запрос должны одобрить 3 из 5 ключевых серверов. Это позволяет избежать основных точек сбоя, а также обеспечивает децентрализацию на уровне управления ключами. Более того, в будущем SEAL будет поддерживатьMPC (многопартийные вычисления) иконфигурации на основе анклав(например, TEE), чтобы вы могли получить еще более надежные гарантии без ущерба для удобства использования. ##Шаг 4: расшифровка на стороне клиента Как ��олько ключ возвращается пользователю, фактическое дешифрование происходитна его устройстве. Это означает: Сервер никогда не видит ваши данные Бэкэнд никогда не хранит расшифрованный контент Только пользователь может получить доступ к окончательному сообщению Это надежная модель конфиденциальности. Даже если кто-то взломает уровень хранения данных (IPFS, Arweave и т. д.), он все равно не сможет прочитать данные, не пройдя логику доступа. Вот краткая ментальная модель: Эта структура позволяет легко создавать dApps, правила доступа которых не жестко закодированы — они динамичны, поддаются аудиту и полностью интегрированы в логику цепочки. ##Команда, стоящая за печатью SEAL возглавляетSamczsun, известная фигура в сообществе блокчейн-безопасности. Ранее он был партнером по исследованиям в Paradigm, а затем провел аудит и спас несколько экосистем от серьезных эксплойтов. Теперь он полностью сосредоточен на превращении SEAL в основную часть инфраструктуры конфиденциальности Web3. Судя по его опыту и авторитету, SEAL — это не просто еще один экспериментальный инструмент — это серьезная попытка сделать децентрализованную конфиденциальность данных практичной и масштабируемой. Внедрение SEAL в тестовой сети Sui Testnet открывает новый стандарт управления секретными данными приложениями Web3. Сочетая контроль доступа в блокчейне, пороговое шифрование и конфиденциальность на стороне клиента, SEAL обеспечивает более надежную основу для децентрализованной обработки данных. Независимо от того, создаете ли вы dApps, DAO или децентрализованные игры, SEAL предоставляет мощный набор инструментов для управления доступом и защиты пользовательских данных без ущерба для децентрализации. Если Web3 собирается двигаться вперед, безопасная инфраструктура, такая как SEAL, не является факультативной, а просто необходима
- Sui
- Architecture
- SDKs and Developer Tools
8 Является ли единственным способом опубликовать пакеты Move через EOA?
Я полагаю, что в цепочке Sui нет такого способа, поскольку в цепочке нет модуля, публикующего пакеты.
- Sui
- SDKs and Developer Tools
- Move
73Лучший ответ
Как Sui предотвращает взлом смарт-контрактов?
Индустрия блокчейна стала проблемой взломов смарт-контрактов: только в 2023 году из-за эксплойтов на таких платформах, как Ethereum, было потеряно более 3 миллиардов долларов. Сеть Sui Network, в которой безопасность является приоритетом, представляет несколько ключевых инноваций, позволяющих минимизировать эти риски. В этой статье рассматриваются следующие вопросы: 🔒 Встроенные функции безопасности Sui 💡 Как язык Move предотвращает распространенные эксплойты 🛡️ Сравнение с уязвимостями Ethereum 🚀 Почему Sui может стать самой безопасной платформой для смарт-контрактов 1. Язык программирования Move: подход, ориентированный на безопасность Sui использует Move, язык, изначально разработанный для блокчейна Facebook Diem и разработанный специально для безопасного управления активами. Ключевые преимущества Move в сфере безопасности: Отсутствие непроверенных внешних звонков — предотвращает атаки повторного входа (например, взлом Ethereum с помощью DAO на 60 миллионов долларов). Строгие правила ввода текста и владения — исключают случайную потерю средств из-за ошибок кодирования. Поддержка формальной верификации — позволяет математически доказать правильность контракта. Пример: в Ethereum простая опечатка может привести к потере средств. В Move компилятор отклоняет небезопасный код перед развертыванием. 2. Объектно-ориентированная модель: изоляция уязвимостей В отличие от модели совместного состояния Ethereum (где одна ошибка может повлиять на многие контракты), объектное хранилище Sui ограничивает распространение эксплойтов: Каждый актив (монета, NFT и т. д.) — это отдельный объект со строгими правилами владения. Контракты не могут произвольно изменять несвязанные данные. Воздействие. Даже если контракт будет скомпрометирован, ущерб будет локализован, в отличие от рисков, связанных с компонуемостью Ethereum (например, взлома моста Wormhole стоимостью 325 млн долларов). 3. Никаких атак на «газовый гриф» В Ethereum злоумышленники могут рассылать спам в контрактах, заключая транзакции с высоким содержанием газа, чтобы заблокировать законных пользователей (например, атаки типа «отказ в обслуживании»). Решение компании Sui: Фиксированные недорогие сделки (без газовых аукционов). Параллельное выполнение предотвращает перегрузку всей сети. 4. Мониторинг безопасности в сети Валидаторы Sui активно отслеживают подозрительную активность: Предварительная проверка транзакций — отклонение явно вредоносных запросов. Аналитика в реальном времени — выявляйте ненормальное поведение (например, внезапное снятие крупных средств). 5. Реальные показатели безопасности (на данный момент) С момента запуска основной сети (2023) у Sui не было серьезных взломов. В среднем Ethereum совершает 2-3 крупных эксплойта DeFi в месяц. Пример из практики: DEX на базе SUI (Cetus) обработал сделки на сумму более 1 миллиарда долларов без инцидентов с безопасностью — в отличие от Ethereum DEX, которые часто подвергаются эксплойтам. 6. Перспективы будущего: формальная верификация и аудиты Судьба поощряет: Формальная верификация — математическое подтверждение отсутствия ошибок в контрактах. Требования к нескольким аудитам. Крупные проекты должны пройти более трех аудитов. Заключение: является ли Sui самой безопасной платформой для смарт-контрактов? Хотя ни одна система на 100% не защищена от взлома, язык Sui Move, объектная модель и параллельное исполнение делают ее гораздо менее уязвимой, чем современный Ethereum. Итог: Для разработчиков: Move снижает риск ошибок, связанных с человеческим фактором. Для пользователей — снижение вероятности потери средств из-за эксплойтов. Для учреждений — безопасность корпоративного уровня укрепляет доверие. **Что дальше? Будет ли Ethereum использовать функции, подобные Move? Сможет ли Sui сохранить свою репутацию в сфере безопасности по мере роста числа пользователей?** Поделитесь своими мыслями ниже
- Sui
6- Статьяharry phan595ДляSuiApr 24, 2025
Межмодульное управление детьми с помощью public_receive
Это третья часть серии «Объекты для родителей и детей в режиме Sui Move». Иногда ваши родительские и дочерние типы определяются в разных модулях или даже в разных пакетах. Например, у вас может быть обычный объект Warehouse, в котором можно хранить любые объекты Parcel. Модуль Warehouse хочет удалить дочерний объект Parcel, но тип участка определен в другом месте. В таких случаях мы используем transfer: :public_receive, который является межмодульным двоюродным братом receive. ###получать и public_receive Как мы уже видели, transfer: :receive можно вызвать только в модуле, который определяет T (или имя друга), поскольку для этого не требуется T: store. Верификатор байт-кода Move фактически гарантирует, что в любом получаемом вызове используется тип T из текущего модуля. Это ограничение безопасности для объектов, содержащих только ключи. transfer: :public_receive — это вариант, который требует хранилища T: key +, но позволяет получать данные за пределами модуля T. Другими словами, если тип объекта можно хранить (то есть ему разрешено свободно существовать в глобальном хранилище), то любой модуль (с идентификатором родительского объекта &mut) может получить его с помощью public_receive. Это идеально подходит для случаев, когда родительский модуль отличается от дочернего модуля. Зачем нужен магазин? Потому что хранилище отмечает, что объект можно безопасно сохранить и передать за пределы определяющего модуля. Объекты, содержащие только ключи, могут иметь собственные инварианты, которые исходный модуль хочет использовать при передаче и получении. Исключая объекты из public_receive, Sui заставляет разработчиков обрабатывать их в модуле (как мы увидим в случае с объектами, привязанными к душе). Если у объекта есть хранилище, оно более разрешительно, а Sui позволяет управлять им извне с помощью общей логики передачи/получения. ###Пример: отдельные родительские и дочерние модули Давайте проиллюстрируем простой сценарий: склад, в котором хранятся объекты Parcel. Тип участка определяется в отдельном модуле, а склад — в другом. Мы покажем, как Хранилище может получить дочернюю посылку с помощью public_receive. module demo::parcel { // Child module use sui::object::{Self, UID}; use sui::tx_context::{Self, TxContext}; /// A parcel object that can be stored in a Warehouse. /// It has both key and store, so it can be transferred across modules. struct Parcel has key, store { id: UID, contents: vector } public entry fun create_parcel(contents: vector, ctx: &mut TxContext): Parcel { Parcel { id: object::new(ctx), contents } } } module demo::warehouse { // Parent module use sui::transfer::{Self, Receiving, public_receive}; use demo::parcel::{Self, Parcel}; use sui::object::{UID}; use sui::tx_context::{Self, TxContext}; struct Warehouse has key { id: UID, location: address } public entry fun create_warehouse(location: address, ctx: &mut TxContext): Warehouse { Warehouse { id: object::new(ctx), location } } /// Receive a Parcel that was sent to this Warehouse. /// Returns the Parcel to the caller (transferred to caller's address). public entry fun withdraw_parcel( warehouse: &mut Warehouse, parcel_ticket: Receiving, ctx: &mut TxContext ): Parcel { // Using public_receive because Parcel is defined in another module and has store let parcel = public_receive(&mut warehouse.id, parcel_ticket) oai_citation_attribution:27‡docs.sui.io oai_citation_attribution:28‡github.com; // Transfer the parcel to the transaction sender (so the caller gets ownership) transfer::transfer(parcel, tx_context::sender(ctx)); // We return nothing because we've transferred the Parcel out to the caller. } } Давайте разберемся, что происходит в withdraw_parcel: Мы называем public_receive (&mut warehouse.id, parcel_ticket). Поскольку в Parcel есть возможность хранения посылок, этот звонок разрешен, даже если нас нет в модуле посылок. На капоте производится та же процедура проверки и извлечения информации, что и при получении, но в разных модулях эта процедура разрешена, так как система хранения показывает, что делать это безопасно. https://github.com/MystenLabs/sui/blob/main/crates/sui-framework/packages/sui-framework/sources/transfer.move#:~:text=public%20fun%20public_receive,T%3E%29%3A%20T Затем мы немедленно передаем полученную посылку на адрес звонящего (tx_context: :sender (ctx)). Этот шаг гарантирует, что посылка покинет склад и отправится пользователю, инициировавшему вывод средств. Кроме того, мы могли бы просто вернуть посылку из этой функции, и Суй воспримет ее как выходные данные, принадлежащие адресу вызывающего абонента (поскольку это выходные данные функции ввода). Выполнение явной передачи более подробное задание, но оно позволяет понять, что происходит (и позволяет нам выполнить любые проверки перед выпуском объекта). Зачем включать магазин в посылку? Если в Parcel отсутствовала возможность хранения (то есть у нее был только ключ), вызов public_receive в demo: :warehouse не скомпилировался — Sui заставляет T оставить в памяти public_receive. В этом случае нам придется забрать посылку с помощью команды receive в самом модуле обработки посылок (или использовать дружеские отношения), что усложнит межмодульное проектирование. Добавляя хранилище в Parcel, мы фактически говорим, что «этот объект можно свободно перемещать и принимать внешними модулями». Именно это и нужно для стандартного шаблона контейнера. Шаблон вызова функций: Чтобы использовать их в транзакции, необходимо выполнить следующую последовательность действий: 1.Депозит (перевод на объект) :Позвоните в transfer: :public_transfer (parcel_obj, @warehouse_id), чтобы отправить посылку на склад. При этом владелец посылки считается складом. (Здесь мы используем public_transfer, потому что оно находится за пределами модуля Parcel и в Parcel есть магазин. В модуле посылки также подойдет простой перевод.) Выведите деньги (получите обратно) :Позже вызовите команду withdraw_parcel (warehouse_obj, «Получение» (parcel_id,...)). Справку о получении можно получить с помощью SDK, указав идентификатор посылки и ее последнюю версию. Функция вызовет public_receive, а затем передаст вам посылку. После вызова withdraw_parcel владелец посылки возвращается на адрес (ваш), так что это снова обычный объект, принадлежащий адресу. Склад больше не владеет им. Межмодульные аспекты: Обратите внимание, что модулю Warehouse необходимо знать тип посылки (мы используем demo: :parcel: :Parcel). Это связано с тем, что мы явно указываем «Получение» как «Получение». Если вам нужен действительно универсальный контейнер, в который можно было бы поместить объекты любого типа, вам придется использовать дженерики или другой подход (возможно, динамические поля со стиранием типов). Но в большинстве случаев вы знаете, каких типов детей вы ожидаете. Почему public_receive вместо простого вызова receive? Если мы попробуем transfer: :receive (&mut warehouse.id, parcel_ticket) в модуле склада, верификатор Move отклонит запрос, так как в demo: :warehouse не определена посылка. Sui предоставляет public_receive в качестве удачного способа сделать это, добавив дополнительную проверку способностей (требующую сохранения). Аналогичным образом, Sui использует transfer против public_transfer, freeze_object против public_freeze_object и т. д., следуя той же схеме: версии public_ предназначены для использования вне определяющего модуля и требуют хранения. Не забудьте разрешение родителя: Даже если вы используете public_receive, вам все равно нужен этот &mut warehouse.id. Мы его получили, потому что withdraw_parcel находится в модуле Warehouse и принимает &mut Warehouse. Таким образом, забрать посылку может только тот, кто так позвонит (владелец склада). Если складской модуль не предоставлял такую функцию публично, никто также не мог бы вызвать public_receive извне для своих дочерних элементов. Таким образом, кросс-модуль не обходит родительский контроль; он просто позволяет родительскому коду работать с дочерними типами типов, которые он не определил. Примечание о возможности хранения: Предоставление хранилища объектов делает его более гибким, но немного менее ограниченным — любой модуль, имеющий ссылку на родительский объект, может удалить его с помощью public_receive. Если вы хотитеограничитьспособ извлечения объекта (например, ввести собственную логику или запретить простое извлечение), вы можете намеренно сделать его доступным только по ключу. Пример этого мы рассмотрим на примере объектов, привязанных к душе. В таких случаях вы можете реализовать собственную функцию получения, а не полагаться на public_receive. Подводя итог этому, можно сказать, что public_receive — ваш друг в управлении дочерними объектами, определенными в других модулях, при условии, что эти объекты можно хранить. Он позволяет создавать кроссмодульные системы (например, наш склад/посылок), сохраняя при этом право собственности и контроль доступа. Просто не забудьте включить хранилище дочерних типов и использовать public_transfer при отправке их родителю из-за пределов модуля.
- Sui
- Architecture
6 - Экспертные Вопросы и ОтветыДляSuiJun 30, 2025
Why can’t I connect my wallet to a Sui dApp?
I’m trying to use a Sui dApp (like Tradeport, SuiSwap, or a custom platform), but my wallet won’t connect properly. Sometimes, I get no error at all—just nothing happens when I click "Connect Wallet." Other times, I see errors like: "Wallet not detected" (even though I have Sui Wallet or another wallet installed) "Connection failed: Invalid account" "Transaction rejected" before I even approve anything What I’ve tried: Refreshing the page Switching browsers (Chrome, Firefox, Brave) Checking wallet extension permissions Trying different networks (Devnet, Testnet, Mainnet) Reinstalling the wallet extension Questions: Why does this happen, and how can I fix it? Are there common mistakes users make when connecting wallets to Sui dApps? If my wallet was working before but suddenly stopped, what could be the cause?
- Sui
- Transaction Processing
61Лучший ответ 
Как создать сложное приложение dApp на Sui Move?
Курс ### #2: Глубокое погружение в программирование Move — создание сложных dApps на Sui Теперь, когда вы освоили основы программирования на Move и внедрили свой первый смарт-контракт, пришло время вывести свои навыки на новый уровень. В этой статье мы рассмотрим, как создавать более сложные децентрализованные приложения (dApps) с помощью блокчейна Move on the Sui. Шаг 1: освоение передовых концепций движения костюмов Прежде чем углубиться в программирование, давайте вернемся к некоторым расширенным функциям Move, которые делают его уникальным для создания безопасных и масштабируемых dApps: ####1. Ресурсно-ориентированное программирование Move рассматривает цифровые активы какресурсы, гарантируя, что их нельзя дублировать, непреднамеренно удалять или использовать не по назначению (https://docs.sui.io/learn/resource-oriented-programming). Это достигается за счет строгих правил владения и безопасности типов. Например: module examples::token { use sui::object::{Self, UID}; use sui::transfer; struct Token has key, store { id: UID, value: u64, } public fun mint(ctx: &mut TxContext, value: u64): Token { Token { id: object::new(ctx), value, } } public fun transfer_token(token: Token, recipient: address) { transfer::public_transfer(token, recipient); } } В этом примере Tokenресурс создан и передан безопасно. Ресурсы в Move по умолчанию неизменяемы, если они явно не помечены как изменяемые, что обеспечивает дополнительный уровень безопасности. ####2. Модули и инкапсуляция Модули в Move выступают в качестве автономных функциональных единиц, обеспечивая лучшую организацию и возможность повторного использования. Например, вы можете отделить логику создания токенов от логики передачи в отдельные модули (https://examples.sui.io/modules). Такая модульность обеспечивает более чистый код и упрощает обслуживание. ####3. Объектно-ориентированный дизайн UIDSui Move представляетобъектно-ориентированную модель, в которой каждый ресурс имеет уникальный в глобальном масштабе идентификатор (). Это позволяет напрямую ссылаться на объекты и взаимодействовать с ними, что упрощает управление сложными переходами состояний (https://docs.sui.io/objects). Шаг 2: написание модульного смарт-контракта Давайте создадим более продвинутый смарт-контракт, демонстрирующий эти концепции. Мы создадим простую торговую площадку NFT, где пользователи смогут создавать NFT и торговать ими. ####Определите ресурс NFT Начните с определения ресурса NFT в модуле Move: module examples::nft_marketplace { use sui::object::{Self, UID}; use sui::transfer; struct NFT has key, store { id: UID, name: String, price: u64, } public fun mint_nft(ctx: &mut TxContext, name: String, price: u64): NFT { NFT { id: object::new(ctx), name, price, } } public fun list_for_sale(nft: NFT, price: u64, ctx: &mut TxContext) { nft.price = price; transfer::public_transfer(nft, tx_context::sender(ctx)); } } Здесь NFTресурс включает такие свойства, как namepriceи. mint_nftФункция создает новый NFT и list_for_saleпозволяет пользователям выставлять свои NFT на продажу. ####Компиляция и развертывание Используйте интерфейс командной строки Sui для компиляции и развертывания контракта. Напишите сценарий развертывания для автоматизации этого процесса: sui move build sui client publish --gas-budget 10000 Это позволит упаковать и развернуть модуль в Sui Devnet (https://docs.sui.io/cli). Шаг 3. Создание интерфейса React для вашего маркетплейса После развертывания смарт-контракта давайте подключим его к интерфейсу React. ####Настройте проект Инициализируйте проект React, если вы еще этого не сделали: npx create-react-app nft-marketplace cd nft-marketplace npm install @mysten/sui.js ####Интеграция с кошельком Sui Используйте @mysten/sui.jsбиблиотеку для взаимодействия с блокчейном Sui: import { JsonRpcProvider, SuiClient } from '@mysten/sui.js'; const provider = new SuiClient({ url: 'https://fullnode.devnet.sui.io' }); async function fetchNFTs(ownerAddress) { const objects = await provider.getObjectsOwnedByAddress(ownerAddress); console.log('User NFTs:', objects); } ####Отображение данных NFT Извлеките и отобразите данные NFT в своем приложении React: function NFTList({ ownerAddress }) { const [nfts, setNFTs] = useState([]); useEffect(() => { async function loadNFTs() { const response = await provider.getObjectsOwnedByAddress(ownerAddress); setNFTs(response.data); } loadNFTs(); }, [ownerAddress]); return ( {nfts.map((nft) => ( {nft.name} Price: {nft.price} SUI ))} ); } Шаг 4. Повышение безопасности и производительности ####1. Безопасные транзакции Убедитесь, что все транзакции проверены как в сети, так и за ее пределами. Используйте такие библиотеки, как @mysten/sui.jsпроверка квитанций о транзакциях: async function verifyTransaction(txDigest) { const result = await provider.getTransaction({ digest: txDigest }); console.log('Transaction Verified:', result); } ####2. Оптимизируйте плату за газ Сотрудничайте с такими сервисами, как* Shami Gas Station*, чтобы предлагать транзакции без газа и улучшать пользовательский интерфейс. В качестве альтернативы можно использовать пакетные транзакции для снижения затрат (https://docs.sui.io/gas-optimization). ####3. Используйте масштабируемость Sui Архитектура Sui обеспечивает высокую пропускную способность и низкую задержку, что делает ее идеальной для децентрализованных приложений с интенсивным использованием. Протестируйте приложение в условиях смоделированной нагрузки, чтобы обеспечить стабильную производительность (https://performance.sui.io). Шаг 5. Тестирование и отладка Тестирование крайне важно для предотвращения уязвимостей. Используйте такие инструменты, как* Sui Explorer*, для мониторинга транзакций и устранения проблем. Кроме того, напишите модульные тесты для своих модулей Move: #[test] fun test_mint_nft() { use sui::test_scenario; let ctx = &mut test_scenario::ctx(); let nft = examples::nft_marketplace::mint_nft(ctx, "Test NFT", 100); assert!(nft.price == 100, 0); } Запустите тесты с помощью интерфейса командной строки Sui: sui move test Шаг 6: Взаимодействие с сообществом Создание dApps — это не только программирование, но и совместная работа. Делитесь своим прогрессом на таких платформах, как* GitHub,* Discord* или* Twitter**. Участвуйте в хакатонах и конкурсах для разработчиков, организованных Фондом Суи, чтобы улучшить свои навыки и получить известность. Заключение Освоив передовые концепции Move, написав модульные смарт-контракты и создав интуитивно понятные интерфейсы, вы уже на пути к тому, чтобы стать опытным разработчиком dApp на блокчейне Sui. Не забывайте уделять приоритетное внимание безопасности, оптимизации производительности и взаимодействию с сообществом, чтобы добиться максимального эффекта. Следите за новостямиCourse #3, где мы рассмотрим реальные сценарии использования и передовые методы масштабирования ваших dApps на Sui! Если вам нужны дополнительные разъяснения или дополнительные ресурсы, не стесняйтесь спрашивать!
- Sui
- Architecture
- Move
6
Начало обучения перемещению - курс #1
Независимо от того, являетесь ли вы новичком или опытным разработчиком, это пошаговое руководство поможет вам понять, как Move, ориентированный на ресурсы, можно использовать для создания dApps на блокчейне Sui. ###Шаг 1: Понимание Move и его ключевых особенностей Прежде чем углубиться в программирование, давайте кратко обсудим, что такоеMoveи почему оно уникально. Move— это язык программирования, предназначенный для написания безопасных и эффективных смарт-контрактов. Он вводитресурсоориентированное программирование**, при котором цифровые активы рассматриваются как первоклассные ресурсы, гарантирующие их непреднамеренное дублирование или удаление. В отличие от других языков,Moveминимизирует уязвимости с помощью таких функций, какстатическая типизация и надежноеуправление ресурсами**. Если вы новичок в программеMove, рекомендуем посмотреть видеоролик «Знакомство с Sui Move**» (https://www.youtube.com/watch?v=cJwN3IhpLnQ)by) Шаян из Фонда Суй. Это позволит получить базовые знания о сети Sui и роли Move в ней. ###Шаг 2: Настройка среды разработки Для начала вам необходимо установить необходимые инструменты и двоичные файлы. Выполните следующие шаги: 1.Установите двоичные файлы Sui Начните с установки двоичных файловSui, чтобы убедиться, что ваша среда разработки готова. Интерфейс командной строки (Sui CLI) позволит вам взаимодействовать с блокчейном Sui. Подробные инструкции можно найти в Sui Docs. 2.Выберите свою платформу В зависимости от того, используете ли вы Windows, macOS или Linux, следуйте соответствующим инструкциям по установке, приведенным в серии видеороликов или официальной документации Sui. 3.Настройте VPS (опционально) Если ваш ноутбук недостаточно мощный, попробуйте настроить виртуальный частный сервер (VPS) для обработки вычислительной нагрузки. ###Шаг 3: составление смарт-контракта «Первый ход» Теперь, когда ваша среда готова, давайте напишем простой смарт-контрактMove. В этом уроке я могу порекомендовать использовать примерSweet Place, вдохновленный фильмомFlash Place. 1.Определение ресурсов Начните с определения ресурса в модуле Move. Например: module examples::sweet_place { use sui::object::{Self, UID}; use sui::transfer; struct SweetPlace has key { id: UID, name: String, } public fun create_sweet_place(ctx: &mut TxContext, name: String) { let sweet_place = SweetPlace { id: object::new(ctx), name, }; transfer::public_transfer(sweet_place, tx_context::sender(ctx)); } } 2.Компиляция и развертывание Используйте интерфейс командной строки Sui для компиляции и развертывания контракта. Напишитескрипт развертывания, чтобы автоматизировать этот процесс и в дальнейшем обеспечить беспрепятственную интеграцию с вашим интерфейсом. ###Шаг 4: создание интерфейса React После развертывания смарт-контракта пришло время подключить его к интерфейсуReact. Этот шаг предполагает, что у вас уже есть некоторый опыт работы с React. Если нет, ознакомьтесь сКурсом React для начинающихот FreeCodecamp.org. 1.Настройте проект Инициализируйте проект React, используя create-react-appлюбой фреймворк по вашему выбору. 2.Интеграция с кошельком Sui Используйте библиотеки для @mysten/sui.jsвзаимодействия с блокчейном Sui. Например: import { JsonRpcProvider } from '@mysten/sui.js'; const provider = new JsonRpcProvider('https://fullnode.devnet.sui.io'); 3.Извлеките данные из своего контракта Запросите данные из развернутого контракта Move и отобразите их в приложении React. Используйтеиндексдля эффективного отслеживания транзакций и изменений состояния. ###Шаг 5: улучшение пользовательского опыта (UX) Одна из отличительных особенностей этого руководства заключается в том, что оно сосредоточено на создании удобного пользовательского интерфейса. Вот как можно улучшить UX: 1.Интегрируйте транзакции без газа Сотрудничайте с такими сервисами, какShami Gas Station, чтобы обеспечить своим пользователям возможность совершать транзакции без газа. Это устраняет барьеры для новичков, не знакомых с комиссиями за криптовалюту. 2.Оптимизируйте производительность Используйте высокую пропускную способность и низкую задержку Sui, чтобы обеспечить бесперебойную работу вашего dApp даже при большой нагрузке. ###Шаг 6: Тестирование и отладка Тестирование крайне важно для обеспечения того, чтобы ваше приложение работало должным образом. Используйте такие инструменты, какSui Explorer, для проверки транзакций и устранения проблем [[Поиск в Интернете]]. Кроме того, посетите платформу электронного обученияMOVE eLearning, чтобы ознакомиться с передовыми практиками тестирования и измерений. ###Шаг 7: Взаимодействие с сообществом Наконец, не забудьте пообщаться с сообществомSui! Делитесь своими успехами, задавайте вопросы и сотрудничайте с другими. Как показано в стенограмме видео, общение с другими разработчиками может открыть перед вами интересные возможности.
- Sui
- Architecture
- SDKs and Developer Tools
- Move
6- Экспертные Вопросы и ОтветыДляSuiJun 26, 2025
How to Properly Use the Sui SDK for Frontend Integration?
I'm building a frontend (React/Next.js) for a Sui dApp and need to interact with the blockchain—fetching objects, sending transactions, and listening to events. I’ve tried using the @mysten/sui.js SDK, but I’m running into issues: Wallet Connection: Sometimes, the wallet doesn’t return the user’s address after connecting. Transaction Handling: Transactions fail silently or return vague errors. RPC Limits: I get rate-limited or timeouts when fetching large datasets. Real-Time Updates: How can I listen for on-chain events (e.g., NFT mints, balance changes)? What I’ve tried: ✔ Basic SuiClient setup with mainnet and testnet RPCs. ✔ Using useWallet() from @mysten/dapp-kit for wallet integration. ✔ Manual transaction signing with signAndExecuteTransactionBlock. Questions: What’s the recommended way to initialize the Sui SDK in a frontend app? How do I handle errors gracefully (e.g., RPC failures, wallet rejections)? Are there best practices for optimizing queries (batching, caching, etc.)? How can I subscribe to real-time updates (e.g., new transactions, object changes)?
- Sui
- SDKs and Developer Tools
62Лучший ответ Как модули Sui Move повышают безопасность смарт-контрактов?
Как модульная система Sui Move позволяет разработчикам определять, организовывать и безопасно взаимодействовать с пользовательскими объектами в блокчейне и каковы уникальные особенности идентификации модулей и хранения объектов в экосистеме Sui по сравнению с традиционными языками смарт-контрактов?
- Sui
- Architecture
- Security Protocols
- Move
61Лучший ответ
