Bitcoin Ord індексатор: де ламається синхронізація даних
Bitcoin Ord індексатор перетворює сирі блоки та вміст мемпулу в зрозумілу базу: кому належить напис, скільки токенів на адресі, які баланси Runes актуальні. Поки він іде нарівні з ланцюгом, це непомітний шар, на якому тримається весь продукт.
Перше місце відмови — відставання бази від ланцюга. Блок із щільною видачею написів обробляється довше, ніж мережа видає наступний, і розрив накопичується: синхронізація індексу йде спочатку на хвилини, потім на години. Затримка оновлення даних видна користувачу як застарілий баланс і неправильний статус переказу.
Друге — розбіжність з мережею на перебудовах. При заміні блоків уже записані операції потрібно відкочувати в тому самому порядку, інакше в базі залишаються фантомні активи, яких у ланцюгу немає.
Повторний запуск це не лікує: потрібна перебудова з контрольної точки і звірка цілісності за висотою блоку.
Третє — відмова запитів при сплеску активності. Хвиля мінту нового токена б'є по одних і тих самих таблицях, пул з'єднань закінчується, і частина звернень падає, не дочекавшись відповіді, рівно в момент пікового навантаження.
Ціна однакова в усіх трьох випадках: команда продукту розбирає скарги замість розвитку, а довіра до даних руйнується після першої нестиковки. Далі розбираємо, як це закривається.
Що дає розгортання у своєму контурі
Повний вузол мережі і власна база індексів — це два незалежних шари. Вузол валідує блоки і віддає їх у міру підтвердження, індексатор розбирає вміст — написи Ordinals, операції BRC-20, емісії Runes — і пише результат у власну базу.
Запити йдуть у неї напряму, тому вибірка за адресою, колекцією або тегом відповідає за частки секунди незалежно від того, скільки клієнтів одночасно звертаються до того самого сервісу.
Другий ефект — незалежність від чужих обмежень. Публічні індексатори ріжуть частоту звернень, віддають тільки верхівку історії і в будь-який момент змінюють правила доступу.
Власний контур тримає всю глибину, яку ви задали при первинному завантаженні, і дозволяє переіндексувати дані з потрібної висоти блоку, коли змінюється схема розбору або додається новий тип активу.
Відновлення вкладається в хвилини, а не в добу: база знімається резервною копією, вузол піднімається поруч, відставання добирається з мережі.
Зберігання виноситься на окремі копії лише для читання — аналітичні історичні вибірки більше не конкурують із сервісними запитами за ті самі ресурси.
І останнє — знятий клас відмов за недостовірними даними. Власний вузол перевіряє блоки і коректно проходить реорганізації, тому видача не розходиться зі станом мережі.
Якщо відставання все ж з'явилося, воно видно на метриках: висота блоку в базі проти висоти в мережі і черга нерозібраних блоків.
Порівняння варіантів: публічний оглядач, оренда, власний вузол
Вибір між публічним оглядачем, орендою виділеного вузла і власним вузлом bitcoin впирається не в зручність, а в обмеження індексації.
Публічні сервіси віддають дані за чужим розкладом: ліміти запитів зрізають пакетні вибірки, історія за конкретною адресою приходить неповною, а формат відповідей змінюється без попередження — інтеграція ламається на рівному місці.
Власний вузол і власна база індексів ці обмеження знімають, але вимагають місця під блоки і часу на первинну синхронізацію. Гібрид закриває розрив: локальний кеш гарячих колекцій і адрес поверх оренди або власного вузла.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Публічний оглядач | Прототип, разова перевірка балансів та історії | Ліміти запитів, неповна історія за адресою, зміна формату відповідей без попередження |
| Оренда виділеного вузла | Потрібна власна індексація, але немає бажання тримати залізо і чергувати на синхронізації | Залежність від провайдера, частина налаштувань індексатора недоступна, доступ за підпискою |
| Власний вузол bitcoin + власна база індексів | Продукт з постійним навантаженням і повними даними по Ordinals, BRC-20 і Runes | Зберігання і синхронізація на своїй стороні, потрібен моніторинг і черговий |
| Гібрид з локальним кешем | Висока частка повторних запитів, важлива затримка відгуку | Кеш треба інвалідувати при реоргах, логіка ускладнюється |
Розвилка вирішується за навантаженням і вимогами до повноти даних: пілот витримує публічний оглядач, продукт з історією за кожною адресою — тільки власний вузол і власна база індексів.
Етапи впровадження: від аудиту контуру до передачі в роботу
Розгортання починається не зі встановлення вузла, а з відповідей: який обсяг історії потрібно проіндексувати, чи підтримуємо BRC-20 і Runes в одному контурі, за який час індексатор зобов'язаний відповідати на запит за адресою або номером блоку.
Від цього залежить схема розгортання — один вузол або розділення на архівний і опорний, де фізично лежить індекс і як організовано доступ до гарячих даних.
- Аудит інфраструктури. Дивимося, що вже розгорнуто, чи вистачає дискового запасу під повну історію ланцюга, які ліміти по мережі і як влаштовано резервне копіювання. Результат — перелік вузьких місць і вимоги до ресурсів під потрібний обсяг індексації.
- Проєктування сховища. Індекс розкладаємо на гарячий шар для запитів і холодний для повної історії, задаємо політику ретенції снапшотів. Тоді відновлення після збою займає хвилини, а не добу.
- Розгортання вузла і шару індексації. Піднімаємо вузол у потрібному режимі, синхронізуємо ланцюг, поверх розгортаємо індексатор з обробкою Ordinals, BRC-20 і Runes. Окремо налаштовуємо реакцію на реорганізації, щоб дані не розходилися з ланцюгом.
- Налаштування доступу. Ключі для продуктових сервісів, квоти, обмеження частоти запитів, журналювання звернень. Права читання і службовий доступ розмежовані.
- Перевірка на історичних даних. Проганяємо повну переіндексацію і звіряємо контрольні зрізи: баланси, власників написів, обсяги переказів за токенами. Розбіжність хоча б в одному зрізі — стоп до з'ясування причини.
- Передача та навчання команди. Передаємо схему, регламент оновлення і відновлення, розбір типових збоїв. Ваші інженери виконують штатні операції самі і знають, у яких випадках кличуть нас.
Комплект поставки: конфігурації, схеми, регламенти
Розгорнутий вузол марний, якщо його логіка живе тільки в голові підрядника. Тому поставка закривається не запуском сервісу, а набором артефактів, за якими ваша команда зможе індексувати, оновлювати і відновлювати контур без нашої участі.
- Конфігурації індексатора — значення по кожному вузлу: глибина переіндексації, розміри пакетів запису, ліміти пам'яті, пороги відкату при реорганізаціях, з коментарями, чому вибрано саме таке значення.
- Схема потоків даних — шлях від вузла мережі до сховища і видачі даних зовнішнім споживачам: де інформація буферизується, в яких точках можлива втрата, як система переживає відставання вузла.
- Політики доступу та ролі — адміністративні, сервісні та доступні лише для читання облікові записи, ключі в сховищі секретів, порядок ротації та журнал звернень.
- Схема резервного копіювання — що потрапляє в копії (стан індексу, метадані реєстрів, конфігурації), з якою періодичністю, яка глибина зберігання і як копія перевіряється на відновлюваність.
- Регламент оновлення — порядок викатки нових збірок вузла та індексатора, міграції схеми сховища, точки відкату та умови, за яких оновлення зупиняється.
- Регламент чергування — перелік метрик і оповіщень: відставання індексу, розрив у блоках, помилки запису, недоступність вузла; схема ескалації та вікна планових робіт.
- Документація з відновлення — покрокове підняття контуру з нуля і з резервної копії з контрольними перевірками цілісності реєстрів після кожної операції.
Комплект перевіряємо прогоном: піднімаємо індексатор на чистому стенді за цією ж документацією — регламенти повинні працювати, а не лежати для вигляду.
Кейс: перехід з публічного оглядача на власний контур
Замовник — маркетплейс Ordinals-активів, де баланси, написи і токени BRC-20 / Runes віддавав публічний оглядач.
Його збої ставали нашими: в піки випуску відповіді приходили із затримкою, частина запитів по гаманцях повертала застарілий стан, а розбіжності з власним вузлом мережі сягали 0,3% за адресами з активною торгівлею.
Підтримка розбирала звернення за недостовірними даними вручну — це був не дефект коду, а відсутність контролю над джерелом даних.
Ми розгорнули в контурі замовника вузол мережі і власний індексатор: блоки забираються напряму, стан збирається в реляційну базу з окремими таблицями під написи, перекази токенів і операції Runes.
Перед записом індексатор звіряє висоту і хеш блоку з вузлом, а реорганізації ланцюга відкочуються до останньої підтвердженої контрольної точки — дані не «їдуть» при перебудові гілки.
Що змінилося в цифрах. Частка розбіжностей з мережею — з 0,3% до нуля вимірювань за квартал спостережень. Час повної перебудови бази — з 40 годин до 6, що дозволяє спокійно змінювати схему зберігання.
Відновлення після відмови — з трьох годин очікування чужого сервісу до 12 хвилин: перемикання на репліку і прогрів індексу йдуть автоматично. Звернення в підтримку за недостовірними даними скоротилися на порядок.
Ключова різниця — клас відмов. Раніше збій приходив ззовні і не мав зрозумілого часу усунення. Тепер він локальний, діагностується за журналом індексації і закривається регламентом без втрати підтверджених даних.
Що робити, якщо індексатор уже розгорнуто, але він розходиться з мережею?
Розбіжність майже завжди локалізується до конкретного шару: незбіг за висотою блоку, різниця всередині одного блоку або помилка розбору окремого формату — Ordinals, BRC-20, Runes.
Починаємо з опитування контрольних висот і хешів у двох незалежних джерел: збіглися хеші — мережа ні до чого, копати потрібно в розборі транзакцій або в схемі зберігання.
Далі — звірка з мережею за контрольними точками: перераховуємо агрегати (кількість написів, обороти за токенами, баланси власників) і порівнюємо з незалежним еталоном.
Монотонно зростаюча розбіжність вказує на пропущений при записі блок; стрибок рівно на одній висоті — на необроблений тип транзакції або неправильний відкат ланцюга.
Часткова перебудова індексу закриває більшість випадків: коли втрачається один формат або вузький діапазон висот, скидаємо записи цього діапазону і проходимо його заново, не зупиняючи решту індексу.
Повна перебудова з повторною звіркою потрібна, якщо розбіжність зачепила кілька форматів, або якщо змінюємо схему зберігання — ідемпотентний запис за ключем «висота і позиція в блоці», транзакційні пачки і розділення гарячих та архівних даних.
Профілактика надійніша за ремонт: безперервна звірка з мережею за контрольними точками показує розсинхронізацію індексу протягом хвилин.
Ми виводимо такі перевірки в моніторинг з оповіщенням на відхилення агрегату, тому відкат ланцюга або зміна формату не перетворюються в тижневий аудит.
Питання щодо навантаження, цілісності та відмовостійкості
Індексатор — похідний шар: будь-який стан у ньому відновлюється перерахунком з блоків і не вважається джерелом істини. Тому цілісність даних перевіряється звіркою висоти і хешу останнього обробленого блоку з вузлом, а розбіжність лікується повторною обробкою діапазону. Ця ж властивість дозволяє відкотити індекси до будь-якої збереженої точки без втрати накопиченого.
Навантаження на читання і запис розділені: важкі вибірки по колекціях, балансах токенів і подіях Runes йдуть на репліки, поки основний процес пише нові блоки.
Обмеження доступу за ролями — читання, запис, адміністрування — задається на рівні запитів, а не тільки на периметрі мережі.
Що відбувається при перебудові ланцюга?
Перебудова відстежується за батьківським хешем нового блоку. Якщо він не збігається з останнім обробленим, індексатор скасовує записи на глибину розбіжності і проганяє блоки канонічної гілки заново — стан залишається детермінованим, а не «приблизно вірним».
Який вузол потрібен для роботи?
Повноцінний вузол з повним набором блоків; підключення до перевіреного провайдера тримаємо як резервний канал. Вузол зобов'язаний віддавати блоки і транзакції без пропусків — інакше перерахунок дасть діри і індекс доведеться піднімати зі збереженої точки.
Як оновлюватися без простою?
Нова версія піднімається поруч на окремій копії індексу, доганяє поточну висоту і перемикає трафік тільки після звірки контрольних сум. Відкат — повернення трафіку на попередню версію, база при цьому залишається недоторканою.
Обговоримо задачу і повернемося з оцінкою та планом
Щоб оцінка проєкту спиралася на реальні навантаження, а не на середні числа, потрібен короткий вхід з вашого боку.
Опишіть сценарії запитів, вимоги до свіжості даних і поточний контур — цього достатньо, щоб порахувати обсяги індексації, вибрати профіль вузла і повернутися з планом.
- Сценарії запитів — які вибірки обслуговує bitcoin ord індексатор: баланси адрес, історія BRC-20, інскрипції колекцій, стан Runes.
- Вимоги до свіжості — допустиме відставання від вершини ланцюга, поведінка при реорзі, чи потрібна повторна обробка блоків.
- Схема поточного контуру — де розміщені біткоїн-нода і сховище, які доступи є, чи є працюючий індексатор під перенесення.
- Обсяги та глибина розбору — з якого блоку починати, чи потрібна повна історія інскрипцій або вікно спостереження.
- Споживачі даних — хто і як часто запитує індекс, в якому вигляді потрібна відповідь, який простій допустимий.
- Обмеження щодо доступів — кому належать домен, сертифікати і секрети, який рівень доступу готові видати команді.
У відповідь ви отримуєте оцінку проєкту за етапами, план робіт із залежностями, схему розгортання і склад поставки: репозиторій, міграції, конфігурації, панелі моніторингу та документацію. Опишіть задачу — повернемося з оцінкою та планом.
