Чому парсинг блокчейн-експлорерів стає вузьким місцем
Коли індекс транзакцій будується поверх публічних блокчейн-експлорерів на кшталт Etherscan, усе впирається в чужі правила гри.
Парсинг блокчейн-експлорерів тримається на лімітах запитів до зовнішніх сервісів: добові квоти, вікна за частотою звернень, обов'язкова посторінкова вибірка за курсором.
На довгих діапазонах це дає рвану історію блоків — обхід обривається на середині, а повтор із того самого курсора повертає вже інший зріз даних.
Друга біда — неповні дані транзакцій. Зовнішній сервіс може не віддати внутрішні перекази, події контрактів або статус фінальності, а частина адрес позначається як виконуваний код лише за фактом його появи в мережі.
У підсумку один і той самий блок у двох джерел описується по-різному: суми сходяться, а склад операцій — ні. Час команди йде не на аналітику, а на ручні звірки та розбір розбіжностей.
Далі вмикається вузьке місце індексації: поки дані довантажуються, звіти, повідомлення та баланси гаманців показують учорашній стан. Один пропущений блок тягнеться через весь ланцюжок залежних розрахунків і спливає вже в клієнта — у вивантаженні, звірці чи рішенні щодо ризику.
Ми проходили цей шлях: починали зі збору вибірок через публічні інтерфейси й упиралися рівно в ті самі стелі. Розбираємо, як це закривається і де закінчується зовнішній сервіс, а починається контур, який ви контролюєте самі.
Що дає керований конвеєр розбору блокчейн-даних
Через публічні експлорери дані йдуть нерівномірно: темп збору задає не наш конвеєр, а зовнішній ліміт запитів. Варто перевищити поріг — частина запитів повертається з відмовою, і якщо обробник не веде журнал діапазонів, ці блоки випадають із реєстру.
Помилка викривається не одразу, а на звірці балансів через тижні, коли відновити пропуск дорожче, ніж зібрати дані заново.
Власна нода знімає цей клас відмов. Ми читаємо блоки напряму з журналу подій і тримаємо вказівник на останній оброблений блок, тому ліміти зовнішнього постачальника перестають задавати темп. Збір іде безперервно: черга наповнюється з ноди, а не з відповідей чужого сервісу. Etherscan і подібні експлорери залишаються корисними для вибіркової перевірки транзакцій.
Цілісність реєстру тримається на ідемпотентному записі: ключ запису — хеш транзакції та індекс події, тому повторна обробка діапазону не створює дублів.
Журнал прогонів зберігає межі кожного діапазону та його статус, тож будь-яку ділянку можна переграти точково, не перезапускаючи конвеєр повністю.
Ефект вимірюваний на трьох метриках: час збору історичного періоду, частка втрачених записів і кількість відмов через ліміти. Перша падає в рази завдяки паралельному читанню, друга прямує до нуля — пропуск видно за журналом, а не за розбіжністю підсумків. Звірка адрес і балансів перестає бути разовим аудитом і йде за розкладом.
Способи збору даних: публічний інтерфейс, власна нода, архів
Вибір способу доступу визначає не лише швидкість розробки, а й те, які питання до даних узагалі можна поставити. Публічний програмний інтерфейс провайдера закриває типові сценарії за лічені дні, але ставить у залежність від чужих лімітів і складу методів.
Власна нода дає контроль над запитами та історією, зате потребує ресурсів на синхронізацію й супровід.
Ключова розвилка — чи потрібна глибина історії. Свіжі блоки та поточні баланси віддає майже будь-яке джерело, а стан на довільній висоті минулого доступний лише там, де зберігається архів блоків: звичайний вузол обрізає старі стани, і частина запитів просто не виконується.
Тому джерела частіше комбінують: публічний інтерфейс — для оперативних завдань, архів — для аналітики та звірки.
| Спосіб | Коли підходить | Обмеження |
|---|---|---|
| Публічний програмний інтерфейс провайдера | Перші версії продукту, гаманцеві сценарії, відстеження свіжих транзакцій | Ліміти запитів, неповна історія, склад методів і глибина змінюються за рішенням провайдера |
| Потокові підписки провайдера | Моніторинг подій у реальному часі та реакція на них | Минуле недоступне, розрив з'єднання потрібно наздоганяти окремим проходом по історії |
| Власна нода | Незалежність від чужих лімітів, власні правила індексації | Тривала первинна синхронізація, зростаючий обсяг сховища, постійний супровід |
| Архів блоків на власній ноді | Аналітика, аудит, запити стану на будь-яку висоту | Сховище зростає помітно швидше за звичайний вузол, вищі вимоги до обладнання |
| Власний шар агрегації поверх архіву | Складні вибірки, звіти та метрики за власними правилами | Потрібна підтримка силами команди, розбіжності з даними сторонніх джерел доводиться звіряти |
Обмеження провайдерів варто перевіряти до старту: які методи доступні, якою є глибина історії, як сервіс поводиться під піковим навантаженням і чи попереджає про зміни. Ми фіксуємо це у схемі джерел — щоб перехід на власну ноду був плановим кроком, а не аварійним.
Етапи впровадження: від аудиту завдань до передачі в підтримку
Порядок робіт однаковий і для однієї мережі, і для мультимережевого контуру: спочатку фіксуємо, що саме потрібно читати з ланцюга, потім описуємо потоки й лише після цього розгортаємо інфраструктуру.
Так виключаємо ситуацію, коли вузол уже піднято й синхронізовано, а дані не сходяться з експлорером.
- Аудит джерел даних. Які мережі, контракти й типи подій потрібні, що віддає публічний API, де є ліміти на частоту запитів і якою є доступна глибина історії. На виході — перелік джерел з їхніми обмеженнями.
- Схема потоків. Розділяємо, що читаємо напряму з вузла, а що з API, де стоїть проміжне сховище і як обробляється перебудова ланцюга. Схему узгоджуємо до початку розробки.
- Розгортання й налаштування. Піднімаємо повний або архівний вузол, налаштовуємо індексацію, черги та повторні спроби при збоях. Запис робимо ідемпотентним, щоб повторний прохід не дублював події.
- Перевірка звіркою. Порівнюємо вивантаження з еталоном — експлорером або другим незалежним джерелом, звіряємо контрольні суми за блоками та підсумкові баланси. Будь-яку розбіжність розбираємо до запуску.
- Навантаження та відмовостійкість. Прогоняємо на історичній глибині, перевіряємо поведінку при недоступності вузла й відновлення після обриву, фіксуємо час догону після простою.
- Передача в експлуатацію. Віддаємо регламенти, панель моніторингу з оповіщеннями про відставання, інструкції для чергового й навчання команди. Далі — гарантійний супровід: доналаштовуємо граничні випадки та залишаємося на зв'язку.
Схеми, політики доступу та регламенти: що залишається в контурі
Контур парсингу цінний не тим, що працює сьогодні, а тим, що його можна відтворити й полагодити чужими руками. Тому в передачу входять не лише сервіси, а й артефакти: конфігурації, схеми та правила, за якими система живе після запуску.
- Карта джерел — які дані звідки беруться: публічні інтерфейси експлорерів, власні вузли, резервні провайдери, і чим що підміняється при відмові.
- Схеми потоків — шлях події від блоку до сховища й вітрин: де нормалізація, де дедуплікація, де повтори запитів, де може втратитися порядок.
- Конфігурації вузла — мережі, глибина зберігання, ліміти з'єднань, режим індексації та пояснення, що змінюється при зростанні навантаження.
- Політики доступу — ролі сервісів, ключі, мережеві правила, права на читання й запис, окремо порядок відкликання доступів.
- Регламент реакції на збої — таблиця «симптом → перевірка → дія»: відставання індексації, розрив у ланцюжку, недоступність провайдера, розбіжність даних.
- Метрики та пороги — які сигнали вважаються нормою, які аварійними, кому й куди надходить оповіщення.
- Інструкції з експлуатації — як розгорнути контур з нуля, як переіндексувати ділянку історії, як підключити нову мережу.
З цим набором команда замовника додає мережу або змінює провайдера за інструкцією, не розбираючи архітектуру заново.
Кейс: прибрали простої та прискорили звірку даних у рази
Замовник — сервіс аналітики по мережі Ethereum — збирав історію через публічні інтерфейси експлорерів, тобто звичайний парсинг блокчейн-експлорерів.
На піках навантаження запити впиралися в ліміти, при перебудові ланцюжка частина блоків губилася, і в базі з'являлися розриви та дублі. Частка втрачених записів сягала 6–7%, а розбіжності з мережею знаходили лише вручну — приблизно 30 звірок на місяць, кожна на вивантаженнях.
Зібрали власний конвеєр: власна нода як джерело, потік блоків і подій, запис за ключем «висота блока + адреса події» — тому повторна обробка діапазону не створює дублів.
При перебудові ланцюжка діапазон перечитується автоматично, збійні запити йдуть на повтор із наростаючою паузою, а відставання від голови ланцюжка видно на графіку й піднімає оповіщення до того, як дані почнуть розходитися.
Додали автоматичну звірку: контрольні суми за діапазонами зіставляються з незалежним джерелом, розбіжності розкладаються за типами — пропуск, дубль, неправильне поле.
Ручних звірок стало 1–2 на місяць замість 30, і кожна займає хвилини: інженер дивиться звіт про розбіжності, а не порівнює сирі вивантаження.
Повний прохід історії скоротився з 14 годин до 40 хвилин завдяки паралельній обробці діапазонів і локальному читанню замість зовнішніх запитів. Пішов цілий клас відмов: втрати через ліміти публічних інтерфейсів і «дірки» після перебудови мережі.
На живому потоці частка втрачених записів тримається на нулі, а щоденне вивантаження сходиться з мережею без ручного втручання.
Чим публічний інтерфейс відрізняється від власної ноди
Публічний інтерфейс — це чужа інфраструктура: хтось інший тримає копію ланцюжка й віддає вам дані за запитом. Власна нода — та сама копія стану, але у вас, і ви самі вирішуєте, що і в якому обсязі індексувати.
Різниця проявляється в трьох місцях: глибина доступної історії, поведінка потоку під навантаженням і те, де рветься зв'язок при збої.
За глибиною публічні шлюзи майже завжди віддають лише недавнє вікно блоків і подій — глибокі запити відхиляються або обрізаються за діапазоном.
Архівний вузол у вас зберігає історію з першого блока, тому перерахунок метрик за минулі періоди й відновлення пропущених подій не впирається в чуже обмеження. Саме це визначає, чи можна добудувати індекс заднім числом або дані доведеться збирати лише вперед.
Під навантаженням публічний інтерфейс вводить ліміти на частоту звернень, відповідає зі змінною затримкою та різною якістю в різних операторів шлюзу.
Власна нода обмежена диском і мережею, а не чужим лімітом: паралелізм запитів, розмір пакета й глибину кешу ви задаєте самі й бачите, у що впираєтеся.
Публічний шлюз — зовнішня точка відмови: зміна умов, переіндексація на чужій стороні або деградація вузла зупиняють збір без вашої участі.
Власна нода переносить відповідальність усередину: потрібні контроль відставання від голови ланцюжка, обробка реорганізацій та ідемпотентний запис, щоб повторний прохід не задвоював події.
Вибір зазвичай не бінарний: публічний інтерфейс закриває розвідку та разові завдання, власна нода — регулярний збір з повною історією.
Що уточнюють перед стартом: ліміти, історія, відмови
Перш ніж будувати схему розбору, інженери фіксують межі доступних даних: які зовнішні сервіси віддають історію, за яким лімітом запитів, доки вона сягає назад і наскільки повна.
Без цієї інвентаризації конвеєр наповнюється до першого впирання в ліміт або виявляє провал у глибині вже на етапі аналітики. Нижче — сумніви, які найчастіше спливають на цьому кроці.
Зовнішній сервіс змінює ліміти або закриває доступ — що тоді?
Ліміти зовнішніх сервісів не константа: їх знижують, вводять платні рівні, іноді вимикають старі методи. Тому доступ інкапсулюється в окремий шар адаптерів — зміна джерела або ліміту не зачіпає логіку обробки. Плюс ми завжди закладаємо власне джерело даних як резервний шлях.
Доступної глибини історії не вистачить для наших завдань?
Публічні інтерфейси зазвичай віддають не весь ланцюжок, а вікно від кількох місяців до пари років. Якщо потрібні раніші стани, піднімаємо власну ноду й вичитуємо блоки послідовно або добираємо відсутній відрізок з архівних джерел. Рішення ухвалюється за конкретним горизонтом, а не «про всяк випадок».
Як переконатися, що дані повні та без пропусків?
Перевірка повноти будується на звірці: безперервність номерів блоків, збіг контрольних сум за вибіркою, сходження агрегатів з незалежним джерелом. Розбіжності логуються окремо, а не розчиняються в загальному потоці — так пропуск видно одразу, а не через місяць у звіті.
Чи можна почати з малого й розширюватися?
Так, і це правильний порядок. Спочатку один контракт або один тип подій, налагодження на ньому, потім поетапне розширення охоплення — нові мережі, токени, історичні періоди.
Кожен крок додається без переписування попереднього, тому обсяг зберігання зростає передбачувано й залишається під контролем.
Обговоримо завдання: що потрібно від вас для оцінки та плану
Щоб повернутися з оцінкою та планом, нам потрібен не загальний задум, а вхідні дані щодо даних та інфраструктури. Нижче — чекліст: якщо частина пунктів поки не визначена, зафіксуємо припущення й уточнимо їх на етапі проєктування, а не в середині робіт.
- Які мережі та сутності потрібні: транзакції, перекази токенів, внутрішні виклики, події контрактів, баланси — і в якому вигляді віддавати їх назовні.
- Звідки беремо дані: публічні API експлорерів, провайдери з готовою індексацією або власна нода з повним архівом.
- Обсяги та частота оновлення: глибина історії, потік нових блоків, допустиме запізнення й вікно перерахунку.
- Схема зберігання та вибірок: де зберігаємо, хто читає, за якими ключами будуємо запити, який обсяг тримаємо гарячим.
- Доступи та ролі: ключі до API, облікові дані нод, права на запис у сховище, хто з вашого боку підтверджує зміни.
- Правила достовірності: як звіряємо пропуски та розбіжності при реорганізаціях ланцюжка, що вважаємо еталонним джерелом.
- Режим видачі: разовий зріз, постійний потік або регулярні перерахунки; чи потрібен повторний програш і відкат.
Опишіть завдання у вільній формі та додайте те, що вже є, — обговоримо варіанти рішення. Далі повернемося з оцінкою та планом робіт: етапи, терміни, склад перевірок і точки, де потрібне ваше підтвердження.
