Разработка бота для бэкраннинга

Разработка бота для бэкраннинга

Backrunning — это исполнение транзакции сразу после целевой транзакции в том же блоке. В отличие от frontrunning, бэкраннер не конкурирует с пользователем — он использует изменённое состояние блокчейна после целевой транзакции. Классический пример: крупный swap двигает цену в пуле, бэкраннер арбитражит разницу между этим пулом и другими.

Разница между ботом, который зарабатывает, и ботом, который сливает газ в ноль — в деталях реализации. Видели боты, которые правильно детектируют возможность, но теряют всё на gas wars с конкурентами.

Где теряются деньги при неправильной реализации

Газ как основная статья расходов

Backrunning — конкурентная среда. Десятки ботов мониторят один и тот же мемпул. Если ваш бот не выиграл gas auction — транзакция попадает после чужой, возможность уже использована, вы платите газ за реверт.

Типичная ошибка: бот отправляет транзакцию с gasPrice = targetTx.gasPrice + 1 gwei. Конкурент ставит + 2 gwei. Бесконечная эскалация приводит к тому, что всю прибыль от арбитража съедает газ.

Правильный подход: расчёт максимально допустимого gas price из ожидаемой прибыли. Если арбитраж даёт $50, gas limit 200k, приемлемая доля расходов 60% — максимальный gas price = $30 / (200000 * ethPrice). Бот не должен ставить выше этого порога.

Simulation перед отправкой

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

Используем eth_call с block: "pending" или Tenderly simulation API для проверки профита непосредственно перед отправкой. Если симуляция показывает убыток — не отправляем.

Bundle через Flashbots вместо публичного мемпула

Отправка через публичный мемпул на Ethereum — почти гарантированный проигрыш конкурентам с Flashbots-доступом. Flashbots MEV-Boost позволяет отправлять bundle транзакций напрямую builder-ам, без публичного мемпула.

Структура bundle: [targetTx, backrunTx]. Builder включает их последовательно. Backrun гарантированно идёт после target в том же блоке. Плата builder-у — coinbaseFee в backrun-транзакции: block.coinbase.transfer(profit * 90 / 100).

На L2-чейнах (Arbitrum, Optimism) MEV-инфраструктура другая. Arbitrum FCFS (first-come-first-served) у sequencer — здесь важна латентность соединения с sequencer endpoint, а не gas auction.

Архитектура бота

Три слоя системы

Monitoring layer. WebSocket-подписка на pending транзакции через eth_subscribe("pendingTransactions"). Анализ calldata целевой транзакции — декодируем через ABI известных протоколов (Uniswap v2/v3, SushiSwap, 1inch). Если это swap с достаточным size — передаём в opportunity evaluator.

Opportunity evaluator. Симуляция целевой транзакции: какой будет цена в пуле после неё? Расчёт арбитражного маршрута: через какие пулы провести обратный своп для выравнивания цены? Расчёт чистого профита с учётом газа и slippage.

Execution layer. Формирование backrun-транзакции. Выбор между Flashbots bundle и публичным мемпулом на основе чейна и размера прибыли. Отправка и мониторинг включения.

Смарт-контракт бота

Для атомарности операции (чтобы не потерять деньги при частичном исполнении) — исполнение через смарт-контракт, а не через EOA:

contract BackrunExecutor {
    address private immutable owner;
    
    function execute(
        address[] calldata path,
        uint256 amountIn,
        uint256 minProfit
    ) external {
        // swap через пулы
        uint256 received = _executeSwaps(path, amountIn);
        require(received >= amountIn + minProfit, "Insufficient profit");
        // отправляем % builder-у
        block.coinbase.transfer(msg.value);
    }
}

minProfit — защита от исполнения при нулевой или отрицательной прибыли. Если арбитражная дельта исчезла между симуляцией и включением — транзакция реверсируется. Газ теряется, но меньше, чем потенциальный убыток.

Мультичейн и маршрутизация

На Arbitrum из-за быстрых блоков и FCFS важнее скорость RPC-соединения, чем сложность стратегии. Бот с co-location рядом с Arbitrum sequencer стабильно выигрывает у бота с той же логикой, но большей задержкой.

Стек разработки

TypeScript/Node.js + ethers.js v6 для мониторинга и формирования транзакций. Python для бэктестинга стратегий на исторических данных (через The Graph или архивная нода).

Flashbots SDK (@flashbots/ethers-provider-bundle) для bundle submission. Для multi-builder стратегии — MEV-Share от Flashbots или прямые интеграции с builder API (beaverbuild, rsync-builder).

Деплой бота: выделенный сервер с минимальной латентностью до Ethereum/L2 нод. AWS Frankfurt или Hetzner для Ethereum. Прямое WSS к ноде, а не через Infura/Alchemy — каждые 50ms на счету.

Ориентиры по срокам

Базовый backrunning-бот для одного DEX на одном чейне — 1 неделя. Мультичейн система с несколькими стратегиями и Flashbots интеграцией — 2 недели. Включая смарт-контракт исполнителя, тесты на форке mainnet и деплой инфраструктуры.