Разработка бота для сэндвич-атак

Разработка бота для сэндвич-атак

Сэндвич-бот — это легальный MEV-инструмент. Арбитраж, ликвидации, сэндвичи — три основных стратегии MEV-извлечения в продакшне. Сэндвич конкретно эксплуатирует slippage tolerance пользователей DEX: бот видит жертву в mempool, вставляет свою покупку перед ней (frontrun), жертва двигает цену вверх, бот продаёт после (backrun). Разница — прибыль бота, убыток жертвы в рамках её же slippage tolerance. Это арбитраж на информации о порядке транзакций.

Разработка такого бота — это одновременно задача о скорости (латентность мемпула), экономике (калькулятор прибыльности), и инфраструктуре (надёжный деплой без потерь).

Где большинство ботов теряют деньги

Неточный расчёт прибыльности

Самая частая ошибка начинающих MEV-разработчиков — расчёт profit без учёта всех costs. Кажется очевидным, но в практике встречается регулярно.

Реальный P&L сэндвича:

profit = amountOut_backrun - amountIn_frontrun
costs = gasCost_frontrun + gasCost_backrun + builderTip
netProfit = profit - costs

gasCost при агрессивных tips на Ethereum mainnet — это не мелочь. Если сэндвич приносит $2, а builder tip составляет $1.5 — сделка убыточна. Бот должен симулировать весь пакет транзакций перед отправкой и отбрасывать сделки с отрицательным net profit.

Симуляция через eth_call на текущем стейте — медленная. Продакшн-боты используют собственные in-process EVM симуляторы (revm на Rust или аналоги) для микросекундной оценки.

Revert из-за price impact расчёта

Бот рассчитал прибыль в moment T, но отправил транзакцию в moment T+50ms. За это время другой бот выполнил свой frontrun. Состояние пула изменилось. Собственный frontrun бота теперь двигает цену сильнее расчётного, жертва попадает за пределы slippage tolerance и её транзакция ревертируется. Backrun не нужен, но gas за frontrun уже потрачен.

Защита: backrun транзакция должна быть conditional — проверять, что целевая транзакция жертвы действительно была включена перед ней. В Flashbots bundle это реализуется через reverting_tx_hashes — если жертва ревертировалась, весь bundle не включается.

Конкуренция и builder relationship

На Ethereum после The Merge 95%+ MEV-bundles проходят через block builders (Flashbots, beaverbuild, rsync-builder). Бот, который отправляет транзакции в публичный mempool напрямую, проигрывает конкурентам с private relay во всех случаях.

Правильная инфраструктура: MEV-Share (Flashbots matchmaker для user-refund MEV), прямые соединения с топ-builders через их private endpoints, мониторинг mev-boost relay для понимания текущего winning builder.

Архитектура production сэндвич-бота

Мемпул мониторинг

Стандартный eth_subscribe("pending") через WebSocket — слишком медленно. Между появлением транзакции в приватных мемпулах крупных нод и публичным анонсом проходит 50–200ms. За это время профессиональные боты уже приняли решение.

Оптимальная схема:

1. Прямые пиринговые соединения с несколькими Ethereum-нодами (Geth, Erigon) для получения транзакций до их широкого распространения.
2. Блоб мемпул фид от специализированных провайдеров (bloXroute, Blocknative) — платный, но даёт доступ к транзакциям на 100–300ms раньше публичного анонса.
3. Собственная нода с --txpool.pricelimit 0 — принимает все транзакции без минимального gas price фильтра.

Фильтрация и оценка кандидатов

Из тысяч pending-транзакций нужно быстро выбрать сэндвич-кандидатов. Критерии:

• to адрес = известный DEX router (Uniswap V2/V3, Sushiswap, Curve, Balancer)
• Декодированный calldata: swap с slippage tolerance > 0.5%
• amountOutMinimum значительно ниже текущего amountOut по getAmountsOut
• Gas price достаточный для inclusion в ближайший блок

Декодирование calldata для Uniswap V3 exactInputSingle и exactInput (multi-hop) — обязательный компонент. Для multi-hop свопов расчёт сложнее: нужно симулировать каждый hop по очереди.

Расчёт оптимального frontrun amount

Ключевая математика: сколько купить в frontrun, чтобы максимизировать прибыль?

Для Uniswap V2 с формулой x * y = k существует аналитическое решение для оптимального input amount. Для V3 с concentrated liquidity и tick-based ценой — численная оптимизация (бинарный поиск по amount).

Приближённая формула для V2:

optimalInput ≈ sqrt(k * victimAmount) - reserveIn

Но это без учёта gas costs и builder tip. Реальная оптимизация учитывает marginal cost каждого дополнительного доллара frontrun amount.

Execution через Flashbots

const bundle = [
  { signer: wallet, transaction: frontrunTx },
  { hash: victimTxHash },           // целевая транзакция жертвы
  { signer: wallet, transaction: backrunTx }
];

const bundleResponse = await flashbotsProvider.sendBundle(
  bundle,
  targetBlockNumber,
  { minTimestamp: 0, maxTimestamp: 0, revertingTxHashes: [victimTxHash] }
);

revertingTxHashes: [victimTxHash] — ключевой параметр: если жертва ревертируется (например, другой бот уже выполнил свой сэндвич), весь bundle дропается. Бот не теряет gas на frontrun без backrun.

Мультичейн и L2 специфика

На Arbitrum и Optimism нет публичного mempool в классическом смысле — sequencer получает транзакции напрямую и публикует их атомарно в батчах. MEV-возможности ограничены, но не исключены: DEX arbitrage между разными протоколами на L2 работает.

На BSC сэндвичи активны, конкуренция ниже чем на Ethereum mainnet, но validator tips работают по другой схеме — прямые соединения с BSC validators через их private endpoints.

Base (OP Stack) — sequencer принадлежит Coinbase, MEV политика ограничивает классические сэндвичи. Арбитраж между Aerodrome, BaseSwap, Uniswap V3 на Base работает лучше.

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

Бот пишем на Rust с библиотекой ethers-rs (или более новой alloy) для максимальной производительности. Критичные компоненты — EVM симулятор (revm), мемпул стриминг, bundle submission — в одном процессе без межпроцессной коммуникации.

Смарт-контракт для atomic execution (чтобы backrun и frontrun выполнялись атомарно из одного контракта, экономя на gas) — Solidity 0.8.x с минимальным footprint. Контракт не хранит state, только delegatecall к исполнительной логике.

Мониторинг: кастомный Prometheus + Grafana дашборд с метриками: бандлы в час, inclusion rate, средний profit per bundle, revert rate.

Процесс работы

Исследование (2–3 дня). Анализ целевого чейна и DEX-экосистемы, оценка MEV-opportunity размера через dune analytics данные.

Разработка (2–3 недели). Мемпул стриминг, декодер транзакций, калькулятор прибыльности, Flashbots/relay интеграция, atomic execution контракт.

Тестирование (3–5 дней). Backtesting на исторических блоках через Foundry fork, simulated competition, paper trading на testnet.

Запуск и оптимизация (ongoing). Первый деплой на mainnet с ограниченным размером позиций, затем постепенное масштабирование по мере валидации профитабельности.

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

Базовый Uniswap V2/V3 сэндвич-бот — 1–2 недели. Multi-DEX с поддержкой Curve, Balancer, Sushiswap + мультичейн — 3–5 недель. Включая оптимизацию latency и builder relationships.