Sui.

Explorer

Приєднуйтесь до спільнот і відкривайте нові ідеї.

Sui.X.Peera.

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

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

Спільноти

Фільтр:Усі блокчейни

Винагорода

  • Peera Admin.Peera.
    Peera Admin31
    ДляMoveMar 11, 2025
    +10

    Sui Move vs Aptos Move - What is the difference?

    Sui Move and Aptos Move - two prominent implementations of the Move programming language. While both are rooted in the same foundational principles, they have diverged significantly in design, execution, and ecosystem development. To better understand their differences, we need to uncover some of their key aspects: How do their runtimes differ? Both Sui and Aptos implement their own custom Move virtual machines (VMs). How does this impact performance, scalability, and developer experience? For instance: Does Sui's runtime optimize for parallel execution differently than Aptos'? Are there notable differences in transaction lifecycle management or gas models? What are the differences between their standard libraries? The Move standard library is a critical component for building smart contracts. However, Sui and Aptos have forked their implementations, leading to divergence: Are there modules or functions unique to one implementation but absent in the other? How do these differences affect common use cases like token creation, NFTs, or decentralized finance (DeFi)? How does data storage differ between them? One of the most significant distinctions lies in how Sui and Aptos handle data storage: Sui uses an object-centric model, where each object has its own ownership and permissions. Aptos, on the other hand, retains a more traditional account-based model similar to Ethereum. How does this impact state management, composability, and gas efficiency? Is it fair to say that Aptos is closer to EVM while Sui is closer to SVM? Some developers argue that Aptos' account-based architecture resembles Ethereum's EVM, while Sui's object-centric approach aligns more closely with Solana's SVM. Do you agree with this analogy? Why or why not? How does this architectural choice influence developer ergonomics and application design? Are there universal packages working for both Sui Move and Aptos Move? Given their shared origins, it would be ideal if some libraries or tools were interoperable across both ecosystems. Are there any existing universal packages or frameworks that work seamlessly on both platforms? If not, what are the main barriers to achieving compatibility? Can one of them be transpiled into another? If a project is built on Sui Move, could it theoretically be transpiled to run on Aptos Move, or vice versa? What are the technical challenges involved in such a process? Are there tools or compilers currently available to facilitate this kind of migration?

    2
    1
  • Peera Admin.Peera.
    Peera Admin36
    ДляSuiMar 05, 2025
    +10

    Помилки перевірки кількох джерел» у публікаціях модуля 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. Обов'язково опублікувати своє рішення нижче.

    4
    1

Найновіші

  • Pluto Dev👽.Peera.
    Pluto Dev👽10
    ДляWalrusMay 01, 2025

    Where else can I get SUI from a faucet?

    I've been using a SUI faucet for some transactions, but I'm looking for alternative options to receive SUI tokens. Are there other faucets or methods I can try?

    0
    1
  • McMMoKing.Peera.
    McMMoKing175
    ДляSuiMay 01, 2025

    Як виправити проблеми з підключенням гаманця Sui та Ledger?

    У мене виникли проблеми з гаманцем Sui у браузері Brave, захищеному моїм пристроєм Ledger. Коли я намагаюся надіслати кошти на біржу, він пропонує мені підключити Ledger, але він стверджує, що він відключений. Як я можу вирішити цю проблему? І чи потрібна фраза відновлення насіння, щоб відновити мою книгу?

    0
    2
  • elfDani.Peera.
    elfDani10
    ДляWalrusMay 01, 2025

    Is my file private when uploaded to Walrus?

    I'm thinking of using Walrus for storing some files. My main concern is whether my files are private by default when I upload them. I don't really want my personal or sensitive data out in the open for everyone to see. Can someone let me know if there's a way to keep my files private, or should I be looking into alternatives?

    0
    1

