У тренді
Відкрийте для себе найпопулярніші дописи.
Пости
2069Бот AMM в екосистемі Sui
Які ключові особливості та функціональні можливості ботів AMM в екосистемі Sui? Як вони покращують традиційні торгові механізми та які переваги вони пропонують користувачам, які користуються протоколами DeFi в мережі Sui? Чи потрібно мені будувати його або я можу використовувати Turbos Finance, наприклад
- Sui
82Найкраща відповідь- Стаття0xduckmove618ДляSuiApr 08, 2025
👀 SEAL- Я думаю, що конфіденційність даних Web3 ось-ось зміниться
👀 SEAL працює на Sui Testnet - я думаю, що конфіденційність даних Web3 ось-ось зміниться У Web3 зазвичай чути фрази на кштал«користувачі володіють своїми даними» або* «децентралізовано за дизайном»*. Але якщо придивитися, багато додатків все ще покладаються на централізовану інфраструктуру для обробки конфіденційних даних - використовуючи такі сервіси, як AWS або Google Cloud для управління ключами. Це вводить протиріччя: децентралізація на поверхні, централізація знизу. Але що, якби був спосіб безпечно управляти секретами, не відмовляючись від децентралізації? Представляємо SEAL - Децентралізоване управління секретами (DSM), тепер працює на Sui Testnet. SEAL прагне виправити одне з найбільших лицемірств Web3: кричати децентралізацію під час таємного використання AWS Ви, можливо, запитаєте мене: Що таке SEAL? SEAL - це протокол, який дозволяє безпечно та** децентралізовано керувати конфіденційними даними - створений спеціально для світу Web3. Подумайте про це як про рівень контролю доступу в першу чергу конфіденційності, який підключається до вашого DApp. Ви можете думати про SEAL як про своєрідний програмований замок для ваших даних. Ви не просто блокуєте та розблоковуєте речі вручну — визаписуєте політику безпосередньо у свої розумні контракти, використовуючи Move on Sui. Припустимо, ви створюєте DApp, де: Тільки власники NFT можуть розблокувати преміум-підручник Або, можливо, DAO повинен проголосувати, перш ніж розкриються конфіденційні файли Або ви хочете, щоб метадані були заблоковані за часом і доступні лише після певної дати SEAL робить все це можливим. Контроль доступу живе 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, не є необов'язковою - це важливо
- Sui
- Architecture
- SDKs and Developer Tools
8 Єдиний спосіб опублікувати пакети Move через EOA?
Я припускаю, що в ланцюжку Sui немає способу, оскільки в ланцюжку немає модуля, який публікує пакети.
- Sui
- SDKs and Developer Tools
- Move
73Найкраща відповідь
Як Sui запобігає хакерам смарт-контрактів?
Хакі смарт-контрактів засмутили індустрію блокчейнів, лише в 2023 році було втрачено понад 3 мільярди доларів через експлойти на таких платформах, як Ethereum. Sui Network, розроблена з пріоритетом безпеки, вводить кілька ключових нововведень для мінімізації цих ризиків. Ця стаття досліджує: 🔒 Вбудовані функції безпеки Sui 💡 Як мова Move запобігає поширеним експлойтам 🛡️ Порівняння з вразливостями Ethereum 🚀 Чому Sui може стати найбезпечнішою платформою смарт-контрактів 1. Мова програмування Move: підхід, перш за все безпека Sui використовує Move, мову, спочатку розроблену для блокчейну Facebook Diem, розроблену спеціально для безпечного управління активами. Основні переваги безпеки Move: Немає неперевірених зовнішніх дзвінків - запобігає атакам повторного вступу (наприклад, хак DAO на Ethereum у розмірі 60 мільйонів доларів). Сильні правила введення та володіння - усуває випадкову втрату коштів через помилки кодування. Підтримка формальної перевірки - Дозволяє математичне підтвердження правильності контракту. Приклад: В Ethereum проста помилка може виснажити кошти. У програмі Move компілятор відхиляє небезпечний код перед розгортанням. 2. Об'єктно-центрична модель: ізоляція вразливостей На відміну від моделі спільного стану Ethereum (де одна помилка може вплинути на багато контрактів), об'єктне сховище Sui обмежує поширення експлойтів: Кожен актив (монета, NFT тощо) є окремим об'єктом із суворими правилами власності. Контракти не можуть довільно змінювати непов'язані дані. Вплив: Навіть якщо контракт скомпрометований, шкода стримується, на відміну від ризиків складності Ethereum (наприклад, злом мосту Wormhole на 325 мільйонів доларів). 3. Ніяких атак «газового жалобу» На Ethereum зловмисники можуть спамувати контракти з високогазовими транзакціями, щоб блокувати законних користувачів (наприклад, атаки на відмову в обслуговуванні). Рішення Суї: Фіксовані бюджетні операції (без газових аукціонів). Паралельне виконання запобігає перевантаженню всієї мережі. 4. Моніторинг безпеки в мережі Валідатори Sui активно стежать за підозрілою діяльністю: Попередня перевірка транзакцій — відхилити явно шкідливі запити. Аналітика в реальному часі — Позначте ненормальну поведінку (наприклад, раптові великі зняття коштів). 5. Реальний запис безпеки (поки що) З моменту запуску основної мережі (2023) у Sui немає основних хаків. Ethereum в середньому становить 2-3 основних експлойту DeFi щомісяця. Тематичне дослідження: DEX на базі SUI (Cetus) обробив угоди понад 1 млрд доларів США без випадків безпеки - на відміну від Ethereum DEX, які часто зазнають експлойтів. 6. Підтримка майбутнього: формальна перевірка та аудит Суй заохочує: Формальна перевірка - Математично підтверджуючі контракти не містять помилок. Вимоги до мультиаудиту - великі проекти повинні пройти 3+ аудитів. Висновок: Чи є Sui найбезпечнішою платформою смарт-контрактів? Хоча жодна система не є 100% захищеною від злому, мова Sui+об'єктна модель + паралельне виконання робить її набагато менш вразливою, ніж Ethereum сьогодні. Підсумок: Для розробників — Move зменшує ризики людських помилок. Для користувачів — менший шанс втратити кошти на експлойти. Для установ - безпека корпоративного рівня створює довіру. **Що далі? Чи прийме Ethereum функції, схожі на рух? Чи може Суй зберегти свій чистий облік безпеки в міру зростання усиновлення?** Поділіться своїми думками нижче
- Sui
6- Статтяharry phan595Для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, коли надсилаєте їх батькові за межами їхнього модуля.
- Sui
- Architecture
6 - Питання та відповіді експертівДляSuiJun 30, 2025
Why can’t I connect my wallet to a Sui dApp?
I’m trying to use a Sui dApp (like Tradeport, SuiSwap, or a custom platform), but my wallet won’t connect properly. Sometimes, I get no error at all—just nothing happens when I click "Connect Wallet." Other times, I see errors like: "Wallet not detected" (even though I have Sui Wallet or another wallet installed) "Connection failed: Invalid account" "Transaction rejected" before I even approve anything What I’ve tried: Refreshing the page Switching browsers (Chrome, Firefox, Brave) Checking wallet extension permissions Trying different networks (Devnet, Testnet, Mainnet) Reinstalling the wallet extension Questions: Why does this happen, and how can I fix it? Are there common mistakes users make when connecting wallets to Sui dApps? If my wallet was working before but suddenly stopped, what could be the cause?
- Sui
- Transaction Processing
61Найкраща відповідь 
Як побудувати складний DApp на Sui Move?
Курс #2: Глибоке занурення в програмування Move - створення складних DApps на Sui Тепер, коли ви зрозуміли основи програмування Move та розгорнули свій перший смарт-контракт, настав час вивести свої навички на новий рівень. У цій статті ми розглянемо, як побудувати більш складні децентралізовані програми (DApps) за допомогою Move on the Sui blockchain. Крок 1: Освоєння розширених концепцій Sui Move Перш ніж зануритися в кодування, давайте переглянемо деякі розширені функції Move, які роблять його унікальним для створення безпечних і масштабованих DApps: ####1. Ресурсоорієнтоване програмування Move розглядає цифрові активи якресурси, гарантуючи, що їх не можна дублювати, ненавмисно видаляти або використовувати неправильно (https://docs.sui.io/learn/resource-oriented-programming). Це досягається за рахунок суворих правил володіння і безпеки типу. Наприклад: module examples::token { use sui::object::{Self, UID}; use sui::transfer; struct Token has key, store { id: UID, value: u64, } public fun mint(ctx: &mut TxContext, value: u64): Token { Token { id: object::new(ctx), value, } } public fun transfer_token(token: Token, recipient: address) { transfer::public_transfer(token, recipient); } } У цьому прикладі Tokenресурс створюється і передається надійно. Ресурси в Move за замовчуванням незмінні, якщо вони явно не позначені як змінні, додаючи додатковий рівень безпеки. ####2. Модулі та інкапсуляція Модулі в Move діють як автономні блоки функціональності, що забезпечує кращу організацію та повторне використання. Наприклад, ви можете відокремити логіку створення токенів від логіки передачі на окремі модулі (https://examples.sui.io/modules). Ця модульність забезпечує більш чистий код і простіше обслуговування. ####3. Об'єктно-центричний дизайн UIDSui Move представляєоб'єктно-орієнтовану модель, де кожен ресурс має глобально унікальний ідентифікатор (). Це дозволяє здійснювати прямі посилання та взаємодію з об'єктами, що полегшує управління складними переходами станів (https://docs.sui.io/objects). Крок 2: Написання модульного смарт-контракту Давайте створимо більш просунутий смарт-контракт, який демонструє ці концепції. Ми створимо простий ринок NFT, де користувачі можуть карбувати та торгувати NFT. ####Визначте ресурс NFT Почніть з визначення ресурсу NFT у модулі Move: module examples::nft_marketplace { use sui::object::{Self, UID}; use sui::transfer; struct NFT has key, store { id: UID, name: String, price: u64, } public fun mint_nft(ctx: &mut TxContext, name: String, price: u64): NFT { NFT { id: object::new(ctx), name, price, } } public fun list_for_sale(nft: NFT, price: u64, ctx: &mut TxContext) { nft.price = price; transfer::public_transfer(nft, tx_context::sender(ctx)); } } Тут NFTресурс включає такі властивості, як nameіprice. mint_nftФункція створює новий NFT, водночас list_for_saleдозволяє користувачам перераховувати свої NFT на продаж. ####Компіляція та розгортання Використовуйте Sui CLI для складання та розгортання контракту. Напишіть скрипт розгортання для автоматизації цього процесу: sui move build sui client publish --gas-budget 10000 Це дозволить упакувати та розгорнути ваш модуль у Sui Devnet (https://docs.sui.io/cli). Крок 3: Створення інтерфейсу React для вашого ринку З розгорнутим смарт-контрактом давайте підключимо його до інтерфейсу React. ####Налаштування проекту Ініціалізуйте проект React, якщо ви ще цього не зробили: npx create-react-app nft-marketplace cd nft-marketplace npm install @mysten/sui.js ####Інтегруйте з гаманцем Sui Використовуйте @mysten/sui.jsбібліотеку для взаємодії з блокчейном Sui: import { JsonRpcProvider, SuiClient } from '@mysten/sui.js'; const provider = new SuiClient({ url: 'https://fullnode.devnet.sui.io' }); async function fetchNFTs(ownerAddress) { const objects = await provider.getObjectsOwnedByAddress(ownerAddress); console.log('User NFTs:', objects); } ####Відображення даних NFT Отримати та відобразити дані NFT у вашому додатку React: function NFTList({ ownerAddress }) { const [nfts, setNFTs] = useState([]); useEffect(() => { async function loadNFTs() { const response = await provider.getObjectsOwnedByAddress(ownerAddress); setNFTs(response.data); } loadNFTs(); }, [ownerAddress]); return ( {nfts.map((nft) => ( {nft.name} Price: {nft.price} SUI ))} ); } Крок 4: Підвищення безпеки та продуктивності ####1. Безпечні транзакції Переконайтеся, що всі транзакції підтверджені як в ланцюжку, так і поза ланцюгом. Використовуйте бібліотеки, наприклад, для @mysten/sui.jsперевірки квитанцій транзакцій: async function verifyTransaction(txDigest) { const result = await provider.getTransaction({ digest: txDigest }); console.log('Transaction Verified:', result); } ####2. Оптимізація плати за газ Співпрацюйте з такими послугами, як* Заправка Шамі*, щоб пропонувати безгазові транзакції, покращуючи користувальницький досвід. Крім того, пакетні транзакції для зменшення витрат (https://docs.sui.io/gas-optimization). ####3. Використовуйте масштабованість Sui Архітектура Sui підтримує високу пропускну здатність і низьку затримку, що робить її ідеальною для DApps з інтенсивним використ��нням. Перевірте свою програму в умовах імітованого навантаження, щоб переконатися, що продуктивність залишається стабільною (https://performance.sui.io). Крок 5: Тестування та налагодження Тестування має вирішальне значення для уникнення вразливостей. Використовуйте такі інструменти, як* Sui Explorer* для моніторингу транзакцій та налагодження проблем. Крім того, напишіть блокові тести для ваших модулів Move: #[test] fun test_mint_nft() { use sui::test_scenario; let ctx = &mut test_scenario::ctx(); let nft = examples::nft_marketplace::mint_nft(ctx, "Test NFT", 100); assert!(nft.price == 100, 0); } Запустіть свої тести за допомогою Sui CLI: sui move test Крок 6: Взаємодія зі спільнотою Створення DApps — це не лише кодування, а й співпраця. Поділіться своїм прогресом на таких платформах, як* GitHub,* Discord* або* Twitter**. Беріть участь у хакатонів та викликах розробників, організованих Фондом Суй, щоб вдосконалити свої навички та отримати експозицію. Висновок Освоюючи розширені концепції Move, пишете модульні смарт-контракти та створюючи інтуїтивно зрозумілі інтерфейси, ви вже на шляху до того, щоб стати досвідченим розробником DApp на блокчейні Sui. Не забудьте визначити пріоритети безпеки, оптимізувати продуктивність та взаємодіяти зі спільнотою, щоб максимізувати свій вплив. Слідкуйте за оновленняКурс #3, де ми вивчимо реальні випадки використання та передові методи масштабування ваших DApps на Sui! Якщо ви хочете отримати додаткові роз'яснення або додаткові ресурси, не соромтеся запитати!
- Sui
- Architecture
- Move
6
Початок роботи з Move Learning - Курс #1
Незалежно від того, новачок ви чи досвідчений розробник, цей покроковий посібник допоможе вам зрозуміти, як Move, орієнтовану на ресурси мову програмування, можна використовувати для побудови DApps на блокчейні Sui. ###Крок 1: Розуміння руху та його ключових особливостей Перш ніж зануритися в кодування, давайте коротко обговоримо, що такеMoveі чому він унікальний. Move- мова програмування, призначена для написання безпечних та ефективних смарт-контрактів. Він запроваджує ресурсоорієнтоване програмування, де цифрові активи розглядаються як першокласні ресурси, гарантуючи, що їх не можна дублювати або видаляти ненавмисно. На відміну від інших мов,Moveмінімізує вразливості за допомогою таких функцій, якстатичне друкуваннята надійнеуправління ресурсом. Якщо ви новачок уMove, радимо переглянутиВступ до Sui Moveвідеоby Шаян з Фонду Суй. Це дасть фундаментальні знання про мережу Sui та роль Move в ній. ###Крок 2: Налаштування середовища розробки Для початку вам потрібно буде встановити необхідні інструменти та бінарні файли. Виконайте такі дії: 1.Встановіть бінарні рядки Sui Почніть з встановленнябінарних рядків Sui, щоб переконатися, що ваше середовище розробки готове. Sui CLI (інтерфейс командного рядка) дозволить вам взаємодіяти з блокчейном Sui. Ви можете знайти докладні інструкції в Sui Docs. 2.Виберіть свою платформу Залежно від того, чи використовуєте ви Windows, macOS або Linux, дотримуйтесь відповідних інструкцій щодо налаштування, наведених у серії відео або офіційній документації Sui. 3.Налаштування VPS (необов'язково) Якщо ваш ноутбук недостатньо потужний, подумайте про налаштування віртуального приватного сервера (VPS) для обробки обчислювального навантаження. ###Крок 3: Написання розумного контракту першого кроку Тепер, коли ваше середовище готове, давайте напишемо простий смарт-контрактMove. Для цього підручника я можу рекомендувати використати прикладSweet Place, який натхненнийFlash Place. 1.Визначте ресурси Почніть з визначення ресурсу в модулі «Переміщення». Наприклад: module examples::sweet_place { use sui::object::{Self, UID}; use sui::transfer; struct SweetPlace has key { id: UID, name: String, } public fun create_sweet_place(ctx: &mut TxContext, name: String) { let sweet_place = SweetPlace { id: object::new(ctx), name, }; transfer::public_transfer(sweet_place, tx_context::sender(ctx)); } } 2.Компіляція та розгортання Використовуйте Sui CLI для складання та розгортання контракту. Напишіть скрипт розгортання**, щоб автоматизувати цей процес, забезпечивши плавну інтеграцію з вашим інтерфейсом пізніше. ###Крок 4: Створення інтерфейсу React З розгорнутим смарт-контрактом настав час підключити його доінтерфейсу React. Цей крок передбачає, що у вас є певний попередній досвід роботи з React. Якщо ні, перегляньтеКурс React для початківціввід FreeCodeCamp.org. 1.Налаштуйте проект Ініціалізуйте проект React за допомогою create-react-appабо будь-якого фреймворку на ваш вибір. 2.* Інтегруйте з гаманцем Sui* Використовуйте бібліотеки, як @mysten/sui.jsдля взаємодії з блокчейном Sui. Наприклад: import { JsonRpcProvider } from '@mysten/sui.js'; const provider = new JsonRpcProvider('https://fullnode.devnet.sui.io'); 3.Отримати дані зі свого контракту Запитуйте дані з вашого розгорнутого контракту Move та відображайте їх у своєму додатку React. Використовуйтеіндексдля ефективного відстеження транзакцій та змін стану. ###Крок 5: Покращення користувальницького досвіду (UX) Однією з видатних особливостей цього підручника є його зосередженість на створенні безперебійного користувальницького досвіду. Ось як ви можете покращити UX: 1.Інтегруйте безгазові транзакції Співпрацюйте з такими послугами, якЗаправка Шамі, щоб забезпечити безгазові транзакції для ваших користувачів. Це усуває бар'єри для новачків, незнайомих з платами за криптовалюту. 2.Оптимізуйте продуктивність Використовуйте високу пропускну здатність Sui та низьку затримку, щоб забезпечити безперебійну роботу вашого DApp навіть під великим навантаженням. ###Крок 6: Тестування та налагодження Тестування має вирішальне значення для того, щоб ваша програма працювала так, як очікувалося. Використовуйте такі інструменти, якSui Explorerдля перевірки транзакцій та проблем налагодження [[Пошук в Інтернеті]]. Крім того, перегляньтеплатформу електронного навчання MOVE, щоб отримати уявлення про найкращі практики тестування та вимірювання. ###Крок 7: Взаємодія зі спільнотою Нарешті, не забудьте взаємодіяти зспільнотою Sui! Поділіться своїм прогресом, задавайте запитання та співпрацюйте з іншими. Як підкреслюється в стенограмі відео, спілкування з колегами-розробниками може призвести до захоплюючих можливостей.
- Sui
- Architecture
- SDKs and Developer Tools
- Move
6- Питання та відповіді експертівДляSuiJun 26, 2025
How to Properly Use the Sui SDK for Frontend Integration?
I'm building a frontend (React/Next.js) for a Sui dApp and need to interact with the blockchain—fetching objects, sending transactions, and listening to events. I’ve tried using the @mysten/sui.js SDK, but I’m running into issues: Wallet Connection: Sometimes, the wallet doesn’t return the user’s address after connecting. Transaction Handling: Transactions fail silently or return vague errors. RPC Limits: I get rate-limited or timeouts when fetching large datasets. Real-Time Updates: How can I listen for on-chain events (e.g., NFT mints, balance changes)? What I’ve tried: ✔ Basic SuiClient setup with mainnet and testnet RPCs. ✔ Using useWallet() from @mysten/dapp-kit for wallet integration. ✔ Manual transaction signing with signAndExecuteTransactionBlock. Questions: What’s the recommended way to initialize the Sui SDK in a frontend app? How do I handle errors gracefully (e.g., RPC failures, wallet rejections)? Are there best practices for optimizing queries (batching, caching, etc.)? How can I subscribe to real-time updates (e.g., new transactions, object changes)?
- Sui
- SDKs and Developer Tools
62Найкраща відповідь Як модулі Sui Move підвищують безпеку смарт-контрактів?
Як модульна система Sui Move дозволяє розробникам визначати, організовувати та безпечно взаємодіяти з користувацькими ланцюговими об'єктами, і які унікальні особливості ідентифікації модулів та зберігання об'єктів в екосистемі Sui порівняно з традиційними мовами смарт-контрактів?
- Sui
- Architecture
- Security Protocols
- Move
61Найкраща відповідь
