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

Для валідатора це означає: при виявленні арбітражної можливості — включити собственний 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-користувачів (за комісію), гарантуючи відсутність 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 bidu (захист від 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-інфраструктури для крупного staking оператора (10k+ validators): 3–5 місяців. Базова MEV-Boost конфігурація з мониторингом — 2–3 тижні.