Розробка BRC-20 токена (Bitcoin Ordinals) під ключ

Чому BRC-20 токен втрачає дані під час індексації

BRC-20 — не окремий протокол із власним консенсусом, а надбудова над Ordinals: баланси ніде в мережі не зберігаються, їх рахує індексатор, розбираючи написи в блоках.

Це і є корінь проблеми — мережа фіксує записи, а стан токена існує лише в обліковій системі того, хто ці записи читає.

Типовий збій виглядає так: написи в блоках на місці, транзакції підтверджені, а баланси власників розходяться з тим, що видно під час незалежного розбору. Причини три.

Перша — перезапуск індексації не з тієї контрольної точки або повний прохід по історії при обриві: частина блоків обробляється двічі, частина пропускається.

Друга — різне трактування ordinals записів: невалідний JSON, повторний випуск із тим самим тикером, напис на «завислому» виході — один індексатор вважає їх дійсними, інший відкидає, і випуск BRC-20 перестає сходитися.

Третя — переказ у два кроки: спочатку напис на переказ, потім прив'язка до виходу; якщо врахувати лише перший крок, токен зависає між адресами.

Окремо б'є реорганізація блокчейну: під час відкату гілки індексатор зобов'язаний зняти ефект скасованих блоків і переграти їх заново.

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

Мовчазним такий збій робить відсутність звірки: поки результат індексатора ніхто не порівнює з незалежним розбором за висотами, помилка не проявляється до моменту виведення або лістингу.

Закривається це дельта-звіркою по кожному блоку, відтворюваною переіндексацією від контрольної точки та єдиним канонічним трактуванням записів — нижче розбираємо, як це влаштовано на нашому випуску.

Ефект від запуску: час випуску, точність обліку, клас відмов

Після грамотно спроєктованого випуску терміни змінюються в рази. Розмітка партії сатоші, формування написів і підпис серії йдуть одним відтворюваним прогоном замість ручних операцій у гаманці — від постановки задачі до першої підтвердженої транзакції минають дні, а не тижні. Повторний випуск іде за тим самим сценарієм зі зміненими параметрами.

Швидкість підтвердження операцій перестає залежати від удачі.

Інженери рахують ставку комісії за завантаженістю черги, розбивають випуск на пакети й залишають запас на перебудову ланцюжка, тому транзакції потрапляють у блок передбачувано — без ручного повторного надсилання та втрати позиції всередині серії.

Точність обліку тримає власний індексатор: він збирає стан із блоків Ordinals і звіряє його з емісією до останньої одиниці. Частка звірок, які робляться руками, падає практично до нуля — розходження спливає під час розбору блоку, а не у звітності перед власниками.

Зникає цілий клас відмов: дублі написів, втрата залишку на решті, порушення порядку всередині серії, пошкодження розмічених сатоші під час перенесення. Частину з них раніше не ловили взагалі й виявляли лише під час спроби продати актив.

Стійкість індексації — окремий контур. Перебудова ланцюжка, повторна доставка й паралельні запити обробляються ідемпотентно, тому баланси та історія операцій відновлюються без ручного втручання й зупинки сервісу.

Способи випуску BRC-20 токена: порівняння підходів

BRC-20 — не смарт-контракт, а запис у даних інскрипції Ordinals, яку інтерпретує індексатор. Сам токен у мережі не існує: баланси, ліміти мінту й перекази визначає та логіка розбору, на яку дивляться гаманці, майданчики та біржі. Тому вибір способу випуску — це насамперед вибір того, хто рахує стан токена і за якими правилами.

Режими емісії задаються на тому самому рівні: деплой з відкритим мінтом, мінт з обмеженням на одну операцію та загальним лімітом, випуск із подальшим переказом.

До обмежень обліку, від яких залежить сумісність із зовнішніми сервісами, належать порядок інскрипцій усередині блоку, одночасні мінти в один ліміт, невалідні та повторні записи, а також перебудова ланцюжка — індекс зобов'язаний коректно відкотити вже враховані операції.

Порівняння підходів випуску

Власний індексатор виправданий там, де правила мінту й обліку потрібно змінювати під задачу, а не підлаштовувати задачу під чужий майданчик.

Етапи робіт: аудит задачі, схема випуску, перевірка, передача

Порядок робіт вибудовуємо так, щоб кожен наступний крок спирався на зафіксований результат попереднього. На вході — обстеження задачі: тип токена, логіка емісії, хто тримає ключі, які обмеження щодо комісії та обсягу записів.

Це знімає головний ризик випуску — незворотність: запис у блокчейні не відкочується, тому помилка в параметрах або адресі отримувача виправляється тільки новою емісією.

