Sui.

Explorer

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

Sui.X.Peera.

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

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

Спільноти

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

Винагорода

  • Bolke .Peera.
    Bolke 203
    ДляSuiAug 12, 2025
    +15

    Помилка Sui Move - Неможливо обробити транзакцію Не знайдено дійсних газових монет для транзакції

    Коли я роблю це: //Розділіть платіж з основної монети конст [PaymentCoin] = TX.спліткойни ( tx.object (первинний Coin.CoinObjectID), [tx.pure.u64 (Обов'язкова сума платежу)] ); //Використовуйте оригінальну монету для оплати газу tx.setGasPayment ([{ Об'єктID: первинний Coin.CoinObjectID, версія: первинна коін.версія, дайджест: первинний коїн.дайджест }]); ТК.сетгасБюджет (10_000_000); Він скаржиться на об'єкти, що змінюються, не можуть з'являтися більше одного в одній транзакції. Коли я знімаю платіж за газ, він скаржиться «Не вдається обробити транзакцію Для транзакції не знайдено дійсних газових монет». Моя функція контракту приймає .01 sui в обмін на NFT

    2
    9
  • Xavier.eth.Peera.
    Xavier.eth308
    ДляSuiJun 27, 2025
    +15

    Невдала операція Sui: об'єкти, зарезервовані для іншої транзакції

    Я стикаюся з наполегли JsonRpcErrorвим при спробі виконати транзакції на Sui. Помилка вказує на те, що об'єкти зарезервовані для іншої транзакції, навіть якщо я впровадив послідовну обробку транзакцій із затримками. JsonRpcError: Failed to sign transaction by a quorum of validators because one or more of its objects is reserved for another transaction. Other transactions locking these objects: AV7coSQHWg5vN3S47xada6UiZGW54xxUNhRv1QUPqWK (stake 33.83) 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 0x1c20f15cbe780ee7586a2df90c1ab70861ca77a15970bea8702a8cf97bd3eed9 Я пробував: Послідовне виконання транзакції (очікування завершення попередньої транзакції) Додані 3-секундні затримки між транзакціями І все ще отримуємо ту саму помилку послідовно. Використання Sui RPC для подання транзакцій. Один і той же ідентифікатор об'єкта з'являється кілька разів у списку блокування. Помилка виникає навіть при ретельному послідовності транзакцій. Що призводить до того, що об'єкти «зарезервовані» для інших транзакцій? Як правильно перевірити наявність об'єкта, перш ніж використовувати його в транзакції? Чи існують найкращі методи роботи з блокуванням об'єктів у Sui? Чи може це бути пов'язано з термінами остаточності транзакції? Хтось стикався з цією проблемою раніше? Будь-яка інформація про правильне управління об'єктами в транзакціях Sui буде дуже вдячна!

    4
    8
  • Xavier.eth.Peera.
    Xavier.eth308
    ДляSuiJun 17, 2025
    +15

    Як обмеження здібностей взаємодіють з динамічними полями в гетерогенних колекціях?

    Я створюю ринок, який повинен обробляти кілька типів активів з різними вимогами до здібностей, і я зіткнувся з деякими фундаментальними запитаннями щодо системи типів Move. Я хочу зберігати різні типи активів в одній колекції, але вони мають різні здібності: Звичайні NFT: key + store(можна передавати) Токени Soulbound: key тільки (не передаються) Користувальницькі активи з обмеженнями передачі public struct Marketplace has key { id: UID, listings: Bag, // Want to store different asset types here } // This works for transferable assets public fun list_transferable( marketplace: &mut Marketplace, asset: T, price: u64 ) { /* ... */ } // But how to handle soulbound assets? public fun list_soulbound( // No store ability marketplace: &mut Marketplace, asset_ref: &T, // Can only take reference price: u64 ) { /* How do I store metadata about this? */ } Ключові питання: Вимоги до здібностей: dynamic_field::add()При використанні Vзавжди потрібно під store час компіляції? Чи можуть типи обгортки обійти це? Гетерогенне зберігання: Чи може одна сумка зберігати об'єкти з різними наборами здіб key + store + copyностей (vskey + store) та обробляти їх по-різному під час виконання? Безпека типу: Оскільки динамічні поля виконують стирання типу, як я можу підтримувати безпеку типу під час отримання значень? Який шаблон для зберігання метаданих типу? Шаблон свідків: Як працюють обмеження здібностей з фантомними типами? Чи можу я зберігати Assetі Assetв тій самій колекції та витягувати інформацію про тип пізніше? Побудова системи, де NFT, токени, пов'язані з душею, та обмежені активи потребують функціональності ринку, але з різною семантикою передачі. Я спробував типи обгортки, кілька колекцій на набір можливостей, окреме зберігання метаданих типу. Кожен з них має компроміси між безпекою типу, витратами на газ та складністю.

    0
    7

Найновіші

  • BBT101.Peera.
    BBT10110
    ДляSuiAug 16, 2025

    Роль Суй у оптимізації глобальної торгівлі та інфраструктури ланцюгів поставок

    Вступ: Глобальна торгівля є вузьким місцем довіри Сучасний ланцюжок поставок охоплює десятки країн, сотні постачальників та незліченну кількість документів - багато з них на папері, схильні до помилок або неперевірені. Від відстеження контейнерів до митних декларацій та сертифікатів походження світову торгівлю мучать: • Фрагментація даних між юрисдикціями та системами • Шахрайська документація та підробка • Неефективне вирішення спорів • Дороге узгодження та відсутність прозорості Sui пропонує програмовану, прозору та масштабовану блокчейн-платформу, здатну моделювати весь глобальний торговий процес - з безпечною автоматизацією, відстежуваністю та модульним управлінням. Навіщо використовувати Sui для торгівлі та ланцюга поставок? На відміну від багатьох блокчейнів загального призначення, об'єктно-орієнтована архітектура і паралельне виконання Sui дозволяють підприємствам: Особлива перевага в торгових додатках Об'єктне моделювання Моделюйте реальні ресурси, такі як контейнери, відправлення, документи Горизонтальна масштабованість Обробляйте відстеження та оновлення подій великого обсягу ZKLogin Аутентифікація Безпечна ідентифікація користувачів (митних агентів, постачальників) Реєстрація подій та викиди Відстежуйте повний ланцюжок зберіг��ння в мережах Спеціальні модулі Move кодування логіки контракту (наприклад, правила походження, тарифи) Sui перетворює торгові документи на перевірені цифрові активи, а процеси в прозорі, самовиконувані робочі процеси. Випадок використання: Міжнародна відвантаження з сертифікатом походження Давайте розглянемо спрощений випадок використання. 👟 Сценарій: відвантаження кросівок з В'єтнаму до ЄС Зацікавлені сторони: • Виробник у Хошиміні • Вантажний перевізник • Митні брокери • Імпортер ЄС Робочий процес на основі інтерфейсу: Об'єкт відвантаження, створений виробником (походження, номер партії, вміст) Сертифікат OforiginObject, виданий торговим органом В'єтнаму Вантажна компанія оновлює TransitStatusObject у міру переміщення вантажу Митний агент перевіряє документи та цифрово підписує оформлення Роздрібний продавець ЄС отримує перевірений продукт+метадані в ланцюжку Переваги: • Усі зацікавлені сторони мають доступ до аудиторського сліду, захищеного від підробки • Відсутність обміну документами на основі електронної пошти або підробки PDF • Негайне дотримання правил імпорту/експорту Архітектура торгового протоколу на основі SUI Кожен актив ланцюга поставок або документ стає першокласним громадянином у ланцюжку. 🔩 Основні модулі: • ShipmentObject — включає елементи, вагу, походження, унікальний ідентифікатор • CertificateModule — перевіряє достовірність документа та ролі емітента • CustomsApprovalModule — митні агенти можуть схвалити/відхилити відвантаження • TransitEventModule — видає оновлення місцезнаходження (наприклад, сканування порту, завантаження) 🔐 Приклад: Переміщення модуля для перевірки сертифікатів модуль торгівлі: :CertificateModule { Struct Сертифікат має ключ { країна_походження: вектор, емітент: адреса, дійсний_до: u64, } public fun issue_certificate (емітент: &підписант, країна: вектор) { let cert = Сертифікат { країна_походження: країна, емітент: підписувач: :адреса_оф (емітент), дійсний_до: 1690000000, }; move_to (емітент, сертифікат); } перевірка публічного задоволення (сертифікат: &Сертифікат): bool { мітка часу: :зараз () < cert.valid_before } } Ця логіка гарантує, що лише довірені органи можуть видавати та перевіряти торгові документи. Суперсумісність: співпраця в реальному часі через кордо Модульна ідентичність та об'єктна логіка Sui дозволяє міжюрисдикційну співпрацю без центрального контролю: Дія зацікавлених сторін щодо Sui Адміністрація порту додає подію сканування до ShipmentObject Національний експортний офіс видає сертифікат з цифровим підписом Вантажний перевізник оновлює ЕТА відправлення та звіти про стан Митний агент перевіряє автентичність та відповідність у мережі Роздрібний продавець отримує перевірену історію продуктів + метадані CO2 За допомогою API та інформаційних панелей, побудованих на Sui, навіть нетехнічні суб'єкти можуть безпечно брати участь у протоколі. Запобігання шахрайству та відстеження Глобальне торгове шахрайство призводить до мільярдів доларів втрачених доходів щорічно. Суй бореться з цим за допомогою: • Цифрові підписані документи, прив'язані до особи через ZKLogin • Незмінний ланцюжок опіки з подіями з позначкою часу • Токени товарів на основі NFT з пов'язаними сертифікатами • Розумні тригери, які запобігають підробленню або несанкціонованим пере Приклад: Антифальсифікаційний доказ Кожен жетон розкішного продукту (наприклад, дизайнерська сумочка) може: • Посилання на сертифікат походу+номер заводської партії • Включити QR-код, прив'язаний до ланцюгового об'єкта • Заборонити перепродаж, якщо не автентифіковано перевіреним обліковим записом Вуглецеві кредити та інтеграція ESG Підприємства знаходяться під тиском, щоб довести стійкі ланцюги поставок. Суй може: • Записуйте викиди вуглецю на відвантаження або одиницю продукту • Дозволити третім сторонам (аудиторам, НУО) перевіряти показники вуглецю • Додайте звіти ESG до доставки NFT • Увімкнути мережеву торгівлю або претендувати на компенсації вуглецю Приклад: Журнали переміщення транспортного контейнера використовуються для оцінки викидів, а до маркера продукту приєднується CarbonScoreObject. Покупці можуть перевірити це перед покупкою. Міркування щодо масштабування глобальних мереж Паралельне виконання Sui та низька затримка роблять його готовим до підприємства: Вимоги до масштабу Особливість Sui 100 000 щоденних оновлень Паралельна обробка об'єктів 100+ зацікавлених сторін на ланцюжок Дозвіл на рівні об'єкта API реального часу потребує високопродуктивних RPC+підписки на події Зберігання даних Історія об'єктів + локальні журнали Sui може масштабуватися так само швидко, як зростає глобальний попит на логістику. Виклики та стратегії розгортання Стратегія пом'якшення викликів Обмеження даних юрисдикції Використовуйте модулі для конкретних регіонів+теги об'єктів Обмежена грамотність блокчейну Створіть зручні DApps + веб-інтерфейси Інтеграція із застарілими системами Middleware + поза ланцюгом роз'єми Безпека + аудит відповідності Журнали викидів+ підписані атестації Почніть з однієї торгової смуги або лінійки продуктів, потім поступово розширюйте протоколи та інтеграції. Висновок: Побудова майбутнього глобальної торгівлі на Sui Об'єктно-центрична, програмована та масштабована архітектура Sui пропонує основу для глобального, перевіреного торгового протоколу. За допомогою Sui підприємства можуть: • Скорочення паперової тяганини, затримок і шахрайства • Автоматизація багатосторонніх робочих процесів • Досягнення повної простежуваності та відповідності ESG • Створення спільних шарів даних без центральних серверів У світі, де довіра, прозорість та швидкість визначають успіх торгівлі, Sui - це більше, ніж блокчейн - це інфраструктура довіри для завтрашніх ланцюгів поставок.

    0
  • D’versacy .Peera.
    D’versacy 10
    ДляSuiAug 16, 2025

    🔒 Забезпечення вашого додатка Sui: практичний контрольний список безпеки

    Будівництво на Sui захоплююче - його об'єктно-орієнтована модель відкриває нові моделі дизайну та швидший паралелізм. Але ⚠️ нові моделі = нові помилки. Помилки власності, витоки ескроу або необережні ключі адміністратора можуть спричинити дорогі втрати. Цей посібник містить покроковий контрольний список безпеки 📝, а також практичний приклад ринку, щоб показати, як уникнути найпоширеніших підводних каменів. ✅ 1) Контрольний список безпеки Sui 🔑 Найменший привілей • Не покладайтеся на один глобальний «ключ адміністратора». • Використовуйте об'єкти можливостей для авторитету. • Охороняйте критичні повноваження адміністратора за допомогою багатофункціонального або мережевого управління. ⚖️ Атомні перекази ескроу • Завжди ескроу-активи всередині виділених об'єктів лістингу. • Використовуйте програмовані блоки транзакцій (PTB) для атомних свопів → запобігає фронтальній та подвійній витраті. 🛡️ Перевірте всі входи • У розділі «Переміщення» перевірте довжини вектора, межі та обмеження. • Перевірте десеріалізацію та відхиліть неправильно сформовані об'єкти. • Ніколи не припускайте безпеку введення лише тому, що об'єкт існує в ланцюжку. 🧪 Агресивно тестуйте та розпушуйте • Напишіть негативні тести: недійсні входи, одночасні оновлення, виснаження газу. • Додайте нечіткість для несподіваних потоків транзакцій. • Автоматизація в CI, щоб рано вловити регресії. 🔐 Управління ключами • Зберігайте ключі адміністратора в апаратних гаманцях. • Використовуйте мультиsig для дій управління. • Повертайте клавіші, коли члени команди виїжджають. 👀 Аудити та стимули • Отримайте перевірку критичних модулів Move. • Запустіть програму винагород за помилки для тестування спільноти. • Пам'ятайте: зовнішні очі ловлять те, що вам не вистачає. 🏪 2) Приклад на практиці: безпечний ринок Ось як застосувати контрольний список у Marketplace DApp: • Безпечне зберігання NFT: Продавець переміщує NFT в об'єкт лістингу. Торговий контракт не може приймати кошти без схвалення продавця. • Правильно обробляти роялті: Обчисліть роялті всередині PTB, забезпечуючи правильний розподіл комісії (стежте за округленням!). • Відновлення? Не тут: Модель ресурсів Move запобігає копіювання/повторному входу за дизайном. Тим не менш, перевірте всі потоки, щоб переконатися, що немає логічних лазівок. 📚 Джерела та подальше читання • Документи Sui: концепції та транзакції • Інформаційна довідка Sui (об'єктно-центрична модель) • Документи SDK TypeScript Mysten Labs • Перемістити книгу • У сховищі GitHub ✨ Винос: На Sui безпека - це менше помилки відновлення у стилі EVM, а більше про власність, авторитет та атомність. Якщо ви дотримуєтесь контрольного списку, ви значно зменшите поверхню атаки, зберігаючи ресурси користувачів у безпеці.

    0
  • theking.Peera.
    theking933
    ДляSuiAug 16, 2025

    Від чистої установки до вашого першого ланцюгового об'єкта без застрягання

    Ви починаєте з встановлення Sui CLI та ланцюжка інструментів Move, щоб ви могли створювати та публікувати код, потім ви запускаєте active-address sui client, щоб підтвердити робочу пару ключів, і натисніть кран, щоб отримати тестовий SUI, після чого ви створюєте новий пакет Move з шаблоном, щоб не боротися зі структурою папок, потім ви редагуєте один модуль, щоб визначити простий об'єкт із полем власника та кількома методами, такими як ініціювати, оновлювати та передавати, щоб ви могли Об'єктна модель Sui швидко, потім ви компілюєте за допомогою sui move build та виправляєте будь-які помилки, які показує компілятор, оскільки це ваша найшвидший цикл зворотного зв'язку, потім ви публікуєте з sui client publish --gas-budget і берете ідентифікатори пакета та модуля з виводу, щоб ви могли викликати функції, після чого ви викликаєте функцію init entry, щоб карбувати об'єкт та скопіювати ідентифікатор об'єкта з ефектів транзакції, потім ви запускаєте об'єкт sui client, щоб побачити версію, власника та поля, щоб підтвердити, що ланцюжок записав те, що ви очікуєте, якщо ви зіткнетеся з «недостатнім газом», ви зменшуєте бюджет газу або запитуєте більше тестів після SUI кожна публікація та дзвінок коштує газу, якщо ви отримуєте «модуль не знайдено», який ви, ймовірно, використовували неправильний ідентифікатор пакета або забув відновити, якщо ваша передача не вдається з помилкою можливостей, ви, ймовірно, зробили об'єкт спільним, коли ви мали на увазі власність, або забули передати правильну форму аргументу, після того, як основи працюють, ви скриптуєте потік у оболонці або скрипті JavaScript, щоб одна команда збирала, публікувала, друкує, оновлює та переносить, що економить час та запобігає друкарським помилкам, і, нарешті, ви передаєте цей мінімальний приклад до сховища, щоб члени команди могли клонувати та виконувати ті самі кроки за лічені хвилини; розглядаючи об'єкт як одиницю мислення, а не єдиний глобальний контракт, ви Узгоджуйте спосіб кодування з тим, як Sui зберігає стан, що зберігає вашу ментальну модель чистою та запобігає важкому налагодженню переходу або перегонам глобальних станів, які ви можете зустріти в інших ланцюгах, а оскільки Sui паралелізує транзакції власних об'єктів, ви також бачите швидке підтвердження під час ітерації, що робить інтеграцію набагато приємнішою.

    0

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

    У тренді

    • Vens.sui.Peera.
      Vens.sui213
      ДляSuiApr 29, 2025

      Бот AMM в екосистемі Sui

      Які ключові особливості та функціональні можливості ботів AMM в екосистемі Sui? Як вони покращують традиційні торгові механізми та які переваги вони пропонують користувачам, які користуються протоколами DeFi в мережі Sui? Чи потрібно мені будувати його або я можу використовувати Turbos Finance, наприклад

      9
      4
    • 0xduckmove.Peera.
      0xduckmove2038
      ДляSuiApr 08, 2025

      👀 SEAL- Я думаю, що конфіденційність даних Web3 ось-ось зміниться

      👀 SEAL працює на Sui Testnet - я думаю, що конфіденційність даних Web3 ось-ось зміниться У Web3 зазвичай чути фрази на кштал«користувачі володіють своїми даними» або* «децентралізовано за дизайном»*. Але якщо придивитися, багато додатків все ще покладаються на централізовану інфраструктуру для обробки конфіденційних даних - використовуючи такі сервіси, як AWS або Google Cloud для управління ключами. Це вводить протиріччя: децентралізація на поверхні, централізація знизу. Але що, якби був спосіб безпечно управляти секретами, не відмовляючись від децентралізації? Представляємо SEAL - Децентралізоване управління секретами (DSM), тепер працює на Sui Testnet. SEAL прагне виправити одне з найбільших лицемірств Web3: кричати децентралізацію під час таємного використання AWS Ви, можливо, запитаєте мене: Що таке SEAL? SEAL - це протокол, який дозволяє безпечно та** децентралізовано керувати конфіденційними даними - створений спеціально для світу Web3. Подумайте про це як про рівень контролю доступу в першу чергу конфіденційності, який підключається до вашого DApp. Ви можете думати про SEAL як про своєрідний програмований замок для ваших даних. Ви не просто блокуєте та розблоковуєте речі вручну — визаписуєте політику безпосередньо у свої розумні контракти, використовуючи Move on Sui. Припустимо, ви створюєте DApp, де: Тільки власники NFT можуть розблокувати преміум-підручник Або, можливо, DAO повинен проголосувати, перш ніж розкриються конфіденційні файли Або ви хочете, щоб метадані були заблоковані за часом і доступні лише після певної дати SEAL робить все це можливим. Контроль доступу живе onchain, повністю автоматизований, адміністратор не потребує керування ним. Просто логіка, запечена прямо в блокчейн. SEAL робить все це можливим. Контроль доступу живе onchain, повністю автоматизований, адміністратор не потребує керування ним. Просто логіка, запечена прямо в блокчейн. Ще один цікавий фрагмент - це те, як SEAL обробляєшифрування. Він використовує щось, що називаєтьсяпорогове шифрування, що означає: жоден вузол не може розшифрувати дані. Для спільної роботи потрібна група серверів - щось на зразок multi-sig, але для розблокування секретів. Це розподіляє довіру та дозволяє уникнути звичайної проблеми з однією точкою відмови. І щоб зберегти речі по-справжньому приватними, SEAL шифрує та розшифровує всена стороні клієнта. Ваші дані ніколи не видимі жодному бекенду. Він залишається у ваших руках - буквально - на вашому пристрої. і SEAL не хвилює, де ви зберігаєте свої дані. Незалежно від того, чи це IPFS, Arweave, Walrus чи якась інша платформа, SEAL не намагається контролювати цю частину. Він просто фокусується накому дозволено бачити чого, а не * де* де* речі зберігаються. Отже, так, це не просто бібліотека чи API — цеверхній, керований доступом, рівень конфіденційності за замовчуваннямдля вашого DApp. SEAL заповнює досить критичний прогалий. Давайте розберемо це трохи більше. Якщо ви створюєте DApp, який займаєтьсябудь-якою формою конфіденційних даних— закритим вмістом, документами користувачів, зашифрованими повідомленнями, навіть метаданими NFT із заблокованими часом — ви зіткнетеся з тією ж проблемою: ➡️ Як ви керуєте доступом безпечно, не покладаючись на централізовану службу? Без чогось на зразок SEAL більшість команд також: Використовуйте централізовані інструменти, такі як AWS KMS або Firebase, що явно суперечить децентралізації Або спробуйте самостійно виправити напіввипечену логіку шифрування, яка зазвичай закінчується крихкою та важкою для перевірки https://x.com/EmanAbio/status/1908240279720841425?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1908240279720841425%7Ctwgr%5E697f93dc65359d0c8c7d64ddede66c0c4adeadf1%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.notion.so%2Fharryph%2FSEAL-Launches-on-Sui-Testnet-1cc4f8e09bb380969c0dcc627b96cc22 Жоден з них не масштабується добре. Особливо не тоді, коли ви намагаєтеся створювати недовірені додатки в декількох мережах або спільнотах. SEAL робить весь цей процес модульним та програмованим. Ви визначаєте свої правила доступу в смарт-контрактах Move, а SEAL обробляє решту — генерацію ключів, схвалення дешифрування та забезпечення доступу — і все це без того, щоб хтось вручну видавав ключі або виконував перевірку бекенду. Ще краще, ці правилапідлягають перевірці та незмінними— як тільки вони підключаються до ланцюга, вони дотримуються контракту, а не людського адміністратора. Тож замість того, щоб запитати «хто повинен керувати доступом до цих даних?» Ви просто запитаєте: «Яка логіка повинна визначати доступ?» > ... і нехай ланцюг впорається з цим. Чистий і масштабований. Це те, що робить SEAL актуальним не лише для «інструментів безпеки» - це базовий шар для будь-якого DApp, який піклується про конфіденційність, відповідність або логіку динамічного доступу.** Це невелика зміна, але це сильно змінює те, як ми думаємо про дані в Web3. Замість того, щоб шифрувати* після* розгортання або покладатися на зовнішні сервіси,ви починаєте з вбудованої конфіденційності - і доступ повністю обробляється логікою смарт-контрактів. І це саме те, що зараз потрібно Web3. Як насправді працює SEAL? Ми розглянулищо таке SEALінавіщо це Web3, давайте подивимося, як він насправді побудований під капотом. У цій частині справи стають більш технічними - але в хорошому сенсі. Архітектура елегантна, коли ви бачите, як усі деталі поєднуються. На високому рівні SEAL працює, поєднуючилогіку доступу в ланцюжкузуправлінням ключами поза мережею, використовуючи техніку під назвоюшифрування на основі ідентичності (IBE). Це дозволяє розробникам шифрувати дані до ідентичності, а потім покладатися на смарт-контракти, щоб визначитикому дозволяється розшифрувати їх. Крок 1: Правила доступу до смарт-контрактів (на Sui) Все починається з смарт-контракту. Коли ви використовуєте SEAL, ви визначаєте функцію під назвою seal_approve у своєму контракті Move - тут ви пишете свої умови для розшифровки. Наприклад, ось просте правило блокування часу, написане в Move: entry fun seal_approve(id: vector, c: &clock::Clock) { let mut prepared: BCS = bcs::new(id); let t = prepared.peel_u64(); let leftovers = prepared.into_remainder_bytes(); assert!((leftovers.length() == 0) && (c.timestamp_ms() >= t), ENoAccess); } Після розгортання цей контракт виконує роль воротаря. Щоразу, коли хтось хоче розшифрувати дані, їх запит перевірятиметься відповідно до цієї логіки. Якщо він проходить, ключ звільняється. Якщо ні, то вони заблоковані. Ніхто не повинен втручатися. ##Крок 2: Шифрування на основі ідентичності (IBE) Ось де відбувається магія. Замість шифрування даних для певної адреси гаманця (наприклад, у PGP або RSA), SEAL використовуєрядки ідентифікації, тобто ви шифруєте щось на кшталт: 0xадреса гаманця дао_голосували: пропозиція_xyz PKGID_2025_05_01 (правило на основі міток часу) або навіть геймкористувач_nftхолдер Коли дані зашифровані, це виглядає так: Encrypt(mpk, identity, message) mpk = головний відкритий ключ (відомий всім) ідентичність = логічно визначений одержувач повідомлення = фактичні дані Пізніше, якщо хтось хоче розшифрувати, сервер ключів перевіряє, чи відповідають вони політиці (за допомогою виклику seal_approve onchain). Якщо він схвалений, він повертає похідний приватний ключ для цього ідентифікатора. Derive(msk, identity) → sk Decrypt(sk, encrypted_data) Потім користувач може розшифрувати вміст локально. Таким чином, шифрування робиться без необхідності знати ко розшифруватиме заздалегідь. Ви просто визначаєте умови, а SEAL з'ясовує решту пізніше. Це динамічно. ##Крок 3: Ключовий сервер - поза ланцюгом, але не централізований Ви можете задатися питанням: хто тримає ці головні ключі? Тут на допомогу приходитьКлючовий сервер SEAL. Подумайте про це як про бекенд, який: Тримає головний секретний ключ (msk) Дивиться на ланцюгові контракти (як ваша логіка seal_approve) Видає лише похідні ключі, якщо умови виконані Але - і це ключове - SEAL не покладається лише на * один* ключовий сервер. Ви можете запустити його впороговому режимі, де кілька незалежних серверів повинні погодитися, перш ніж буде видано ключ розшифровки. Наприклад: 3 з 5 ключових серверів повинні схвалити запит. Це дозволяє уникнути центральних точок відмови та дозволяє децентралізувати також на рівні управління ключами. Ще краще, що в майбутньому SEAL підтримуватимеMPC (багатосторонні обчислення) таналаштування на основі анклав(наприклад TEE) - так що ви можете отримати ще сильніші гарантії без шкоди для зручності використання. ##Крок 4: Дешифрування на стороні клієнта Після повернення ключа користувачеві фактичне дешифрування відбуваєтьсяна його пристрої. Це означає: Сервер ніколи не бачить ваші дані Backend ніколи не зберігає розшифрований вміст Тільки користувач може отримати доступ до остаточного повідомлення Це надійна модель конфіденційності. Навіть якщо хтось компрометує шар зберігання (IPFS, Arweave тощо), вони все одно не можуть прочитати дані, не передаючи логіку доступу. Ось швидка ментальна модель: Ця структура дозволяє легко створювати DApps, де правила доступу не жорстко закодовані - вони динамічні, піддаються перевірці та повністю інтегровані у логіку вашого ланцюга. ##Команда за SEAL SEAL очолюєSamczsun, відома фігура в спільноті безпеки блокчейнів. Раніше був дослідницьким партнером Paradigm, він перевіряв та врятував кілька екосистем від великих подвигів. Тепер він повністю зосереджений на тому, щоб SEAL перетворився на основну частину інфраструктури конфіденційності Web3. Завдяки своєму досвіду та довірі SEAL є не просто ще одним експериментальним інструментом - це серйозна спроба зробити децентралізовану конфіденційність даних практичною та масштабованою. Оскільки SEAL виходить в ефір на Sui Testnet, він приносить новий стандарт того, як додатки Web3 можуть керувати секретами. Поєднуючи контроль доступу в ланцюжок, порогове шифрування та конфіденційність на стороні клієнта, SEAL пропонує більш надійну основу для децентралізованої обробки даних. Незалежно від того, створюєте ви DApps, DAO чи децентралізовані ігри - SEAL надає потужний набір інструментів для забезпечення контролю доступу та захисту даних користувачів без шкоди для децентралізації. Якщо Web3 збирається рухатися вперед, безпечна інфраструктура, така як SEAL, не є необов'язковою - це важливо

      8
    • BigSneh.Peera.
      BigSneh2024
      ДляSuiJul 30, 2025

      Як об'єднати два об'єкти монети в Move?

      Я намагаюся зрозуміти цей аспект мережі Sui, тому що я або будую, налагоджую або розгортаю щось, що стосується цієї області. Я хочу детальне пояснення того, як працює цей механізм або функція, разом із відповідним використанням CLI, структурою переміщення коду або архітектурними концепціями. Моя мета — отримати достатню ясність, щоб застосувати ці знання в реальному проекті — будь то спеціальний смарт-контракт, система NFT, інтеграція гаманця чи інструмент DeFi. Мережа Sui має унікальні особливості порівняно з мережами EVM, тому мене особливо цікавить, що її відрізняє та як це впливає на найкращі практики розробки. Це допомогло б мати зразок коду, приклади командного рядка або типові помилки, на які слід стежити, особливо під час використання Sui CLI, SDK або розгортання в localnet/testnet. Зрештою, я хочу уникнути поширених помилок, дотримуватися найкращих принципів безпеки та гарантувати, що функціональність, над якою я працюю, поводиться так, як очікувалося в реалістичних умовах. *

      7
      15