Головна

harry phan15

Apr 09, 2025

Стаття

Посібник з транзакцій 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.

0xduckmove125

Apr 08, 2025

Стаття

👀 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%2Ffanyv88.com%3A443%2Fhttps%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, не є необов'язковою - це важливо

Lokie13

Mar 16, 2025

Стаття

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

Bahador85

Mar 15, 2025

Стаття

У сьогоднішній статті я хочу зануритися в пропозицію дорожньої карти для тих, хто любить вступити у шлях розвитку 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, я сподіваюся, що це корисно для вас, хлопці. Щасливе кодування. Щасливого позову!

0xduckmove125

Mar 12, 2025

Стаття

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: [email protected] ├── @mysten/[email protected] └── @mysten/[email protected] 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

Bahador85

Mar 11, 2025

Стаття

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!

Bahador85

Mar 11, 2025

Стаття

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.

Bahador85

Mar 10, 2025

Стаття

Одна з цікавих речей, яка привернула мене до ланцюжка SUI, - це манера роботи транзакцій, тому в цій статті ми збираємося отримати деякі знання про те, як працюють транзакції в блокчейні SUI. Кожна транзакція в Sui чітко перераховує, які об'єкти вона буде читати або змінювати. Оскільки кожен об'єкт є незалежним, валідатори Sui можуть легко перевіряти список об'єктів для кожної вхідної транзакції. Це допомагає системі вирішити, які транзакції можуть запускатися одночасно: Незалежні транзакції (без об'єктів, що перекриваються): Якщо дві транзакції стосуються абсолютно різних об'єктів, вони не конфліктують один з одним. Суй знає, що це не завадить, тому він може виконувати їх одночасно паралельно. Наприклад, одна транзакція може оновити об'єкт монети Аліси, а інша може перенести об'єкт NFT Боба — оскільки це окремі об'єкти, не потрібно чекати одного, перш ніж робити інший. Конфліктні транзакції (спільні об'єкти): Якщо дві транзакції намагаються використовувати один і той же об'єкт, вони конфліктують і не можуть бути виконані в один і той же момент. Sui впорається з цим, замовляючи та виконуючи ці конкретні операції одна за одною, щоб уникнути плутанини або подвійних витрат. У цьому випадку механізм консенсусу мережі вступає в дію, щоб вирішити справедливий порядок транзакцій, які стосуються тих самих даних. Замовляються лише операції, які конфліктують; всі інші незалежні операції можуть протікати паралельно, не чекаючи. По суті, модель транзакцій Суй відокремлює «прості» транзакції від «залежних». Прості транзакції, які впливають лише на об'єкти одного власника, часто можуть бути оброблені дуже швидко, не залучаючи всю мережу до важкої координації. Більш складні транзакції (наприклад, транзакції, які взаємодіють із спільним об'єктом смарт-контракту, який можуть використовувати багато користувачів) проходять традиційний процес замовлення (консенсус), щоб гарантувати, що вони не конфліктують між собою. Таким чином, Sui використовує глобальний консенсус лише тоді, коли це дійсно потрібно, і він може дозволити більшості транзакцій проходити одночасно, коли в даних, до яких вони торкаються, немає перекриттів. Паралельне виконання в Sui проти традиційних блокчейнів У традиційних блокчейнів, таких як Bitcoin або Ethereum, транзакції обробляються послідовно (одна за одною). Навіть якщо дві транзакції не мають нічого спільного між собою, послідовна система все одно поставить одну в чергу за іншою, створюючи непотрібне очікування. Це схоже на наявність єдиного каси в магазині - навіть клієнти, які купують різні товари, повинні стояти в одній черзі. Це викликає заторів і уповільнює роботу в напружені періоди. Sui використовує інший підхід, дозволяючи паралельне виконання транзакцій. Це аналогічно тому, що багато касових лічильників відкритих: кілька транзакцій можна обробляти одночасно, якщо вони незалежні, що значно покращує пропускну здатність та ефективність. Через об'єктно-орієнтовану конструкцію Суї операції над одним об'єктом не впливають і не затримують операції на іншому об'єкті . Валідатори в мережі Sui можуть використовувати кілька ядер і потоків процесора для виконання декількох транзакцій одночасно, подібно до паралельної обробки декількох завдань на комп'ютері. Результатом є значне підвищення масштабованості - Sui може обробляти велику кількість транзакцій в секунду, не потіваючи. Тести продемонстрували, що підхід Суї може підтримувати величезну пропускну здатність (близько сотень тисяч транзакцій в секунду) завдяки цьому паралелізму. Не менш важливо, що паралельне виконання зменшує затримку для окремих транзакцій, тобто користувачі бачать, що свої транзакції підтверджуються швидше, оскільки вони не застрягли в очікуванні непов'язаних транзакцій. Загалом, модель паралельного виконання Sui усуває вузькі місця, які вражають однопотокові (послідовні) блокчейни, дозволяючи мережі масштабувати та обробляти робочі навантаження, які б переповнили традиційні конструкції. Кінцевість та швидкість підтвердження Остаточність відноситься до того, як швидко транзакція підтверджується незворотно (тобто після підтвердження вона не буде повернена). Sui призначений для швидкої остаточності, часто досягаючи підтвердження за частку секунди. На практиці типову транзакцію Sui можна підтвердити приблизно за 300-500 мілісекунд (значно менше однієї секунди) після її обробки - по суті майже миттєво для користувача. Це набагато швидше, ніж багато старих блокчейнів. Для порівняння, мережі Ethereum зазвичай потрібно від декількох секунд до хвилин, щоб дійсно завершити транзакцію (блоки Ethereum знаходяться приблизно в ~ 12 секунд, і для високої впевненості може знадобитися кілька блоків або більше), тоді як біткойн може потребувати десятків хвилин (через 10-хвилинний час блокування та кілька підтверджень), щоб транзакція вважалася остаточною. Сучасний консенсус і паралельне виконання Sui надають йому велику перевагу в швидкості: транзакції на Sui підтверджуються майже відразу після того, як ви їх відправляєте. Не потрібно довго чекати, поки новий блок включить транзакцію або кілька підтверджень. Коротше кажучи, Sui забезпечує кінцевість на півсекунди, що означає, що користувачі можуть надіслати транзакцію та побачити її остаточно врегульовану негайно. Це швидке підтвердження особливо корисно для таких програм, як ігри, фінанси в режимі реального часу або роздрібні платежі, де очікування навіть десятків секунд може бути занадто повільним. Sui швидко надає користувачеві впевненість, завдяки чому блокчейн відчуває себе набагато більш чуйним порівняно з традиційними ланцюгами.

