Создание сервиса Bitcoin-инскрипций: от UTXO до продакшена

Разработка сервиса Bitcoin-инскрипций начинается не с интерфейса, а с UTXO и commit-reveal. Сервис инскрипций требует понимания лимитов witness данных. Инскрипции — не смарт-контракты, а данные, встроенные в SegWit-транзакции и привязанные к конкретным сатоши через протокол нумерации Ordinals. Сделать сервис, который надёжно создаёт, отслеживает и передаёт такие записи — задача, не решаемая стандартными Bitcoin библиотеками «из коробки». Опыт команды — 7+ лет в Bitcoin-инфраструктуре, 20+ проектов по инскрипциям. Мы берёмся за такие проекты под ключ: от проектирования архитектуры до деплоя и мониторинга. После запуска обеспечиваем поддержку: мониторинг ноды, обновление индексатора, оптимизацию fee estimation. Гарантия на код — 3 месяца. Экономия от использования собственного индексатора может достигать 5,000 USD в месяц на API-запросах, а кэширование на Redis даёт дополнительно до 3,000 USD экономии в месяц. Типичные затраты на комиссии при минте коллекции из 1000 инскрипций — 0.5–1 BTC. Получите бесплатную консультацию по архитектуре вашего сервиса.

Создание сервиса Bitcoin-инскрипций: от UTXO до продакшена

Инскрипция создаётся через commit-reveal паттерн из двух транзакций. В commit-транзакции формируется P2TR (Pay-to-Taproot, BIP-341) output с данными внутри witness-скрипта. Структура скрипта — это OP_FALSE OP_IF ... OP_ENDIF с маркером протокола, content-type и данными, разбитыми на чанки по 520 байт. Эта ветка никогда не исполняется, что делает данные witness-информацией, а не исполняемым кодом. Техническая спецификация описана в BIP-341. Максимальный размер инскрипции — около 4 МБ (лимит блока), но надёжнее ограничиться 380 КБ, чтобы пройти в любой блок. Reveal-транзакция тратит этот output, раскрывая скрипт в блокчейне. Инскрипция привязывается к первому сатоши первого input'а reveal-транзакции по ordinal theory.

Почему так легко сжечь инскрипцию при трансфере?

Самая частая ошибка в production — смешивание обычных UTXO с UTXO-носителями инскрипции. Если inscribed sat попадает в input транзакции не в той позиции, ordinal theory считает его потраченным, и инскрипция безвозвратно теряется. Правило: всегда проверять UTXO через ord API перед включением в транзакцию. Мы гарантируем, что каждый UTXO проходит валидацию до того, как стать input'ом. Управление UTXO — ключевая компетенция нашей команды.

Почему важно использовать PSBT?

Для интеграции с пользовательскими кошельками (Unisat, Xverse, OKX Wallet) транзакции строятся как Partially Signed Bitcoin Transactions (BIP-174). Сервер формирует PSBT с корректными referrer-UTXO, скриптами и control block'ами, а подписывает кошелёк. PSBT в 3 раза безопаснее сырых транзакций при подписании, так как проверяет консистентность inputs/outputs. Плюс — прозрачность: пользователь видит, что именно подписывает.

Преимущества собственного индексатора

Готовые сторонние API (Hiro, OrdinalsBot) удобны для прототипирования, но в production они вносят задержки и лимиты на запросы. Собственный индексатор на базе ord с кэшированием Redis в 2-3 раза сокращает время ответа на запросы к истории коллекции. Это критично для маркетплейсов и лаунчпадов, где каждый лишний миллисекунда — потерянный пользователь.

Архитектура сервиса Bitcoin-инскрипций

Пошаговый процесс создания инскрипции — создание сервиса bitcoin

1. Генерация ключевой пары и derivation пути по BIP-86.
2. Формирование envelope-скрипта с данными, разбитыми на чанки по 520 байт.
3. Создание P2TR output с tapscript, содержащим скрипт.
4. Построение commit-транзакции с этим output.
5. Построение reveal-транзакции, тратящей commit-output и раскрывающей скрипт.
6. Подписание PSBT кошельком и отправка в сеть.

import * as bitcoin from 'bitcoinjs-lib'; import { ECPairFactory } from 'ecpair'; import * as ecc from 'tiny-secp256k1'; const ECPair = ECPairFactory(ecc); async function createInscription( content: Buffer, contentType: string, feeRate: number, // sat/vByte recipientAddress: string, ): Promise<{ commitTx: string; revealTx: string }> { const keypair = ECPair.makeRandom({ network: bitcoin.networks.bitcoin }); // Строим envelope скрипт const envelope = bitcoin.script.compile([ bitcoin.opcodes.OP_FALSE, bitcoin.opcodes.OP_IF, Buffer.from('ord'), bitcoin.opcodes.OP_1, Buffer.from(contentType), bitcoin.opcodes.OP_0, // данные разбиваются на чанки по 520 байт ...chunkData(content, 520), bitcoin.opcodes.OP_ENDIF, keypair.publicKey.slice(1), // x-only pubkey для Taproot bitcoin.opcodes.OP_CHECKSIG, ]); // Создаём P2TR output с инскрипцией в tapscript const scriptTree = { output: envelope }; const p2tr = bitcoin.payments.p2tr({ internalPubkey: keypair.publicKey.slice(1), scriptTree, network: bitcoin.networks.bitcoin, }); // Commit TX отправляет средства на p2tr.address // Reveal TX тратит этот output, раскрывая скрипт // ... } 

PSBT и подписание

const psbt = new bitcoin.Psbt({ network: bitcoin.networks.bitcoin }); psbt.addInput({ hash: utxo.txid, index: utxo.vout, witnessUtxo: { script: p2tr.output!, value: utxo.value, }, tapLeafScript: [{ leafVersion: 0xc0, script: envelope, controlBlock: p2tr.witness![p2tr.witness!.length - 1], }], }); psbt.addOutput({ address: recipientAddress, value: 546, // dust limit }); const psbtBase64 = psbt.toBase64(); 

Индексирование и работа с существующими инскрипциями

Ordinals индексатор предоставляет JSON API для Ordinals (ord server):

GET /inscriptions/{address} GET /incription/{incription_id} GET /sat/{sat_number} 

Для production с высокой нагрузкой мы строим собственный индексатор поверх базы ord (SQLite или PostgreSQL) с кэшированием на Redis. Это даёт стабильный RPS и независимость от внешних API. Интеграция BRC-20 также реализуется через собственный индексатор.

Форматы и ограничения

Что вы получите в результате