Разработка 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 — инструмент решения о цене. Первый показывает, что стало; второй — сколько будет стоить операция и когда её выгодно отправить.

Частые технические вопросы о мониторинге газа

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

Как подключается новая сеть?

Сеть описывается конфигурацией: идентификатор цепочки, адреса узлов, схема расчёта комиссии. Добавление проверяем на исторических блоках — правок ядра не требуется.

Что делать с уже развёрнутым сбором метрик?

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

Что если узел-источник недоступен?

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

Нужен ли доступ к кошелькам?

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

Обсудим задачу: какие данные прислать для оценки

Оценка проекта газового трекера упирается не в объём кода, а в ясность текущей картины: где сервис уже собирает данные о газе, а где метрика живёт в голове дежурного. Чем точнее вводные, тем меньше допущений в плане работ и тем быстрее мы назовём сроки и состав этапов.

Что прислать, чтобы оценка была предметной:

• Перечень сетей и их роли: основная сеть, тестовые контуры, сети второго уровня — где мониторинг газа нужен, а где сейчас не покрыт.
• Источники данных о газе сегодня: собственный узел, публичные точки доступа или внешний сервис — и какой из них считается источником истины при расхождении.
• Текущий сбор метрик: что уже пишется — базовая ставка, приоритетная надбавка, заполнение блока, число транзакций — в каком виде хранится и как глубоко доступна история.
• Критичные расхождения: какие случаи вы считаете сбоем — пропущенный пик, расхождение между источником и подтверждением в сети, задержка оповещения на несколько блоков.
• Внутренний контур: куда должны уходить оповещения (панель мониторинга, система инцидентов, чат), кто получатель и какое действие ожидается после срабатывания.
• Объёмы и частота: сколько транзакций в сутки идёт через сервис, нужен ли разбор истории или достаточно скользящего окна последних блоков.
• Ограничения доступов: допустимый контур развертывания, закрытые сегменты, требования к хранению ключей и журналов.
• Существующие наработки: собственные скрипты, правила оповещений, схемы данных — чтобы не переписывать то, что уже работает.

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