Peera.

Explorer

Присоединяйтесь к сообществам и открывайте новые идеи.

Sui.X.Peera.

Заработай свою долю из 1000 Sui

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

Сообщества

Фильтр:Все блокчейны

Награда

  • Xavier.eth.Peera.
    Xavier.eth298
    Для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.eth298
    ДляSuiJun 17, 2025
    +15

    Как ограничения возможностей взаимодействуют с динамическими полями в гетерогенных коллекциях?

    Я создаю торговую площадку, которая будет работать с несколькими типами ресурсов с разными требованиями к возможностям, и я задал несколько фундаментальных вопросов о системе типов Move. Я хочу хранить разные типы активов в одной коллекции, но у них разные возможности: Обычные NFT: key + store(можно передавать другим лицам) key Только токены Soulbound (не подлежат передаче) Настраиваемые активы с ограничениями на перевод 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 + copykey + storeи по-разному обрабатывать их во время выполнения? Безопасность типов: поскольку в динамических полях происходит стирание типов, как обеспечить безопасность типов при извлечении значений? Какова схема хранения метаданных типов? Паттерн Witness: как ограничения способностей работают с фантомными типами? Могу ли я хранить информацию о AssetAssetтипах в той же коллекции и извлекать информацию о типах позже? Создание системы, в которой NFT, токены soulbound и активы с ограниченным доступом требуют функциональности торговой площадки, но с другой семантикой передачи данных. Я испробовал типы оболочек, несколько коллекций для каждого набора способностей, хранилище метаданных отдельных типов. В каждом из них есть компромисс между безопасностью типов, стоимостью газа и сложностью.

    0
    5
  • Peera Admin.Peera.
    Peera Admin37
    ДляSuiMay 29, 2025
    +10

    Почему BCS требует точного порядка полей для десериализации, когда структуры Move содержат именованные поля?

    Почему BCS требует точного порядка полей для десериализации, если структуры Move содержат именованные поля? Я углубился в кодирование/декодирование BCS в Move, особенно в том, что касается межсетевой связи и обработки данных вне сети. Изучая примеры из документации Sui Move, я обнаружил, что некоторые действия кажутся мне нелогичными, и я пытаюсь понять основные проектные решения. Согласно спецификации BCS, «в BCS нет структур (поскольку нет типов); структура просто определяет порядок сериализации полей». Это означает, что при десериализации мы должны использовать peel_*функции в том же порядке, в котором указано определение поля структуры. Мои конкретные вопросы: Обоснование проектирования: почему 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

Самые новые

