Сканирование мемпула 101: фильтры, задержка и…

Краткий ответ — сканирование мемпула в 2026 году сводится к двум отдельным задачам: получить чистый сигнал (подписка с низкой задержкой + фильтры, не убивающие полноту охвата) и успеть отреагировать в доступном окне (симуляция + подпись + отправка достаточно быстро, чтобы попасть в блок раньше следующего поисковика). Большинство операторов перенастраивают фильтры и недонастраивают цикл действий — это неверное направление: хорошо отфильтрованный поток, который вы обрабатываете медленно, — это просто другой вид бесполезности. Рабочая схема: подписаться на хорошо связанный узел (eth_subscribe('newPendingTransactions') в цепочках с общедоступным мемпулом, WSS-канал секвенсора в Arbitrum, gossip-протокол op-node в цепочках OP Stack); применить минимальные фильтры (белый список пулов, минимальный порог суммы, белый список роутеров); профилировать каждый этап своего цикла, пока не станет понятно, куда уходят миллисекунды. Затем итерировать именно тот этап, который оказался худшим нарушителем — и почти никогда это не набор фильтров.

Путь к мастерству

• Что такое MEV?
• Бэкраннинг против сэндвич-стратегии
• Вероятность включения 101
• Руководство по исправлению неудачных пакетов
• Сканирование мемпула 101 (текущее)

«Сканирование мемпула» не означает одно и то же в каждой цепочке

Этот термин заимствован из основной сети Ethereum, где существует буквально уровень одноранговой трансляции. В других цепочках механизм другой и термин неряшливый:

• Ethereum, BSC, Polygon, Avalanche и т. д. — настоящий публичный мемпул. eth_subscribe('newPendingTransactions') на любом хорошо связанном узле дает вам живой поток.
• Arbitrum — нет общедоступного мемпула. Эквивалентным сигналом служит WebSocket-канал секвенсора, который транслирует принятые транзакции до того, как они попадут в подтвержденные блоки.
• Optimism, Base — нет общедоступного мемпула в стиле Ethereum, но секвенсор принимает отправки по JSON-RPC и распространяет их через gossip; хорошо связанный op-node видит их через стандартную подписку.
• Solana — нет концепции мемпула; транзакции пересылаются непосредственно валидаторам. Задача «сканирования» здесь сводится к потоковой передаче через плагин Geyser или подписке на block engine.

На что вы подписываетесь и что считается «возможностью в мемпуле» зависит от того, в какой цепочке вы находитесь. Бюджеты задержки и формы фильтров следуют соответственно.

Компромисс между фильтром и полнотой охвата

Ловушка интуиции: «более жесткие фильтры → меньше шума → более быстрые решения → лучшее включение». Это неверно, потому что фильтры не снижают задержку обработки — они снижают полноту охвата возможностей.

Фильтр, который отбрасывает 90 % ожидающих транзакций, заставляет ваш цикл принятия решений работать на 10 % данных. Если ваш фильтр слишком жесткий, вы упускаете реальные возможности лишь для того, чтобы избежать шума, который и так не замедлил бы вас. Правильная калибровка:

1. Белый список пулов: пулы, которыми фактически торгует ваша стратегия. Новые добавляются явно, а не по умолчанию.
2. Минимальный порог суммы: ниже этого размера триггерной транзакции математика бэкрана не работает в принципе. (Примерно от ~1 тыс. долларов в номинале на Ethereum и ~200 долларов на дешевых цепочках.)
3. Белый список роутеров. Роутеры, с которыми ваша стратегия реально может составлять маршруты. Роутеры с привязанным токеном или незнакомые роутеры идут в отдельный «исследовательский» поток, а не в основной горячий путь.

Вот и все по фильтрам горячего пути. Все, что агрессивнее, — это чрезмерная настройка, которая жертвует полнотой охвата.

Бюджет задержки

Разложите общее время от запуска до отправки на этапы и профилируйте каждый из них:

