Самые новые
Будьте в курсе последних постов.
Посты
1817- СтатьяДляSuiApr 09, 2025
Руководство по транзакциям Sui: от настройки до выполнения и проверки
Руководство по транзакциям Sui: от настройки до выполнения и проверки Если вам интересно узнать, как проводить транзакции в блокчейне Sui, и вам нужно подробное практическое руководство, которое поможет вам на каждом этапе. В этой статье мы рассмотрим весь процесс: от настройки клиентской среды, проверки состояния кошелька, расчета платы за газ до подписания и выполнения транзакции и, наконец, проверки ее деталей. Давайте разберем всё шаг за шагом: Что делает Суй таким особенным? 🔥 Sui предлагает высокооптимизированную платформу для децентрализованных приложений (dApps) и смарт-контрактов. Элегантный дизайн, позволяющий управлять тарифами на газ и логикой транзакций, делает эту платформу интересной игровой площадкой для разработчиков, стремящихся расширить границы технологии Web3. 2. Начало работы: настройка среды и конфигурация кошелька ⚙️ 2.1. Настройка клиентской среды Sui Прежде чем приступить к транзакциям, убедитесь, что ваш клиент Sui правильно настроен. Sui поддерживает несколько сетей (devnet, mainnet, testnet), и вы можете проверить, какая из них активна, выполнив следующую команду: ➜ sui client envs ╭─────────┬─────────────────────────────────────┬────────╮ │ alias │ url │ active │ ├─────────┼─────────────────────────────────────┼────────┤ │ devnet │ https://fullnode.devnet.sui.io:443 │ │ │ mainnet │ https://fullnode.mainnet.sui.io:443 │ │ │ testnet │ https://fullnode.testnet.sui.io:443 │ * │ ╰─────────┴─────────────────────────────────────┴────────╯ Это подтверждает, что вы подключены к тестовой сети. Подключение к правильной сети — это первый шаг к успешной транзакции. 2.2. Проверка активного кошелька Затем подтвердите адрес активного кошелька. Это очень важно, потому что каждая транзакция связана с идентификацией вашего кошелька: ➜ sui client active-address 0x35370841d2e69b495b1e2f944a3087e4242f314e503691a00b054e0ee2a45a73 2.3. Запрос принадлежащих объектов Используя API Suix_GetOwnedObjects, вы можете получить сведения о принадлежащих вам объектах (например, монетах) в блокчейне. Эта команда поможет вам проверить баланс счета и активы, доступные для транзакций: { "jsonrpc": "2.0", "id": 1, "method": "suix_getOwnedObjects", "params": [ "0x35370841d2e69b495b1e2f944a3087e4242f314e503691a00b054e0ee2a45a73", { "filter": { "MatchAll": [ { "StructType": "0x2::coin::Coin" } ] }, "options": { "showType": true, "showOwner": true, "showPreviousTransaction": true } } ] } Этот шаг очень важен для проверки наличия в вашем кошельке необходимых монет (в данном случае монет SUI), прежде чем совершать какие-либо транзакции. 3. Расчет газа: бюджетирование транзакционных издержек 💸 Газ — это топливо, обеспечивающее транзакции в блокчейне. Чтобы избежать сбоев в транзакциях, важно понимать как цену на газ, так и бюджет на газ. 3.1. Получение цены на газ Текущую цену на газ можно получить с помощью вызова API Suix_GetReferenceGasPrice: { "jsonrpc": "2.0", "id": 1, "method": "suix_getReferenceGasPrice", "params": [] } Если API возвращает «1000», это означает, что каждая единица газа стоит 1000 MIST. Помните, что 1 SUI равен 10 ^ 9 MIST, поэтому даже небольшие цифры в MIST могут суммироваться при составлении бюджета. 3.2. Настройка бюджета на газ Ваш бюджет на газ — это максимальное количество газа (в формате MIST), которое вы готовы потратить. Например, предположим, что ваш бюджет на газ составляет 4964000 MIST. Общая стоимость транзакции обычно рассчитывается следующим образом: Общая стоимость = стоимость вычислений + стоимость хранения — скидка на хранение Например: • Стоимость вычислений: 1 000 000 MIST • Стоимость хранения: 2 964 000 MIST • Скидка на хранение: 978 120 MIST Таким образом, чистая стоимость составляет 1 000 000 + 2 964 000 − 978 120 = 2 985 880 MIST. Четкое определение бюджета на газ гарантирует, что на транзакцию будет достаточно средств для успешного выполнения. 4. Составление сделки: путь к доверию 🔧 Прежде чем отправлять транзакцию в реальном времени, лучше всего провести пробную проверку, чтобы выявить возможные проблемы. Это позволит вам проверить логику транзакции, не тратя денег на газ. 4.1. Создание пробной транзакции Вот пример функции TypeScript, демонстрирующий, как подготовить и выполнить пробную транзакцию. В этом коде описывается, как разделить монеты и подготовить операции перевода: export const signSuiDryRunTransaction = async (requestParams: SignDryRequestParams): Promise => { const { gasPrice, privateKey, coinRefs, network, recipients } = requestParams; const keypair = Ed25519Keypair.fromSecretKey(privateKey); const tx = newTransaction(); // Configure gas payment, price, and sender tx.setGasPayment(coinRefs); tx.setGasPrice(gasPrice); tx.setSender(keypair.toSuiAddress()); // Split coins based on each recipient's amount const coins = tx.splitCoins(tx.gas, recipients.map((transfer) => transfer.amount)); recipients.forEach((transfer, index) => { tx.transferObjects([coins[index]], transfer.to); }); // Build and sign the transaction with the client const client = newSuiClient({ url: getFullnodeUrl(network) }); const bytes = await tx.build({ client }); const { signature } = await keypair.signTransaction(bytes); await verifyTransactionSignature(bytes, signature, { address: keypair.getPublicKey().toSuiAddress() }); return JSON.stringify([toBase64(bytes), signature]); }; Этот пробный шаг очень важен для того, чтобы убедиться, что все детали верны, прежде чем вкладывать реальные средства. 5. Подписание и выполнение транзакции: собираем все воедино ✍️ После успешного пробного запуска следующим шагом будет подписание и отправка транзакции в блокчейн. 5.1. Подписание транзакции Ниже приведен усовершенствованный пример функции, которая подписывает транзакцию с указанным бюджетом газа: const signSuiTransaction = async (requestParams: SignRequestParams): Promise => { const { gasBudget, gasPrice, privateKey, coinRefs, network, recipients } = requestParams; const keypair = Ed25519Keypair.fromSecretKey(privateKey); const tx = newTransaction(); // Set up gas parameters, including the gas budget tx.setGasPayment(coinRefs); tx.setGasPrice(gasPrice); tx.setGasBudget(gasBudget); tx.setSender(keypair.toSuiAddress()); // Split coins for each recipient const coins = tx.splitCoins(tx.gas, recipients.map((transfer) => transfer.amount)); recipients.forEach((transfer, index) => { tx.transferObjects([coins[index]], transfer.to); }); // Build the transaction and sign it const client = newSuiClient({ url: getFullnodeUrl(network) }); const bytes = await tx.build({ client }); const { signature } = await keypair.signTransaction(bytes); await verifyTransactionSignature(bytes, signature, { address: keypair.getPublicKey().toSuiAddress() }); return JSON.stringify([toBase64(bytes), signature]); }; Эта функция объединяет все необходимые параметры, включая данные о газе и получателях, обеспечивая надежное подписание транзакции и ее готовность к исполнению. 5.2. Выполнение транзакции После подписания транзакция отправляется в блокчейн с использованием конечной точки API SUI_ExecuteTransactionBlock: curl --location 'https://fullnode.testnet.sui.io:443' \ --header 'Content-Type: application/json' \ --data '{ "jsonrpc": "2.0", "id": 1, "method": "sui_executeTransactionBlock", "params": [ "", [""], { "showInput": true, "showRawInput": true, "showEffects": true, "showEvents": true, "showObjectChanges": true, "showBalanceChanges": true }, "WaitForLocalExecution" ] }' Этот вызов возвращает подробный ответ в формате JSON с такой информацией, как дайджест транзакций, потребление газа, модификации объектов и обновления баланса. 6. Подтверждение транзакции: перепроверьте все 🔍 После выполнения транзакции важно убедиться, что все выполнено так, как ожидалось. 6.1. Верификация браузера Вы можете проверить транзакцию в обозревателе блокчейнов, например Suivision Testnet Explorer. В обозревателе все сведения о транзакциях отображаются в интуитивно понятном визуальном формате, что упрощает обнаружение любых проблем. 6.2. Верификация в командной строке Для более подробного аудита используйте командную строку: sui client tx-block -- 3FopuDy5qzKm1kLRFZCdi8Lynadym9j15NaVxzUH6nYD Эта команда предоставляет исчерпывающую информацию о транзакции, включая сведения об отправителе, оплату газа, изменения объекта и статус выполнения. 7. Анализ ответа JSON: понимание уровней транзакции Давайте распакуем ответ JSON, который вы получите после выполнения транзакции: 7.1. Обзор транзакций jsonrpc & id: стандартные поля для протокола JSON-RPC. дайджест: уникальный хэш транзакции (например, «3fopudy5qzkm1klrfzcdi8lynadym9j15navxzuh6nyD»), который используется для отслеживания. TimestampMS и контрольная точка: укажите контекст того, когда транзакция была выполнена, и контрольную точку блокчейна в данный момент. 7.2. Содержимое транзакции Данные отправителя и газа: включают адрес отправителя и все конфигурации, связанные с газом (оплата, цена, бюджет). Операции (транзакции): логика транзакций включает такие операции, как: SplitCoins: разделение газовой монеты на более мелкие части. TransferObjects: перемещение сегментов монет по указанным адресам получателей. Подписи: криптографические подписи (в кодировке Base64) обеспечивают подлинность транзакции. 7.3. Эффекты выполнения Статус: статус «успешный» подтверждает, что транзакция была обработана без ошибок. Использование газа: подробная информация о вычислительных затратах и расходах на хранение, а также о применимых скидках. Изменения объектов: описание объектов, которые были изменены, созданы или обновлены в результате транзакции. Зависимости: список связанных хэшей транзакций, от которых зависит эта транзакция. Эта детальная разбивка необходима для отладки и повышения производительности вашего dApp. 8. Практическая информация для разработчиков: советы и выводы Понимая каждый этап этого процесса, вы приобретете навыки создания безопасных и эффективных приложений Web3 на Sui. Эти сведения не только помогают устранять неполадки, но и позволяют уверенно внедрять инновации в экосистеме Sui.
- Sui
- SDKs and Developer Tools
- Transaction Processing
1 Стейкинг в кошельке Sui: можно ли вывести деньги в любое время?
Мне было интересно, сделаю ли я ставку в кошельке Sui Wallet, могу ли я снять свою ставку в любое время или есть период разблокировки?
- Transaction Processing
01Что произойдет, если я не получу ETH через мост Sui?
Я использовал мост Sui для перевода некоторого количества ETH, но пока не воспользовался им, так как комиссии довольно высоки. Что произойдет, если я оставлю деньги невостребованными?
- Sui
00Что произойдет, если я не получу ETH через мост Sui?
Я использовал мост Sui для перевода некоторого количества ETH, но пока не воспользовался им, так как комиссии довольно высоки. Что произойдет, если я оставлю деньги невостребованными?
- Sui
00- Статья0xduckmove120Для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, не является факультативной, а просто необходима
- Sui
- Architecture
- SDKs and Developer Tools
1 Как обеспечить, чтобы только владелец NFT мог передать его в контракте?
Всем привет! Я работаю над реализацией контракта NFT и хочу убедиться, что только законный владелец NFT может передать его. У меня есть следующая функция для перевода: public fun transfer( nft: DevNetNFT, recipient: address, _: &mut TxContext ) { transfer::public_transfer(nft, recipient) } Выполняется ли эта проверка в public_transferметоде или мне нужно добавить дополнительную логику?
- Move CLI
03Как получить значения из ObjectTable с помощью динамических полей?
dynamicFieldObjectЯ пытаюсь получить значения из ObjectTable с помощью динамических полей из внешнего интерфейса, но у меня возникает ошибка с. Unexpected arg String("gms") for the expected type Struct(MoveStructLayout...)В ошибке говорится. Как выбрать правильный тип значения и избежать этой ошибки?
- Move CLI
- Move
03Как внести токены SUI из сети SUI на Binance?
Я хочу отправить свои токены SUI на свой аккаунт Binance. Я пытался использовать мост через портал, но это сбивает с толку. Я слышал, что для этого мне нужно конвертировать токены SUI в SUI USDC перед мостовым соединением. Как правильно это сделать без использования портального моста? Кроме того, как я могу конвертировать SUI в USDC или USDT, попав на Binance, если это не позволяет мне напрямую?
- Sui
02Как решить проблемы с установкой и запуском сервиса Heimdall?
Я пытаюсь установить и запустить службу Heimdall на своем сервере Ubuntu, но у меня возникают ошибки. Сначала во время установки возникла ошибка сценария предварительного удаления, указывающая на то, что «heimdalld.service» не был загружен. Позже, после переустановки, сервис не удалось запустить, так как он не был найден. Может ли кто-нибудь помочь мне решить эти проблемы?
- Polygon Edge
04Как протестировать функцию с параметром Receiving в Sui?
Я пытаюсь протестировать receive_objectфункцию с Receivingпараметром в языке Sui на основе документации по этой ссылке. Сначала я создал тест на этом примере, но не могу понять, как сделать так, чтобы отправленный аргумент был Receivingтипом. Я также попытался указать тип получения, но обнаружил ошибки. Может ли кто-нибудь помочь мне правильно протестировать эту функцию?
- Move CLI
- Move
04
