Разработка MEV-стратегий для валидаторов

Разработка MEV-стратегий для валидаторов

После перехода Ethereum на Proof-of-Stake разграничение MEV изменилось. Validators не выполняют транзакции — они только предлагают и аттестуют блоки. Фактическое упорядочивание и включение транзакций делегировано через PBS (Proposer-Builder Separation): builders строят блоки, proposers (validators) выбирают самый выгодный. MEV для валидатора сегодня — это прежде всего правильная конфигурация MEV-boost и понимание того, в каких случаях стоит отклонять предложенные блоки.

MEV-Boost: архитектура и риски

MEV-Boost — программное обеспечение, которое запускается рядом с consensus client валидатора (Lighthouse, Prysm, Teku). Оно реализует протокол mev-boost relay: validator запрашивает блоки у нескольких relay (Flashbots, BloXroute, Ultra Sound, Aestus и др.), выбирает максимальный bid, подписывает blind header, получает полный block body от relay и публикует.

Validator → MEV-Boost → [Relay 1, Relay 2, ..., Relay N]
                              ↓
                         Builder auction
                              ↓
               Highest bidder's block → Validator signs

Конфигурация relay

Подключение к большему числу relay увеличивает конкуренцию и bid. Но не все relay одинаковы:

Для максимального MEV дохода — подключать все доступные relay без OFAC-фильтрации. Для институциональных валидаторов с compliance требованиями — только regulated relay. Разница в доходности: 10–30% в зависимости от периода.

Проверка bid перед подписью

Критическая проблема: relay может предложить блок с невалидным payload или undervalued bid. MEV-boost проверяет минимальный порог (min-bid в ETH), ниже которого валидатор строит блок самостоятельно:

# Запуск MEV-Boost с несколькими relay и минимальным bid
./mev-boost \
  -relay https://[email protected] \
  -relay https://[email protected] \
  -relay https://[email protected] \
  -min-bid 0.05 \
  -addr 0.0.0.0:18550

Timing games

Продвинутая стратегия для максимизации MEV — late block proposals. Валидатор имеет полный слот (12 секунд) на публикацию блока. Если ждать до последних 2–4 секунд, builder успевает включить больше MEV-транзакций из мемпула (последние арбитражи, больше swap-транзакций). Риск: при задержке > T+9 секунд растёт вероятность missed slot, что стоит дороже выигрыша от late arrival.

Оптимальный timing зависит от сетевых условий и географии инфраструктуры. Рекомендуется собственный мониторинг: логировать время получения bid от каждого relay, время публикации блока, итоговую стоимость.

Самостоятельное MEV: собственный builder

Крупные staking провайдеры (Lido, EigenLayer operators, Coinbase) строят собственные builders для вертикальной интеграции MEV. Это имеет смысл от ~1000+ активных validators.

Архитектура builder

Mempool monitoring → Transaction ordering → Block template → 
Simulation → Bid calculation → Submission to relay network

Simulation engine — центральный компонент. Каждый bundled transactions должен быть симулирован перед включением в блок: проверка газа, проверка отсутствия reverting транзакций, расчёт реального profit после газа:

type SimulationResult struct {
    Profit    *big.Int
    GasUsed   uint64
    Reverted  bool
    StateRoot common.Hash
}

func (b *Builder) simulateBundle(bundle *Bundle, state *state.StateDB) SimulationResult {
    snapshot := state.Snapshot()
    defer state.RevertToSnapshot(snapshot)
    
    totalGasUsed := uint64(0)
    totalProfit := new(big.Int)
    
    for _, tx := range bundle.Transactions {
        result, err := b.evm.Call(tx, state)
        if err != nil || result.Failed() {
            return SimulationResult{Reverted: true}
        }
        totalGasUsed += result.UsedGas
        // расчёт profit из coinbase transfers и gas premium
    }
    
    return SimulationResult{
        Profit:   totalProfit,
        GasUsed:  totalGasUsed,
        Reverted: false,
    }
}

Стратегии ордеринга транзакций

MEVMAX ordering — жадный алгоритм: сортировка транзакций по effectiveFeePerGas в убывающем порядке. Простой и предсказуемый, но не оптимальный при наличии interdependent транзакций (bundles).

Knapsack optimization — транзакции с зависимостями рассматриваются как атомарные группы. NP-hard в общем случае, решается heuristics (greedy + beam search) для практических block sizes.

Bundle merging — два не конфликтующих bundle могут быть включены в один блок. Обнаружение конфликтов — через state access lists (EIP-2930): если два bundle не трогают одни и те же storage slots, они независимы.

Локальные MEV-стратегии (независимо от relay)

Arbitrage

Классический CEX-DEX арбитраж: цена на Binance выше on-chain Uniswap → купить on-chain, продать на CEX. Validator имеет естественное преимущество: может включить свои транзакции в любую позицию блока без газовой войны.

Для валидатора это означает: при обнаружении арбитражной возможности — включить собственный arb bundle в начало блока без priority fee (экономия на gas).

Liquidation capture

Aave, Compound, MakerDAO имеют позиции, которые становятся ликвидируемыми при изменении цен. Мониторинг unhealthy positions:

async def monitor_aave_positions(web3: Web3) -> List[LiquidatablePosition]:
    # Получить все активные займы через события Borrow
    borrow_events = await get_all_borrow_events()
    
    liquidatable = []
    for position in borrow_events:
        account_data = await aave.functions.getUserAccountData(
            position.borrower
        ).call()
        
        health_factor = account_data[5]  # в wei (1e18 = 1.0)
        if health_factor < 10**18:  # < 1.0
            liquidatable.append(LiquidatablePosition(
                borrower=position.borrower,
                health_factor=health_factor / 10**18,
                max_debt_to_liquidate=account_data[1]
            ))
    
    return sorted(liquidatable, key=lambda p: p.health_factor)

Sandwich prevention (anti-MEV сервис)

Другая монетизация для валидаторов с крупными staking операциями: предлагать private mempool для DEX-пользователей (за fee), гарантируя отсутствие sandwich attacks. По сути — конкурент Flashbots Protect, но с гарантией включения в блоки конкретного валидатора.

Compliance и риски

С июля 2023 OFAC sanction list применяется к relay. Большинство крупных relay отказываются включать транзакции к/от санкционированных адресов (Tornado Cash). Валидатор, использующий некензурируемые relay, технически не нарушает правила Ethereum-протокола — censorship resistance является фичей блокчейна. Но юридический риск для регулируемых операторов существует.

Проседание при missed slot: если MEV-boost блок не приходит в срок (relay timeout), consensus client должен автоматически перейти на locally-built блок. Критическая настройка: --local-block-value-boost 10 в Lighthouse — предпочитать локальный блок, если его стоимость в пределах 10% от MEV-boost бида (защита от relay downtime).

Метрики и мониторинг

Обязательный мониторинг для MEV-валидатора:

# Grafana дашборд метрики
- mevboost_bid_received_total: кол-во полученных bids по relay
- mevboost_bid_value_eth: распределение bid values  
- validator_block_value_eth: итоговый доход за блок
- missed_slots_total: пропущенные слоты
- local_block_fallback_total: сколько раз использовался local block

Сравнение validator_block_value_eth с p50/p95 по сети помогает оценить качество relay конфигурации. Если median block value ниже сетевого — проблема с relay latency или конфигурацией.

Разработка полной MEV-инфраструктуры для крупного стейкинг оператора (10k+ validators): 3–5 месяцев. Базовая MEV-Boost конфигурация с мониторингом — 2–3 недели.