Парсинг нових токенів: детектування, аналіз і ризики

Парсинг токенів: де ламається потік даних

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

Мовчазний обрив підписки страшніший за явну помилку — детектування нових токенів просто зупиняється.

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

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

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

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

Що змінює керований збір: швидкість, повнота, стійкість

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

Швидкість детектування: секунди від блоку до запису

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

Повнота реєстру: пропуски рахуються, а не припускаються

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

Стійкість до збоїв: реєстр сходиться після перезапуску

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

Менше ручної перевірки: фільтри замість порядкового розбору

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

Порівняння підходів до парсингу токенів: режими та обмеження

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

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

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

Етапи впровадження: від аудиту джерел до передачі

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

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

Конфігурації, схеми даних і регламенти: що ви отримуєте

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

• Файли конфігурації — адреси вузлів мережі, перелік відстежуваних джерел, ліміти запитів, інтервали опитування. Правляться без перезбирання образу й перезапуску обробки.
• Опис схеми даних — таблиці за токенами, пулами, транзакціями та подіями, зв'язки між ними, індекси. Окремо фіксуємо, чому обрано такий ключ партиціонування і як він впливає на швидкість вибірок.
• Правила фільтрації — пороги ліквідності, мінімальний обсяг торгів, вік пулу, відсікання дублів і контрактів-пасток. У кожного правила коментар: навіщо воно і що зміниться при вимкненні.
• Панель метрик — затримка виявлення нового токена, частка хибних спрацювань, відставання від голови мережі, довжина черги необроблених записів.
• Документація з експлуатації — як підняти сервіс з нуля, як переіндексувати історію за довільний період, як підключити нове джерело без зупинки обробки.
• Регламент під час збою — покрокові дії при відставанні від мережі, недоступності джерела та розбіжності даних з еталонним вузлом, із зазначенням відповідального й часу реакції.
• Набір тестів і записаних подій — на них проганяються правила фільтрації після будь-яких правок, щоб зміни не відкрили потік сміття в базу.

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

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

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

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

На потоці близько 200 тисяч подій на добу частка пропусків сягала 3,2%, запис з'являвся через 40–90 секунд, і черговий інженер звіряв вибірку вручну 6–8 разів на тиждень.

Що змінили

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

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

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

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

Відставання підписника від голови ланцюга винесено в окремий алерт, тож деградація видна до того, як у картках з'явиться прогалина.

Чим детектування токена відрізняється від його аналізу?

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

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

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

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

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

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

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

Детектору потрібен потік подій, аналізу — версіоновані зрізи стану, щоб бачити, як оцінка змінювалася в часі.

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

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

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

Що з даними при перезапуску вузла?

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

Навіщо кілька джерел, якщо одне стабільне?

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

Наскільки дані відстають від реального часу?

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

Що з підтримкою після передачі?

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

Обговоримо задачу: що уточнити перед стартом

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

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

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