Peera.

Explorer

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

Sui.X.Peera.

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

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

Спільноти

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

Винагорода

  • Xavier.eth.Peera.
    Xavier.eth313
    Для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 буде дуже вдячна!

    2
    5
  • Xavier.eth.Peera.
    Xavier.eth313
    Для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
    5
  • Peera Admin.Peera.
    Peera Admin37
    ДляSuiMay 29, 2025
    +10

    Чому BCS вимагає точного порядку полів для десеріалізації, коли структури Move мають названі поля?

    Чому BCS вимагає точного порядку полів для десеріалізації, коли структури Move мають названі поля? Я глибоко занурювався в кодування/декодування BCS у Move, особливо для міжланцюгового зв'язку та обробки даних поза ланцюгом. Опрацьовуючи приклади в документації Sui Move, я зіткнувся з деякою поведінкою, яка здається неінтуїтивною, і я намагаюся зрозуміти основні рішення щодо дизайну. Відповідно до специфікації BCS, «в BCS немає структур (оскільки немає типів); структура просто визначає порядок, в якому поля серіалізуються». Це означає, що при десеріалізації ми повинні використовувати peel_*функції в тому ж порядку, що і визначення поля struct. Мої конкретні запитання: Обґрунтування дизайну: Чому BCS вимагає точного узгодження порядку полів, коли структури Move мають названі поля? Чи не було б надійніше серіалізувати імена полів поряд зі значеннями, подібними до JSON або інших форматів, що самоописуються? Взаємодія загальних типів: У документах згадується, що «типи, що містять поля загального типу, можна обробити до першого поля загального типу». Розглянемо таку структуру: struct ComplexObject has drop, copy { id: ID, owner: address, metadata: Metadata, generic_data: T, more_metadata: String, another_generic: U } Як саме тут працює часткова десеріалізація? Чи можу я десеріалізувати до more_metadata та ігнорувати обидва загальні поля, чи перше загальне поле (generic_data) повністю блокує подальшу десеріалізацію? Міжмовна послідовність: Під час використання бібліотеки JavaScript @mysten /bcs для серіалізації даних, які будуть споживані контрактами Move, що станеться, якщо: Я випадково змінюю порядок полів в об'єкті JavaScript? Визначення структури Move змінює порядок поля в оновленні контракту? У мене є вкладені структури з власними загальними параметрами? Практичні наслідки: як команди обробляють еволюцію схеми BCS у виробничих системах? Ви редагуєте свої схеми BCS, чи очікуєте, що порядок полів структури є незмінним після розгортання?

    5
    3

