Создание сервиса 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 также реализуется через собственный индексатор.

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

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