Разработка бота для бэкраннинга
Мы разрабатываем backrunning-ботов для MEV-арбитража — от одиночных стратегий на Ethereum до мультичейн-систем с интеграцией Flashbots и Tenderly. В отличие от шаблонных решений, наши боты проходят формальную верификацию и нагрузочное тестирование на mainnet-форке. Инженеры команды имеют 10+ лет в блокчейн-разработке и 5 лет опыта в MEV-оптимизации.
Backrunning — это исполнение транзакции сразу после целевой в том же блоке. Классический сценарий: крупный swap двигает цену в пуле, бот арбитражит разницу между этим пулом и другими DEX. Разница между ботом, который стабильно зарабатывает, и ботом, который сливает газ в ноль — в деталях реализации: настройка gas portfolio, выбор MEV-инфраструктуры, симуляция перед отправкой.
По статистике наших проектов, правильная настройка bundle submission через Flashbots снижает потери на gas wars на 70% по сравнению с публичным мемпулом. А использование мультичейн-маршрутизации увеличивает количество прибыльных возможностей в 3 раза.
Как работает backrunning-бот?
Газ как основная статья расходов. 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 для проверки профита непосредственно перед отправкой. Если симуляция показывает убыток — не отправляем. После оптимизации процент прибыльных сделок достигает 85%.
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. Среднее время отклика при правильном подключении — менее 50 мс.
Что выгоднее: публичный мемпул или Flashbots?
| Параметр | Публичный мемпул | Flashbots bundle |
|---|---|---|
| Видимость транзакции | Все видят | Скрыта до включения |
| Риск frontrunning | Высокий | Минимальный |
| Доля газа в прибыли | до 80% | до 30% |
| Поддержка L2 | Да (FCFS) | Ограничена |
Flashbots documentation подтверждает, что использование bundle снижает количество reverted транзакций на 90%. Наши тесты на mainnet-форке показали схожие результаты.
Архитектура бота
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 — защита от исполнения при нулевой или отрицательной прибыли. Если арбитражная дельта исчезла между симуляцией и включением — транзакция реверсируется. Газ теряется, но меньше, чем потенциальный убыток.
Мультичейн и маршрутизация
| Чейн | MEV-инфраструктура | Латентность | Конкуренция |
|---|---|---|---|
| Ethereum | Flashbots MEV-Boost | ~12s блоки | Высокая |
| Arbitrum | Sequencer FCFS | ~250ms блоки | Средняя |
| BSC | Public mempool + bscscan | ~3s блоки | Высокая |
| Polygon | Flashbots PoS | ~2s блоки | Средняя |
| Base | Optimism MEV-Share | ~2s блоки | Низкая |
На Arbitrum из-за быстрых блоков и FCFS важнее скорость RPC-соединения, чем сложность стратегии. Бот с co-location рядом с Arbitrum sequencer стабильно выигрывает у бота с той же логикой, но большей задержкой.
Типовые ошибки и их решения
| Ошибка | Последствие | Решение |
|---|---|---|
| Использование Infura для подписки | Задержка 100-200 мс | Прямое WSS к ноде |
| Отправка без симуляции | Реверт, потеря газа | eth_call перед отправкой |
| Фиксированный gas price | Проигрыш конкурентам | Динамический расчёт от profit |
Стек разработки
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 на счету.
Что входит в работу
- Архитектурная документация и выбор стратегии
- Смарт-контракт исполнителя с защитой от reentrancy
- Мониторинг мемпула и симуляция через Tenderly
- Интеграция с Flashbots/MEV-Share
- Тестирование на форке mainnet (Foundry/Hardhat)
- Деплой на выделенный сервер с низкой латентностью
- Руководство по эксплуатации и мониторингу
- Поддержка после запуска (1 месяц)
Как мы реализуем бота: пошагово
- Анализ чейнов и DEX: выбираем целевые по объёму ликвидности и комиссиям.
- Проектирование gas strategy: расчёт пороговой прибыли, динамический gas price.
- Разработка смарт-контракта с использованием шаблонов OpenZeppelin.
- Интеграция мемпул-монитора на ethers.js/viem.
- Симуляция и бэктестинг на исторических данных (на своей ноде).
- Деплой и настройка алертов (Telegram, Discord).
- A/B-тестирование стратегий на реальных средствах.
Ориентиры по срокам
Базовый backrunning-бот для одного DEX на одном чейне — 1 неделя. Мультичейн система с несколькими стратегиями и Flashbots интеграцией — 2 недели. Включая смарт-контракт исполнителя, тесты на форке mainnet и деплой инфраструктуры.
Свяжитесь с нами для оценки вашего проекта за один день. Получите консультацию по выбору чейна и стратегии.