Sui.

Награда

Зарабатывайте токены за свой вклад.

Sui.X.Peera.

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

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

Посты

3
  • Награда+15

    Xavier.eth.
    Jun 17, 2025
    Экспертные Вопросы и Ответы

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

    Я создаю торговую площадку, которая будет работать с несколькими типами ресурсов с разными требованиями к возможностям, и я задал несколько фундаментальных вопросов о системе типов 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 и активы с ограниченным доступом требуют функциональности торговой площадки, но с другой семантикой передачи данных. Я испробовал типы оболочек, несколько коллекций для каждого набора способностей, хранилище метаданных отдельных типов. В каждом из них есть компромисс между безопасностью типов, стоимостью газа и сложностью.

    • Sui
    • Architecture
    0
    0
  • Награда+10

    Peera Admin.
    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
    5
    2
    Лучший ответ
  • Награда+10

    Peera Admin.
    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
    4
    1
    Лучший ответ