Розробка сервісу мінтингу Ordinals

Розробка сервісу мінтингу Ordinals

Ordinals — це протокол inscriptions на Bitcoin, запропонований Casey Rodarmor у 2023 році. Кожен сатоші нумеруються в порядку майнингу (ordinal theory), а довільні дані вписуються в section witness транзакції через OP_FALSE OP_IF <data> OP_ENDIF envelope. Це не смарт-контракти — це дані inscribed on-chain у Bitcoin. Розробка mass-minting сервісу для Ordinals вимагає глибокого розуміння Bitcoin UTXO моделі, яка принципово відрізняється від Ethereum account моделі.

UTXO модель: чому це складніше, ніж здається

Управління UTXO — ядро проблеми

У Ethereum у тебе є address → balance. У Bitcoin — набір UTXO (Unspent Transaction Outputs), кожен з яких потрібно явно використовувати як input у наступній транзакції. Inscription прив'язана до конкретного UTXO (точніше, до першого satoshi цього UTXO — "cardinal" sat).

Перша помилка при mass minting: UTXO consolidation без урахування inscriptions. Стандартний Bitcoin гаманець може автоматично об'єднувати дрібні UTXO для оптимізації комісій. Якщо consolidation бере UTXO з inscription як input — inscription йде на output з правильним routing'ом (при везінні) або теряється в dust (при помилці). Ordinals wallet має розрізняти "cardinal UTXO" (з inscription) і "plain UTXO" (для платежів).

Dust limit і padding

Inscription створюється в reveal транзакції, яка тратить commit UTXO. Output reveal транзакції — це UTXO, що несе inscription. Цей output має бути >= dust limit Bitcoin (546 satoshi для P2WPKH, 330 для P2TR). Якщо робиш batch і пробуєш заощадити, відправивши inscription на output 0 satoshi — транзакція не пройде через mempool (non-standard output).

Практика: кожен inscribed output = 546–1000 satoshi (залежить від вимог користувача). При мінтингу 1,000 inscriptions це 0.546–1 BTC тільки на "прикріплення" dust до кожної inscription.

Commit-reveal схема та її timing

Ordinals inscription створюється в два кроки:

Commit транзакція — P2TR output з tapscript, що містить дані inscription у locked script. Публікується в мемпул.

Reveal транзакція — тратить commit output, розкриваючи tapscript з даними. Після підтвердження commit (мінімум 1 блок) можна публікувати reveal.

Для mass minting: тисячі commit транзакцій можна готувати паралельно. Reveal транзакції — послідовно після підтвердження кожного commit. При blocktimes ~10 хвилин і congested mempool — цей процес може розтягнутися на години. Потрібна черга зі станом: PENDING_COMMIT → COMMITTED → PENDING_REVEAL → INSCRIBED.

Архітектура сервісу

Backend: Node.js + bitcoinjs-lib

Основна бібліотека для роботи з Bitcoin транзакціями — bitcoinjs-lib. Для Taproot/Ordinals — підтримка P2TR з v6.x. Альтернатива: @scure/btc-signer — більш сучасний API з типами.

Для взаємодії з Bitcoin нодою — bitcoin-core RPC або публічний Esplora API (Mempool.space, Blockstream). Для production: своя Bitcoin Core нода з txindex=1 — не залежиш від зовнішніх сервісів, критично при високій нагрузці.

Розрахунок комісій

Bitcoin fee = fee_rate (sat/vByte) × transaction_size (vBytes). Розмір reveal транзакції залежить від розміру даних inscription: 1 vByte ≈ 4 witness weight units. Inscription 100KB у witness = ~25,000 vByte. При fee rate 50 sat/vByte = 1,250,000 satoshi = ~0.0125 BTC на одну inscription.

Сервіс має:

1. Отримувати актуальний fee rate з mempool.space (endpoint /api/v1/fees/recommended)
2. Рахувати точний розмір транзакції до її зборки (через psbt.toBase64().length estimation)
3. Показувати користувачу total cost = inscription fee + miner fee + service fee
4. Мати feeRate multiplier для priority (1.0x economy, 1.5x standard, 2.0x fast)

Batch inscriptions: одна транзакція vs множество

Один reveal може містити кілька inscriptions, якщо вони упаковані в один tapscript через concatenation у envelope. Це знижує overhead: одна транзакція замість N, спільний commit. Мінус: якщо reveal не підтверджується (застрягне у mempool) — всі inscriptions з batch чекають разом. Для комерційного сервісу часто краще окремі транзакції з незалежним статусом.

Користувальницький інтерфейс

Загрузка файлів: drag-and-drop, підтримка WebP/PNG/GIF/MP4/HTML (inscription може містити будь-які MIME типи). Предпросмотр і розрахунок fee до оплати. BTC-адреса для оплати з QR-кодом. Real-time статус через WebSocket: detecting payment → commit sent → commit confirmed → reveal sent → inscribed. Посилання на ordinals.com або ord.io для перегляду inscription після завершення.

Безпека та edge cases

RBF (Replace-By-Fee) — користувач може спробувати замінити транзакцію оплати. Чекаємо мінімум 1 підтвердження перед публікацією commit.

Orphaned commits — reveal не був опубліковий, commit витрачений іншою транзакцією. Рідко, але трапляється при помилках у UTXO management. Потрібний reconciliation процес: перевіряємо статус кожного commit UTXO по блокчейну.

Content filtering — сервіс має мати політику щодо нелегального контенту. Hash-based блеклист на етапі загрузки.

Процес роботи

Аналітика (1–2 дні). Цільова аудиторія (одиночні inscriptions / bulk / API для інших проектів), підтримка BRC-20 або тільки plain Ordinals.

Розробка (1–2 тижні). Bitcoin transaction builder + job queue + payment detection + frontend.

Тестування. Testnet4 (актуальний Bitcoin testnet) для повного end-to-end тестування commit-reveal pipeline.

Деплой. VPS з Bitcoin Core нодою (вимагає ~600GB SSD), докеризований backend, мониторинг pending jobs.

Кошторис по часу

Базовий сервіс одиночних inscriptions — 1–1.5 тижня. Bulk minting з dashboard та API — 2–3 тижні.

Вартість розраховується після аналізу вимог до масштабу і функціональності.