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

Розробка сервісу Bitcoin-інскрипцій починається не з інтерфейсу, а з UTXO і commit-reveal. Сервіс інскрипцій потребує розуміння лімітів witness даних. Інскрипції — не смарт-контракти, а дані, вбудовані в SegWit-транзакції та прив'язані до конкретних сатоші через протокол нумерації Ordinals. Зробити сервіс, який надійно створює, відстежує та передає такі записи — задача, яку не вирішити стандартними Bitcoin бібліотеками «з коробки». Досвід команди — 7+ років у Bitcoin-інфраструктурі, 20+ проєктів з інскрипцій. Ми беремося за такі проєкти під ключ: від проєктування архітектури до деплою та моніторингу. Після запуску забезпечуємо підтримку: моніторинг ноди, оновлення індексатора, оптимізацію fee estimation. Гарантія на код — 3 місяці. Використання власного індексатора дозволяє значно скоротити витрати на API-запити. Комісії при мінті колекції залежать від кількості та розміру інскрипцій. Отримайте консультацію з архітектури вашого сервісу.

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

Формати та обмеження

Що ви отримаєте в результаті