Винагорода

Заробляйте жетони за ваші внески.

Зароби свою частку з 1000 Sui

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

Пости

Винагорода+15
Xavier.eth301
Jun 17, 2025
Питання та відповіді експертів
Як обмеження здібностей взаємодіють з динамічними полями в гетерогенних колекціях?
Я створюю ринок, який повинен обробляти кілька типів активів з різними вимогами до здібностей, і я зіткнувся з деякими фундаментальними запитаннями щодо системи типів Move. Я хочу зберігати різні типи активів в одній колекції, але вони мають різні здібності: Звичайні NFT: key + store(можна передавати) Токени Soulbound: key тільки (не передаються) Користувальницькі активи з обмеженнями передачі 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 + copyностей (vskey + store) та обробляти їх по-різному під час виконання? Безпека типу: Оскільки динамічні поля виконують стирання типу, як я можу підтримувати безпеку типу під час отримання значень? Який шаблон для зберігання метаданих типу? Шаблон свідків: Як працюють обмеження здібностей з фантомними типами? Чи можу я зберігати Assetі Assetв тій самій колекції та витягувати інформацію про тип пізніше? Побудова системи, де NFT, токени, пов'язані з душею, та обмежені активи потребують функціональності ринку, але з різною семантикою передачі. Я спробував типи обгортки, кілька колекцій на набір можливостей, окреме зберігання метаданих типу. Кожен з них має компроміси між безпекою типу, витратами на газ та складністю.
- Sui
- Architecture
0
0
Винагорода+10
Peera Admin37
May 29, 2025
Питання та відповіді експертів
Чому BCS вимагає точного порядку полів для десеріалізації, коли структури Move мають названі поля?
Чому BCS вимагає точного порядку полів для десеріалізації, коли структури Move мають названі поля? Я глибоко занурювався в кодування/декодування BCS у Move, особливо для міжланцюгового зв'язку та обробки даних поза ланцюгом. Опрацьовуючи приклади в документації Sui Move, я зіткнувся з деякою поведінкою, яка здається неінтуїтивною, і я намагаюся зрозуміти основні рішення щодо дизайну. Відповідно до специфікації BCS, «в BCS немає структур (оскільки немає типів); структура просто визначає порядок, в якому поля серіалізуються». Це означає, що при десеріалізації ми повинні використовувати peel_*функції в тому ж порядку, що і визначення поля struct. Мої конкретні запитання: Обґрунтування дизайну: Чому 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 Admin36
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
Найкраща відповідь