Без ответа

  • theking.Peera.
    theking918
    ДляSuiJul 25, 2025

    Каков стандарт отображения объектов на Sui?

    Стандарт отображения объектов (https://docs.sui.io/standards/object-display) определяет способ отображения объектов Sui (например, NFT) с использованием таких метаданных, как имя, описание и URL-адреса изображений. Он используется для единообразного рендеринга в кошельках и торговых площадках. Внедрите это в свой контракт Move, добавив структуру Display с такими полями, как name и image_url. Код см. в примерах Sui NFT (https://github.com/MystenLabs/sui).

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

    GRT Token — что вы думаете?

    The Graph (GRT) — это децентрализованный протокол, предназначенный для индексации и запроса данных из блокчейнов, начиная с Ethereum. Он позволяет разработчикам создавать и публиковать открытые API, известные как подграфы, которые облегчают доступ к данным блокчейна для децентрализованных приложений (dApps). Собственный токен GRT используется в сети такими участниками, как индексаторы, кураторы и делегаты, для обеспечения экономической безопасности и целостности запрашиваемых данных. По состоянию на 14 марта 2025 года GRT торгуется примерно по 0,094 доллара США, а 24-часовой объем торгов составляет около 36 миллионов долларов. Эта текущая цена значительно снизилась по сравнению с историческим максимумом в 2,84 доллара, что указывает на тенденцию к снижению в последние несколько лет. На ценовую траекторию GRT повлияли различные факторы, включая технологические достижения, изменения в регулировании и более широкие макроэкономические показатели. Все эти факторы в совокупности способствовали наблюдаемому снижению стоимости с течением времени. Обратите вни��ание, что рынки криптовалют очень волатильны, и прошлые результаты не гарантируют будущих результатов. Прежде чем принимать какие-либо инвестиционные решения, важно провести тщательное исследование и рассмотреть свое финансовое положение.

    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

В тренде

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

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

    Каковы ключевые особенности и функциональные возможности ботов AMM в экосистеме Sui? Как они улучшают традиционные торговые механизмы и какие преимущества они предлагают пользователям, использующим протоколы DeFi в сети Sui? Нужно ли мне его создавать или я могу использовать, например, Turbos Finance

    9
    3
  • 0xduckmove.Peera.
    0xduckmove2018
    Для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 делает все это возможным. Контроль доступа работает «в сетевом режиме», полностью автоматизирован, управление им не требуется со стороны администратора. Просто логика, встроенная прямо в блокчейн. SEAL делает все это возможным. Контроль доступа работает «в сетевом режиме», полностью автоматизирован, управление им не требуется со стороны администратора. Просто логика, встроенная прямо в блокчейн. Еще одна интересная статья — как SEAL обрабатывает шифрование. Он использует так называемоепороговое шифрование**, что означает, что ни один узел не может расшифровать данные. Для совместной работы требуется группа серверов — как в случае с несколькими подписями, но для разблокировки секретов. Это распределяет доверие и позволяет избежать обычной проблемы, возникающей в случае сбоя в одной точке. А чтобы сохранить конфиденциальность информации, 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 адрес кошелька dao_voted:proposal_xyz pkGid_2025_05_01 (правило, основанное на отметках времени) или даже game_user_nft_holder Когда данные зашифрованы, они выглядят следующим образом: Encrypt(mpk, identity, message) mpk = мастер-публичный ключ (известный всем) личность = логически определенный получатель сообщение = фактические данные Позже, если кто-то захочет расшифровать данные, сервер ключей проверяет, соответствуют ли они политике (с помощью вызова seal_approve onchain). Если запрос одобрен, он возвращает производный закрытый ключ для этого удостоверения. Derive(msk, identity) → sk Decrypt(sk, encrypted_data) Затем пользователь может локально расшифровать содержимое. Таким образом, шифрование выполняется без необходимости заранее знать, кто будет расшифровывать данные. Вы просто определяете условия, а SEAL выяснит остальное позже. Это динамично. ##Шаг 3: Сервер ключей — вне блокчейна, но не централизован Возможно, вы задаетесь вопросом: у кого эти мастер-ключи? Здесь на помощь приходитСервер ключей SEAL. Думайте об этом как о бэкенде, который: Содержит главный секретный ключ (msk) Следит за контрактами в блокчейне (например, за вашей логикой seal_approve) Выпускает производные ключи только при соблюдении условий Но — и это главное — SEAL не полагается только на один* сервер ключей. Вы можете запустить его в режимеthreshold, когда перед выдачей ключа дешифрования необходимо согласование нескольких независимых серверов. Например: запрос должны одобрить 3 из 5 ключевых серверов. Это позволяет избежать основных точек сбоя, а также обеспечивает децентрализацию на уровне управления ключами. Более того, в будущем SEAL будет поддерживатьMPC (многопартийные вычисления) иконфигурации на основе анклав(например, TEE), чтобы вы могли получить еще более надежные гарантии без ущерба для удобства использования. ##Шаг 4: расшифровка на стороне клиента Как только ключ возвращается пользователю, фактическое дешифрование происходитна его устройстве. Это означает: Сервер никогда не видит ваши данные Бэкэнд никогда не хранит расшифрованный контент Только пользователь может получить доступ к окончательному сообщению Это надежная модель конфиденциальности. Даже если кто-то взломает уровень хранения данных (IPFS, Arweave и т. д.), он все равно не сможет прочитать данные, не пройдя логику доступа. Вот краткая ментальная модель: Эта структура позволяет легко создавать dApps, правила доступа которых не жестко закодированы — они динамичны, поддаются аудиту и полностью интегрированы в логику цепочки. ##Команда, стоящая за печатью 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 Network, потому что занимаюсь разработкой, отладкой или развертыванием чего-то, затрагивающего эту область. Мне нужно подробное объяснение работы этого механизма или функции, а также соответствующего использования интерфейса командной строки, структуры кода Move или архитектурных концепций. Моя цель — получить достаточно ясности, чтобы применить эти знания в реальном проекте, будь то специальный смарт-контракт, система NFT, интеграция кошельков или инструмент DeFi. Сеть Sui обладает уникальными возможностями по сравнению с сетями EVM, поэтому мне особенно интересно, что её отличает и как это влияет на передовые практики разработки. Было бы полезно ознакомиться с образцами кода, примерами командной строки или типичными ошибками, особенно при использовании интерфейса командной строки Sui, SDK или развертывании в localnet/testnet. В конечном итоге я хочу избежать распространенных ошибок, следовать лучшим принципам безопасности и обеспечить, чтобы функциональность, над которой я работ��ю, работала должным образом в реальных условиях. *

    7
    13