Розробка backrunning-бота
Backrunning — це виконання транзакції одразу після цільової транзакції в тому ж блоці. На відміну від frontrunning, backrunner не конкурує з користувачем — використовує змінений стан блокчейна після цільової транзакції. Класичний приклад: крупний swap рухає ціну в пулі, backrunner арбітражить різницю між цим пулом та іншими.
Різниця між ботом, який заробляє, та ботом, який спалює газ у нуль — у деталях реалізації. Видили ботів, які правильно детектують можливість, але втрачають все у gas wars з конкурентами.
Де втрачаються гроші при неправильній реалізації
Газ як основна стаття витрат
Backrunning — конкурентне середовище. Десятки ботів моніторять один й той же мемпул. Якщо ваш бот не виграв gas auction — транзакція попадає після чужої, можливість уже використана, ви платите газ за revert.
Типова помилка: бот відправляє транзакцію з 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 — захист від виконання при нульовій або негативній прибутку. Якщо арбітражна дельта зникла між симуляцією та включенням — транзакція скасується. Газ втрачається, але менше ніж потенційний убиток.
Мультичейн та маршрутизація
| Чейн | 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 стабільно перемагає бота з однаковою логікою, але більшою затримкою.
Стек розробки
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 та розгортання інфраструктури.