Без відповіді

  • Rogue.Peera.
    Rogue82
    ДляSuiApr 25, 2025

    Кращий мемекоін на SUI

    Подаруйте мені кілька мемокоїнів SUI

    2
    0
  • RogueRig.Peera.
    RogueRig82
    ДляSuiApr 25, 2025

    Протокол моржа - прихована перлина на SUI

    Термін «Морж» в контексті наданих вами документів відноситься до децентралізованої платформи зберігання даних, розробленої Mysten Labs, яка є частиною екосистеми Sui. Walrus призначений для задоволення масштабних потреб у зберіганні даних, якими традиційні блокчейни не можуть ефективно керувати. Він пропонує економічно ефективне, масштабоване та програмоване рішення для зберігання, зміцнюючи позиції Sui як глобального координаційного рівня. Платформа Walrus також пов'язана з токеном WAL, який відіграє вирішальну роль у харчуванні мережі за допомогою делегованого підтвердження частки та забезпеченні надійного зберігання даних за допомогою нових викликів атестації. Крім того, Walrus використовується для зберігання медіа-контенту, як демонструє Decrypt, провідне медіа-видання Web3, яке публікує всю свою бібліотеку вмісту в Walrus. Для отримання більш детальної інформації ви можете звернутися до Whitepaper про моржі.

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

    Що станеться, якщо я не претендую на ETH через міст Sui?

    Я використовував міст Sui для передачі деяких ETH, але ще не претендував на нього, оскільки комісії досить високі. Що буде, якщо я залишу його незатребуваним?

    0
    0