Если какой-либо из этих показателей находится в диапазоне «типично плохих», именно его следует оптимизировать, а не ваш набор фильтров. Этап получения состояния — самый частый скрытый нарушитель; многие боты получают состояние через round-trip-вызовы JSON-RPC на каждую транзакцию, тогда как могли бы поддерживать локальное зеркало, обновляемое из той же WSS-подписки.

Включение против ложных срабатываний

Два отдельных показателя, часто смешиваемых:

• Доля включения: какая часть отправленных мной пакетов попала в блок? Если для стратегии, рассчитанной на 80%+, этот показатель ниже 60% — это инфраструктурная проблема (задержка, модель оплаты комиссий, покрытие билдеров).
• Доля ложных срабатываний: какая часть событий мемпула, прошедших мой фильтр, на деле не оказалась реальной возможностью? Высокая доля ложных срабатываний не имеет значения, пока их отсеивает симулятор на следующем этапе — это просто значит, что ваш фильтр недостаточно жесткий. Мягкий фильтр — это нормально; проблема в дорогой обработке на последующих этапах.

Операторы иногда ужесточают фильтры, чтобы получить неправильный показатель. Если у вас низкий уровень включения, ответом редко будет более жесткий фильтр.

Что измерять

Ежедневные значения для каждой стратегии, которые необходимо сохранить:

• Сигналы об устаревании подписки (события старше порога 500 мс).
• Процентили задержки по каждому этапу (см. таблицу выше).
• Доля прохождения фильтра (событий в минуту, прошедших фильтр).
• Доля прибыльных после симуляции (прошедших симуляцию в минуту).
• Доля включения относительно отправленного.
• Включение в разбивке по релеям (для цепочек с несколькими релеями).

Эти шесть цифр на ежедневной информационной панели подскажут вам, где бот здоров, а где проигрывает. Без них отладка превращается в догадки.

Распространенные ошибки сканирования

• Единственная подписка без перекрестной проверки. Вторая подписка у другого провайдера подтверждает, что вы видите то, что на самом деле происходит в сети. Без этого незаметно пропущенное покрытие будет выглядеть так, будто «стратегия просто не находит возможностей».
• Штормы переподключения WSS, стирающие состояние подписки. Некоторые провайдеры сбрасывают соединения каждые 30–60 минут для балансировки нагрузки. Если ваш подписчик не восстанавливает подписки при переподключении, вы будете пропускать по несколько секунд подряд.
• Разбор JSON на горячем пути. Наивный JSON.parse полных конвертов ожидающих транзакций добавляет миллисекунды на каждое событие. Потоковые парсеры, которые извлекают только нужные поля (to/from/value/префикс data), реально экономят время при пиковых нагрузках.
• Межрегиональная подписка, которая незаметно урезает преимущество вдвое. «Резервная» схема с переключением с us-east на ap-southeast добавляет 100+ мс в каждую сторону. Настройте алерты по задержке, а не только по жестким сбоям.
• Доверие покрытию одного провайдера без проверки. Особенно в BSC у некоторых коммерческих провайдеров слабо связанные узлы, которые незаметно отставают. Периодически перепроверяйте.

Рабочая конфигурация

Минимальный жизнеспособный подписчик мемпула:

1. Две параллельные WSS-подписки (провайдер A + провайдер B) для перекрестной проверки покрытия.
2. Набор фильтров: белый список пулов + минимальный порог суммы + белый список роутеров. Никакой более глубокой фильтрации на горячем пути.
3. Состояние поддерживается как локальное зеркало, обновляемое из того же WSS-потока, а не запрашиваемое повторно на каждую транзакцию.
4. Профилирование задержки на каждом этапе с ежедневным сохранением процентилей.
5. Логика переподключения с восстановлением подписок, которая возобновляет подписку в течение 200 мс после разрыва связи.

Агент FRB реализует все это по умолчанию; части, которые имеют значение для самостоятельных систем, в любом случае одни и те же.

Ссылки

• Руководство по подписке на Reth WSS
• Фид секвенсора Arbitrum
• Инструмент проверки задержки WSS