Бот моніторингу мемпулу: де губляться транзакції і чому
Мемпул Ethereum — це не один спільний список очікуваних транзакцій, а безліч локальних черг: кожен вузол тримає свій пул з обмеженим розміром і власними правилами відбору.
При переповненні черги транзакцій вузол витісняє найслабші записи, тому бот моніторингу мемпулу, підключений до одного вузла, бачить лише його зріз подій.
Витіснення за комісією виглядає так: щойно пул заповнено, під тиском дорожчих транзакцій старий запис зникає з черги, так і не потрапивши в блок. Формально вона не відхилена — вона просто зникла з потоку.
Якщо бот спирається лише на появу хешу в підписці й не перевіряє підсумковий статус, транзакція залишається в обліку як відправлена, а пов'язана заявка зависає.
Друге джерело втрат — розрив підписки на потік. З'єднання з вузлом рветься під час його перезапуску, мережевих збоїв або зміни точки доступу, і події з моменту обриву губляться мовчки: підписка відновлюється з поточного моменту.
Зовні все працює, помилок у логах немає, але пропущені транзакції накопичуються, і розбіжність спливає пізніше, коли відновити потік уже неможливо.
У L2 картина складніша: своя черга приймання, свої пороги комісії та своя затримка до включення в блок, тому одна й та сама транзакція поводиться в мемпулі Ethereum і в L2 по-різному.
Далі розбираємо, як це закривається — що перевіряти, як переживати обриви і як відрізнити загублену транзакцію від просто повільної.
Що дає безперервне спостереження за чергою транзакцій
Подія в черзі транзакцій живе миті: поки обробник прокидається за розкладом, можливість уже втрачено.
Безперервне спостереження за чергою транзакцій переводить затримку реакції на подію з десятків секунд у десяті частки — сигнал іде в момент появи транзакції, а не на наступному циклі опитування.
Частка пропущених подій проявляється лише на безперервному потоці. Під час опитування з паузами частина транзакцій не потрапляє до жодного знімка, і такі втрати не видно в логах: про них просто нічого записати.
Подієвий прийом із підтвердженням обробки та повторною доставкою утримує частку пропусків на нулі — кожен збій доставки фіксується й розбирається.
Час відновлення після збою вимірюється не запуском процесу, а поверненням до повноти даних. Автоматичне перепідключення до вузла, добір пропущених блоків від контрольної точки та звірка стану скорочують цей шлях до десятків секунд — замість годин сліпого ручного розбору.
Окремий ефект — знятий клас відмов. Йдеться не про «бот упав», а про сервіс, який працює й мовчить: подія пройшла, сигналу немає.
Дедуплікація, ідемпотентна обробка та коректний відкат стану при перебудові ланцюга прибирають цей клас цілком: пропуск стає видимим інцидентом, а не тихою втратою.
Додається керованість: метрики черги, відставання обробки, лічильник повторів і поріг оповіщення показують, що спостереження живе, до того як це з'ясується за пропущеною подією.
На виході — затримка реакції в частки секунди, частка пропусків практично на нулі, відновлення за хвилину та відсутність класу «пропущена подія». Кожен пункт перевіряється на графіку, а не на словах.
Моніторинг мемпулу: режими роботи та їх обмеження
Моніторинг мемпулу починається з вибору режиму спостереження за потоком: саме він визначає, що бот взагалі здатен побачити, і це обмеження первинне щодо будь-якої логіки фільтрації.
Транзакція стає видимою вузлу в момент розсилки по мережі, але потрапляння в потік не гарантує ні включення в блок, ні збереження порядку — частина транзакцій замінюється за ціною, частина відкидається при перебудові ланцюга.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Повна підписка на потік | Потрібні всі події до включення в блок, включно з невдалими | Потребує власного вузла із запасом по диску й каналу; у потоці дублі та шум, фільтрація лягає на бота |
| Вибіркове відстеження адрес | Цікавить обмежений набір гаманців і контрактів | Вузол віддає лише збіги — контекст навколо угоди не видно; при зміні адрес правила перезбираються |
| Опитування за розкладом | Рідкісні перевірки, немає вимог до затримки | Між опитуваннями події губляться, сплески активності пропускаються цілком |
| Спостереження за підтвердженими блоками | Потрібна достовірність і звітність, а не швидкість | Дані надходять із затримкою в кілька блоків, реакція на подію неможлива |
Режими не взаємовиключні: типовий контур поєднує повну підписку для раннього сигналу й підтверджені блоки як джерело істини, а вибіркове відстеження адрес знижує навантаження, коли адрес небагато.
Часта помилка — вважати потік гарантованим: без обробки перебудов ланцюга та заміни транзакцій бот показує події, яких в підсумковій історії не буде. Тому обмеження режиму фіксуємо в описі контуру заздалегідь, а не після першої розбіжності цифр.
Як ми впроваджуємо бота: етапи інженерної роботи
Роботи йдуть за етапами — від аудиту потоку до передачі керування. Кожен крок закривається артефактом, який можна перевірити до запуску в роботу.
- Аудит потоку та вузла. Обираємо джерело подій — своя нода або зовнішній провайдер, рівні підтвердження, спосіб підписки на блоки й транзакції. Вимірюємо пікову інтенсивність і частку шуму: від цього залежать пороги, ліміти та потреба в резервному джерелі.
- Схема обробки подій. Фіксуємо маршрут транзакції: прийом, розбір, нормалізація полів, відсів дублів, черга, обробник, повідомлення. Гарячий шлях відокремлюємо від аналітики, щоб затримки не накопичувалися на сплесках.
- Налаштування фільтрів. Збираємо правила за адресами, контрактами, методами виклику, порогом газу та типом операції. Для L2 — окремий набір: там порядок подій і підтвердження відрізняються від основної мережі. Кожне спрацювання пишемо в журнал із причиною, щоб правило можна було пояснити й вимкнути без правки коду.
- Навантажувальна перевірка. Проганяємо піковий потік і обрив з'єднання, дивимося, чи наздоганяє бот пропущене, чи немає дублів і втрат, як поводиться черга. Окремо перевіряємо перемикання на резервне джерело.
- Розбір хибних спрацювань. На реальній вибірці правимо пороги й ваги, прибираючи шум без втрати значущих подій. Фіксуємо визначення хибного спрацювання, щоб метрика була однозначною.
- Приймання та передача. Здаємо за описаними заздалегідь перевірками, віддаємо конфігурації, схему обробки, інструкцію з експлуатації та порядок відкату. Далі — регламент: як змінювати фільтри, оновлювати список адрес і що дивитися в моніторингу.
Конфігурації, схеми та регламенти, які залишаються у вас
Ми передаємо не доступ до сервера, а комплект, за яким бот піднімається, переналаштовується й супроводжується без нас. Конфігурації, схеми та регламенти лежать у вашому репозиторії: інженер, який раніше бота не бачив, розбирається за ними за одну зміну чергування.
- Файли конфігурації бота. Окремі профілі під основну мережу та потрібні L2: адреси вузлів, пороги розміру й комісії, списки відстежуваних адрес і пулів. Правки — через змінні середовища, без зміни коду.
- Схема потоків даних. Шлях події від підписки на нові транзакції та блоки до фільтрації й надсилання оповіщення: де буфер, де повтори, як наздоганяється інтервал після розриву зв'язку з вузлом.
- Правила відбору подій. Матриця умов: що потрапляє в оповіщення, а що гаситься як шум — обміни в конкретних пулах, зняття ліквідності, незвичні виклики контрактів, пороги під ваші задачі.
- Карта точок відмови. Де бот втрачає події: розрив потоку, реорганізація ланцюга, переповнення черги, недоступність каналу оповіщень. Для кожної точки — ознака та дія чергового.
- Оповіщення. Шаблони повідомлень і маршрути в месенджер або внутрішню шину, розподіл за критичністю — уночі надходять лише значущі події.
- Документація та регламенти. Розгортання й оновлення, порядок чергування, чек-лист під час інциденту та відкат на попередню конфігурацію.
- Панель метрик. Затримка обробки події, частка відкинутого шуму, кількість пропущених інтервалів — деградація видна до того, як стане проблемою.
Кейс: частка пропущених подій знизилася в рази
До впровадження бот опитував вузол за таймером раз на кілька секунд: за цей час частина транзакцій встигала потрапити в блок, і події губилися. Черговий дізнавався про них із логів уже постфактум, а розбіжність балансів розбирали вручну.
На кожен інцидент ішло до півгодини звірок за адресами й нонсами — при потоці в сотні транзакцій за хвилину такі перевірки з'їдали зміну цілком.
Що змінили
Збір перевели з опитування на підписку до потоку вхідних транзакцій мемпулу Ethereum, підключили кілька незалежних вузлів-джерел і зшили їх із дедуплікацією за хешем. Фільтр розбирає дані за адресами, контрактами та викликами методів, а не жене все в обробник.
Окремо закрили повторну обробку при перебудові ланцюга — раніше саме на цьому губилися й дублювалися події. Оповіщення йде одразу в месенджер чергового та в чергу сервісу, у кожної події є посилання на транзакцію та статус підтверджень.
Що стало
Замір на тому самому потоці: частка пропущених подій знизилася з кількох відсотків до часток відсотка, час від появи транзакції в мемпулі до оповіщення скоротився з десятків секунд до однієї-двох, ручні перевірки — приблизно в десять разів.
Логи, метрики та оповіщення про недоступність вузла зібрані в одному місці: якщо джерело відстало або відвалилося, це видно до того, як подія загубиться. Той самий контур працює й для L2 — змінюється лише набір джерел.
Потік транзакцій чи підтверджені блоки: що вибрати?
Коротка відповідь: це не альтернативи, а два різних шари даних. Потік транзакцій дає раннє оповіщення ще до включення в блок, підтверджені блоки — стійкість до перебудови ланцюга.
Бот, який слухає лише мемпул Ethereum, реагує швидше, але регулярно ловить події, яких немає у фінальній історії.
Ціна раннього сигналу — шум. Транзакція з мемпулу може бути витіснена, замінена версією з більшою комісією або не потрапити в блок; при перебудові ланцюга побачена подія зникає з канонічної гілки. Якщо бот виконує дію одразу, кожна розбіжність дає відкат або дублікат.
Опора лише на блоки знімає проблему, але додає затримку: до потрібної глибини підтверджень проходить кілька блоків. Тому в робочій схемі обидва канали живуть разом і розрізняються роллю: потік — сигнал, блок — істина.
На практиці це подвійне підтвердження події. Первинний сигнал ставить подію в чергу й запускає підготовку, а дія виконується, коли та сама транзакція знайдена в блоці на заданій глибині.
Ключ дедуплікації за хешем, буфер останніх блоків і перегравання при перебудові не дають одній події спрацювати двічі.
Окрема розвилка — вибір джерела даних: своя нода дає повний потік і свої фільтри, але потребує супроводу; сторонній провайдер знімає навантаження, але обмежує частоту запитів і глибину історії. Для L2 перевірку глибини налаштовують окремо — дані секвенсора й моста підтверджуються інакше.
Сумніви та обмеження: що перевірити до старту робіт
Перед стартом варто розвести два різних питання: як бот поводиться під навантаженням і що відбувається, коли він помиляється. Потік вхідних транзакцій у публічній мережі Ethereum — це десятки тисяч подій за секунду, і підписка «на все» навантажує вузол сильніше, ніж сам бот.
Тому відбір іде на боці вузла — за адресами й сигнатурами методів, а не перебором у застосунку, і під спостереження виділяється окремий вузол, а не спільний з іншими сервісами.
Другий клас ризиків — пропуски та шум. Розрив зв'язку, перезапуск або відставання вузла дають «сліпе вікно», тому позначка останнього обробленого блока й захист від повторів зберігаються на диску: після рестарту бот наздоганяє пропущене, а не починає з чистого аркуша.
Хибні спрацювання дають скасовані та замінені транзакції й перебудови ланцюга — їх відсікають за кількістю підтверджень і повторною перевіркою стану.
Наскільки це навантажить наш вузол?
Відбір виконується на боці вузла, зайві підписки не відкриваються, а відставання винесено в метрики моніторингу. При перевантаженні бот пригальмовує потік, а не накопичує чергу в пам'ять.
Що буде після перезапуску або падіння?
Стан лежить на диску, тому після рестарту бот наздоганяє пропущені блоки й продовжує з тієї самої точки. Повідомлення ідемпотентні — повторний алерт за тією самою транзакцією не надходить.
Як відсікаються хибні спрацювання?
Перевіряємо не факт появи в потоці, а підсумковий стан: замінені транзакції, скасування та перебудови ланцюга відкидаються. Поріг підтверджень налаштовується під вашу задачу — від миттєвої реакції до захищеної від відкатів.
Які обмеження залишаються принципово?
У мережах другого рівня потік формує секвенсор, і частина транзакцій до включення в блок просто не видна. Ми фіксуємо це в документації, щоб не обіцяти сигнал раніше, ніж він фізично можливий.
Що з підтримкою після передачі?
Передаємо вихідні коди, конфігурації, схему розгортання та порядок дій при збоях, проводимо навчання вашої команди. Далі — узгоджений період супроводу з регламентом реакції.
Обговоримо задачу та повернемося з оцінкою й планом
Щоб обговорити задачу предметно, потрібні ввідні щодо інфраструктури: які вузли вже піднято, хто тримає до них доступи, чи слухаєте ви мемпул основної мережі та L2, чи потрібен розбір приватних потоків транзакцій. Від цього залежить, де ставиться підписка на мемпул і який потік подій витримає контур без втрат.
Надішліть те, що є під рукою — решту уточнимо на дзвінку.
- Схема інфраструктури: власні вузли або провайдер, чи є архівний вузол, хто володіє ключами й доступами.
- Перелік мереж і L2 у контурі та пріоритет за ними: що слухаємо першим, а що пізніше.
- Що вважаємо цільовою подією: нові транзакції, заміна за комісією, великі перекази, звернення до контракту — з порогами спрацювання.
- Канали доставки повідомлень і припустима затримка: месенджер, HTTP-повідомлення, запис у базу, дашборд.
- Очікуване навантаження: середня кількість подій за хвилину, пікові сплески, глибина зберігання історії.
- Вимоги до стійкості: перепідключення при обриві, обробка реорганізацій ланцюга, журнал пропущених подій.
- Хто з боку замовника приймає результат і за якими метриками вважаємо роботу виконаною.
Повертаємося з оцінкою та планом робіт: етапи, склад команди під кожен етап, терміни й точки приймання. Порядок старту узгодимо після того, як зійдемося за схемою подій і навантаженням.