Bahador85

Mar 10, 2025

Стаття

In this article, we are going to find out some of the differences between Sui and Ethereum and be able to choose from them based on our project requirements. Sui utilizes novel design choices, including a unique object-centric data model and the Move programming language (originating from Facebook’s Diem project), to enable high throughput and secure smart contract execution. Both platforms enable developers to create smart contracts and decentralized applications, but they differ fundamentally in architecture and approach. This article provides a detailed comparison of Ethereum and Sui, highlighting key differences in their programming paradigms, features, architecture, consensus mechanisms, scalability, developer experience, and ecosystem maturity. Let's compare these two chains: Consensus Mechanism: Sui Delegated Proof-of-Stake with Byzantine consensus (Narwhal & Bullshark). Validators (chosen each epoch) use a DAG-based mempool (Narwhal) and BFT consensus (Bullshark) for fast ordering​. Near-instant finality (sub-second in ideal conditions) is achieved with this optimized consensus​. Ethereum Proof-of-Stake .Validators stake ETH to propose and validate blocks; finality achieved via epochs and attestations​(approx~ 13 minutes or 2 epochs) Smart Contract Language Sui Move. Uses an adapted Move language that treats assets as objects with strict ownership rules. Move’s design prevents asset duplication or loss by default and enforces safety at the language level​. This leads to more secure contracts out-of-the-box, with a slightly stricter programming model. Ethereum Solidity (also Vyper for pythonists, Yul, and Huff). Contracts compiled to EVM bytecode. Solidity is flexible but prone to developer errors if not carefully written; extensive audits and best practices are needed for security. Execution Model Sui Parallel execution via object-centric design. Transactions in Sui specify the objects they read/write. If transactions affect independent objects (especially “owned” objects with separate owners), they can be executed concurrently by validators​. Only conflicts (e.g. two txns touching the same “shared” object) require ordering through consensus​. This enables multiple transactions to be processed simultaneously, dramatically improving throughput., Ethereum Sequential execution on the EVM. Transactions are ordered in each block and executed one by one on every node, which means each transaction must run to completion (updating global state) before the next begins​. This simplifies state management but creates a bottleneck – even independent transactions cannot be processed in parallel. Transaction Processing Sui Sub-second block finality in optimal conditions​; theoretical throughput in the tens of thousands TPS. Sui’s design (parallel execution and efficient consensus) has demonstrated >120,000 TPS in test settings​. In practice, Sui’s mainnet is expected to handle high loads without sharding. Transaction fees are designed to remain stable, with gas price governance per epoch​, keeping costs low even as demand grows. Ethereum 12 second block time; throughput historically 15–30 TPS on mainnet (scaling achieved via Layer-2 solutions). Finality is probabilistic per block, with economic finality after 2 epochs (6-13 minutes) in PoS​. Gas fees can spike under load, and users often rely on rollups or sidechains for higher performance. Scalability Sui Horizontal scalability by design. Sui can utilize more validator resources to increase throughput – analogous to adding more “lanes” for transactions​. The network does not have a fixed TPS limit; if more hardware is added and transactions are independent, throughput scales up. This makes Sui capable of scaling on the base layer for high-demand use cases (e.g., gaming, social networks) without immediately needing layer-2s or sharding. Ethereum Relies on Layer-2 scaling (Rollups like Optimistic or ZK-Rollups) and future sharding upgrades. Ethereum’s roadmap (Danksharding, etc.) aims to increase base layer throughput, but currently, the strategy is to offload activity to L2 networks and use Ethereum for settlement. This approach maintains decentralization but pushes true scale to auxiliary networks. Developer Experience Sui Growing and security-focused. Sui provides a new toolkit (Sui CLI, SDKs, Move compiler, etc.) and detailed documentation. Developers may need to learn the Move language and adapt to thinking in terms of objects and resources. This learning curve can be offset by Sui’s emphasis on correctness – by following Sui’s model, developers naturally avoid many pitfalls. The ecosystem is actively building tools (for example, Move package managers and testing frameworks), and Mysten Labs has invested in developer outreach (hackathons, tutorials). While not as extensive as Ethereum’s, Sui’s developer community is enthusiastic, and early adopters benefit from direct support channels as the ecosystem matures. Ethereum Ethereum has numerous developer tools: IDEs (Remix online IDE), frameworks (Foundry, Hardhat, Brownie), libraries (Web3.js, Ethers.js, Viem.js, etc.), and test networks. The community support is unparalleled – countless tutorials, forums, and established patterns exist. However, mastering Ethereum development requires understanding gas mechanics, security patterns, and the EVM’s constraints, which can be challenging for newcomers​. My above explanations can be summarized into this line: In summary, Ethereum stands as the established general-purpose blockchain with broad adoption and a rich ecosystem, whereas Sui is an emerging high-performance blockchain incorporating new paradigms for scalability and safety. As blockchain technology evolves, both platforms could coexist, each inspiring improvements in the other. Ethereum might adopt some parallelization techniques (research is ongoing into parallel EVM execution​, and Sui will certainly learn from Ethereum’s experiences in governance and community building. For developers and businesses, the choice will come down to the demands of their project: the comfort of the tried-and-true versus the allure of the new and fast. By understanding the key differences outlined above – from programming models to consensus – one can make an informed decision or strategy that harnesses the best of both worlds, potentially leveraging Ethereum’s solidity and Sui’s agility to build the next generation of decentralized applications