Sui.

Explorer

Присоединяйтесь к сообществам и открывайте новые идеи.

Sui.X.Peera.

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

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

Сообщества

Фильтр:Все блокчейны

Награда

  • Xavier.eth.Peera.
    Xavier.eth313
    ДляSuiJun 27, 2025
    +15

    Сбой транзакции Sui: объекты, зарезервированные для другой транзакции

    JsonRpcErrorПри попытке выполнить транзакции на Sui возникает постоянная ошибка. Ошибка означает, что объекты зарезервированы для другой транзакции, несмотря на то, что я реализовал последовательную обработку транзакций с задержками. JsonRpcError: Failed to sign transaction by a quorum of validators because one or more of its objects is reserved for another transaction. Other transactions locking these objects: AV7coSQHWg5vN3S47xada6UiZGW54xxUNhRv1QUPqWK (stake 33.83) 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 Я попробовал: Последовательное выполнение транзакции (ожидание завершения предыдущей транзакции) Добавлены 3-секундные задержки между транзакциями И все еще постоянно возникает одна и та же ошибка. Использование Sui RPC для отправки транзакций. Один и тот же идентификатор объекта несколько раз появляется в списке блокировок. Ошибка возникает даже при тщательном определении последовательности транзакций. Почему объекты «зарезервированы» для других транзакций? Как правильно проверить, доступен ли объект, прежде чем использовать его в транзакции? Существуют ли передовые методы работы с замками объектов в Sui? Может ли это быть связано со сроками завершения транзакции? Кто-нибудь сталкивался с этой проблемой раньше? Мы будем очень признательны за любую информацию о правильном управлении объектами в транзакциях Sui!

    2
    4
  • Xavier.eth.Peera.
    Xavier.eth313
    ДляSuiJun 17, 2025
    +15

    Как ограничения возможностей взаимодействуют с динамическими полями в гетерогенных коллекциях?

    Я создаю торговую площадку, которая будет работать с несколькими типами ресурсов с разными требованиями к возможностям, и я задал несколько фундаментальных вопросов о системе типов Move. Я хочу хранить разные типы активов в одной коллекции, но у них разные возможности: Обычные NFT: key + store(можно передавать другим лицам) key Только токены Soulbound (не подлежат передаче) Настраиваемые активы с ограничениями на перевод public struct Marketplace has key { id: UID, listings: Bag, // Want to store different asset types here } // This works for transferable assets public fun list_transferable( marketplace: &mut Marketplace, asset: T, price: u64 ) { /* ... */ } // But how to handle soulbound assets? public fun list_soulbound( // No store ability marketplace: &mut Marketplace, asset_ref: &T, // Can only take reference price: u64 ) { /* How do I store metadata about this? */ } Ключевые вопросы: Требования к возможностям: dynamic_field::add()Vвсегда ли при использовании требуется store время компиляции? Могут ли типы оболочек обойти эту проблему? Гетерогенное хранилище: можно ли в одном пакете хранить объекты с разными наборами способностей key + store + copykey + storeи по-разному обрабатывать их во время выполнения? Безопасность типов: поскольку в динамических полях происходит стирание типов, как обеспечить безопасность типов при извлечении значений? Какова схема хранения метаданных типов? Паттерн Witness: как ограничения способностей работают с фантомными типами? Могу ли я хранить информацию о AssetAssetтипах в той же коллекции и извлекать информацию о типах позже? Создание системы, в которой NFT, токены soulbound и активы с ограниченным доступом требуют функциональности торговой площадки, но с другой семантикой передачи данных. Я испробовал типы оболочек, несколько коллекций для каждого набора способностей, хранилище метаданных отдельных типов. В каждом из них есть компромисс между безопасностью типов, стоимостью газа и сложностью.

    0
    4
  • Peera Admin.Peera.
    Peera Admin37
    ДляSuiMay 29, 2025
    +10

    Почему 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 или ожидаете, что порядок полей структуры после развертывания останется неизменным?

    5
    3

Самые новые

  • CarlkawIy.Peera.
    CarlkawIy259
    ДляSuiJul 01, 2025

    Как восстановить монеты SUI из старого кошелька?

    Я пытался найти свои монеты SUI при создании новой учетной записи Slush, но не вижу их. Как проверить, правильно ли я использую фразу при импорте своего старого кошелька?

    0
    2
  • MiniBob.Peera.
    MiniBob701
    ДляSuiJul 01, 2025

    Освоение понятий языка движений — курс #2

    Если курс #1, написанный мною ранее, познакомил вас с основами написания смарт-контрактов в Move и созданием простых dApps на блокчейне Sui, то этот курс посвящен углублению понимания самого языка Move— от его мощной системы шрифтов до сложных паттернов, таких как дженерики, события, модули и механизмы контроля доступа. К концу этого курса вы сможете: Напишите модульный, многоразовый и безопасный код Move Эффективно используйте дженерики, возможности и типы ресурсов Внедрите детальное управление доступом с использованием функциональных возможностей Создавайте и слушайте события для интеграции вне сети Работайте со сложными структурами данных, такими как таблицы и векторы Узнайте, чем Move отличается от других языков смарт-контрактов, таких как Solidity Давайте погрузимся в самое сердце языка Move! Шаг 1. Понимание основных языковых функций Move Move разработан с учетом требований безопасности и ясности. Давайте рассмотрим некоторые из наиболее важных функций, которые делают Move уникальным языком смарт-контрактов. 1.1 Ресурсоориентированное программирование (вновь) В основе Move лежит концепцияресурсов, представляющих собой специальные типы, которые нельзя копировать или удалять без явного разрешения. Это обеспечивает безопасное обращение с цифровыми активами, такими как токены или NFT. module examples::token { use sui::object::{Self, UID}; struct MyToken has key, store { id: UID, value: u64, } public fun mint(ctx: &mut TxContext): MyToken { MyToken { id: object::new(ctx), value: 100, } } } В этом примере: MyToken- keyявляетсяресурсом, потому что у него есть такая возможность. store- Его можно сохранить (id) и по нему можно однозначно идентифицировать. Если не указано иное, его нельзя дублировать или удалять. Это гарантирует, что каждый MyTokenэкземпляр находится в уникальном владении и управлении, что предотвращает случайное копирование или удаление. 1.2 Система способностей У каждого типа Move есть наборспособностей, определяющих поддерживаемые операции: | Способность | Значение | | --------| ---------| | copy| Можно дублировать | | drop| Можно выбросить без разрушения | | store| Может храниться в глобальном хранилище | | key| Может использоваться как структура с полем ID (например, объект) | Пример: struct Example has copy, drop { value: u64 } Понимание этих возможностей необходимо для разработки безопасных и предсказуемых смарт-контрактов. Почему способности важны Во время компиляции способности накладывают строгие правила. Например: Структура, содержащая только keyи storeне подлежащая копированию или удалению. Невозможно вернуть из функции структуру, которую нельзя удалить, если она не сохранена или не передана. Это позволяет избежать таких ошибок, как двойное расходование средств или случайная потеря токенов. 1.3 Дженерики и параметры типов Move поддерживает универсальные типы, что позволяет разработчикам писать гибкий и многократно используемый код. module examples::storage { use sui::object::{Self, UID}; struct Box has key { id: UID, content: T, } public fun new_box(ctx: &mut TxContext, content: T): Box { Box { id: object::new(ctx), content, } } } Вот `параметрtype, позволяющий Box`работать с любым типом, сохраняя при этом безопасность и эффективность. Примечание: phantomключевое слово означает, что Tоно не влияет на представление структуры во время выполнения — полезно для абстрактного моделирования. Шаг 2: модульная разработка и управление пакетами По мере усложнения проектов Move организация кода становится критически важной. 2.1 Создание и публикация пакетов Move ПакетMoveсодержит один или несколько модулей и определяет зависимости. Это модуль развертывания и управления версиями в Move. Структура каталогов: sources/ place.move user.move Move.toml Определите зависимости вMove.toml: [dependencies] Sui = { git = "https://github.com/MystenLabs/sui.git", subdir = "crates/sui-framework" } MyLibrary = { local = "../my-library" } Пакеты можно публиковать в сети Sui и повторно использовать их в нескольких dApps. 2.2 Повторное использование существующих модулей cointransfertx_contextSui Frameworkпредоставляет проверенные в боях модули, такие как и. Всегда проверяйте, что доступно, прежде чем писать собственную логику. Например, чтобы перенести объект, выполните следующие действия: use sui::transfer; public entry fun send_place(place: Place, recipient: address) { transfer::public_transfer(place, recipient); } Использование стандартных библиотек обеспечивает более безопасную, быструю разработку и лучшую совместимость. Шаг 3: события и внесетевая коммуникация Чтобы создавать реальные приложения, ваши контракты Move должны взаимодействовать с внесетевыми системами, такими как фронтенды или индексаторы. 3.1 Эмиссия событий Move позволяет генерироватьсобытия, которые могут индексироваться внешними сервисами. use sui::event; struct PlaceCreated has drop { name: String, } public fun emit_place_created(name: String) { event::emit(PlaceCreated { name }); } Это событие появится в блокчейне и может быть подхвачено исследователями или инструментами индексации. 3.2 Прослушивание событий Используйте такие инструменты, какSuite Explorer,Subsquidили API Sui JSON-RPC, чтобы отслеживать генерируемые события и соответствующим образом реагировать в приложении. В JavaScript/TypeScript: import { JsonRpcProvider } from '@mysten/sui.js'; const provider = new JsonRpcProvider('https://fullnode.devnet.sui.io'); const events = await provider.getEvents({ MoveEventType: '0x...::example::PlaceCreated' }); Шаг 4. Паттерны управления доступом и безопасности При работе со смарт-контрактами безопасность имеет первостепенное значение. Move предоставляет несколько инструментов для внедрения надежного контроля доступа. 4.1 Модель владения объектами Sui обеспечивает право собственности на уровне протокола. Только владелец объекта может изменять или передавать его. public entry fun update_name(sweet_place: &mut SweetPlace, new_name: String) { sweet_place.name = new_name; } Только текущий владелец может вызвать эту функцию. 4.2 Шаблон возможностей Для получения более подробных разрешений используйте паттернcapability— создавайте специальные объекты, предоставляющие ограниченный доступ к определенным функциям. struct AdminCap has key { id: UID } public entry fun grant_admin_cap(ctx: &mut TxContext) { let cap = AdminCap { id: object::new(ctx) }; transfer::public_transfer(cap, tx_context::sender(ctx)); } public entry fun restricted_action(_: &AdminCap) { // perform admin action } Теперь AdminCapвыполнять могут только те пользователи, у которых есть эта функцияrestricted_action. Этот шаблон широко используется в DeFi и DAO для безопасного делегирования полномочий. Шаг 5. Работа со сложными структурами данных Move поддерживает структурированные типы данных, которые позволяют разработчикам моделировать сложную логику и взаимосвязи. 5.1 Векторы Векторы используются для хранения упорядоченных коллекций предметов одного типа. let names = vector[String::utf8(b"Alice"), String::utf8(b"Bob")]; Они полезны для хранения списков NFT, ролей пользователей или динамических метаданных. Пример использования: vector::push_back(&mut names, String::utf8(b"Charlie")); 5.2 Таблицы (через стандартную библиотеку Sui) Хотя Move изначально не поддерживает карты или хеш-таблицы, Sui предоставляет эти Tableтипы в своей стандартной библиотеке. use sui::table::{Self, Table}; struct Registry has key { id: UID, entries: Table, } public fun add_entry(registry: &mut Registry, key: u64, value: String) { table::add(&mut registry.entries, key, value); } Используйте таблицы для эффективного управления большими наборами данных. Шаг 6. Тестирование и отладка контрактов Тестирование гарантирует, что ваш код Move работает должным образом в различных условиях. 6.1 Модульное тестирование в Move Пишите модульные тесты непосредственно в модулях Move, используя фреймворк тестирования. #[test] public fun test_create_sweet_place() { let ctx = tx_context::dummy(); create_sweet_place(&mut ctx, String::utf8(b"My House")); } Запускайте тесты с помощью: sui move test 6.2 Использование Sui Explorer После развертывания контракта используйте Sui Explorer для проверки транзакций, просмотра состояний объектов и устранения неполадок. Шаг 7. Реальное применение передовых концепций перемещения Теперь, когда вы разбираетесь в основных языковых функциях, давайте рассмотрим, как они применимы к реальным сценариям. 7.1 Платформа для майнинга NFT Создайте платформу, которая позволит пользователям создавать NFT на основе ресурсов Move, используя модели владения и ресурсов. 7.2 Система голосования DAO Внедрите децентрализованную автономную организацию (DAO), используя Move для голосования, предложений и управления, используя события и возможности для безопасных действий. 7.3 Обмен токенами и банкоматами Создайте децентрализованную биржу (DEX), используя модули Move для представления пулов ликвидности и свопов токенов, используя дженерики и таблицы для эффективного управления состоянием.

    2
  • Evgeniy CRYPTOCOIN.Peera.
    Evgeniy CRYPTOCOIN196
    ДляSuiJun 30, 2025

    Что такое динамические NFT и почему Sui в них преуспевает?

    Пространство NFT выходит за рамки статических изображений и изображений профиля (PFP). Следующий рубеж? Динамические NFT (dNFT) — токены, которые могут меняться в зависимости от реальных данных, взаимодействий пользователей или событий в сети. Хотя многие блокчейны поддерживают NFT, Sui Network благодаря своей инновационной архитектуре обладает уникальными возможностями для развития DNFT в будущем. В этой статье рассматриваются следующие вопросы: Что делает NFT «динамичным»? Почему технология Sui идеально подходит для DNFT Реальные сценарии использования сегодня Будущее интерактивных цифровых активов 1. Что такое динамические NFT? В отличие от традиционных NFT (которые являются статическими и неизменяемыми), динамические NFT могут обновлять свои: Метаданные (например, спортивный NFT, который меняется в зависимости от игровой статистики) Внешний вид (например, произведение искусства, которое со временем меняется) Утилита (например, NFT для лояльности, открывающий новые привилегии) Как они работают? DNFT используют логику смарт-контрактов и внешний ввод данных (оракулы, действия пользователей и т. д.) для инициирования изменений. Пример: Чувствительное к погодным условиям изображение в формате NFT, меняющее цвета на основе климатических данных в реальном времени. Игровой персонаж NFT, уровень которого повышается по мере игры. 2. Почему Sui — лучший блокчейн для динамических NFT Хотя Ethereum и Solana также поддерживают DNFT, дизайн Sui обладает ключевыми преимуществами: Ончейн-хранилище (без внешних зависимостей) Большинство блокчейнов хранят метаданные NFT вне сети (например, IPFS), что затрудняет динамическое обновление. Sui хранит все данные в блокчейне, обеспечивая мгновенные и надежные изменения. Move Language: безопасные и гибкие обновления Solidity от Ethereum требует сложных прокси-контрактов для обновляемых NFT. Язык Sui Move обеспечивает встроенную изменчивость — никаких сложных обходных решений. Параллельная обработка (высокая масштабируемость) Обновление тысяч DNFT одновременно? Ethereum борется с перегрузкой. Параллельное исполнение Sui обрабатывает миллионы обновлений без замедления. Объектно-ориентированная модель (детальное управление) Каждый NFT — это независимый объект с настраиваемой логикой. Обеспечивает точную настройку интерактивности (например, изменения может инициировать только владелец). 3. Реальные примеры использования dNFT на Sui Игры и метавселенная Эволюция внутриигровых предметов (например, меч NFT, способности которого приобретаются по мере использования). Совместимость между играми (объекты Суи могут перемещаться между DApps). Пример: *В играх на основе SUI, таких как Panzerdogs, в качестве настраиваемых аватаров используются DNFT. * Генеративное и реактивное искусство NFT на базе искусственного интеллекта, меняющие стиль в зависимости от рыночных тенденций. Совместное творчество, в котором коллекционеры влияют на конечное произведение. Пример: *В художественных лабораториях, таких как Sui Gallery, проводятся выставки DnFT. * Отслеживание реальных активов (RWA) Зарегистрируйте NFT, которые обновляются записями о собственности. Сертификационные бейджи, срок действия которых истекает или продлевается автоматически. Программы лояльности и членства NFT с динамическими скидками, которые улучшаются по мере увеличения расходов клиентов. Абонементы VIP-доступа, которые со временем открывают новые уровни. Пример: *Розничные партнеры Sui тестируют программы лояльности dNFT. * 4. Будущее DNFT в Sui Ожидайте увидеть: DNFT, интегрированные в искусственный интеллект (например, чат-боты, живущие в аватарах NFT). DNFT, обеспеченные Defi (стоимость корректируется в зависимости от рыночных условий). Полностью сетевые игры, в которых каждый актив представляет собой изменяемый dNFT. Вывод: Суй строит будущее NFT В то время как статические NFT доминировали в 2021-2023 годах, динамические NFT будут доминировать в следующем буме, а технология Sui делает их идеальной платформой. Благодаря сетевому хранилищу, безопасности Move и непревзойденной масштабируемости, Sui готова стать родиной передовых DNFT.

    5

Без ответа

  • Owen.Peera.
    Owen496
    ДляSuiJun 11, 2025

    Как обновить ключ продавца в ObjectTable при его изменении в структуре?

    Всем привет! Я только начинаю писать смарт-контракты и работаю над своим самым первым проектом. Мне бы очень хотелось получить помощь в решении проблемы, в которой я застрял. До сих пор я создал Merchantструктуру, которая выглядит следующим образом: -id: уникальный идентификатор (UID) -owner: адрес продавца -key: строка, используемая в качестве уникального ключа -balance: u64, представляющий их баланс Я также создал MerchantRegistryструктуру для управления всеми продавцами: -id: еще один UID -merchant_to_address: ObjectTableсопоставление адресов продавцов -merchant_to_key: ObjectTableсопоставление ключей с продавцами Я хочу найти продавца по егоадресуили поключу. MerchantКогда пользователь обновляет свой ключ в merchant_to_keyструктуре, это изменение не приводит к автоматическому обновлению ключа в таблице. Это означает, что старый ключ по-прежнему указывает на продавца, что ломает ситуацию. Я попытался удалить запись из таблицы и вставить её обратно с новым ключом, но всё время сталкивался с такими ошибками, как: «Невозможно игнорировать значения, не умея их удалять» Я уверен, что это ошибка новичка, но мне нигде не удалось найти четкого объяснения или решения. Есть ли правильный способ обновления ключа как в структуре, так и в таблице поиска?

    5
    0
  • 0xduckmove.Peera.
    0xduckmove618
    ДляSuiJun 06, 2025

    В каком интерфейсе проще всего загружать моржевые капли?

    простой пользовательский интерфейс для загрузки в walrus? (кроме бивня)

    2
    0
  • 1 Luca.Peera.
    1 Luca199
    ДляSuiApr 09, 2025

    Что произойдет, если я не получу ETH через мост Sui?

    Я использовал мост Sui для перевода некоторого количества ETH, но пока не воспользовался им, так как комиссии довольно высоки. Что произойдет, если я оставлю деньги невостребованными?

    0
    0

В тренде

  • Vens.sui.Peera.
    Vens.sui211
    ДляSuiApr 29, 2025

    Бот AMM в экосистеме Sui

    Каковы ключевые особенности и функциональные возможности ботов AMM в экосистеме Sui? Как они улучшают традиционные торговые механизмы и какие преимущества они предлагают пользователям, использующим протоколы DeFi в сети Sui? Нужно ли мне его создавать или я могу использовать, например, Turbos Finance

    8
    2
  • 0xduckmove.Peera.
    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, не является факультативной, а просто необходима

    8
  • MarlKey.Peera.
    MarlKey61
    ДляSuiApr 30, 2025

    Является ли единственным способом опубликовать пакеты Move через EOA?

    Я полагаю, что в цепочке Sui нет такого способа, поскольку в цепочке нет модуля, публикующего пакеты.

    7
    3