У тренді

  • 0xduckmove.Peera.
    0xduckmove220
    Для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 робить все це можливим. Контроль доступу живе onchain, повністю автоматизований, адміністратор не потребує керування ним. Просто логіка, запечена прямо в блокчейн. SEAL робить все це можливим. Контроль доступу живе onchain, повністю автоматизований, адміністратор не потребує керування ним. Просто логіка, запечена прямо в блокчейн. Ще один цікавий фрагмент - це те, як SEAL обробляєшифрування. Він використовує щось, що називаєтьсяпорогове шифрування, що означає: жоден вузол не може розшифрувати дані. Для спільної роботи потрібна група серверів - щось на зразок multi-sig, але для розблокування секретів. Це розподіляє довіру та дозволяє уникнути звичайної проблеми з однією точкою відмови. І щоб зберегти речі по-справжньому приватними, 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адреса гаманця дао_голосували: пропозиція_xyz PKGID_2025_05_01 (правило на основі міток часу) або навіть геймкористувач_nftхолдер Коли дані зашифровані, це виглядає так: Encrypt(mpk, identity, message) mpk = головний відкритий ключ (відомий всім) ідентичність = логічно визначений одержувач повідомлення = фактичні дані Пізніше, якщо хтось хоче розшифрувати, сервер ключів перевіряє, чи відповідають вони політиці (за допомогою виклику seal_approve onchain). Якщо він схвалений, він повертає похідний приватний ключ для цього ідентифікатора. Derive(msk, identity) → sk Decrypt(sk, encrypted_data) Потім користувач може розшифрувати вміст локально. Таким чином, шифрування робиться без необхідності знати ко розшифруватиме заздалегідь. Ви просто визначаєте умови, а SEAL з'ясовує решту пізніше. Це динамічно. ##Крок 3: Ключовий сервер - поза ланцюгом, але не централізований Ви можете задатися питанням: хто тримає ці головні ключі? Тут на допомогу приходитьКлючовий сервер SEAL. Подумайте про це як про бекенд, який: Тримає головний секретний ключ (msk) Дивиться на ланцюгові контракти (як ваша логіка seal_approve) Видає лише похідні ключі, якщо умови виконані Але - і це ключове - SEAL не покладається лише на * один* ключовий сервер. Ви можете запустити його впороговому режимі, де кілька незалежних серверів повинні погодитися, перш ніж буде видано ключ розшифровки. Наприклад: 3 з 5 ключових серверів повинні схвалити запит. Це дозволяє уникнути центральних точок відмови та дозволяє децентралізувати також на рівні управління ключами. Ще краще, що в майбутньому SEAL підтримуватимеMPC (багатосторонні обчислення) таналаштування на основі анклав(наприклад TEE) - так що ви можете отримати ще сильніші гарантії без шкоди для зручності використання. ##Крок 4: Дешифрування на стороні клієнта Після повернення ключа користувачеві фактичне дешифрування відбуваєтьсяна його пристрої. Це означає: Сервер ніколи не бачить ваші дані Backend ніколи не зберігає розшифрований вміст Тільки користувач може отримати доступ до остаточного повідомлення Це надійна модель конфіденційності. Навіть якщо хтось компрометує шар зберігання (IPFS, Arweave тощо), вони все одно не можуть прочитати дані, не передаючи логіку доступу. Ось швидка ментальна модель: Ця структура дозволяє легко створювати DApps, де правила доступу не жорстко закодовані - вони динамічні, піддаються перевірці та повністю інтегровані у логіку вашого ланцюга. ##Команда за SEAL SEAL очолюєSamczsun, відома фігура в спільноті безпеки блокчейнів. Раніше був дослідницьким партнером Paradigm, він перевіряв та врятував кілька екосистем від великих подвигів. Тепер він повністю зосереджений на тому, щоб SEAL перетворився на основну частину інфраструктури конфіденційності Web3. Завдяки своєму досвіду та довірі SEAL є не просто ще одним експериментальним інструментом - це серйозна спроба зробити децентралізовану конфіденційність даних практичною та масштабованою. Оскільки SEAL виходить в ефір на Sui Testnet, він приносить новий стандарт того, як додатки Web3 можуть керувати секретами. Поєднуючи контроль доступу в ланцюжок, порогове шифрування та конфіденційність на стороні клієнта, SEAL пропонує більш надійну основу для децентралізованої обробки даних. Незалежно від того, створюєте ви DApps, DAO чи децентралізовані ігри - SEAL надає потужний набір інструментів для забезпечення контролю доступу та захисту даних користувачів без шкоди для децентралізації. Якщо Web3 збирається рухатися вперед, безпечна інфраструктура, така як SEAL, не є необов'язковою - це важливо

    8
  • harry phan.Peera.
    harry phan360
    ДляSuiApr 24, 2025

    Крос-модульне управління дітьми за допомогою public_receiver

    Це частина 3 серії «Об'єкти батьків-дитини в Sui Move». Іноді ваші батьківські та дитячі типи визначаються в різних модулах або навіть різних пакетах. Наприклад, у вас може бути загальний об'єкт Warehouse, який може зберігати будь-які об'єкти Parcel. Модуль «Склад» хоче витягнути дочірню групу «Посилка», але тип «Посилка» визначається в іншому місці. У таких випадках ми використовуємо transfer: :public_receiver, який є крос-модульним двоюрідним братом отримання. ###отримувати проти публічний_отримати Як ми бачили, transfer: :receiver можна викликати лише в модулі, який визначає T (або друга), оскільки він не вимагає T: store. Верифікатор Move байтового коду фактично гарантує, що під час будь-якого виклику для отримання тип T походить від поточного модуля. Це обмеження безпеки для об'єктів, що мають лише ключ. transfer: :public_receiver — це варіант, який вимагає* T: ключ+сховище, але дозволяє отримувати за межами модуля T. Іншими словами, якщо тип об'єкта має можливість зберігання (тобто йому дозволено вільно існувати в глобальному сховищі), то будь-який модуль (заданий &mut UID батьківського користувача) може отримати його за допомогою public_receiver. Це ідеально підходить для випадків, коли батьківський модуль відрізняється від модуля дитини. Навіщо потрібен магазин? Оскільки сховище позначає, що об'єкт можна безпечно зберігати та передати поза його визначальним модулем. Об'єкти, що містять лише ключі, можуть мати власні інваріанти, які оригінальний модуль хоче застосувати під час передачі та отримання; виключаючи ці з public_receiver, Sui змушує розробників обробляти їх у модулі (як ми побачимо з об'єктами, пов'язаними з душею). Якщо об'єкт має сховище, він є більш дозвільним, і Sui дозволяє загальній логіці передачі/прийому керувати ним зовні. ###Приклад: окремі батьківські та дочірні модулі Проілюструємо простим сценарієм: Склад, який зберігає об'єкти Parcel. Тип посилки визначається у власному модулі, а Склад - в іншому. Ми покажемо, як Warehouse може отримати дочірню посилку за допомогою public_receiver. 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. } } Давайте розберемо те, що відбувається в _parcel: Викликаємо public_receiver (&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: :send (ctx)). Цей крок гарантує, що посилка покине склад і переходить до користувача, який ініціював виведення. Ми також могли просто повернути Parcel з функції, і Sui розглядає його як вихід, який належить адресі абонента (оскільки це вихід функції введення). Виконання явної передачі є більш детальним, але дає зрозуміти, що відбувається (і дозволяє нам робити будь-які перевірки перед випуском об'єкта). Навіщо включати магазин у Parcel? Якщо у Parcel не вистачало можливості зберігання (тобто він мав лише ключ), виклик public_receiver у демо: :warehouse не компілюватиметься — Sui забезпечує те, що T має сховище для public_receiver. У цьому випадку ми будемо змушені отримати посилку за допомогою отримання в самому модулі посилки (або використовувати деякі стосунки з друзями), що ускладнює дизайн між модулями. Додавши магазин до Parcel, ми фактично говоримо «цей об'єкт можна вільно переміщати та отримувати зовнішніми модулями», що ми хочемо для загального шаблону контейнера. Шаблон виклику функції: Щоб використовувати їх у транзакції, потік буде таким: 1.Депозит (переказ на об'єкт) :Телефонуйте переказ: :public_transfer (parcel_obj, @warehouse_id) для відправки Посилки на Склад. Це позначає власника посилки як склад. (Ми використовуємо public_transfer тут, оскільки він знаходиться поза модулем Parcel, а Parcel має магазин. Всередині модуля посилки також спрацює звичайна передача.) Вивести (отримати назад) :Пізніше зателефонуйте _parcel (warehouse_obj, Прийом (ідентифікатор посилки,...)). Отримання можна отримати за допомогою SDK, посилаючись на ідентифікатор посилки та останню версію. Функція викличе public_receiver, а потім передасть вам посилку. Після дзвінка _parcel власник посилки повертається на адресу (вашу), тому це знову звичайний об'єкт, що належить адресі. Склад більше не володіє ним. Міркування між модулями: Зверніть увагу, що модуль Склад повинен знати про тип посилки (ми використовуємо demo: :parcel: :Parcel). Це тому, що ми явно вводимо Прийом як отримання. Якщо вам потрібен справді загальний контейнер, який міг би отримувати будь-який тип об'єкта, вам доведеться використовувати генерики або інший підхід (можливо, динамічні поля зі стиранням типів). Але для більшості випадків використання ви будете знати, яких типів дітей ви очікуєте. Навіщо public_receiver замість того, щоб просто телефонувати Receive? Якщо ми спробуємо передати: :receiver (&mut warehouse.id, parcel_ticket) у модулі складу, перевірка переміщення відхилить його, оскільки Parcel не визначено в демо: :warehouse. Sui надає public_receiver як благословенний спосіб зробити це за допомогою додаткової перевірки здібностей (вимагає зберігання). Аналогічно, Sui має передачу проти public_transfer, freeze object проти public_freeze object тощо, за тим самим шаблоном: версії public_ призначені для використання поза визначальним модулем і вимагають зберігання. Не забудьте дозвіл батьків: Навіть з public_receiver вам все одно потрібен &mut warehouse.id. Ми отримали його, тому що _parcel знаходиться в модулі складу і приймає &mut Warehouse. Таким чином, вилучити посилку може тільки той, хто міг би на це подзвонити (власник складу). Якщо модуль складу не надав таку функцію публічно, ніхто не міг би ззовні викликати public_receiver на її дочірніх програмах. Таким чином, крос-модуль не обходить батьківський контроль; він просто дозволяє батьківському коду працювати з дочірніми типами, які він не визначив. Примітка щодо можливості зберігання: Надання сховища об'єктів робить його більш гнучким, але трохи менш обмеженим - будь-який модуль з батьківським посиланням може витягнути його за допомогою public_receiver. Якщо ви хочетеобмежитиспосіб отримання об'єкта (наприклад, застосувати власну логіку або запобігти легкому вилученню), ви можете навмисно зробити його лише для ключів. Ми побачимо приклад цього з предметами, пов'язаними з душею. У таких випадках ви можете реалізувати спеціальну функцію отримання замість того, щоб покладатися на public_receiver. Підсумовуючи цю частину: public_receiver є вашим другом для керування дочірніми об'єктами, визначеними в інших модулах, якщо ці об'єкти мають можливість зберігання. Це дозволяє створювати крос-модульні системи (наприклад, наш склад/посилка), дотримуючись при цьому права власності та контролю доступу. Просто не забудьте включити магазин за дочірніми типами та використовувати public_transfer, коли надсилаєте їх батькові за межами їхнього модуля.

    5
  • 0xduckmove.Peera.
    0xduckmove220
    ДляSuiApr 25, 2025

    Підсумок відео може покращити вашу подорож Sui Dev

    Давайте будемо реальними, якщо ви коли-небудь будували наSui, ви, ймовірно, потрапили в деякі стіни. Від загадкових ідентифікаторів об'єктів до жонглювання CLI та обертання локальних мереж - це як підготовка до боротьби з босами, перш ніж ви навіть напишіть свій перший рядок бізнес-логіки. Під час недавнього семінару в рамках серії «Дорога до переповнення» Moven з Dubhe Foundation розбив, як працює Dubhe Engine, які проблеми він вирішує, і як це більше, ніж просто інструмент - це зростаючий рух. Посилання на відео: https://www.youtube.com/watch?v=CHkOS-TYehM Проблема: фрагментований інструмент, важка установка Moven розпочав справу реальною розмовою про поточний ландшафт розробників Sui: Новачки стикаються з крутою кривою навчання: налаштування гаманців, отримання тестових токенів, пакетів риштування, вивчення синтаксису Move, обертання локальних тестових мереж, налаштування SDK тощо. Навіть досвідчені розробники витрачають час на повторювані завдання налаштування, а не зосереджуються на фактичній логіці DApp. Кодові бази швидко стають монолітними - великі, безладні файли.move зі структурами даних, конструкторами, помічниками та функціями введення, все це зіпсовано разом. Коротше кажучи: екосистема швидко зростає, але інструменти досі не встигли. ##Рішення: Генерація коду на основі схеми В основіDubhe Engineлежить одна ключова ідея:Схема-перша розробка. За допомогою одного файла конфігурації (d.config.ts) розробники можуть визначити: Їх структури даних в ланцюжку Події Помилки Користувальницькі типи (навіть 2D вектори самовизначених структур!) Звідти одна команда (pnpm dub schema:gen) автоматично генерує повністю структурований пакет Move та інтеграцію з інтерфейсом, у комплекті з: Модульована структура файлів Компонованість на ланцюзі (через імпорт з опублікованих пакетів Sui) Налаштування локальної мережі, збірка, розгортання та підтримка інтерфейсу (Next.js готовий) Ви пишете логіку.Dubheобробляє плиту котла. ##* ⏱️ Реальний вплив: 80% менше повторюваного коду* У внутрішніх експериментах проекти, створені Dubb, показали, що лише* 20% коду*потрібно писати вручну, а решта - це риштування, автоматично згенеровані за допомогою схем. Це означає швидший прототип, менше помилок та більше часу, щоб зосередитися на тому, що насправді важливо: основна цінність вашого додатка. ##Двигун екосистеми розробника Дубб не зупиняється на риштуванні. Movin дав зрозуміти: цеінфраструктура для нової економіки забудовників. Ось як розвивається спільнота Dubb Engine: Газові субсидії:** Для новобудовників, які експериментують з Дуббом Нагороди за завдання:** Як і «хороші перші випуски» GitHub, але з нагородами Рівень управління (D-OS) :**Онлайн-голосування за пріоритетність проекту Підтримка Launchpad:** Допомога зрілим проектам забезпечити фінансування DApp Staking:** Користувачі можуть робити ставку D-токенів, щоб підтримати свої улюблені DApps та голосувати за рішення щодо дорожньої карти Цей цикл зворотного зв'язку підживлює всю екосистему Sui: більше розробників → більше додатків → більше користувачів → більше розробників.

    5
Ми використовуємо файли cookie, щоб гарантувати вам найкращий досвід на нашому сайті.
Детальніше