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