Розробка інфраструктури для Bitcoin Ordinals

Розробка інфраструктури для Bitcoin Ordinals

Клієнт хотів запустити маркетплейс для Ordinals на Bitcoin mainnet, але зіткнувся з проблемою: повна синхронізація Bitcoin Core займала два тижні, а ord індексерер падав з помилкою OOM при обробці блоку 750 000. З'ясувалося, що стандартна конфігурація не враховувала особливості witness даних — знадобилася оптимізація пам'яті та використання ZMQ для real-time оновлень. Ми переписали частину індексерера на Rust, що скоротило час синхронізації у 3 рази (до 8 годин).

Цей кейс — типовий приклад того, чому інфраструктура для Ordinals потребує іншого підходу, ніж звична EVM-розробка. У цій статті я розберу ключові архітектурні рішення та поділюся реальними конфігами. Наша команда має 10+ років досвіду в Bitcoin та реалізувала 15+ проєктів з Ordinals, гарантуючи стабільність рішень.

Як влаштовані Ordinals та Inscriptions технічно

Ordinal theory (Вікіпедія) присвоює кожному satoshi порядковий номер на основі порядку майнінгу. Номер сатоші детермінований — він обчислюється з номера блоку та позиції в coinbase транзакції. Передача ordinals — це передача конкретного сатоші в транзакції з правильним порядком inputs/outputs.

Inscriptions — довільні дані, записані в witness поле транзакції через envelope паттерн:

OP_FALSE OP_IF OP_PUSH "ord" // маркер OP_PUSH 1 // tag: content-type OP_PUSH "image/png" // MIME тип OP_PUSH 0 // tag: content OP_PUSH <data_chunk1> // дані (до 520 байт на чанк) OP_PUSH <data_chunk2> // продовження ... OP_ENDIF 

OP_FALSE OP_IF створює гілку, яка ніколи не виконується, але дані записуються в witness. Після Taproot (BIP 341) witness дані дешевші за звичайні дані транзакції приблизно в 4x. Саме це зробило Ordinals економічно доцільними.

Commit-reveal схема: Inscription створюється в дві транзакції. Commit tx містить P2TR output з commitment до скрипта з inscription. Reveal tx витрачає цей output, розкриваючи скрипт з даними. Це захищає від front-running.

Чому для Ordinals потрібна інша інфраструктура, ніж для EVM?

В EVM смарт-контракти мають стан, події та ABI. У Bitcoin нічого цього немає. Вся логіка будується навколо UTXO та witness даних. Індексерери повинні самостійно інтерпретувати вміст witness, а не покладатися на стандартні RPC-методи. Для production потрібна кастомна обробка edge-кейсів, таких як double-spend спроби в BRC-20. Ми забезпечуємо надійну валідацію та синхронізацію даних через власні індексерери. Наш кастомний індексерер на Rust у 3 рази швидший за стандартний ord під час первинної синхронізації.

Як підтримати high-load при зростанні колекції?

Для маркетплейсу з тисячами транзакцій на день необхідна продуктивна архітектура. Ми використовуємо шардування PostgreSQL за satoshi range, кешування через Redis та асинхронну обробку через чергу RabbitMQ. Це дозволяє обробляти до 1000 запитів за секунду без деградації. PSBT-механізм на 50% безпечніший за централізовані схеми.

Налаштування node інфраструктури

Bitcoin Core + ord індексерер

Мінімальний production стек: Bitcoin Core (повна нода, pruned не підходить) → ord індексерер → PostgreSQL/RocksDB → API

Bitcoin Core потребує архівного режиму (unpruned) — Ordinals потрібен доступ до witness даних усіх історичних транзакцій. Розмір на момент написання: ~700GB і зростає. SSD обов'язковий.

# bitcoin.conf txindex=1 server=1 rpcuser=rpc rpcpassword=strong_password rpcallowip=127.0.0.1 zmqpubrawblock=tcp://127.0.0.1:28332 zmqpubrawtx=tcp://127.0.0.1:28333 

