Sui.

Головна

Ласкаво просимо на форум спільноти Sui

Нові статті

  • article banner.
    harry phan.
    Apr 13, 2025
    Стаття
    Механіка контролю доступу та прийому об'єктів

    Це частина 2 серії «Об'єкти батьків-дитини в Sui Move». Ви можете прочитати частину 1 тут Передача контролю доступу об'єкта: :отримання Механіка Отже, ви помістили об'єктXвсередині батьківськогоP(передаючи X на ідентифікатор P) - як його повернути або використовувати? 🤔 Ось тут і приходить спеціальний механізм прийому Суй. Коли об'єкт передається батькові, він автоматично не вискакує. Він знаходиться там, належитьP. Щоб * використати* або * видалити* цей дочірній об'єкт у транзакції, ви повинніотриматийого. Sui надає структурований спосіб зробити це за допомогоюОтримання квит ката функції transfer: :reception. ##Приймальний квитк Подумайте про отримання як заявку на дочірній об'єкт типу Т. У транзакції замість того, щоб безпосередньо передавати дочірній об'єкт (яким ви ще не володієте) функції, ви передаєте Прийняття — по суті посилання на «об'єкт з ідентифікатором Y, який належить батькові X». Цей прийом є спеціальною структурою Move, яка містить ідентифікатор, версію та дайджест об'єкта, який потрібно отримати. Він має лише здатність падати, тобто він може існувати ефемерно, але не може зберігатися наполегливо. Іншими словами, це квиток одноразового використання всередині транзакції. Як ви отримуєте отримання? Зазвичай, виконуючи передачу. У програмованому блоці транзакцій (PTB) один крок може перенести об'єктCбатьківськомуP, що дає запит отримання, який може використовувати наступний крок. Якщо дитина вже сиділа у батькові з попередньої транзакції, ви можете вказати Приймання як вхід до нової транзакції (Sui SDK/CLI дозволяє вказати дочірній об'єкт за його ідентифікатором та батьком для створення квитка). Важливо: Прийом не є самим об'єктом - він ще не дає тобі володіння. Це просто сигналізує про те, що «об'єкт типу Т з цим ідентифікатором належить цьому батькові, і я маю намір його взяти». Щоб насправді захопити об'єкт, необхідно викликати transfer: :receiver: module example::toy_box { use sui::transfer::{Self, Receiving}; struct Toy has key { id: UID, name: vector } struct Box has key { id: UID } /// Remove a Toy child from a Box, returning the Toy to the caller. public entry fun take_toy(box: &mut Box, toy_ticket: Receiving): Toy { // Use the parent's UID and the Receiving ticket to get the Toy let toy = transfer::receive(&mut box.id, toy_ticket); // Now toy is an owned value we can return (or transfer to someone). toy } } У take_toy, toy_ticket: Отримання представляє іграшку, яка належить до коробки. Викликаючи transfer: :receiver (&mut box.id, toy_ticket), ми викликаємо власну логіку Суї, щоб фактично витягти об'єкт Toy з коробки. Це робить кілька критичних речей: Вінперевіряєпід час виконання, що toy_ticket дійсно посилається на об'єкт, який зараз належить полі (використовуючи UID батька). Якщо щось не збігається (неправильний батько або об'єкт, який насправді немає), це буде перервано. Потім він повертає фактичний об'єкт Toy як власне значення в транзакції, тобто тепер іграшка знаходиться під контролем нашої функції. Зверніть увагу, що нам довелося передати &mut box.id. Sui стверджує, що у нас єзмінне посилання на UID батьківдля отримання виклику. Це розумний контроль доступу: лише модуль, який може створити & mut UID батька, може дозволити отримання. Як правило, модуль визначення батьківського типу відкриває таку функцію, як take_toy, яку отримують внутрішні виклики. Якщо батьківський модуль не відкриває жодної функції, яка видає UID &mut (прямо чи опосередковано), то жоден зовнішній код не зможе вилучити його дочірні дані. Таким чином, батьківський модуль контролює, як і коли можна отримати доступ до дітей. У прикладі Box має поле id: UID. Оскільки take_toy знаходиться в тому ж модулі, він може запозичити &mut box.id. Зовнішні модулі або транзакції можуть викликати take_toy (box_obj, ticket), але самі не можуть викликати transfer: :receiver на Box, оскільки box.id є приватним. Цей шаблон гарантує, що лише авторизований код може отримати дітей.✅ А як щодо вкладених об'єктів? Якби іграшка була буквально полем всередині коробки (скажімо, Box {id, toy: Toy}), нам не потрібен був би жоден прийом - іграшка була б доступна, коли у вас є &mut Box. Але це також означає, що видалити його або обробити окремо важче (це як частина коробки). З дитячими предметами ми роз'єднуємо сховище: іграшка відокремлена і її потрібно явно вийняти. Ця чіткість є причиною того, що Sui вимагає отримання квитка та отримання дзвінка - це робить пошук дитини дозволеною дією. Змінювана довідкова вимога: Ви можете задатися питанням, чому &mut UID, а не лише &UID? Mutable гарантує, що батько буде заблоковані під час операції прийому, запобігаючи одночасним змінам та гарантуючи, що абонент насправді має право змінювати цього батька (зазвичай маючи на увазі, що він є власником). Це частина динамічних перевірок власності Sui - беручи змінну позику UID батьків, Sui гарантує, що жодна інша транзакція чи паралельна дія не можуть перешкодити під час вилучення дитини. Це трохи схоже на блокування батьківських дверей перед видаленням вмісту. Приклад використання в блоці транзакцій: Припустимо, що об'єкт Box належить Алісі, і у неї є об'єкт Toy, який вона хоче помістити в коробку, а потім випадково Вийміть його пізніше. Ось як це могло б бути k: Прикріпіть іграшку до коробки:** Аліса викликає transfer: :public_transfer (toy, @); в PTB. Це переносить іграшку під коробку (ми використовуємо public_transfer тут, оскільки це контекст транзакції — про це незабаром докладніше). Тепер іграшка - дитина коробки. -У тій же чи іншій транзакції, витягніть іграшку: Аліса викликає example: :toy_box: :take_toy (box_obj,), де отримання відноситься до іграшки. Під капотом виклики take_toy приймають, перевіряють зв'язок і повертає Toy. Тепер іграшка буде виведенням транзакції, зазвичай повертаючись під адресою Аліси (оскільки ми повернули її з функції введення). Ключові висновки: Дочірні об'єкти за замовчуванням недоступні; вам потрібен квиток прийому та відповідна функція, щоб вивести їх. Батьківський модуль вирішує, як ви можете отримати (надаючи функцію з &mut UID). transfer: :receiver використовується в модулі визначення батьків для об'єктів цього модуля або його друзів. Якщо тип дитини визначено в іншому місці, вам знадобиться інший підхід (введіть public_receiver...). Перш ніж рухатися далі, ще одна деталь: якщо об'єкт типу T має лише здатність ключа (немає магазину), Sui розглядає його як трохи більш обмежений. Такі об'єкти неможна отримувати за допомогою узагальненого коду поза їх модулем. На практиці це означає, що якщо T є лише ключем і стає дочірнім, вам потрібно буде обробляти його пошук у власному модулі або батьківському модулі за допомогою спеціального правила. Якщо T також має магазин, ми маємо більшу гнучкість через public_receiver. Давайте дослідимо це далі.

    2
  • article banner.
    harry phan.
    Apr 12, 2025
    Стаття
    ✏️ Об'єкти батьків-дитини в Sui Move

    У Sui Move об'єкти можуть володіти іншими об'єктами так само, як облікові записи власними об'єктами. Це відкриває нові шаблони дизайну (і кілька недоліків) для розробників. У цьому посібнику я розб'ю концепції батьків-дочірніх об'єктів у Sui Move на чотири частини: 1.Вступ до концепцій батьків-дитини в Sui Move 2.Механіка контролю доступу та прийому об'єктів 3.Міжмодульне управління дітьми за допомогою public_receive 4.Логіка прив'язки душі та шаблон квитанції повернення До кінця ви зрозумієте, як вставляти об'єкти, отримувати дочірні об'єкти за допомогою transfer: :receiver, керувати дочірніми модулями за допомогою public_receiver і навіть створювати об'єкти, пов'язані з душею, які бумерангом повертаються власнику. Вступ до концепцій батьків-дитини в Sui Move ###Що таке батьківські та дитячі об'єкти? У Sui кожен об'єкт має унікальний ідентифікатор та * власника. Зазвичайвласником є адреса*(як обліковий запис користувача), але власником також може бути інший об'єкт. Якщо об'єкт A володіє об'єктом B, ми називаємо A батьком, а B - дочірнім. Дитина належить об'єкту, а не адресній. Передача на об'єкти: Sui насправді не розрізняє адресу та ідентифікатор об'єкта під капотом - обидва є лише 32-байтовими ідентифікаторами. Це означає, що ви можете перенести об'єкт на ідентифікатор іншого об'єкта так само, як ви передаєте на адресу користувача. Коли ви робите це, ви фактично вкладаєте об'єкт всередині батьківського об'єкта. Час виконання Sui встановлює поле власника дитини на ідентифікатор батька (замість адреси) То чому це круто? Тому що дитина зберігає свій власний унікальний ідентифікатор і існує незалежно в сховищі, але тепер він прив'язаний до батька. Це все одно, що дати своєму другові унікальний предмет колекціонування, який він може тримати в шафці - предмет колекціонування зберігає свій ідентифікатор і його можна відстежувати, але шафка вашого друга тепер вказана як його власник. Важливо розрізнятиУнікальні та вкладені та дочірні об'єкти: Унікальний об'єкт (власник адреси) :**Звичайний об'єкт, що належить адресі (наприклад, обліковий запис користувача). Це випадок за замовчуванням — подумайте про NFT, монети тощо, які живуть безпосередньо в гаманці користувача. Кожен з них має унікальний ідентифікатор і є верхнім рівнем зберігання. Вкладений (обгорнутий) об'єкт:* Об'єкт, який зберігаєтьсявсередині даних іншого об'єкта* (наприклад, як поле в структурі). У цьому випадку внутрішній об'єкт є загорнутом, анеокремою сутністю верхнього рівня. Він не відображається за своїм ідентифікатором у глобальному сховищі, оскільки він є частиною байтового вмісту батьківського файлу. У Суї, якщо ви поставите об'єкт як поле в інший без спеціального поводження, він стає загорнутим. Дочірній об'єкт (об'єкт-власник) :*Об'єкт, який належить іншому об'єкту *але не загорнутий безпосередньо в його поля. Дочірня особа залишається окремим об'єктом верхнього рівня у сховищі (з власним ідентифікатором та даними), а ідентифікатор батька записується як власник у метаданих дитини. Це означає, що ви можете* запитувати або отримати доступ до дитини за її ідентифікатором (з правильними дозволами). Він фізично не вбудований у вміст батьків, просто логічно належить. Використовуючи нашу аналогію, це ніби ви дали своєму другові свій колекційний предмет для зберігання - він все ще окремо позначений та відстежується, просто зберігається у їхній шафці. Перевага створення дитячого об'єкта (через передачу) замість його обгортання полягає в тому, що посвідчення особи дитини залишається доступним зовні. Наприклад, дослідники або гаманці можуть перелічити дочірній об'єкт за ідентифікатором, тоді як обгорнутий об'єкт невидимий поза батьківським об'єктом. Дочірні об'єкти також підтримують стабільні ідентифікатори, навіть коли вони переміщуються між власниками або вкладаються в різних батьків. Це чудово підходить для таких речей, як мережевий інвентар або шаблони «гаманець всередині гаманця», де ви хочете, щоб об'єкт контейнера містив багато предметів, на які інші все ще можуть посилатися окремо Власність та доступ: Якщо об'єкт належить іншому об'єкту, лише власник батька зазвичай може отримати доступ до дочірнього об'єкта або використовувати його. Це форма динамічної авторизації. Наприклад, якщо Аліса володіє батьківським об'єктом P, а P володіє дочірнім об'єктом C, то лише Аліса (або транзакції, які підписує Аліса) може маніпулювати C. Суй здійснює це так, щоб володіння батьком було схоже на утримання ключів для всіх його дочірніх 🔑. Може бути, ви знаєте: Функція передачі на об'єкт Суй, по суті, дає нам деревоподібне володіння об'єктом. Батьки можуть мати багато дітей (і ці діти можуть мати своїх дітей, формуючи ієрархію). Це робиться шляхом обробки ідентифікаторів об'єктів, як адрес для передачі. У нас є: Адресні об'єкти**(звичайні унікальні об'єкти), Об'єкти, що належать об'єктам**(дочірні об'єкти, все ще верхнього рівня, але прив'язані до батьківського), Обгорнуті об'єкти**(вкладені в дані іншого об'єкта, а не верхнього рівня). У наступних статтях ми побачимо, як насправді отримати дочірні об'єкти або взаємодіяти з ними (оскільки вони не є безпосередньо доступними, як адресні) та як застосовувати правила навколо них.

    3
  • article banner.
    harry phan.
    Apr 10, 2025
    Стаття
    Створення DApp лотереї NFT наступного покоління за допомогою Sui Move та сучасного інтерфейсу користувача

    🧩 Створення DApp лотереї NFT наступного покоління за допомогою Sui Move та сучасного інтерфейсу користувача Це ваш остаточний посібник із створення гейміфікованого лотерейного DApp на базі NFT за допомогоюSui Move, з підтримкою кількох раундів, реферальними системами, управлінням DAO та системою дизайну Gen Z, яка сподобається. Від архітектури контрактів до потоку інтерфейсу користувача — давайте розберемося. 📦 Фазова поломка Фаза 1 — Основна лотерея Багатораундний геймплей NFT квитки Система винагород за рефералів Базове голосування DAO Фаза 2 - Маркетплейс та гейміфікація Інтеграція ринку NFT Бустери (збільшити шанс на виграш) Система джекпотів Приховані аеродропи Фаза 3 - DAO та багатоланцюг Крос-ланцюгова сумісність DAO з розширеними пропозиціями Динамічне ціноутворення Онлайн-аналітика 🧠 Глибоке занурення смарт-контракту на Sui Move Структура контракту module nft_lottery_x::nft_lottery_x { use sui::object; use sui::balance::{Balance, zero}; use sui::coin::{Self, Coin}; use sui::clock::Clock; use sui::random::Random; use sui::event::emit; use sui::transfer; use sui::tx_context::TxContext; use std::option; use std::signer; const EGameNotStarted: u64 = 1000; const EGameAlreadyFinished: u64 = 1001; const EInvalidPayment: u64 = 1002; const ENoTickets: u64 = 1003; const EWinnerAlreadyChosen: u64 = 1004; const ENotWinner: u64 = 1005; public struct Game has key { id: UID, ticket_price: u64, start_time: u64, end_time: u64, total_tickets: u32, round: u32, winner: Option, balance: Balance, referral_bonus: u64, } public struct Ticket has key { id: UID, game_id: ID, ticket_number: u32, buyer: address, referrer: Option, } public struct GameCreated has copy, drop { game_id: ID, start_time: u64, end_time: u64, ticket_price: u64, } public struct TicketBought has copy, drop { game_id: ID, ticket_number: u32, buyer: address, referrer: Option, } public struct WinnerAnnounced has copy, drop { game_id: ID, winner_ticket: u32, round: u32, } public struct RewardClaimed has copy, drop { game_id: ID, ticket_number: u32, amount: u64, } public fun create_game( start_time: u64, end_time: u64, ticket_price: u64, referral_bonus: u64, ctx: &mut TxContext ) { let game = Game { id: object::new(ctx), ticket_price, start_time, end_time, total_tickets: 0, round: 1, winner: option::none(), balance: zero(), referral_bonus, }; emit(GameCreated { game_id: object::id(&game), start_time, end_time, ticket_price, }); transfer::share_object(game); } public fun buy_ticket( game: &mut Game, coin: Coin, clock: &Clock, referrer: Option, ctx: &mut TxContext ): Ticket { assert!(clock.timestamp_ms() >= game.start_time, EGameNotStarted); assert!(clock.timestamp_ms() (TicketBought { game_id: object::id(game), ticket_number: ticket.ticket_number, buyer: ticket.buyer, referrer: ticket.referrer, }); ticket } public entry fun determine_winner( game: &mut Game, rand: &Random, clock: &Clock, ctx: &mut TxContext ) { assert!(clock.timestamp_ms() >= game.end_time, EGameNotStarted); assert!(game.winner.is_none(), EWinnerAlreadyChosen); assert!(game.total_tickets > 0, ENoTickets); let mut generator = rand.new_generator(ctx); let winning_ticket = generator.generate_u32_in_range(1, game.total_tickets); game.winner = option::some(winning_ticket); emit(WinnerAnnounced { game_id: object::id(game), winner_ticket: winning_ticket, round: game.round, }); } public fun claim_reward( ticket: Ticket, game: Game, ctx: &mut TxContext ): Coin { assert!(object::id(&game) == ticket.game_id, EInvalidPayment); let ticket_num = ticket.ticket_number; assert!(game.winner.contains(&ticket_num), ENotWinner); let amount = game.balance.value(); let reward = game.balance.into_coin(ctx); emit(RewardClaimed { game_id: object::id(&game), ticket_number: ticket.ticket_number, amount, }); object::delete(object::id(&game)); reward } } Ключові висновки: ✅ Balanceзабезпечує безпеку типу та належне поводження з монетами ✅ Optionчітко сигналізує, чи був обраний переможець ✅ Події пропонують простежуваність для фронтендів та дослідників 🛠 Команди Sui CLI sui client call --package --module nft_lottery_x --function create_game --args --gas-budget 10000000 Щоб купити квиток, визначити переможця або отримати винагороду, дотримуйтесь подібних потоків CLI. 🔮 Майбутні доповнення Логіка автоматичного скидання для наступного раунду claim_reward Випускайте більше подій на кшталт ReferralRewardDistributed Рефактор джекпотів та рефералів у підмодулі Дайте мені знати, якщо ви хочете, щоб частина 2 створила інтерфейс користувача та інтегрувалася в testnet Sui!

    3
  • article banner.
    harry phan.
    Apr 09, 2025
    Стаття
    Посібник з транзакцій Sui: від налаштування до виконання та перевірки

    Посібник з транзакцій Sui: від налаштування до виконання та перевірки Якщо вам цікаво про гайки виконання транзакцій на блокчейні Sui і хочете поглиблений практичний посібник, який проведе вас через кожен крок. У цій статті ми розглянемо весь шлях - від налаштування вашого клієнтського середовища, перевірки об'єктів вашого гаманця, обчислення комісій за газ, до підписання та виконання транзакції та, нарешті, перевірки її деталей. Давайте розберемо це крок за кроком: Що робить Суй таким особливим? 🔥 Sui пропонує високооптимізовану платформу для децентралізованих додатків (DApps) та смарт-контрактів. Його елегантний дизайн в управлінні комісіями за газ та логікою транзакцій робить його захоплюючим майданчиком для розробників, які прагнуть розширити межі технології Web3. №2. Початок роботи: Налаштування середовища та конфігурація гаманця ⚙️ 2.1. Налаштування середовища клієнта Sui Перш ніж зануритися в транзакції, переконайтеся, що ваш клієнт Sui правильно налаштований. Sui підтримує кілька мереж (devnet, mainnet, testnet), і ви можете перевірити, яка з них активна за допомогою команди нижче: ➜ sui client envs ╭─────────┬─────────────────────────────────────┬────────╮ │ alias │ url │ active │ ├─────────┼─────────────────────────────────────┼────────┤ │ devnet │ https://fullnode.devnet.sui.io:443 │ │ │ mainnet │ https://fullnode.mainnet.sui.io:443 │ │ │ testnet │ https://fullnode.testnet.sui.io:443 │ * │ ╰─────────┴─────────────────────────────────────┴────────╯ Це підтверджує, що ви підключені до testnet. Перебування в правильній мережі - це перший крок до успішної транзакції. 2.2. Перевірка активного гаманця Далі перевірте свою активну адресу гаманця. Це має вирішальне значення, оскільки кожна транзакція пов'язана з ідентифікацією вашого гаманця: ➜ sui client active-address 0x35370841d2e69b495b1e2f944a3087e4242f314e503691a00b054e0ee2a45a73 2.3. Запит на об'єкти, що належать Використовуючи API Suix_GetOwnEdObjects, ви можете отримати деталі про об'єкти (наприклад, монети), якими ви володієте, на блокчейні. Ця команда допомагає перевірити баланс вашого рахунку та активи, доступні для транзакцій: { "jsonrpc": "2.0", "id": 1, "method": "suix_getOwnedObjects", "params": [ "0x35370841d2e69b495b1e2f944a3087e4242f314e503691a00b054e0ee2a45a73", { "filter": { "MatchAll": [ { "StructType": "0x2::coin::Coin" } ] }, "options": { "showType": true, "showOwner": true, "showPreviousTransaction": true } } ] } Цей крок є життєво важливим для перевірки того, що у вашому гаманці є необхідні монети (в даному випадку монети SUI), перш ніж робити будь-які транзакції. №3. Розрахунок газу: Бюджетування транзакційних витрат 💸 Газ - це паливо, яке забезпечує транзакції блокчейну. Важливо розуміти як ціну на газ, так і бюджет газу, щоб уникнути збоїв у транзакціях. 3.1. Підвищення ціни на газ Поточну ціну газу можна отримати за допомогою виклику API SUIX_getReferenceGasPrice: { "jsonrpc": "2.0", "id": 1, "method": "suix_getReferenceGasPrice", "params": [] } Якщо API повертає «1000", це означає, що кожна одиниця газу коштує 1000 MIST. Пам'ятайте, що 1 SUI дорівнює 10 ^ 9 MIST, тому навіть невеликі цифри в MIST можуть скластися під час складання бюджету. 3.2. Встановлення бюджету на газ Ваш бюджет газу - це максимальна кількість газу (у MIST), яку ви готові витратити. Для нашого прикладу, припустимо, ваш бюджет газу становить 4964000 MIST. Загальна вартість транзакції зазвичай обчислюється як: Загальна вартість = Вартість обчислення+вартість зберігання - знижка на зберігання Наприклад: • Вартість обчислення: 1 000 000 MIST • Вартість зберігання: 2,964,000 MIST • Знижка на зберігання: 978,120 MIST Отже, чиста вартість стає 1 000 000 + 2 964 000 - 978 120 = 2 985 880 МІСТ. Точне встановлення бюджету газу гарантує, що ваша транзакція має достатньо коштів для успішного виконання. №4. Створення транзакції: сухий біг для впевненості 🔧 Перш ніж надсилати реальну транзакцію, найкраще запустити «сухий пробіг», щоб виявити будь-які потенційні проблеми. Це дозволяє перевірити логіку транзакцій, не витрачаючи жодного газу. 4.1. Побудова транзакції сухого запуску Ось зразок функції TypeScript, яка демонструє, як підготувати та виконати транзакцію сухого запуску. У цьому коді описано, як розділити монети та підготувати операції з переказу: export const signSuiDryRunTransaction = async (requestParams: SignDryRequestParams): Promise => { const { gasPrice, privateKey, coinRefs, network, recipients } = requestParams; const keypair = Ed25519Keypair.fromSecretKey(privateKey); const tx = newTransaction(); // Configure gas payment, price, and sender tx.setGasPayment(coinRefs); tx.setGasPrice(gasPrice); tx.setSender(keypair.toSuiAddress()); // Split coins based on each recipient's amount const coins = tx.splitCoins(tx.gas, recipients.map((transfer) => transfer.amount)); recipients.forEach((transfer, index) => { tx.transferObjects([coins[index]], transfer.to); }); // Build and sign the transaction with the client const client = newSuiClient({ url: getFullnodeUrl(network) }); const bytes = await tx.build({ client }); const { signature } = await keypair.signTransaction(bytes); await verifyTransactionSignature(bytes, signature, { address: keypair.getPublicKey().toSuiAddress() }); return JSON.stringify([toBase64(bytes), signature]); }; Цей крок сухого запуску має вирішальне значення для того, щоб кожна деталь була правильною, перш ніж вкладати реальні кошти. №5. Підписання та виконання транзакції: об'єднання всього ✍️ Після успішного сухого запуску наступним кроком є підписання та відправка транзакції на блокчейні. 5.1. Підписання транзакції Нижче наведено уточнений приклад функції, яка підписує угоду із зазначеним бюджетом газу: const signSuiTransaction = async (requestParams: SignRequestParams): Promise => { const { gasBudget, gasPrice, privateKey, coinRefs, network, recipients } = requestParams; const keypair = Ed25519Keypair.fromSecretKey(privateKey); const tx = newTransaction(); // Set up gas parameters, including the gas budget tx.setGasPayment(coinRefs); tx.setGasPrice(gasPrice); tx.setGasBudget(gasBudget); tx.setSender(keypair.toSuiAddress()); // Split coins for each recipient const coins = tx.splitCoins(tx.gas, recipients.map((transfer) => transfer.amount)); recipients.forEach((transfer, index) => { tx.transferObjects([coins[index]], transfer.to); }); // Build the transaction and sign it const client = newSuiClient({ url: getFullnodeUrl(network) }); const bytes = await tx.build({ client }); const { signature } = await keypair.signTransaction(bytes); await verifyTransactionSignature(bytes, signature, { address: keypair.getPublicKey().toSuiAddress() }); return JSON.stringify([toBase64(bytes), signature]); }; Ця функція інтегрує всі необхідні параметри, включаючи дані про газ та одержувачів, гарантуючи надійне підписання вашої транзакції та готовність до виконання. 5.2. Виконання транзакції Після підписання транзакція надсилається в блокчейн за допомогою кінцевої точки API SUI_ExecuteTransactionBlock: curl --location 'https://fullnode.testnet.sui.io:443' \ --header 'Content-Type: application/json' \ --data '{ "jsonrpc": "2.0", "id": 1, "method": "sui_executeTransactionBlock", "params": [ "", [""], { "showInput": true, "showRawInput": true, "showEffects": true, "showEvents": true, "showObjectChanges": true, "showBalanceChanges": true }, "WaitForLocalExecution" ] }' Цей виклик повертає детальну відповідь JSON з такою інформацією, як дайджест транзакцій, споживання газу, модифікації об'єктів та оновлення балансу. №6. Перевірка вашої транзакції: Перевірте все 🔍 Після виконання транзакції важливо переконатися, що все виконано, як очікувалося. 6.1. Перевірка браузера Ви можете перевірити свою транзакцію на блокчейн-провіднику, наприклад Suivision Testnet Explorer. Провідник відображає всі деталі транзакції в інтуїтивно зрозумілому візуальному форматі, що полегшує виявлення будь-яких проблем. 6.2. Перевірка командного рядка Для більш детального аудиту скористайтеся командним рядком: sui client tx-block -- 3FopuDy5qzKm1kLRFZCdi8Lynadym9j15NaVxzUH6nYD Ця команда забезпечує вичерпну розбивку транзакції, включаючи реквізити відправника, платіж за газ, зміни об'єкта та статус виконання. №7. Аналіз відповіді JSON: розуміння шарів транзакції Давайте розпакуємо відповідь JSON, яку ви отримаєте після виконання транзакції: 7.1. Огляд транзакцій jsonrpc & id: Стандартні поля для протоколу JSON-RPC. дайджест: Унікальний хеш транзакції (наприклад, «3fOPudy5qzkm1klrfzcdi8lynadym9j15navxzuH6nyd»), який використовується для відстеження. TimeStamps & checkpoint: Надайте контекст щодо того, коли транзакція була виконана, та контрольну точку блокчейну в цей момент. 7.2. Зміст транзакції Дані відправника та газу: включає адресу відправника та всі конфігурації, пов'язані з газом (оплата, ціна, бюджет). Операції (транзакції): Логіка транзакцій включає такі операції, як: SplitCoins: Розбивання газової монети на менші частини. TransferObjects: переміщення сегментів монет на вказані адреси одержувачів. Підписи: Криптографічні підписи (кодовані Base64) забезпечують автентичність транзакції. 7.3. Ефекти виконання Статус: статус «успіх» підтверджує, що транзакція була оброблена без помилок. Використання газу: Детально описує витрати на обчислення та зберігання разом із будь-якими відповідними знижками. Зміни об'єктів: Визначає, які об'єкти були змінені, створені або оновлені в результаті транзакції. Залежності: перераховує пов'язані хеші транзакцій, від яких залежить ця транзакція. Ця детальна розбивка має важливе значення для налагодження та підвищення продуктивності DApp. №8. Практична інформація для розробників: поради та висновки Розуміння кожного кроку цього процесу дає вам навички створення безпечних, ефективних програм Web3 на Sui. Ці відомості не тільки допомагають вирішити проблеми, але й дають вам змогу впевнено впроваджувати інновації в екосистемі Sui.

    3
  • article banner.
    0xduckmove.
    Apr 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, не є необов'язковою - це важливо

    4
  • article banner.
    Lokie.
    Mar 16, 2025
    Стаття
    Step by step guide to create a Suiet wallet

    Step by step guide to create a Suiet wallet: Download suiet extension: https://suiet.app/ After successful installation, click on the Suiet icon in your browser and select "Create New". Set a strong password to protect your wallet. Write down and save your recovery phrase in a safe place. This phrase is needed to recover your wallet if needed Done

    1
  • article banner.
    Bahador.
    Mar 15, 2025
    Стаття
    Подорож як розробник смарт-контрактів SUI Move

    У сьогоднішній статті я хочу зануритися в пропозицію дорожньої карти для тих, хто любить вступити у шлях розвитку SUI. 1. Зрозумійте основи блокчейну Основні поняття:* Ознайомтеся з ключовими концепціями блокчейну, такими як децентралізація, механізми консенсусу, криптографічні примітиви та смарт-контракти. Огляд блокчейну SUI:* Дізнайтеся про те, що робить SUI унікальним — його об'єктно-орієнтовану модель даних, цілі ефективності та як він керує державним управлінням. 2. Вивчіть мову руху Основи мови:* Почніть з основ мови програмування Move. Зосередьтеся на: Типи ресурсів:* Як працюють ресурси для забезпечення безпеки та власності. Модулі та структури:* Як визначити модулі та структури даних. Функц��ї входу:* Як транзакції виконуються через визначені точки входу. Рекомендовані ресурси: Використовуйте офіційні навчальні посібники з мови Move, документацію та зразки сховищ коду. 3. Налаштуйте середовище розробки Інструменти та CLI:* Встановіть SUI CLI та налаштуйте ланцюжок інструментів «Переміщення» на локальній машині. Місцеве тестове середовище:* Налаштуйте локальну мережу розробки SUI або використовуйте доступні тест-мережі. Це допоможе вам експериментувати з розгортанням та тестуванням смарт-контрактів перед запуском. IDE та налагодження:* Виберіть інтегроване середовище розробки (IDE), яке підтримує Move (наприклад, VSCode з розширеннями Move) та ознайомтеся з налагодженням та тестуванням ваших контрактів. 4. Створіть свій перший простий контракт Практичні підручники:* Почніть з простого проекту, такого як токен-контракт. Це дозволить застосувати основні конструкції Move. Дослідіть специфічні шаблони для UI:* Працюйте з об'єктною моделлю SUI та дізнайтеся, як транзакції обробляються в екосистемі SUI. Документація та приклади:* Використовуйте документацію розробників SUI та зразки проектів, щоб зрозуміти найкращі практики. 5. Глибоке занурення в специфічні функції для SUI Об'єктно-центрична модель:* Зрозумійте, як SUI по-різному ставиться до об'єктів від блокчейнів на основі облікових записів, таких як Ethereum. Модель газу та транзакцій:* Вивчіть, як розраховуються комісії за газ та як керується виконанням транзакцій у SUI. Державне управління:* Дізнайтеся про підхід SUI до зберігання стану, модульних оновлень та управління життєвим циклом об'єктів. 6. Тестування, налагодження та розгортання Тестування одиниць та інтеграції:* Напишіть тести, щоб перевірити логіку та безпеку ваших смарт-контрактів. Переконайтеся, що ви охоплюєте крайові випадки та потенційні вразливості. Локальне та тест-мережеве розгортання:* Розгортайте свої контракти в контрольованому середовищі, щоб побачити, як вони працюють у реальних умовах. Інструменти:* Використовуйте інструменти налагодження SUI та функції журналу для ітерації та вдосконалення вашого коду. 7. Найкращі практики безпеки та аудит коду Зрозумійте загальні підводні камені:* Вивчіть поширені вразливості безпеки в смарт-контрактах (наприклад, повторний вхід, неправильний контроль доступу) і те, як дизайн Move пом'якшує їх. Код Відгуки:* Приєднуйтесь до перевірки коду спільноти або співпрацюйте з колегами, щоб перевірити та покращити свій код. Формальна перевірка:* Вивчіть усі доступні офіційні інструменти перевірки для Move, щоб математично довести правильність ваших контрактів. 8. Приєднуйтесь до спільноти розробників SUI Канали спільноти:* Спілкуйтеся з іншими розробниками через форуми, канали Discord або дзвінки спільноти. Обмін досвідом та викликами неоціненний. Внески з відкритим кодом:* Сприяйте проектам з відкритим кодом або сховищам розробників, пов'язаних із SUI та Move. Залишайтеся в оновленнях:* Слідкуйте за блогами SUI та Move, сховищами GitHub та каналами соціальних мереж, щоб відстежувати нові розробки, оновлення та найкращі практики. 9. Ознайомтеся з розширеними темами Складні програми:* Коли вам стане зручніше, експериментуйте з більш досконалими дизайнами смарт-контрактів, такими як протоколи децентралізованих фінансів (DeFi), NFT або гаманці з кількома підписами. Суперсумісність та інтеграція:* Дізнайтеся, як взаємодіяти з іншими смарт-контрактами та інтегрувати модулі SUI Move з позаланцюговими системами. Продуктивність та масштабованість:* Дослідіть методи оптимізації ваших контрактів для швидкості та економічної ефективності на блокчейні SUI. 10. Створіть портфоліо та продовжуйте практикувати Вітринні проекти:* Розробіть та документуйте серію проектів, які демонструють ваше розуміння та досвід. Постійне навчання:* Blockchain і Move швидко розвиваються - зробіть постійне навчання звичкою, переглядаючи документацію, відвідуючи семінари та беручи участь у хакатоні. Цикл зворотного зв'язку:* Використовуйте відгуки спільноти, щоб вдосконалити свої навички та залишатися на передовій у розробці смарт-контрактів. Хоча вищезазначені пункти є пропозиціями і не є єдиним способом перетворитися на розробника SUI, я сподіваюся, що це корисно для вас, хлопці. Щасливе кодування. Щасливого позову!

    2
  • article banner.
    0xduckmove.
    Mar 12, 2025
    Стаття
    Setting Up a Project to Test the SUI Name Service (SuiNS)

    The SUI Name Service (SuiNS) is a decentralized naming system on the SUI blockchain that allows users to map human-readable names (e.g., "0xduck.sui") to blockchain addresses or other data, enhancing usability and accessibility. For developers, testing the SuiNS SDK is an essential step to ensure applications can resolve these names correctly. In this article, we’ll walk you through the process of setting up a project to test the SuiNS SDK, from preparing your development environment to querying a name record like "0xduck.sui" and understanding the results. Introduction to SUI Name Service The SUI Name Service (SuiNS) simplifies blockchain interactions by allowing users to register memorable names instead of using complex cryptographic addresses. For example, instead of sending tokens to "0x1234...abcd", you could send them to "0xduck.sui". Testing the SuiNS SDK ensures that your application can correctly interact with this system, retrieving and interpreting name records as needed. In this project, we’ll set up a Node.js environment, connect to the SUI mainnet, and write a script to query the name record for "0xduck.sui". By the end, you’ll have a working setup to explore SuiNS further. Prerequisites Before starting, ensure you have the following: Node.js (version 14 or higher) and npm (version 6 or higher) installed. Download them from nodejs.org if needed. Basic understanding of JavaScript, particularly asynchronous programming (e.g., async/await). A code editor like Visual Studio Code (VS Code) for writing and running scripts. An internet connection to install packages and connect to the SUI. Setting Up the Development Environment Let’s create a new project directory and initialize it as a Node.js project. This will provide a clean workspace for our test. Step-by-Step Instructions: Open your terminal (e.g., Command Prompt, PowerShell, or a Unix shell). Create a new directory: mkdir suins-test-project cd suins-test-project Initialize a Node.js project: Run this command to create a package.json file with default settings: npm init -y Your project is now set up with a basic structure. Installing Dependencies Run the following in your terminal: npm install @mysten/suins @mysten/sui Verify the Installation: Check that the packages are added to package.json under dependencies. You can also confirm the installed versions by running: npm list @mysten/suins @mysten/sui This should output something like: suins-test-project@1.0.0 ├── @mysten/sui@x.x.x └── @mysten/suins@y.y.y Configuring the SUI Client The SUI client connects your project to the SUI blockchain. For testing, we’ll use the mainnet. Create a Script File: In your project directory, create a file named test-suins.js: touch test-suins.js # On Unix/macOS echo. > test-suins.js # On Windows Open test-suins.js in your editor and add the following: import { getFullnodeUrl, SuiClient } from '@mysten/sui/client'; // Create a SUI client connected to the testnet const suiClient = new SuiClient({ url: getFullnodeUrl('testnet') }); Note: If you encounter an error about ES modules (e.g., "Cannot use import statement outside a module"), add "type": "module" to your package.json: { "name": "suins-test-project", "version": "1.0.0", "type": "module", ... } Testing the Name Service Now, let’s write a script to query the name record for "0xduck.sui" and log the result. import { getFullnodeUrl, SuiClient } from '@mysten/sui/client'; import { SuinsClient } from '@mysten/suins'; // Create a SUI client connected to the testnet // const suiClient = new SuiClient({ url: getFullnodeUrl('mainnet') }); const client = new SuiClient({ url: getFullnodeUrl('mainnet') }); // Create a SuiNS client using the SUI client const suinsClient = new SuinsClient({ client, network: 'mainnet', }); // Function to test the name service async function testNameService() { try { // Query the name record for 'demo.sui' const nameRecord = await suinsClient.getNameRecord('0xduck.sui'); // Log the result console.log('Name Record for "0xduck.sui":', nameRecord); } catch (error) { console.error('Error fetching name record:', error.message); } } testNameService(); In your terminal, execute: node test-suins.js

    3
  • article banner.
    Bahador.
    Mar 11, 2025
    Стаття
    Suibase, a great tool to experience the SUI

    As I was checking some resources for the SUI development, I faced a tool named, suibase. In my exploration on that, I found it very helpful, especially when using localnet which a local explorer will be set up on our local system. I loved it so much. as there is stated in the official website of Suibase: Suibase makes it easy to create "workdirs", each defining a distinct development environment targeting a network. It seems like virtual env in python programming. As far as I found this tool, there are many usefull functionalities which we can take benefit of: Key functionalities of Suibase include: Workdir Management: Suibase enables the creation of isolated workdirs for each network, ensuring that configurations and dependencies are maintained separately. This isolation facilitates organized and efficient development workflows. ​ Suibase Simplified Command-Line Interface:* The tool provides scripts such as lsui, dsui, tsui, and msui, which serve as frontends to the Mysten Labs sui binaries for localnet, devnet, testnet, and mainnet, respectively. These scripts eliminate the need to manually switch environments, as they automatically execute the appropriate sui client and keystore for the targeted network. ​ Localnet Operations:* Suibase offers commands like localnet start, localnet stop, and localnet status to manage the local network. Additionally, the localnet regen command allows developers to reset the network to its initial state, complete with predefined addresses and aliases, which is particularly useful for testing purposes. ​ Faucet Functionality:* The localnet faucet command enables the distribution of Sui coins to specified addresses or all addresses within the localnet, facilitating testing and development activities. ​ Independent Installation:* Suibase operates independently of other Mysten Labs installations and keystores, ensuring that it does not interfere with existing setups. This design allows Suibase to coexist safely with standard installations on the same system. ​ By providing these features, Suibase enhances the development experience on the Sui network, offering a structured and efficient environment for building and testing applications.​ I recommend testing it!

    3
  • article banner.
    Bahador.
    Mar 11, 2025
    Стаття
    How to fix the SUI installation error?

    When I try to install and build the SUI binary on my local system with this command: cargo install --git https://github.com/MystenLabs/sui.git --bin sui --branch devnet I face this error: Please specify a package, e.g. cargo install --git https://github.com/MystenLabs/sui.git anemo-benchmark. After some digging, I found the solution and was able to install and build it error-free and completely using some modification in the above command: For Devnet: cargo install --locked --git https://github.com/MystenLabs/sui.git sui --branch devnet For Testnet: cargo install --locked --git https://github.com/MystenLabs/sui.git sui --branch devnet This way, you can install and build SUI on your local machine and start on your way! Best of luck.

    3

Пости

203
  • Ramirez.
    Apr 14, 2025
    Обговорення

    Проблеми з копіткою та обміном на гаманці SUI

    Привіт, люди, я використовую гаманець SUI і зіткнувся з невеликою перешкодою. Я зробив ставку на свій SUI на AfSui (ліквідний стейкінг), але тепер, коли я натискаю кнопку розстановки, він просто продовжує завантажуватися, і нічого не відбувається. Натомість спробував замінити SUI і отримав помилку: «Розрахунок не вдалося знайти постачальників свопів.» Мої кошти, здається, в глухому куті. Спробував перевстановити додаток і перевірити баланс плати за газ, але не пощастило. Будь-яка порада, як це виправити?

    • Sui
    • Architecture
    0
    2
  • farshad.
    Apr 14, 2025
    Обговорення

    Як отримати доступ до гаманця Sui, якщо він створений через Google або ZKLogin?

    Я налаштував свій гаманець Sui за допомогою Google, але не можу знайти парольну фразу чи приватний ключ. Як отримати доступ до свого гаманця та переконатися, що моя адреса щоразу однакова?

    • Sui
    0
    2
  • deriss.
    Apr 13, 2025
    Обговорення

    Чи можу я переглянути свій апаратний гаманець Sui у Phantom?

    Я намагаюся переглянути свій гаманець Sui, налаштований на апаратному гаманці за допомогою Phantom. Однак, схоже, у Phantom відображаються лише неапаратні гаманці. Як я можу зробити так, щоб мій апаратний гаманець Sui з'явився в додатку Phantom, якщо це можливо?

    • Security Protocols
    0
    1
  • article banner.
    harry phan.
    Apr 13, 2025
    Стаття

    Механіка контролю доступу та прийому об'єктів

    Це частина 2 серії «Об'єкти батьків-дитини в Sui Move». Ви можете прочитати частину 1 тут Передача контролю доступу об'єкта: :отримання Механіка Отже, ви помістили об'єктXвсередині батьківськогоP(передаючи X на ідентифікатор P) - як його повернути або використовувати? 🤔 Ось тут і приходить спеціальний механізм прийому Суй. Коли об'єкт передається батькові, він автоматично не вискакує. Він знаходиться там, належитьP. Щоб * використати* або * видалити* цей дочірній об'єкт у транзакції, ви повинніотриматийого. Sui надає структурований спосіб зробити це за допомогоюОтримання квит ката функції transfer: :reception. ##Приймальний квитк Подумайте про отримання як заявку на дочірній об'єкт типу Т. У транзакції замість того, щоб безпосередньо передавати дочірній об'єкт (яким ви ще не володієте) функції, ви передаєте Прийняття — по суті посилання на «об'єкт з ідентифікатором Y, який належить батькові X». Цей прийом є спеціальною структурою Move, яка містить ідентифікатор, версію та дайджест об'єкта, який потрібно отримати. Він має лише здатність падати, тобто він може існувати ефемерно, але не може зберігатися наполегливо. Іншими словами, це квиток одноразового використання всередині транзакції. Як ви отримуєте отримання? Зазвичай, виконуючи передачу. У програмованому блоці транзакцій (PTB) один крок може перенести об'єктCбатьківськомуP, що дає запит отримання, який може використовувати наступний крок. Якщо дитина вже сиділа у батькові з попередньої транзакції, ви можете вказати Приймання як вхід до нової транзакції (Sui SDK/CLI дозволяє вказати дочірній об'єкт за його ідентифікатором та батьком для створення квитка). Важливо: Прийом не є самим об'єктом - він ще не дає тобі володіння. Це просто сигналізує про те, що «об'єкт типу Т з цим ідентифікатором належить цьому батькові, і я маю намір його взяти». Щоб насправді захопити об'єкт, необхідно викликати transfer: :receiver: module example::toy_box { use sui::transfer::{Self, Receiving}; struct Toy has key { id: UID, name: vector } struct Box has key { id: UID } /// Remove a Toy child from a Box, returning the Toy to the caller. public entry fun take_toy(box: &mut Box, toy_ticket: Receiving): Toy { // Use the parent's UID and the Receiving ticket to get the Toy let toy = transfer::receive(&mut box.id, toy_ticket); // Now toy is an owned value we can return (or transfer to someone). toy } } У take_toy, toy_ticket: Отримання представляє іграшку, яка належить до коробки. Викликаючи transfer: :receiver (&mut box.id, toy_ticket), ми викликаємо власну логіку Суї, щоб фактично витягти об'єкт Toy з коробки. Це робить кілька критичних речей: Вінперевіряєпід час виконання, що toy_ticket дійсно посилається на об'єкт, який зараз належить полі (використовуючи UID батька). Якщо щось не збігається (неправильний батько або об'єкт, який насправді немає), це буде перервано. Потім він повертає фактичний об'єкт Toy як власне значення в транзакції, тобто тепер іграшка знаходиться під контролем нашої функції. Зверніть увагу, що нам довелося передати &mut box.id. Sui стверджує, що у нас єзмінне посилання на UID батьківдля отримання виклику. Це розумний контроль доступу: лише модуль, який може створити & mut UID батька, може дозволити отримання. Як правило, модуль визначення батьківського типу відкриває таку функцію, як take_toy, яку отримують внутрішні виклики. Якщо батьківський модуль не відкриває жодної функції, яка видає UID &mut (прямо чи опосередковано), то жоден зовнішній код не зможе вилучити його дочірні дані. Таким чином, батьківський модуль контролює, як і коли можна отримати доступ до дітей. У прикладі Box має поле id: UID. Оскільки take_toy знаходиться в тому ж модулі, він може запозичити &mut box.id. Зовнішні модулі або транзакції можуть викликати take_toy (box_obj, ticket), але самі не можуть викликати transfer: :receiver на Box, оскільки box.id є приватним. Цей шаблон гарантує, що лише авторизований код може отримати дітей.✅ А як щодо вкладених об'єктів? Якби іграшка була буквально полем всередині коробки (скажімо, Box {id, toy: Toy}), нам не потрібен був би жоден прийом - іграшка була б доступна, коли у вас є &mut Box. Але це також означає, що видалити його або обробити окремо важче (це як частина коробки). З дитячими предметами ми роз'єднуємо сховище: іграшка відокремлена і її потрібно явно вийняти. Ця чіткість є причиною того, що Sui вимагає отримання квитка та отримання дзвінка - це робить пошук дитини дозволеною дією. Змінювана довідкова вимога: Ви можете задатися питанням, чому &mut UID, а не лише &UID? Mutable гарантує, що батько буде заблоковані під час операції прийому, запобігаючи одночасним змінам та гарантуючи, що абонент насправді має право змінювати цього батька (зазвичай маючи на увазі, що він є власником). Це частина динамічних перевірок власності Sui - беручи змінну позику UID батьків, Sui гарантує, що жодна інша транзакція чи паралельна дія не можуть перешкодити під час вилучення дитини. Це трохи схоже на блокування батьківських дверей перед видаленням вмісту. Приклад використання в блоці транзакцій: Припустимо, що об'єкт Box належить Алісі, і у неї є об'єкт Toy, який вона хоче помістити в коробку, а потім випадково Вийміть його пізніше. Ось як це могло б бути k: Прикріпіть іграшку до коробки:** Аліса викликає transfer: :public_transfer (toy, @); в PTB. Це переносить іграшку під коробку (ми використовуємо public_transfer тут, оскільки це контекст транзакції — про це незабаром докладніше). Тепер іграшка - дитина коробки. -У тій же чи іншій транзакції, витягніть іграшку: Аліса викликає example: :toy_box: :take_toy (box_obj,), де отримання відноситься до іграшки. Під капотом виклики take_toy приймають, перевіряють зв'язок і повертає Toy. Тепер іграшка буде виведенням транзакції, зазвичай повертаючись під адресою Аліси (оскільки ми повернули її з функції введення). Ключові висновки: Дочірні об'єкти за замовчуванням недоступні; вам потрібен квиток прийому та відповідна функція, щоб вивести їх. Батьківський модуль вирішує, як ви можете отримати (надаючи функцію з &mut UID). transfer: :receiver використовується в модулі визначення батьків для об'єктів цього модуля або його друзів. Якщо тип дитини визначено в іншому місці, вам знадобиться інший підхід (введіть public_receiver...). Перш ніж рухатися далі, ще одна деталь: якщо об'єкт типу T має лише здатність ключа (немає магазину), Sui розглядає його як трохи більш обмежений. Такі об'єкти неможна отримувати за допомогою узагальненого коду поза їх модулем. На практиці це означає, що якщо T є лише ключем і стає дочірнім, вам потрібно буде обробляти його пошук у власному модулі або батьківському модулі за допомогою спеціального правила. Якщо T також має магазин, ми маємо більшу гнучкість через public_receiver. Давайте дослідимо це далі.

    • Sui
    2
  • hohm.
    Apr 12, 2025
    Обговорення

    Як вирішити проблеми з доставкою змішувача для завдань X?

    Я намагаюся отримати кран, але він не працює за завданнями X. Я навіть намагався отримати доступ до нього за рекомендованим посиланням, але я постійно перенаправляюся назад до завдань X, де він продовжує виходити з ладу. Хтось знає, як я можу успішно отримати кран?

    • Sui
    0
    2
  • article banner.
    harry phan.
    Apr 12, 2025
    Стаття

    ✏️ Об'єкти батьків-дитини в Sui Move

    У Sui Move об'єкти можуть володіти іншими об'єктами так само, як облікові записи власними об'єктами. Це відкриває нові шаблони дизайну (і кілька недоліків) для розробників. У цьому посібнику я розб'ю концепції батьків-дочірніх об'єктів у Sui Move на чотири частини: 1.Вступ до концепцій батьків-дитини в Sui Move 2.Механіка контролю доступу та прийому об'єктів 3.Міжмодульне управління дітьми за допомогою public_receive 4.Логіка прив'язки душі та шаблон квитанції повернення До кінця ви зрозумієте, як вставляти об'єкти, отримувати дочірні об'єкти за допомогою transfer: :receiver, керувати дочірніми модулями за допомогою public_receiver і навіть створювати об'єкти, пов'язані з душею, які бумерангом повертаються власнику. Вступ до концепцій батьків-дитини в Sui Move ###Що таке батьківські та дитячі об'єкти? У Sui кожен об'єкт має унікальний ідентифікатор та * власника. Зазвичайвласником є адреса*(як обліковий запис користувача), але власником також може бути інший об'єкт. Якщо об'єкт A володіє об'єктом B, ми називаємо A батьком, а B - дочірнім. Дитина належить об'єкту, а не адресній. Передача на об'єкти: Sui насправді не розрізняє адресу та ідентифікатор об'єкта під капотом - обидва є лише 32-байтовими ідентифікаторами. Це означає, що ви можете перенести об'єкт на ідентифікатор іншого об'єкта так само, як ви передаєте на адресу користувача. Коли ви робите це, ви фактично вкладаєте об'єкт всередині батьківського об'єкта. Час виконання Sui встановлює поле власника дитини на ідентифікатор батька (замість адреси) То чому це круто? Тому що дитина зберігає свій власний унікальний ідентифікатор і існує незалежно в сховищі, але тепер він прив'язаний до батька. Це все одно, що дати своєму другові унікальний предмет колекціонування, який він може тримати в шафці - предмет колекціонування зберігає свій ідентифікатор і його можна відстежувати, але шафка вашого друга тепер вказана як його власник. Важливо розрізнятиУнікальні та вкладені та дочірні об'єкти: Унікальний об'єкт (власник адреси) :**Звичайний об'єкт, що належить адресі (наприклад, обліковий запис користувача). Це випадок за замовчуванням — подумайте про NFT, монети тощо, які живуть безпосередньо в гаманці користувача. Кожен з них має унікальний ідентифікатор і є верхнім рівнем зберігання. Вкладений (обгорнутий) об'єкт:* Об'єкт, який зберігаєтьсявсередині даних іншого об'єкта* (наприклад, як поле в структурі). У цьому випадку внутрішній об'єкт є загорнутом, анеокремою сутністю верхнього рівня. Він не відображається за своїм ідентифікатором у глобальному сховищі, оскільки він є частиною байтового вмісту батьківського файлу. У Суї, якщо ви поставите об'єкт як поле в інший без спеціального поводження, він стає загорнутим. Дочірній об'єкт (об'єкт-власник) :*Об'єкт, який належить іншому об'єкту *але не загорнутий безпосередньо в його поля. Дочірня особа залишається окремим об'єктом верхнього рівня у сховищі (з власним ідентифікатором та даними), а ідентифікатор батька записується як власник у метаданих дитини. Це означає, що ви можете* запитувати або отримати доступ до дитини за її ідентифікатором (з правильними дозволами). Він фізично не вбудований у вміст батьків, просто логічно належить. Використовуючи нашу аналогію, це ніби ви дали своєму другові свій колекційний предмет для зберігання - він все ще окремо позначений та відстежується, просто зберігається у їхній шафці. Перевага створення дитячого об'єкта (через передачу) замість його обгортання полягає в тому, що посвідчення особи дитини залишається доступним зовні. Наприклад, дослідники або гаманці можуть перелічити дочірній об'єкт за ідентифікатором, тоді як обгорнутий об'єкт невидимий поза батьківським об'єктом. Дочірні об'єкти також підтримують стабільні ідентифікатори, навіть коли вони переміщуються між власниками або вкладаються в різних батьків. Це чудово підходить для таких речей, як мережевий інвентар або шаблони «гаманець всередині гаманця», де ви хочете, щоб об'єкт контейнера містив багато предметів, на які інші все ще можуть посилатися окремо Власність та доступ: Якщо об'єкт належить іншому об'єкту, лише власник батька зазвичай може отримати доступ до дочірнього об'єкта або використовувати його. Це форма динамічної авторизації. Наприклад, якщо Аліса володіє батьківським об'єктом P, а P володіє дочірнім об'єктом C, то лише Аліса (або транзакції, які підписує Аліса) може маніпулювати C. Суй здійснює це так, щоб володіння батьком було схоже на утримання ключів для всіх його дочірніх 🔑. Може бути, ви знаєте: Функція передачі на об'єкт Суй, по суті, дає нам деревоподібне володіння об'єктом. Батьки можуть мати багато дітей (і ці діти можуть мати своїх дітей, формуючи ієрархію). Це робиться шляхом обробки ідентифікаторів об'єктів, як адрес для передачі. У нас є: Адресні об'єкти**(звичайні унікальні об'єкти), Об'єкти, що належать об'єктам**(дочірні об'єкти, все ще верхнього рівня, але прив'язані до батьківського), Обгорнуті об'єкти**(вкладені в дані іншого об'єкта, а не верхнього рівня). У наступних статтях ми побачимо, як насправді отримати дочірні об'єкти або взаємодіяти з ними (оскільки вони не є безпосередньо доступними, як адресні) та як застосовувати правила навколо них.

    • Sui
    • Move
    3
  • tomek.
    Apr 11, 2025
    Питання та відповіді експертів

    Чому з мене стягували суікони, але токен не був створений?

    Я використав suicoins.com для створення токена, який стягував мені 2 SUI, але токен не генерувався так, як очікувалося. Також він з'явився під нерозпізнаним розділом. Як я можу вирішити це, і чи логотип відображається на dexscreen без розпізнавання?

    • Sui
    0
    2
  • Michelle .
    Apr 10, 2025
    Питання та відповіді експертів

    Чому гаманець мого торгового бота блокується до наступної епохи?

    У мене виникла проблема, коли мій торговий гаманець, який використовує бота, часто отримує помилку: «Не вдалося підписати транзакцію кворумом валідаторів...» Це призводить до того, що гаманець блокується до наступної епохи, іноді годинами. Він з'являється особливо після тайм-ауту RPC під час транзакції. Чому це відбувається, і як це можна виправити, щоб уникнути таких довгих замків?

    • Sui
    0
    1
  • Xavier.eth.
    Apr 10, 2025
    Обговорення

    Як перевести SUI зі стандартного гаманця на гаманець Ledger?

    Я підключив свій Ledger до нещодавно створеного гаманця SUI, і це добре спрацювало. Тепер я хочу перевести свій SUI з мого «Стандартного» гаманця SUI на свій гаманець SUI «Ledger». Чи є ярлик, чи мені потрібно надсилати SUI з однієї адреси на іншу, наприклад, надсилати токени на біржі? Я хочу, щоб цей процес був безпечним.

    • Transaction Processing
    0
    1
  • article banner.
    harry phan.
    Apr 10, 2025
    Стаття

    Створення DApp лотереї NFT наступного покоління за допомогою Sui Move та сучасного інтерфейсу користувача

    🧩 Створення DApp лотереї NFT наступного покоління за допомогою Sui Move та сучасного інтерфейсу користувача Це ваш остаточний посібник із створення гейміфікованого лотерейного DApp на базі NFT за допомогоюSui Move, з підтримкою кількох раундів, реферальними системами, управлінням DAO та системою дизайну Gen Z, яка сподобається. Від архітектури контрактів до потоку інтерфейсу користувача — давайте розберемося. 📦 Фазова поломка Фаза 1 — Основна лотерея Багатораундний геймплей NFT квитки Система винагород за рефералів Базове голосування DAO Фаза 2 - Маркетплейс та гейміфікація Інтеграція ринку NFT Бустери (збільшити шанс на виграш) Система джекпотів Приховані аеродропи Фаза 3 - DAO та багатоланцюг Крос-ланцюгова сумісність DAO з розширеними пропозиціями Динамічне ціноутворення Онлайн-аналітика 🧠 Глибоке занурення смарт-контракту на Sui Move Структура контракту module nft_lottery_x::nft_lottery_x { use sui::object; use sui::balance::{Balance, zero}; use sui::coin::{Self, Coin}; use sui::clock::Clock; use sui::random::Random; use sui::event::emit; use sui::transfer; use sui::tx_context::TxContext; use std::option; use std::signer; const EGameNotStarted: u64 = 1000; const EGameAlreadyFinished: u64 = 1001; const EInvalidPayment: u64 = 1002; const ENoTickets: u64 = 1003; const EWinnerAlreadyChosen: u64 = 1004; const ENotWinner: u64 = 1005; public struct Game has key { id: UID, ticket_price: u64, start_time: u64, end_time: u64, total_tickets: u32, round: u32, winner: Option, balance: Balance, referral_bonus: u64, } public struct Ticket has key { id: UID, game_id: ID, ticket_number: u32, buyer: address, referrer: Option, } public struct GameCreated has copy, drop { game_id: ID, start_time: u64, end_time: u64, ticket_price: u64, } public struct TicketBought has copy, drop { game_id: ID, ticket_number: u32, buyer: address, referrer: Option, } public struct WinnerAnnounced has copy, drop { game_id: ID, winner_ticket: u32, round: u32, } public struct RewardClaimed has copy, drop { game_id: ID, ticket_number: u32, amount: u64, } public fun create_game( start_time: u64, end_time: u64, ticket_price: u64, referral_bonus: u64, ctx: &mut TxContext ) { let game = Game { id: object::new(ctx), ticket_price, start_time, end_time, total_tickets: 0, round: 1, winner: option::none(), balance: zero(), referral_bonus, }; emit(GameCreated { game_id: object::id(&game), start_time, end_time, ticket_price, }); transfer::share_object(game); } public fun buy_ticket( game: &mut Game, coin: Coin, clock: &Clock, referrer: Option, ctx: &mut TxContext ): Ticket { assert!(clock.timestamp_ms() >= game.start_time, EGameNotStarted); assert!(clock.timestamp_ms() (TicketBought { game_id: object::id(game), ticket_number: ticket.ticket_number, buyer: ticket.buyer, referrer: ticket.referrer, }); ticket } public entry fun determine_winner( game: &mut Game, rand: &Random, clock: &Clock, ctx: &mut TxContext ) { assert!(clock.timestamp_ms() >= game.end_time, EGameNotStarted); assert!(game.winner.is_none(), EWinnerAlreadyChosen); assert!(game.total_tickets > 0, ENoTickets); let mut generator = rand.new_generator(ctx); let winning_ticket = generator.generate_u32_in_range(1, game.total_tickets); game.winner = option::some(winning_ticket); emit(WinnerAnnounced { game_id: object::id(game), winner_ticket: winning_ticket, round: game.round, }); } public fun claim_reward( ticket: Ticket, game: Game, ctx: &mut TxContext ): Coin { assert!(object::id(&game) == ticket.game_id, EInvalidPayment); let ticket_num = ticket.ticket_number; assert!(game.winner.contains(&ticket_num), ENotWinner); let amount = game.balance.value(); let reward = game.balance.into_coin(ctx); emit(RewardClaimed { game_id: object::id(&game), ticket_number: ticket.ticket_number, amount, }); object::delete(object::id(&game)); reward } } Ключові висновки: ✅ Balanceзабезпечує безпеку типу та належне поводження з монетами ✅ Optionчітко сигналізує, чи був обраний переможець ✅ Події пропонують простежуваність для фронтендів та дослідників 🛠 Команди Sui CLI sui client call --package --module nft_lottery_x --function create_game --args --gas-budget 10000000 Щоб купити квиток, визначити переможця або отримати винагороду, дотримуйтесь подібних потоків CLI. 🔮 Майбутні доповнення Логіка автоматичного скидання для наступного раунду claim_reward Випускайте більше подій на кшталт ReferralRewardDistributed Рефактор джекпотів та рефералів у підмодулі Дайте мені знати, якщо ви хочете, щоб частина 2 створила інтерфейс користувача та інтегрувалася в testnet Sui!

    • Sui
    3

Sui is a Layer 1 protocol blockchain designed as the first internet-scale programmable blockchain platform.

203Пости300Відповіді
Кампанія винагородКвітень
Sui.X.Peera.

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

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

Топ теги
  • Sui
  • SDKs and Developer Tools
  • Architecture
  • Move
  • NFT Ecosystem
  • Transaction Processing
  • Security Protocols
Ми використовуємо файли cookie, щоб гарантувати вам найкращий досвід на нашому сайті.
Детальніше