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