Разработка системы прогнозирования цен на газ в Ethereum

Пользователь хочет отправить транзакцию, но не знает, сколько она будет стоить через 30 минут или 2 часа. Простой ответ «смотри на текущий baseFee» не работает — он меняется каждые 12 секунд и на длинных горизонтах бесполезен. Мы разрабатываем системы прогнозирования газовых цен под ключ для DeFi-проектов, используя ML и on-chain анализ. Наш опыт — более 5 лет, более 10 реализованных проектов. Система собирает исторические данные за несколько месяцев, строит модель на базе XGBoost или Prophet и отдаёт прогноз через REST API. Мы предоставляем документацию, обучение и поддержку после внедрения. Гарантируем точность прогнозов и интеграцию в ваш стек. Получите консультацию по выбору модели прогнозирования для вашего проекта.

Как устроен gas pricing после EIP-1559?

Механизм gas стал двухкомпонентным:

• baseFee — алгоритмически определяемая базовая комиссия, сжигаемая навсегда. Изменяется на максимум ±12.5% от блока к блоку в зависимости от того, был ли предыдущий блок заполнен более или менее чем на 50% (target_gas_used = block_gas_limit / 2).
• maxPriorityFee (tip) — чаевые валидатору. Пользователь выставляет сам, рынок определяет минимальный приемлемый уровень.
• maxFeePerGas — максимум, который пользователь готов заплатить. Фактически уплачивается baseFee + min(tip, maxFeePerGas - baseFee).

Формула изменения baseFee:

baseFee_new = baseFee_old * (1 + 0.125 * (gas_used - target_gas) / target_gas) 

Это ключевое: baseFee детерминированно вычисляется из on-chain данных. Если знаешь gas utilization каждого блока, можно точно реконструировать историческую baseFee и строить модель. Подробнее — в спецификации EIP-1559.

Какие данные нужны для прогнозирования?

Минимальный набор данных для каждого блока:

interface BlockGasData {
    blockNumber: bigint;
    timestamp: number;
    baseFeePerGas: bigint;
    gasUsed: bigint;
    gasLimit: bigint;
    utilizationRate: number; // gasUsed / gasLimit
    // из транзакций в блоке:
    medianPriorityFee: bigint;
    p25PriorityFee: bigint;
    p75PriorityFee: bigint;
    p95PriorityFee: bigint;
    txCount: number;
    mempoolSizeAtBlock?: number; // если есть доступ к mempool данным
}

Пошаговая инструкция по сбору данных

1. Подключите архивный узел Ethereum (Alchemy/QuickNode Archive) или используйте публичные датасеты (Dune Analytics, BigQuery).
2. Настройте WebSocket на newHeads и для каждого блока дополнительно запрашивайте eth_getBlockByNumber с флагом true для получения транзакций.
3. Собирайте данные минимум за 3–6 месяцев — этого достаточно для захвата разных рыночных условий (bull/bear, NFT-mints).
4. Опционально: подпишитесь на mempool через Mempool.space API или Blocknative для более точного краткосрочного прогноза.

Как работает краткосрочный прогноз (1–10 блоков, ~12–120 секунд)?

Детерминированная модель: следующая baseFee вычисляется точно из текущей плюс текущего utilization. На 5–10 блоков можно применять марковскую цепь на основе исторических паттернов utilization.

def predict_next_basefee(current_basefee: int, utilization: float) -> int:
    change = 0.125 * (utilization - 0.5)  # -0.0625 to +0.0625
    return int(current_basefee * (1 + change))

Это детерминировано для следующего блока. Для горизонта 5–10 блоков используем Monte Carlo симуляцию с распределением utilization из исторических данных.

Как работает среднесрочный прогноз (10 мин – 2 часа)?

Здесь детерминизм заканчивается, начинается ML. XGBoost / LightGBM с временными признаками хорошо работают для tabular данных:

• Фичи: текущая baseFee, rolling average за 10/30/60 блоков, time of day (sin/cos encoding), day of week, pending tx count в mempool, recent utilization trend
• Target: baseFee через N блоков

LSTM / Transformer — лучше улавливают долгосрочные паттерны, но сложнее в обслуживании. Для практической системы часто хватает gradient boosting.

Метрика качества: не RMSE, а практическая — какой % времени пользователь, поставивший recommended gas, попал в следующий блок vs. переплатил vs. застрял.

Как работает долгосрочный прогноз (2–48 часов)?

На таких горизонтах доминирует временная сезонность. Prophet (Facebook) хорошо справляется с суточными и недельными паттернами:

from prophet import Prophet
model = Prophet(
    daily_seasonality=True,
    weekly_seasonality=True,
    changepoint_prior_scale=0.05
)
model.fit(df[["ds", "y"]])  # ds=timestamp, y=basefee_gwei
forecast = model.predict(future_df)

Практическая точность на 24h горизонте: ±30–50% от медианного значения. Достаточно чтобы дать совет «завтра утром UTC газ будет значительно ниже, чем сейчас». Подробнее — Prophet.

Таблица 1: Сравнение моделей прогнозирования

Таблица 2: Сравнение источников данных

Рекомендации для конкретных сценариев

Система должна конвертировать прогноз в actionable рекомендации:

interface GasRecommendation {
  scenario: "fast" | "standard" | "economy";
  maxFeePerGas: bigint; // в wei
  maxPriorityFee: bigint; // в wei
  estimatedInclusionTime: number; // секунды
  confidence: number; // 0–1
  usdCostFor21000Gas: number; // для простого transfer
}

Economy сценарий: «если не торопитесь — подождите до UTC 04:00, gasWei будет ~40% от текущего». Используем исторические перцентили для часовых сегментов.

API и интеграция

Результаты прогнозирования отдаём через REST API:

GET /v1/gas/current — текущие цены + краткосрочный прогноз
GET /v1/gas/forecast?hours=24 — прогноз на период
GET /v1/gas/recommend?speed=economy — рекомендация для сценария
WS /v1/gas/stream — обновления каждый блок

Кешируем результаты: текущие данные — TTL 12 сек (один блок), краткосрочный прогноз — TTL 1 мин, долгосрочный — TTL 15 мин. Redis.

Что входит в работу

• Документация архитектуры и API (Swagger/OpenAPI)
• Доступ к дашборду мониторинга точности прогнозов (Grafana)
• Обучение команды заказчика работе с системой
• Техническая поддержка в течение 1 месяца после внедрения
• Интеграция с существующей инфраструктурой (cloud, CI/CD)

Реалистичный срок разработки системы с ML прогнозированием и API: 8–12 недель. Стоимость рассчитывается индивидуально. Свяжитесь с нами для обсуждения вашего проекта — мы подготовим оценку за 2 дня.