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

Ми розробляємо MEV-стратегії для валідаторів — від базового налаштування MEV-Boost до власного builder під ключ.

Наш досвід включає понад 50 проєктів за 5 років роботи, і ми гарантуємо збільшення дохідності на 20–40% за рахунок оптимізації relay, timing games та власних арбітражних бандлів. Оцінимо вашу поточну конфігурацію.

Після переходу 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 дає у 2 рази більший контроль над доходами, але потребує у 10 разів більше ресурсів на розробку та підтримку.

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

Для валідатора це означає: при виявленні арбітражної можливості — включити власний 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 і ризики

Після введення санкційних списків більшість великих 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-інфраструктури та рекомендації щодо налаштування relay.
• Конфігурація MEV-Boost з моніторингом (Grafana дашборд, алерти).
• Розробка власного builder (за потреби) з симуляцією та оптимізацією ордерингу.
• Впровадження стратегій арбітражу та ліквідацій з нульовою затримкою.
• Навчання команди та документація з експлуатації.
• Технічна підтримка на 3 місяці після запуску.

Розробка повної MEV-інфраструктури для великого стейкінг оператора (10k+ validators) займає від 3 до 5 місяців. Базова MEV-Boost конфігурація з моніторингом — 2–3 тижні. Зв'яжіться з нами для оцінки вашого проєкту — розрахуємо вартість і терміни індивідуально.