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

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

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

UTXO модель: почему это сложнее, чем кажется

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

В Ethereum у тебя есть address → balance. В Bitcoin — набор UTXO (Unspent Transaction Outputs), каждый из которых нужно явно использовать как input в следующей транзакции. Инскрипция привязана к конкретному UTXO (точнее, к первому satoshi этого UTXO — "cardinal" sat).

Первая ошибка при mass minting: UTXO consolidation без учёта инскрипций. Стандартный Bitcoin кошелёк может автоматически объединять мелкие UTXO для оптимизации комиссий. Если consolidation берёт UTXO с инскрипцией как input — инскрипция уходит на output с правильным routing (при везении) или теряется в dust (при ошибке). Ordinals wallet должен различать "cardinal UTXO" (с инскрипцией) и "plain UTXO" (для платежей).

Dust limit и padding

Инскрипция создаётся в reveal транзакции, которая тратит commit UTXO. Output reveal транзакции — это UTXO, несущий инскрипцию. Этот output должен быть >= dust limit Bitcoin (546 satoshi для P2WPKH, 330 для P2TR). Если делаешь batch и пытаешься сэкономить, отправив инскрипцию на output 0 satoshi — транзакция не пройдёт через mempool (non-standard output).

Практика: каждый inscribed output = 546-1000 satoshi (зависит от требований пользователя). При мinтинге 1,000 инскрипций это 0.546-1 BTC только на "прикрепление" dust к каждой инскрипции.

Commit-reveal схема и её timing

Ordinals инскрипция создаётся в два шага:

Commit транзакция — P2TR output с tapscript, содержащим данные инскрипции в 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 — не зависишь от внешних сервисов, критично при высокой нагрузке.

Fee calculation

Bitcoin fee = fee_rate (sat/vByte) × transaction_size (vBytes). Размер reveal транзакции зависит от размера данных инскрипции: 1 vByte ≈ 4 witness weight units. Инскрипция 100KB в witness = ~25,000 vByte. При fee rate 50 sat/vByte = 1,250,000 satoshi = ~0.0125 BTC на одну инскрипцию.

Сервис должен:

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 можно содержать несколько инскрипций, если они упакованы в один tapscript через concatenation в envelope. Это снижает overhead: одна транзакция вместо N, общий commit. Минус: если reveal не подтверждается (застрял в мемпуле) — все инскрипции из batch ждут вместе. Для коммерческого сервиса часто лучше отдельные транзакции с независимым статусом.

Пользовательский интерфейс

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

Безопасность и edge cases

RBF (Replace-By-Fee) — пользователь может попытаться заменить транзакцию оплаты. Ждём минимум 1 подтверждение перед публикацией commit.

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

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

Процесс работы

Аналитика (1-2 дня). Целевая аудитория (одиночные инскрипции / 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.

Ориентиры по срокам

Базовый сервис одиночных инскрипций — 1-1.5 недели. Bulk minting с dashboard и API — 2-3 недели.

Стоимость рассчитывается после анализа требований к масштабу и функциональности.