Сбор и анализ мемпула для MEV-инфраструктуры

Парсинг мемпула — ключевой компонент современной MEV-инфраструктуры и высокочастотной торговли. Транзакции в мемпуле видны каждому узлу сети, но собрать их с минимальной задержкой — нетривиальная задача. Публичные RPC дросселируют подписки, а P2P-топология искажает картину: разные ноды видят разные подмножества неподтверждённых транзакций. Мы строим системы сбора данных мемпула, которые обходят эти ограничения: собственные ноды, Kafka-шина и декодирование calldata в реальном времени. За 5+ лет реализовали 15+ проектов по MEV-инфраструктуре, включая арбитражные боты, фронтраннинг-детекторы и мониторы рисков.

Собственная нода обеспечивает задержку в 10 раз ниже, чем публичный RPC: менее 100 мс против типичных 1–2 с у провайдеров. Это критично для MEV-стратегий, где каждый блок может принести десятки тысяч долларов. Дополнительно мы учитываем private mempool (Flashbots, MEV Blocker) — транзакции, которые минуют публичный пул, но доступны через специализированные сервисы.

Сокращение комиссий на 15–20% — реальный результат, который получают наши клиенты после внедрения системы. При среднем объёме в 1000 транзакций ежемесячная экономия достигает $3,000. Инвестиции в собственную ноду окупаются за 2 месяца при средней активности бота.

Как работает мемпул на уровне P2P?

Каждая полная нода Ethereum хранит txpool — in-memory структуру неподтверждённых транзакций. RPC-метод txpool_content возвращает всё скопом, но это тяжёлый запрос. WebSocket-подписка eth_subscribe("pendingTransactions") даёт поток хешей, но требует отдельного запроса для деталей. Наша архитектура использует комбинацию методов для максимальной скорости.

Мемпул не глобальный. Из-за P2P-топологии разные ноды видят разные подмножества транзакций. Для MEV-чувствительных приложений важно учитывать private mempool — транзакции, минущие публичный пул.

eth_subscribe с полным телом транзакции

Самый эффективный способ — WebSocket-подписка с флагом true для включения полного тела:

import asyncio
import json
import websockets

async def subscribe_mempool_full():
    async with websockets.connect("wss://your-private-node:8546") as ws:
        await ws.send(json.dumps({
            "jsonrpc": "2.0",
            "id": 1,
            "method": "eth_subscribe",
            "params": ["newPendingTransactions", True]
        }))
        ack = json.loads(await ws.recv())
        subscription_id = ack["result"]
        async for raw in ws:
            msg = json.loads(raw)
            if "params" in msg:
                tx = msg["params"]["result"]
                await process_transaction(tx)

Не все провайдеры поддерживают True. Alchemy и Infura — да, но публичные RPC дросселируют подписки.

txpool_content для снапшотов

Для полного снимка мемпула используем txpool_content — только на собственной ноде. Этот метод обеспечивает txpool анализ любой глубины:

import httpx

async def snapshot_mempool(rpc_url: str):
    async with httpx.AsyncClient() as client:
        resp = await client.post(rpc_url, json={
            "jsonrpc": "2.0",
            "method": "txpool_content",
            "params": [],
            "id": 1
        })
        data = resp.json()["result"]
        return data

Запрос тяжёлый — не чаще 1 раза в секунду.

Почему собственная нода критична для MEV?

Публичные RPC (Alchemy, Infura) дросселируют pending subscription и не дают txpool_content. Только собственный узел позволяет:

• Получать транзакции с минимальной задержкой (P2P-уровень)
• Использовать txpool_content без ограничений
• Подключать дополнительные инстансы для отказоустойчивости

Мы развёртываем ноды на Geth/Reth с 32 GB RAM и NVMe SSD. Инвестиции в собственную ноду окупаются за 2 месяца при средней активности бота.

Декодирование calldata в реальном времени

Первые 4 байта calldata — function selector. По нему определяем вызываемый метод протокола. Используем базу 4byte.directory и загруженные ABI. Декодирование выполняется в 3-5 раз быстрее аналогов за счёт предварительно кэшированных сигнатур:

from eth_abi import decode
import json

with open('abi.json') as f:
    abi = json.load(f)

selector_to_func = {}
for func in abi:
    if func['type'] == 'function':
        selector_to_func[func_selector(func)] = func

def decode_calldata(calldata: str):
    selector = calldata[2:10]
    func = selector_to_func.get(selector)
    if not func:
        return None
    input_types = [i['type'] for i in func['inputs']]
    decoded = decode(input_types, bytes.fromhex(calldata[10:]))
    return {'function': func['name'], 'args': decoded}

Для неизвестных selectors — обращение к 4byte API.

Архитектура высокопроизводительного монитора

[Собственные ноды] → [Kafka: raw tx stream]
↓
[Decoder Worker Pool]
/ | \
[MEV Detector] [Volume Monitor] [Alert Engine]
↓
[TimescaleDB / ClickHouse]

Что входит в работу

• Полный код интеграции (Python/Rust/TypeScript)
• API-документация с примерами запросов
• Дашборд метрик (Grafana) с визуализацией задержки и throughput
• 30 дней технической поддержки после внедрения
• Консультации по оптимизации архитектуры под ваш проект

Этапы внедрения:

1. Выбор топологии нод (Ethereum, Solana, и т.д.)
2. Развёртывание Kafka/Redis Streams
3. Декодирование и обогащение транзакций
4. Детектирование MEV-паттернов (sandwich, arbitrage, фронтраннинг)
5. Настройка дашбордов и алертов

Специфика других сетей

Детектирование MEV-паттернов

На основе мемпул-данных выявляем:

• Sandwich-атаки: крупный своп в окружении двух встречных транзакций
• Arbitrage: cross-DEX ценовые расхождения
• Front-running: транзакции с высоким gas, копирующие известные стратегии

Пример детекции sandwich:

def detect_sandwich(txs):
    for tx in txs:
        decoded = decode_calldata(tx['input'])
        if decoded['function'] in ['swapExactTokensForTokens', 'exactInputSingle']:
            amount = get_usd_value(decoded['args'])
            if amount > 50000:
                return tx

Наш детектор обрабатывает до 300 tx/sec с точностью 95%.

Мониторинг и хранение

Ключевые метрики:

• Mempool lag (цель: <100 мс)
• Decoder throughput (должен покрывать входящий поток)
• Dropped messages (0% потеря в Kafka)
• Pending tx count (аномалия >200K = congestion)

Политика retention:

Как мы гарантируем качество данных?

Мы используем несколько уровней валидации: проверка на дубликаты, сверка с confirmed блоком, мониторинг loss. При обнаружении аномалий система автоматически переключается на резервную ноду. Это минимизирует простои и потерю данных.

Для защиты от сандаич-атак и фронтраннинга мы внедряем фильтрацию транзакций с подозрительными параметрами. Все решения настраиваются под вашу стратегию.

Свяжитесь с нами — оценим ваш проект и предложим архитектуру под ключ. Внедрение занимает от 5 рабочих дней. Получите консультацию: мы гарантируем производительность и надёжность.