Розробка Bitcoin Ordinals NFT Inscriptions
Протокол Ordinals з'явився в січні 2023 року і змінив сприйняття Bitcoin як "нудного" активу без смарт-контрактів. Кожен сатоші має унікальний порядковий номер (ordinal), і до нього можна прикріпити довільні дані — зображення, HTML, JavaScript, навіть робочий 3D-рушій. Це inscription. Жодних смарт-контрактів, жодного другого шару — дані зберігаються безпосередньо в Bitcoin witness (SegWit v1, Taproot).
Розробка колекції Ordinals відрізняється від розробки EVM принципово: немає Solidity, немає ABI, немає подій. Є UTXO-модель, обмеження розміру witness та специфіка роботи з Bitcoin transaction builder'ами.
Як працює протокол Ordinals
Нумерація сатошей
Протокол Ordinals (Casey Rodarmor, BIP-300) вводить детерміністичну нумерацію: перший сатоші першого блока отримує номер 0, останній сатоші останнього блока епохи халвінгу — максимальний номер. Нумерація стабільна і незалежно верифікована.
"Рідкість" сатоші визначається його позицією: сатоші з першого блока кожної епохи халвінгу — "legendary", з першого блока кожного коригування складності — "rare" тощо. Торгівля рідкими сатошами — окремий ринок в екосистемі Ordinals.
Inscription як envelope в Tapscript
Inscription створюється через Tapscript у транзакції SegWit v1. Дані упаковуються в OP_FALSE OP_IF ... OP_ENDIF envelope, який вузли Bitcoin ігнорують під час виконання, але зберігають у witness. Тип контенту вказується тегом ord плюс MIME тип:
OP_FALSE
OP_IF
OP_PUSH "ord"
OP_1
OP_PUSH "image/png"
OP_0
OP_PUSH <image_data_chunk_1>
OP_PUSH <image_data_chunk_2>
...
OP_ENDIF
Обмеження на одну inscription — 520 байт на push операцію, але pushів може бути багато. Практичне обмеження — розмір witness даних у блоці (близько 4MB з witness discount). Зображення 400KB+ розміщуються без проблем.
Sat-to-inscription binding
Inscription прив'язана до першого сатоші першого output транзакції commit (точніше, reveal). При передачі цього UTXO — inscription переходить новому власнику. Маркетплейси (Magic Eden Bitcoin, Gamma.io, Unisat) відслідковують рух UTXO і показують нового власника.
Це принципово відрізняється від EVM: немає виклику ownerOf, немає revert при несанкціонованому трансфері. Власність визначається через UTXO-модель Bitcoin — у кого UTXO з цим сатошем, той і власник.
Рекурсивні inscriptions
Технічно найцікавіша частина: inscription може посилатися на іншу inscription через спеціальний шлях /content/{inscription_id}. Браузер (Ordinals explorer або маркетплейс) резолвить ці посилання й рендерить композит.
Застосування: 10 000-елементна колекція, де кожен trait (фон, голова, тіло) — окрема inscription розміром 2–5KB. Остаточне зображення — HTML-inscription, яка посилається на trait-inscriptions і збирає їх через теги <img> або canvas. Замість 10K × 50KB зображень — 20 trait-inscriptions × 3KB + 10K × 1KB HTML. Економія на комісіях суттєва.
Інваріант рекурсії: referenced inscriptions мають існувати до моменту створення referencing inscription. Не можна створити HTML-inscription, яка посилається на trait-inscriptions, які ще не створені.
Інструменти розробки
ord CLI
Офіційний інструмент від Casey Rodarmor. Вимагає повної Bitcoin ноди (Bitcoin Core) або можна використовувати через RPC з --bitcoin-rpc-url. Основні команди:
# Створення inscription з файлу
ord wallet inscribe --fee-rate 15 --file image.png
# Отримання інформації про inscription
ord index info --inscription <inscription_id>
Для production batch inscribing — кастомні скрипти через bitcoinlib (Python) або bitcoin-ts (TypeScript) з прямою роботою з PSBT (Partially Signed Bitcoin Transactions).
Робота з PSBT для колекцій
Batch mint 10K inscriptions через CLI — повільно й ненадійно. Використовуємо програмний підхід:
- Генеруємо trait-inscriptions пачками по 100
- Для кожної пари (commit tx, reveal tx) будуємо PSBT
- Підписуємо через HD wallet (BIP-32 derivation)
- Broadcast через Bitcoin RPC або Mempool API
Управління fee rate критично: при congestion mempool комісія за байт може вирасти в 10–20x. Скрипт має перевіряти поточний fee market через mempool.space/api/v1/fees/recommended і вибирати оптимальний рівень.
Verifier для колекції
Аналог rarity checker для EVM: скрипт, який за inscription ID отримує метаданні (через API Ordinals explorer або власну ноду), парсить traits з JSON-inscription, будує таблицю rarity. Публікується як open source — користувачі можуть незалежно верифікувати рарити.
Ethereum проти Bitcoin Ordinals
| Аспект | EVM NFT | Bitcoin Ordinals |
|---|---|---|
| Зберігання даних | IPFS / on-chain (дорого) | Нативно в Bitcoin witness |
| Трансфер | safeTransferFrom + revert |
Рух UTXO, без захисту |
| Метаданні | JSON з trait attributes | Довільний контент (image, HTML, JSON) |
| Royalties | EIP-2981 (опціонально) | Немає нативного механізму |
| Комісії за мінт | Gas (змінний) | Bitcoin sat/vbyte × розмір witness |
| Смарт-контракти | Повний EVM | Відсутні |
Відсутність royalties на рівні протоколу — ключовий недолік для монетизації команди. Маркетплейси (Magic Eden Bitcoin) реалізують "soft royalties" через UI, але технічна примусовість відсутня.
Процес роботи
Підготовка контенту (залежить від проекту). Для рекурсивних колекцій: генерація trait-inscriptions, перевірка коректності HTML-шаблонів, тест рендерингу в Ordinals explorer.
Testnet деплой (1–2 дні). Bitcoin signet або testnet для перевірки всього pipeline. Ordinals працює на testnet — можна повністю перевірити мінт і відображення.
Batch inscribing (залежить від розміру). 10K inscriptions при fee rate 15 sat/vbyte — приблизно 1–2 BTC в комісіях для зображень середнього розміру. Для рекурсивних — значно менше.
Листинг на маркетплейсах. Magic Eden Bitcoin, Gamma.io — верифікація колекції через форму або API.
Кошторис по часу
Проста колекція без рекурсії (static images) — 3–5 днів включаючи інструменти. Рекурсивна колекція з HTML-генератором — 1–1.5 тижня. Вартість Bitcoin fees для мінту обговорюється окремо — залежить від поточного fee market.