Розробка системи бектестингу DeFi-стратегій

Розроблення системи бэктестингу DeFi-стратегій

«Стратегія показувала 200% APY на бэктесті» — часто це означає, що бэктест був написаний неправильно. Найчастіша помилка: стратегія використовує closing price свічки, по якій вона ж та приймає рішення про вхід. Це look-ahead bias — у реальному часі ти не знаєш closing price поточної свічки. Другий варіант: бэктест ігнорує gas costs та slippage, перетворюючи збиткову стратегію на прибиткову на папері.

DeFi-специфічний бэктестинг складніше традиційного фінансового, тому що потребуються on-chain дані: історичні стани пулів, реальні ставки lending протоколів, історичний gas price, события ліквідацій та flash loans. Все це змінюється поблочно.

Джерела історичних on-chain даних

The Graph та subgraph архіви

The Graph індексує события on-chain з блоку деплоя. Для більшості крупних DeFi протоколів (Uniswap v2/v3, Aave v2/v3, Compound, Curve) існують офіційні subgraphs з історією всіх swap, deposit, borrow событій.

Проблема: hosted service The Graph має rate limits та періодично втрачає дані при реіндексації. Для серйозного бэктестингу потребується або власна Graph Node з архівною нодою Ethereum, або комерційні джерела (Dune Analytics, Flipside Crypto, Goldsky).

Dune Analytics — SQL-інтерфейс до декодованих on-chain даних. Дозволяє писати запити по событіям будь-якого контракту. Обмеження: API для програмного доступу дорогий, але для побудови датасетів одноразові вивантажувачи безплатні.

Архівні ноди

Деякі дані неможливо отримати з событій — потребується читання state конкретного блоку. Наприклад: balanceOf адреси в історичному блоці, totalSupply токена, ціна в AMM пулі в конкретний момент.

Для цього потребується архівна нода (archive node) — повна історія state. Infura, Alchemy, QuickNode надають архівний доступ через eth_call з параметром blockNumber. Власна архівна нода Ethereum займає 12+ TB.

from web3 import Web3

w3 = Web3(Web3.HTTPProvider(ARCHIVE_RPC_URL))

def get_pool_reserves_at_block(pool_address: str, block_number: int) -> tuple:
    """Отримання резервів Uniswap v2 пулу в конкретному блоці"""
    pool = w3.eth.contract(address=pool_address, abi=UNISWAP_V2_PAIR_ABI)
    reserves = pool.functions.getReserves().call(block_identifier=block_number)
    return reserves[0], reserves[1]

Архітектура системи бэктестингу

Шар даних

Завантажуємо та нормалізуємо історичні дані у локальну PostgreSQL базу. Схема:

-- Історичні события Uniswap v3 swap
CREATE TABLE uniswap_v3_swaps (
    block_number    BIGINT NOT NULL,
    block_timestamp TIMESTAMPTZ NOT NULL,
    tx_hash         BYTEA NOT NULL,
    pool_address    VARCHAR(42) NOT NULL,
    amount0         NUMERIC(78, 0),
    amount1         NUMERIC(78, 0),
    sqrt_price_x96  NUMERIC(78, 0),
    tick            INTEGER,
    liquidity       NUMERIC(78, 0),
    PRIMARY KEY (tx_hash, pool_address)
);

-- Історичні lending ставки (Aave)
CREATE TABLE aave_rate_history (
    block_number        BIGINT NOT NULL,
    block_timestamp     TIMESTAMPTZ NOT NULL,
    asset               VARCHAR(42) NOT NULL,
    liquidity_rate      NUMERIC(40, 0),  -- RAY
    variable_borrow_rate NUMERIC(40, 0),
    utilization_rate    NUMERIC(20, 18),
    PRIMARY KEY (block_number, asset)
);

-- Історичний gas price
CREATE TABLE gas_price_history (
    block_number    BIGINT PRIMARY KEY,
    block_timestamp TIMESTAMPTZ NOT NULL,
    base_fee_gwei   NUMERIC(20, 9),
    priority_fee_p50 NUMERIC(20, 9)
);

Симуляційний рухавик

Рухавик проходить по блокам послідовно, для кожного блоку викликає стратегію з доступними даними:

class BacktestEngine:
    def __init__(self, strategy: Strategy, start_block: int, end_block: int):
        self.strategy = strategy
        self.db = DataLayer()
        
    def run(self) -> BacktestResult:
        portfolio = Portfolio(initial_capital=self.strategy.config.initial_capital)
        
        for block_data in self.db.iter_blocks(self.start_block, self.end_block):
            # Тільки дані до поточного блоку — не look-ahead
            context = MarketContext(
                block=block_data,
                prices=self.db.get_prices_at(block_data.number),
                lending_rates=self.db.get_rates_at(block_data.number),
                gas_price=block_data.base_fee + block_data.priority_fee_p50,
            )
            
            signals = self.strategy.generate_signals(context, portfolio)
            
            for signal in signals:
                # Применяємо реалістичне виконання
                execution = self.simulate_execution(signal, context)
                portfolio.apply(execution)
                
        return BacktestResult(portfolio=portfolio, metrics=self.compute_metrics(portfolio))
    
    def simulate_execution(self, signal: Signal, ctx: MarketContext) -> Execution:
        """Враховуємо slippage, gas, partial fills"""
        slippage = self.estimate_slippage(signal.size, ctx.pool_liquidity)
        gas_cost_usd = ctx.gas_price * signal.estimated_gas * ctx.eth_price / 1e18
        executed_price = signal.direction * slippage
        
        return Execution(
            price=executed_price,
            gas_cost=gas_cost_usd,
            timestamp=ctx.block.timestamp,
        )

Розрахунок slippage

Для Uniswap v2: price_impact = trade_size / (pool_reserve × 2). Для v3 — точніше через математику concentrated liquidity, але для швидких прикидок v2 формула працює.

Для lending протоколів slippage не применяється, але є utilization impact: крупний депозит знижує utilization rate та відповідно APR наступних періодів.

Метрики бэктеста

Недостатньо дивитися тільки на P&L. Важливі метрики:

Gas-adjusted APY — ключова метрика саме для DeFi. Стратегія з 50% APY та щотижневим rebalancingом на Ethereum mainnet може мати 30% gas-adjusted APY. Та ж стратегія на Arbitrum — 45% (gas в 50x дешевше).

Стек

Python — pandas для часових рядів, sqlalchemy для роботи з PostgreSQL. PostgreSQL — зберігання історичних даних (TimescaleDB для часових рядів опціонально). The Graph / Dune — вивантажувачі даних. Plotly / Dash — інтерактивні графіки P&L, drawdown, equity curve. Celery — черги для паралельних бэктестів (перебір параметрів).

Орієнтири за часом

Система для одного протоколу та однієї стратегії з базовими метриками — 1-2 тижні. Повноцінна мульти-протокольна платформа з паралельним перебором параметрів та dashboard — 4-6 тижнів. Час на збір історичних даних залежить від глибини архіву. Вартість розраховується індивідуально.