Розробка gas tracker під ключ: система моніторингу газу для EVM-мереж

Чому gas tracker бреше: вузькі місця моніторингу газу

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

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

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

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

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

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

Точність оцінки газу перестає бути константою із запасом.

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

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

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

Разом із цим падає частка відхилених транзакцій.

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

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

Стійкість сервісу — наслідок схеми, а не обіцянка. Кілька незалежних RPC-джерел, контроль відставання вузла, буферизація оповіщень у разі недоступності каналу та повторна доставка без втрати подій.

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

Способи збору даних про газ: порівняння підходів

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

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

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

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

Етапи розробки: від аудиту джерел до передачі

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

Тому етапи впровадження йдуть від аудиту джерел до передачі системи, і кожен етап закінчується перевірюваним артефактом.

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

   Розбіжність в одиниці відсотків означає різні методики усереднення — фіксуємо одну, інакше оповіщення почнуть суперечити одне одному.

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

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

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

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

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

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

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

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

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

До: ручна звірка

Команда, яка вела розрахунки газу для гаманця з кількома тисячами активних користувачів, тримала вартість вручну: черговий раз на 15 хвилин звіряв базову ставку в публічному оглядачі Etherscan і правив надбавку в налаштуваннях.

Поки мережа була спокійною, схема трималася, а на сплесках транзакції зависали в очікуванні по 20-40 хвилин.

Прогноз розходився з фактичною ефективною ціною більш ніж на 20% приблизно в кожному восьмому відправленні, а 6-9 транзакцій за добу падали через недостатню надбавку. Користувач бачив «відправлено», потім «застрягло», потім платив повторно.

Після: автоматичний збір

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

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

Частка відправлень із розбіжністю вище 20% упала до однієї із шістдесяти, затримка оновлення прогнозу — з 15 хвилин до 3-5 секунд, частка невдалих відправлень — з 7% до 0,4%.

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

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

Чим gas tracker відрізняється від оглядача блоків?

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

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

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

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

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

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

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

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

Часті технічні питання про моніторинг газу

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

Як підключається нова мережа?

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

Що робити з уже розгорнутим збором метрик?

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

Що якщо вузол-джерело недоступний?

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

Чи потрібен доступ до гаманців?

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

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

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

Що надіслати, щоб оцінка була предметною:

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

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