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

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

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