Найновіші

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

  • BitcoinADUK.Peera.
    BitcoinADUK10
    ДляThe GraphMar 14, 2025

    Токен GRT - які ваші думки?

    Графік (GRT) - це децентралізований протокол, призначений для індексування та запиту даних з блокчейнів, починаючи з Ethereum. Це дозволяє розробникам створювати та публікувати відкриті API, відомі як підграфи, які роблять дані блокчейну легко доступними для децентралізованих додатків (dApps). Власний токен, GRT, використовується в мережі такими учасниками, як індексатори, куратори та делегатори, щоб забезпечити економічну безпеку та цілісність запитуваних даних. Станом на 14 березня 2025 року GRT торгується приблизно на рівні 0.094 доларів, а 24-годинний обсяг торгів становить близько 36 мільйонів доларів. Ця поточна ціна відображає значне зниження від свого історичного максимуму в 2.84 долара, що вказує на тенденцію до зниження за останні кілька років. На цінову траєкторію ГРТ впливали різні фактори, включаючи технологічний прогрес, регуляторні розробки та більш широкі макроекономічні показники. Ці елементи спільно сприяли спостережуваному зниженню вартості з часом. Зверніть увагу, що ринки криптовалют дуже мінливі, і минулі показники не гарантують майбутніх результатів. Важливо провести ретельне дослідження та розглянути своє фінансове становище, перш ніж приймати будь-які інвестиційні рішення.

    0
    0
  • Fractal Visions.Peera.
    Fractal Visions30
    ДляFractal VisionsNov 17, 2024

    Fractal Visions MVP Launch

    Fractal Visions, a decentralized marketplace platform built on the superchain concept, has officially launched its new marketplace, positioning itself as a pivotal player in the blockchain ecosystem. This innovative marketplace leverages the power of the superchain—a scalable and interoperable blockchain network—to offer a seamless user experience for creators, collectors, and traders of digital assets. Here are some key highlights of the Fractal Visions marketplace: 1. Superchain Integration Fractal Visions has integrated the superchain infrastructure to ensure high scalability, low transaction costs, and fast settlement times. By tapping into this architecture, Fractal Visions can offer cross-chain interoperability, allowing users to transact seamlessly across different blockchain ecosystems. This is a significant advantage over traditional, isolated blockchain networks, providing users with more flexibility and access to a wider range of digital assets. 2. Decentralized Marketplace The Fractal Visions platform operates in a fully decentralized manner, empowering users to retain full control over their digital assets. Artists, creators, and collectors can freely trade and showcase NFTs and other digital items without the interference of centralized entities. This decentralized nature enhances transparency, reduces the risk of censorship, and provides a trustless environment for users. 3. User-Centric Features The marketplace is designed with the user experience in mind. It offers a simple, intuitive interface for easy browsing, buying, and selling of NFTs and other digital assets. Fractal Visions includes advanced search features, personalized recommendations, and an advanced bidding system for auction-style sales. 4. Multichain Support Fractal Visions supports multiple blockchains, allowing users to connect their wallets across various networks. This includes support for Optimism, Base, Mode, and other leading layer 2 networks. The multichain approach ensures that users can access a wide range of assets and interact with a large, global audience. 5. Focus on Creators Fractal Visions offers unique opportunities for creators to monetize their work. By providing creators with complete ownership of their assets and offering flexible revenue-sharing models, the platform ensures that artists and developers can thrive within a decentralized ecosystem. Additionally, creators can set up royalty structures, allowing them to earn income from secondary sales of their work. 6. Innovative Features The marketplace incorporates cutting-edge technology, such as AI-driven content recommendations and enhanced security features, ensuring that the platform remains at the forefront of blockchain-based marketplaces. Additionally, Fractal Visions is working on integrating VR (Virtual Reality) and AR (Augmented Reality) features to allow users to experience digital assets in immersive environments. 7. Community Engagement Fractal Visions is committed to building a strong community around its platform. The marketplace supports community-driven governance, allowing users to participate in decision-making processes and contribute to the evolution of the platform. Whether through voting on proposals or engaging in social interactions, users are at the heart of the ecosystem. 8. Sustainability and Eco-Friendliness As part of its commitment to sustainability, Fractal Visions is optimizing its network for energy efficiency, ensuring that the platform operates with a minimal environmental footprint. This aligns with the broader trend of eco-consciousness within the blockchain industry. Fractal Visions’ new marketplace launch marks a significant step forward in the evolution of decentralized, superchain-based platforms. By combining the power of interoperability, decentralization, and user-centric design, Fractal Visions is set to reshape how digital assets are created, traded, and experienced. The marketplace’s seamless integration with multiple blockchains, along with its focus on empowering creators and fostering community engagement, positions it as a major contender in the rapidly growing digital asset ecosystem.

    0
    0
  • 0x5ca8...8c95.Peera.
    0x5ca8...8c9510
    ДляAaveOct 17, 2024

    Rewards Edge Cases

    Q1: Is it possible that if a user supplies certain asset on AAVE V2, instead of just receiving equivalent number of Atoken, the user can also receive a non-Atoken? Q2: If I supplied 1000 USDC on AAVE V2, I am subjected to receive equivalent amount of aUSDC and get intrest on it, is it possible I can receive other rewards too without doing anything? If yes how?

    0
    0

У тренді

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

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

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

    8
    3
  • 0xduckmove.Peera.
    0xduckmove630
    Для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
  • MarlKey.Peera.
    MarlKey61
    ДляSuiApr 30, 2025

    Єдиний спосіб опублікувати пакети Move через EOA?

    Я припускаю, що в ланцюжку Sui немає способу, оскільки в ланцюжку немає модуля, який публікує пакети.

    7
    3