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

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

Реальна задача звучить так: користувач хоче виконати транзакцію, йому потрібно знати, скільки це буде коштувати через 30 хвилин, через 2 години і через 12 годин. Простий ответ "дивись на поточний baseFee" не працює — він змінюється кожні 12 секунд і на довгих горизонтах непотрібний. Потрібна система, яка прогнозує майбутні gas prices з розумною точністю для практичних рішень.

Як влаштований gas pricing на Ethereum (EIP-1559)

Після EIP-1559 в August 2021 механізм газу став двокомпонентним:

• 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 й будувати модель.

Збирання даних

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

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 даних
}

Історичні дані: для навчання моделі потрібні дані як мінімум за 3–6 місяців (різні ринкові умови, bull/bear періоди, события типу NFT mints і token launches які створювали gas spikes). Швидше отримати через Alchemy/QuickNode Archive API або публічні датасети (Dune Analytics, Google BigQuery Ethereum dataset).

Real-time дані: WebSocket підписка на newHeads, для кожного блоку додатково запитуємо eth_getBlockByNumber з true для отримання транзакцій (потрібні priority fees). На завантажених мережах — суттєвий обсяг даних, потребує rate-limit-aware polling.

Mempool дані — опціональні, але цінний сигнал. Pending транзакції показують "тиск спроса" до конфірмації. Доступні через eth_getFilterChanges або Mempool.space API, Blocknative streaming.

Часові паттерни

Gas prices мають виразну сезонність:

Внутрішньодобова: активність UTC 13:00–21:00 (перетин EU + US business hours) стабільно вище ніж UTC 02:00–10:00 (Asia ніч + US ніч). Різниця може бути 3–5x на baseFee.

День тижня: пятниця й вихідні — піки NFT і gaming активності. Понеділок–середа — DeFi й institutional операції.

События-піки: major NFT mint, token airdrop claim, protocol launch — газ може виросту в 10–50x за кілька хвилин. Не можна прогнозувати конкретний spike, але можна детектувати його початок і швидко оновити прогноз.

Моделі прогнозування

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

Детерміністична модель: наступна baseFee вичисляється точно з поточної + поточного utilization. На 5–10 блоків можна застосовувати Markov chain на основі історичних паттернів 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 блоків, час дня (sin/cos encoding), день тижня, pending tx count у mempool, recent utilization trend
• Target: baseFee через N блоків

LSTM / Transformer — краще ловлять довгостроковими паттерни, але складніше в обслуговуванні. Для практичної системи часто хватає gradient boosting.

Метрика якості: не RMSE, а практична — який % часу користувач з recommended газом потрапляє в наступний блок 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 газ буде значно нижче ніж зараз".

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

Система повинна конвертувати прогноз в 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.

Реалістичний срок розробки системи з ML прогнозуванням і API: 8–12 тижнів.