1. Аудит задачі. Розбираємо розподіл часток, ліміти на одну операцію, кількість майбутніх записів і те, хто підтверджує випуск. На виході — карта ризиків і вимоги до гаманців і доступів.
2. Схема емісії. Фіксуємо загальний обсяг, крок випуску, правила розблокування та адресу резерву. Схему узгоджуємо до першого запису — після випуску змінювати її не можна.
3. Налаштування випуску. Збираємо записи, задаємо черговість входів і запас щодо комісії, щоб випуск не застряг у черзі під час пікового навантаження на мережу.
4. Перевірка в тестовій мережі. Проганяємо повний цикл: випуск, переказ, спрацювання лімітів, відновлення гаманця з резервної копії. Окремо звіряємо індексацію — баланси у внутрішньому гаманці та в сторонніх оглядачах мають збігатися до запису.
5. Приймання за чек-листом. Перевіряємо кожен пункт з очікуваним результатом, розходження закриваємо до передачі, а не після.
6. Передача управління. Віддаємо доступи й схему підпису, інструкції для чергової зміни та регламент дій при зміні комісій або лімітів.

Після передачі залишаємося на зв'язку на період супроводу — правки в схемі випуску обговорюємо окремо й вносимо лише через погодження.

Пакет передачі: конфігурації, схеми обліку, регламенти

Пакет передачі — не папка з файлами «на всякий випадок», а набір артефактів, за якими ваша команда зможе самостійно випустити токен, читати його стан і обслуговувати без нашої участі.

Ми фіксуємо систему на момент здачі: що розгорнуто, де лежать ключі, як визначається баланс і що робити при розходженні вузлів.

• Конфігурації вузла та індексації — робочі параметри синхронізації, зберігання блоків і розбору написів, із позначкою, які значення змінювалися й чому саме так.
• Схеми потоків обліку — шлях від випуску до зарахування на адресу: де формується переказ, як рахується залишок, у який момент баланс стає остаточним.
• Політики доступу до ключів — розподіл ролей випуску, мінту й підпису переказів, пороги мультипідпису, порядок ротації та зберігання резервних копій.
• Регламент експлуатації — планові перевірки, реакція на реорганізацію ланцюга, повторне надсилання й розходження індексів, вікна обслуговування та порядок виведення вузла з роботи.
• Інструкції для команди — покрокові сценарії: випуск наступної партії, додавання токена, відкат невдалої операції, відновлення з копії.
• Звіт за навантажувальними перевірками та журнал спостережень — що і за якого навантаження тестували, які вузькі місця залишилися і як їх відстежувати.

Кейс: як облік активу перестав розходитися з мережею

Клієнт прийшов не із запитом «випустити токен», а з проблемою: облік випущеного активу розходився зі станом мережі.

Інскрипції створювали токени, а внутрішній реєстр жив окремо — емісії підтверджували вручну, частину переказів між адресами вносили з пам'яті, а розходження спливало лише під час спроби вивести актив на зовнішню адресу.

Розходження прибрали як клас. Підняли індексатор, який перебудовує стан активу прямо з блоків Bitcoin Ordinals, і повісили на нього щоденну звірку балансів із журналом випуску.

Кожній партії присвоїли ідентифікатор, тому повторне надсилання не створює дубль — операція просто відсікається за незмінною ознакою.

Емісію перевели в автоматизований контур: підготовка партії, підпис, підтвердження в мережі та запис в облік ідуть одним сценарієм із перевірками до надсилання. Інженер бачить розходження до того, як транзакція пішла, а не через тиждень у вивантаженні.

Результат у цифрах

• Щоденна звірка: 5–6 годин ручного зіставлення — 20 хвилин на розбір винятків.
• Частка операцій, оброблених вручну: 40% — 3% (лише нештатні випадки).
• Розходження балансів, знайдені постфактум: 5–7 на місяць — нуль за квартал спостереження.
• Випуск партії активу: робочий день — 15 хвилин від підготовки до підтвердження.
• Відновлення обліку з нуля за ланцюжком: доба — 40 хвилин автоматичного перерахунку.

Автоматизація емісії дала головне: реєстр перестав бути окремою реальністю, що живе своїм життям. Звірку можна перезапустити будь-якої миті й отримати той самий стан — це і є гарантія, що облік відповідає мережі, а не пам'яті оператора.

Готовий сервіс чи власний індексатор: що вибрати?

Готовий сервіс закриває стандартний сценарій: Ordinals розмічає написи, а публічний індексатор рахує баланси BRC-20 за правилами стандарту — деплой, мінт, переказ. Старт займає дні, своєї інфраструктури не потрібно. Межі починаються там, де ваша логіка розходиться зі стандартною.

