Разработка системы бэктестинга DeFi-стратегий
«Стратегия показывала 200% APY на бэктесте» — часто это означает, что бэктест был написан с ошибками. Самая распространённая: стратегия использует closing price свечи, по которой принимает решение о входе. Это look-ahead bias — в реальном времени вы не знаете closing price текущей свечи. Второй вариант: бэктест игнорирует gas costs и slippage, превращая убыточную стратегию в прибыльную на бумаге. Мы разрабатываем системы бэктестинга, которые исключают эти ошибки и учитывают все on-chain реалии: историческое состояние пулов, реальные ставки lending протоколов, потери от комиссий газа.
DeFi-специфичный бэктестинг сложнее традиционного финансового, поскольку требует on-chain данных: исторические состояния пулов, реальные ставки lending протоколов, исторический gas price, события ликвидаций и flash loans. Всё это меняется поблочно.
Как избежать look-ahead bias в бэктесте?
Look-ahead bias устраняется строгой привязкой к хронологии блоков. Движок бэктеста последовательно проходит по блокам от начального до конечного, и на каждом блоке стратегия видит только данные, доступные до этого блока. Например, для входа по цене свечи нужно использовать цену открытия, а не закрытия. Если стратегия использует индикаторы на основе исторических данных, они должны строиться только на данных до текущего блока.
Источники исторических 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 для программного доступа дорогой, но для построения датасетов разовые выгрузки бесплатны.
| Источник данных | Тип доступа | Лимиты | Стоимость |
|---|---|---|---|
| The Graph (Hosted) | GraphQL | 10 req/s | Бесплатно (с ограничениями) |
| Dune Analytics | SQL | 1 req/s (Free) | Бесплатно / Pro $390 |
| Архивная нода (Alchemy) | eth_call | 100k req/day (Free) | Плата за трафик |
Архивные ноды
Некоторые данные нельзя получить из событий — нужно читать 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
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):
# Только данные до текущего блока — no 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 следующих периодов.Какие метрики показывают эффективность DeFi-стратегии?
Недостаточно смотреть только на P&L. Наш опыт (более 5 лет в DeFi-разработке, 10+ внедрённых систем) показывает, что критичны метрики Gas-adjusted APY, Sharpe и Sortino ratio. Gas-adjusted APY — ключевая метрика для DeFi: стратегия с 50% APY и еженедельным ребалансингом на Ethereum mainnet может иметь 30% gas-adjusted APY, а на Arbitrum — 45%.
| Метрика | Формула | Benchmark |
|---|---|---|
| Sharpe ratio | (returns - risk_free) / std_dev | >1.5 хорошо |
| Sortino ratio | (returns - risk_free) / downside_std | >2.0 хорошо |
| Max drawdown | peak_to_trough / peak | <30% для DeFi |
| Calmar ratio | annual_return / max_drawdown | >1.0 |
| Gas-adjusted APY | APY с вычетом gas costs | Зависит от L2 |
Как мы строим систему? Процесс и сроки
Мы гарантируем корректность бэктеста за счёт строгого контроля look-ahead bias и реалистичных исполнений. Работа включает:
- Анализ стратегии и выбор протоколов
- Интеграцию источников on-chain данных (The Graph, Dune, архивные ноды)
- Разработку симуляционного движка с учётом gas и slippage
- Реализацию метрик и дашборда
- Тестирование на исторических данных
- Передачу документации и обучение команды
Сроки: система для одного протокола — от 1 до 2 недель, мультипротокольная — от 4 до 6 недель. Всё выполняется под ключ. Свяжитесь с нами, чтобы оценить ваш проект.