Розробка бота для бекраннінгу
Ми розробляємо 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 та деплой інфраструктури.
Зв'яжіться з нами для оцінки вашого проекту за один день. Отримайте консультацію з вибору чейну та стратегії.