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(можно передавать другим лицам) 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

Самые новые

  • 0xduckmove.Peera.
    0xduckmove781
    ДляSuiJul 14, 2025

    который успешно работает через devInspectTransactionBlock ()

    Привет всем! Я использую Type Script SDK и получаю сообщение об ошибке «UnusedValueWithoutDrop» после вызова tx.MoveCall (flash_swap на MMT LP). Я предполагаю, что мне придется вернуть или вернуть возвращенные монеты после обмена. Может кто-нибудь подсказать мне, как эффективно сбросить или перенести возвращенные объекты (в настоящее время NestedResult) после моего MoveCall? Благодарю за любую помощь, спасибо! Вот код, который успешно запускается с помощью devInspectTransactionBlock () let [returnCoinA, returnCoinB, returnReceip] = tx.moveCall({ target: targetFunctionLP2, typeArguments: [suiTokenType, usdcTokenType], arguments: [ tx.object(poolAddressLP2), tx.pure.bool(false), tx.pure.bool(true), tx.pure.u64(amountOutUSDNormalized), tx.pure.u128(limit_sqrt_priceB), tx.object(clockObjectAddressLP2), tx.object(versionAddressLP2), ], }); tx.transferObjects([returnCoinA, returnCoinB], tx.pure.address(sender)) `

    1
    1
  • Benjamin XDV.Peera.
    Benjamin XDV236
    ДляSuiJul 14, 2025

    Понимание модуля Sui Clock и использования временных меток

    ВSui Moveя создаю логику, чувствительную ко времени (например, передача токенов, сроки проведения аукционов), но мне трудно обеспечить надежную обработку временных меток. Ключевые вопросы: Объект Clock: зачем Суи нужны общие часы вместо блочных временных меток? Точность: насколько точны эти временные метки по сравнению со временем блоков? Модели использования: лучшие практики в отношении временных ограничений, сроков и планирования? Тестирование: как имитировать время в модульных тестах? Текущие проблемы: Базовое использование sui: :clock работает, но кажется ограниченным Не знаете, как распределить время на разных сегментах и валидаторах Тестирование логики, зависящей от времени, некорректно

    0
    2
  • 24p30p.Peera.
    24p30p174
    ДляSuiJul 14, 2025

    Существуют ли привязки TypeScript для Move?

    Есть ли способ автоматической генерации типов или интерфейсов TypeScript из моих модулей Move для упрощения интеграции с интерфейсом?

    0
    1

Без ответа

  • 0xduckmove.Peera.
    0xduckmove781
    ДляSuiJul 12, 2025

    Trust sdk для вашего мультиподписанного смарт-контракта

    SDK для Rust для интеграции с реализацией учетной записи account.tech на Sui с несколькими подписями: https://github.com/account-tech/multisig-rust-sdk 1 Что такое мультиподпись Решение Multisig — это внедрение смарт-аккаунта, разработанное и поддерживаемое основной командой account.tech. Оно использует основные функции фреймворка, включая намерения и действия, а также предоставляет дополнительные функции для управления конфигурацией. Вы можете прочитать больше https://account-tech.gitbook.io/docs/move-registry/multisig?q =

    0
    0
  • 24p30p.Peera.
    24p30p174
    ДляSuiJul 12, 2025

    Как справиться с несоответствиями версий объектов?

    Иногда моя транзакция не удаётся из-за изменения версии объекта. Как избежать или надежно решить эту проблему?

    0
    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

В тренде

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

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

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

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

    Является ли единственным способом опубликовать пакеты Move через EOA?

    Я полагаю, что в цепочке Sui нет такого способа, поскольку в цепочке нет модуля, публикующего пакеты.

    7
    3