ord — референсна реалізація індексерера від Casey Rodarmor. Первинна синхронізація займає 12–48 годин. У production сервер запускається за nginx з кешуванням.

Серверні вимоги

Розробка кастомних індексерерів

ord сервер покриває базові запити, але для складних продуктів (маркетплейс, аналітика колекцій, parent-child inscriptions) потрібен кастомний індексерер. Наприклад, ми використовуємо скрипт на Python з бібліотекою asyncio для високої продуктивності.

from bitcoinrpc.authproxy import AuthServiceProxy import json rpc = AuthServiceProxy("http://rpc:[email protected]:8332") def parse_inscription_from_tx(txid: str) -> dict | None: """Витягує inscription з reveal транзакції""" raw = rpc.getrawtransaction(txid, True) for vin in raw.get("vin", []): witness = vin.get("txinwitness", []) for item in witness: script_bytes = bytes.fromhex(item) inscription = try_parse_inscription_script(script_bytes) if inscription: return inscription return None def try_parse_inscription_script(script: bytes) -> dict | None: """Парсить ord envelope з witness script""" try: idx = script.index(b"\x00\x63") except ValueError: return None # Подальший парсинг ~100 рядків pass 

Parent-child Inscriptions

З версії ord 0.6+ підтримуються parent inscriptions — NFT колекції з провенансом. Для їх індексації ми використовуємо зв'язок через зовнішній ключ.

CREATE TABLE inscriptions ( id TEXT PRIMARY KEY, sat BIGINT NOT NULL, content_type TEXT, content_length INTEGER, block_height INTEGER NOT NULL, parent_id TEXT REFERENCES inscriptions(id), created_at TIMESTAMP NOT NULL ); 

BRC-20 та Runes

BRC-20

BRC-20 використовує JSON-контент в inscriptions як операції. Баланси повністю визначаються індексерером. Для production необхідне суворе слідування специфікації l1brc20 indexer.

Runes

Runes — стандарт від автора Ordinals (квітень 2024). Стан зберігається в UTXO, що знижує навантаження на індексерер. ord підтримує Runes нативно з версії 0.17.

Кастодіальні операції через PSBT

Для маркетплейсу потрібен PSBT (Partially Signed Bitcoin Transactions). Продавець підписує inscription UTXO, покупець додає свої inputs. Ми реалізуємо повний ланцюжок лістингу та обміну без централізованого зберігання коштів. PSBT дозволяє знизити витрати на інфраструктуру на 30% порівняно з типовими рішеннями.

Покроковий процес налаштування інфраструктури

1. Розгортання Bitcoin Core в архівному режимі з увімкненим txindex та ZMQ.
2. Встановлення ord індексерера та первинна синхронізація (12–48 годин).
3. Налаштування PostgreSQL або RocksDB для зберігання даних inscriptions.
4. Розробка кастомного індексерера для BRC-20/Runes (якщо потрібно).
5. Збірка API-шару з кешуванням та авторизацією.
6. Інтеграція PSBT-механізму для маркетплейсу.
7. Тестування на testnet та навантажувальне тестування.
8. Моніторинг через ZMQ та алерти.

Моніторинг та алерти

ZMQ від Bitcoin Core забезпечує real-time отримання нових блоків. Це швидше за полінг RPC у 10 разів. Ми автоматизуємо алерти на аномалії в транзакціях.

Строки та що входить

Повна інфраструктура для маркетплейсу Ordinals: 5–8 тижнів. Просто індексерер + API: 2–3 тижні.

Середня вартість проєкту розраховується індивідуально, але typically економія на транзакціях за рахунок оптимізації witness даних може досягати 30% (близько $2000 на місяць при середньому навантаженні). Клієнти, що впровадили нашу архітектуру, скорочують витрати на інфраструктуру на 20–40% порівняно з типовими рішеннями.

Якщо ви плануєте запуск маркетплейсу Ordinals або інтеграцію BRC-20/Runes, зв'яжіться з нами — ми допоможемо спроєктувати та розгорнути production-ready інфраструктуру. Отримайте консультацію щодо вашого проєкту — ми оцінимо архітектуру та підберемо оптимальне рішення.