Архитектура MEV-ботов и стратегии извлечения прибыли

Что такое MEV на практике2

Как уже я описывал в статье про сам MEV - в теории пользователю может казаться, что транзакции в блокчейне исполняются в порядке отправки. На практике же порядок определяется валидаторами, билдерами и рынком комиссий. Существуют:

• публичный мемпул;
• приватные ордерфлоу;
• валидаторы;
• билдеры блоков;
• поисковики возможностей (searchers);
• relays;
• аукцион за приоритет включения в блок.

То есть транзакция обычного пользователя - это не просто запрос “обменять ETH на USDC”. Это сигнал рынку, который можно интерпретировать и монетизировать. (и многие это и монетизируют)

Особенно хорошо это видно в DEX’ах с AMM-моделью вроде Uniswap-подобных пулов. Если кто-то собирается сделать достаточно крупный swap, то он заметно двигает цену внутри пула. А если цену можно сдвинуть - значит кто-то другой может заработать:

• до этого сдвига (frontrun);
• сразу после него (backrun);
• между двумя рынками (разными dex-ами), где цена обновляется не одновременно (arbitrage);
• в случае ликвидаций (liquidation).

1) Backrun: встать сразу после крупной транзакции

Backrun - бот хочет выполнить свою транзакцию сразу после определённой транзакции.

Типичный случай

Пользователь делает большой swap и двигает цену в пуле. После этого:

• на другом DEX никто не делал обмен данного токена и цена осталась прежней;
• в этом же пуле появляется краткосрочный дисбаланс;
• возникает арбитражная возможность.

Бот ставит транзакцию сразу после чужой сделки, чтобы забрать этот дисбаланс раньше остальных.

Пример

Допустим:

• на DEX A цена ETH = 3000 USDC;
• на DEX B цена ETH = 3002 USDC.

Разница маленькая, неинтересная.

Но приходит крупный swap на DEX A, который выталкивает цену ETH до 3035 USDC.
Теперь бот может:

• купить ETH на DEX B дешевле;
• продать на DEX A дороже;
• зафиксировать разницу.

Важно: пользователь своей сделкой сам создал эту возможность. Бот лишь встроился сразу после неё.

Почему backrun это даже “полезно”

Потому что в этой модели бот обычно не ухудшает цену входа пользователя напрямую и не мешает ему, не меняет цену, как при sandwich-атаке (которую опишу позже). Он просто приводит отдельные элементы рынка к некому равновесию - например, быстро выравнивает цены между разными площадками, создавая “справедливую” цену по рынку.

Но с точки зрения получения прибыли ботом - это всё равно гонка инфраструктур. Прибыль получает тот, кто первым увидел изменение состояния и первым (после той, на которую охотились/увидели) исполнил свою транзакцию.

2) Frontrunning и Sandwich: игра с порядком исполнения

Если Backrun - это реакция после события, то здесь речь о попытке повлиять на сделку пользователя, встроившись до и вокруг неё.

Frontrunning: встать перед чужой транзакцией

Это попытка вставить свою транзакцию до чужой, зная, что она изменит состояние рынка.

Бот видит в мемпуле крупный swap и понимает: после его исполнения цена в пуле сдвинется. Значит можно попытаться:

1. купить актив до пользователя;
2. дать пользователю сдвинуть цену;
3. продать дороже.

На уровне идеи это выглядит как банальная спекуляция, но ключевой момент здесь - контроль порядка исполнения внутри блока.

Однако в “чистом виде” фронтран встречается реже, чем кажется. Потому что:

• нужно точно попасть перед конкретной транзакцией;
• нужно учитывать slippage пользователя (иначе его сделка может просто не исполниться);
• конкуренция за это место в блоке очень высокая;
• риск, что тебя самого “обгонят”, тоже никуда не исчезает.

Поэтому на практике фронтран почти всегда превращается в более устойчивую форму - sandwich.

Sandwich attack: фронтран + бэкран в одной конструкции

Sandwich attack - это развитие идеи фронтрана, где бот не просто встаёт перед пользователем, а оборачивает его сделку с двух сторон:

1. покупает до (front leg);
2. пользователь исполняется по уже ухудшенной цене;
3. продаёт после (back leg).

То есть пользователь оказывается “зажат” между двумя транзакциями бота.

Как это работает

Допустим, пользователь делает крупный swap в AMM-пуле.

Бот видит эту транзакцию и понимает:

• если он купит первым - цена уже немного вырастет;
• пользователь всё ещё исполнится (если slippage позволяет), но по худшей цене;
• после этого бот может продать обратно в “разогретый” пул.

В результате:

• бот покупает дешевле, чем пользователь;
• пользователь покупает дороже, чем ожидал;
• бот фиксирует прибыль на обратной продаже.

Фактически прибыль бота формируется за счёт ухудшения цены пользователя.

Почему это работает

Ключевой механизм здесь - AMM-кривая и slippage:

• каждая сделка сдвигает цену;
• пользователь заранее задаёт допустимый диапазон (slippage tolerance);
• бот может “забрать” часть этого диапазона себе.

Чем шире slippage - тем больше пространство для атаки.

