Разработка системы прогнозирования цен на газ в 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 дня.