Кастомізація логіки — перша причина переходити на своє.

Знімок балансів на фіксованій висоті блоку для роздачі, окремі правила обліку для ігрової механіки, відбір лише за своїми підбірками, оновлення стану без затримки публічного сервісу — готовий індексатор цього не віддає, а обхідні рішення впираються в неповноту даних.

Другий аргумент — масштабування обліку. Публічний сервіс обмежує частоту запитів і не гарантує повноту вибірки: під піковим навантаженням ви бачите не весь потік переказів і дізнаєтеся про це постфактум.

Власний вузол знімає питання — ви приймаєте кожен блок самі, розбираєте написи своїм фільтром і зберігаєте стан у своїй базі.

Ціна рішення — повна копія блокчейну, час на синхронізацію та повторний розбір історії, супровід. Натомість — детермінований результат, можливість переграти стан з нуля після зміни правил обліку й незалежність від доступності та лімітів чужого сервісу.

Тому на старті зазвичай достатньо сервісу, а власний індексатор і вузол виправдані при зростанні обсягів або нестандартній логіці. Часто збираємо гібрид: вузол як основне джерело, сервіс — другим контуром для звірки та відлову розходжень.

Часті технічні питання щодо випуску та обліку активу

Інженерні сумніви щодо BRC-20 зазвичай стосуються не самого випуску, а того, як актив поводитиметься під навантаженням і що з ним можна робити після запуску.

Питань чотири: навантаження на мережу під час мінту, зберігання ключів підпису, поведінка обліку при затримках підтвердження та правки після деплою.

Відповіді нижче — про те, як це влаштовано в реалізації, а не про теорію. BRC-20 — це написи в блоках Біткоїна, тому все, що стосується черги транзакцій і фінальності, працює так само, як у звичайних переказів.

Як захищені ключі, які підписують інскрипції?

Ключі підпису не зберігаються на сервері й не потрапляють у репозиторій. Ролі розділені: окремий ключ на випуск, окремий на оплату комісії, окремий на зміну правил обліку.

Критичні операції йдуть під кількома підписами, щоб одиничний витік не давав контролю над емісією, а журнал підписання дозволяє розібрати будь-яку операцію постфактум.

Що відбувається з обліком, якщо підтвердження затримується або блок відкотився?

Баланси рахуємо за підтвердженими блоками. Поки транзакція в черзі, вона показується як «в обробці» і в облік не потрапляє — розходжень між балансом користувача та станом мережі не виникає. Після відкату ланцюжка операції зі скасованого блоку перераховуються, подвійного нарахування немає.

Чи можна доопрацювати токен після запуску?

Тикер, загальна пропозиція та ліміт на одну операцію записані в першому написі й не змінюються — тільки випуск нового тикера. Решту можна правити: правила обліку в індексаторі, логіка розподілу, інтерфейс, звітність.

Супровід включає моніторинг черги непідтверджених транзакцій і розходжень між індексаторами при змінах стандарту.

Обговоримо задачу: підготовка до оцінки та плану випуску

Щоб повернутися з оцінкою та планом робіт, а не із загальними словами, потрібні вхідні дані щодо проєкту. Нижче — мінімальний набір, який знімає більшу частину питань на етапі розрахунку. Якщо якихось даних поки немає, позначте це прямо: під них закладемо припущення у схему випуску.

• Параметри емісії: тикер, загальний обсяг, кількість знаків, ліміт на адресу та правила мінту.
• Логіка розподілу: частки команди й спільноти, чи потрібні вестинги та розкриття адрес.
• Очікуване навантаження: порядок кількості учасників мінту й пікова частота транзакцій — від цього залежить стратегія комісій і розбиття випуску на етапи.
• Інфраструктура: власний індексатор або зовнішній, чи потрібна інтеграція з гаманцями та торговими майданчиками.
• Безпека: хто тримає ключі емітента, чи потрібен мультипідписний контур і хто підтверджує випуск.
• Комплаєнс і розкриття: вимоги вашої юрисдикції та чи потрібна публічна документація щодо токена.
• Критерії приймання: що вважаємо успішним випуском — підтверджений мінт, працюючий індексатор, звіт за транзакціями.
• Терміни та ролі: дата релізу, ваш технічний контакт і порядок погодження рішень.

З цим набором ми повернемося з оцінкою трудовитрат, схемою випуску за етапами та планом робіт із точками контролю. Для обговорення задачі достатньо описати її у вільній формі — розберемо вузькі місця й домовимося про старт.