Если пользователь разрешает 3–5%, он по сути даёт системе диапазон, внутри которого его сделка всё равно исполнится. Бот просто использует часть этого диапазона в свою пользу.

Техническая сложность

Несмотря на простую идею, реализация требует точности:

• нужно оценить, насколько можно сдвинуть цену, чтобы не сломать сделку пользователя;
• нужно правильно подобрать объём front и back транзакций;
• нужно учитывать комиссии пула и gas;
• нужно гарантировать порядок: front → пользователь → back;
• нужно конкурировать с другими ботами, которые делают ровно то же самое.
• нужно не попасть в ситуацию, когда другие боты могут использовать саму нашу транзакцию бота в качестве мишени для своего front-run.

Именно поэтому здесь снова решает не идея, а инфраструктура.

Почему это вредно для пользователя

Потому что пользователь получает хуже цену, чем мог бы. Его сделка не просто исполняется - она становится объектом паразитирования. Формально протокол работает как задумано, но экономический результат для пользователя хуже. Поэтому для критичных и больших сделок лично я рекомендую использовать или лимитные ордера или защищаться от паразитирования точными указаниями slippage (минимально/максимально допустимых цен)

Чем шире пользователь ставит slippage tolerance, тем больше пространство для атаки.

Если человек разрешил 5%, бот понимает, что можно довольно сильно ухудшить цену, и сделка всё равно исполнится. Другими словами пользователь сам “подписывает” диапазон, в котором его можно эксплуатировать.

3) Arbitrage

Арбитраж - это поиск ценовых различий между площадками и извлечение прибыли из этих различий.

В DeFi это происходит постоянно, потому что каждый DEX - это локальная кривая ликвидности, а не единый “центральный стакан” как на централизованных биржах. Цена может отличаться:

• между двумя AMM;
• между DEX и CEX;
• между спотовым и деривативным рынком;
• между разными блокчейнами или L2.

Базовый пример

Если на одном DEX токен стоит 0.99 USDC, а на другом 1.02 USDC, бот может:

• купить дешевле;
• продать дороже;
• забрать спред.

Арбитраж - это основа MEV-экосистемы

После крупной сделки, ликвидации или сэндвича рынок временно деформируется. И кто-то должен вернуть цены ближе к равновесию.

Именно поэтому часть MEV-ботов - это не “охотники на пользователей”, а машины по выравниванию состояния рынка.

4) Liquidation: самый “легитимный” вид MEV

Ликвидации часто стоят особняком, потому что они нужны самим кредитным протоколам и чаще всего часть таких ботов реализуются самими протоколами.
Если заемщик дал залог и взял долг, а цена залога упала ниже допустимого порога, кто-то должен закрыть часть или всю позицию и вернуть системе устойчивость.

Этим “кто-то” и становится ликвидатор-бот.

Как это работает

В лендинговом протоколе есть правило:

• позиция здорова, пока коэффициент обеспечения выше порога;
• если рынок падает и позиция уходит ниже этого порога, она становится ликвидируемой;
• ликвидатор гасит часть долга и получает залог со скидкой или бонусом.

Пример

Пользователь заложил 1 ETH и когда цена была 4000 занял 2000 стейблкоинов. ETH резко просел до 2300. Health factor позиции ушёл ниже порога и позиция уже может быть ликвидирована.

Бот, который мониторит:

• цену оракулов/рынка,
• состояние позиций,
• размер бонуса/параметров ликвидации,
• конкуренцию/расчеты по стоимости gas/включения в блок,

Видит возможность. Формирует транзакцию, в которой отправляет лендинг протоколу 2000 стейблкойнов, получает 0.9eth из залога пользователя (“залог cо скидкой” или “liquidation bonus”). После чего обменивает эти 0.9 на каком-либо DEX по 2300, получая 2070. В итоге получив прибыль порядка 70 (не учитываю тут затраты на исполнение и т.д.) Это очень упрощенная схема, т.к. пороги ликвидации/возвраты залогов, бонусы ликвидаторам и сами схемы варьируются в зависимости от лендинг-протокола.

Почему liquidation - не совсем эксплуатация

Потому что ликвидации встроены в экономику протокола. Это не баг и не атака в классическом смысле. Но это всё ещё MEV, потому что прибыль возникает из-за права быть первым исполнителем события, доступного всем, но достающегося самому быстрому.

Где на самом деле идёт борьба: не в стратегии, а в инфраструктуре

Если убрать романтику, почти все MEV-боты упираются в одни и те же инженерные проблемы:

• очень быстрый приём и декодирование потока транзакций;
• локальная симуляция математики исполнения;
• оценка прибыли после gas и комиссий;
• работа с несколькими источниками состояния;
• устойчивость к reorg и устаревшим данным;
• отправка через публичные и приватные каналы;
• борьба с конкурентами, у которых та же идея, но лучше latency.

Поэтому разработка таких систем - это не столько “написать скрипт на каком-нибудь языке”, сколько собрать инфраструктуру, где даже незначительная ошибка лишь в одном пункте из вышеперечисленного списка может перечеркнуть “лучшие по сравнению с конкурентами” реализации всех остальных действий.