Розробка gas tracker під ключ: система моніторингу газу для EVM-мереж

Розробка gas tracker: система відстеження газу для блокчейну

Розробка gas tracker — завдання, яке на перший погляд здається простим: взяти eth_gasPrice і показати. На практиці ж DeFi-протоколи втрачають до 30% на комісіях через неправильний вибір моменту або неврахування компонентів EIP-1559. Ми будуємо не дашборд, а інженерну систему: збираємо baseFee та priorityFee по кожному блоку, зберігаємо в TimescaleDB, передбачаємо на 5–10 блоків і віддаємо через API з WebSocket. За 5 років роботи ми зробили gas трекери для 30+ проектів, включаючи великі DEX та дослідницькі групи. Нижче — як це влаштовано зсередини і що ви отримаєте під ключ.

Як влаштований gas tracker під капотом?

EIP-1559: основна формула

Після EIP-1559 (лондонський хардфорк) ціна газу складається з двох частин:

baseFeePerGas — базова комісія, спалюється. Визначається протоколом: якщо блок > 50% заповненості, base fee зростає на 12.5%, якщо < 50% — падає. Передбачувана на 1-2 блоки вперед.

maxPriorityFeePerGas (tip) — чайові майнеру/валідатору. Ринкова частина — конкуруєте за включення в блок.

Реальна вартість транзакції: min(maxFeePerGas, baseFeePerGas + priorityFee) * gasUsed. Для gas tracker важливо відстежувати обидва компоненти окремо, не лише підсумкову ціну.

Збір даних: колектор та зберігання

Основне джерело — eth_feeHistory. Повертає baseFee, gasUsedRatio та percentile-статистику priorityFee за діапазон блоків. Використовуємо viem:

import { createPublicClient, http } from 'viem' import { mainnet } from 'viem/chains' const client = createPublicClient({ chain: mainnet, transport: http(RPC_URL) }) const feeHistory = await client.getFeeHistory({ blockCount: 100, rewardPercentiles: [25, 50, 75, 95], }) // feeHistory.baseFeePerGas: BigInt[] // feeHistory.reward: BigInt[][] // feeHistory.gasUsedRatio: number[] (0..1) 

eth_gasPrice — актуальна ціна на момент запиту. Mempool дані (pending транзакції) — для real-time аналізу конкуренції.

Зберігаємо дані в TimescaleDB — оптимально для time-series:

CREATE TABLE gas_stats ( time TIMESTAMPTZ NOT NULL, block_number BIGINT NOT NULL, base_fee_gwei NUMERIC(20, 9) NOT NULL, tip_slow NUMERIC(20, 9), tip_standard NUMERIC(20, 9), tip_fast NUMERIC(20, 9), tip_instant NUMERIC(20, 9), gas_used_ratio NUMERIC(5, 4), network VARCHAR(50) NOT NULL DEFAULT 'ethereum' ); SELECT create_hypertable('gas_stats', 'time'); 

Retention policy: детальні дані по блоках — 7 днів, годинні агрегати — 1 рік, денні — безстроково.

Що входить у розробку gas tracker під ключ?

Також гарантуємо точність даних: пишемо тести для колектора, моніторинг через Tenderly, використовуємо Slither для перевірки смарт-контрактів (якщо вони частина системи).

Які типи даних збирає gas tracker?

Окрім базових компонентів, ми збираємо метрики для кожного блоку: кількість транзакцій, середня та медіанна priorityFee по процентилях, заповненість блоку (gasUsedRatio). Це дозволяє будувати не лише поточні рекомендації, а й історичні розподіли — наприклад, шанс потрапити в блок із заданим tip. Для мультичейн-систем додатково логується L1 data fee (для L2) та вартість мосту. Всі дані потрапляють у TimescaleDB з автоматичною агрегацією.

Як ми прогнозуємо газ?

Простий вивід поточного baseFee недостатній. Потрібна оцінка: "скільки поставити, щоб потрапити в наступний блок з імовірністю X%?".

Наступний baseFee передбачуваний точно:

function predictNextBaseFee(currentBaseFee: bigint, gasUsedRatio: number): bigint { const targetRatio = 0.5 const maxChangeDenominator = 8n const delta = gasUsedRatio - targetRatio const change = (currentBaseFee * BigInt(Math.round(delta * 1000))) / (maxChangeDenominator * 1000n) return currentBaseFee + change } 

Priority fee — ринкова, передбачити складніше. Використовуємо EMA останніх N блоків:

def calculate_priority_fee_estimate( recent_tips: list[float], alpha: float = 0.3, ) -> float: ema = recent_tips[0] for tip in recent_tips[1:]: ema = alpha * tip + (1 - alpha) * ema return ema 

Також враховуємо часові патерни: газ дешевший у UTC 02:00-08:00. Показуємо "оптимальне вікно" для нетермінових транзакцій.

Чому варто обрати TimescaleDB для зберігання?

TimescaleDB — PostgreSQL extension для time-series. Дозволяє автоматично партиціонувати за часом, створювати неперервні агрегати та швидко виконувати віконні запити. Альтернативи (InfluxDB, ClickHouse) вимагають окремого стеку, а TimescaleDB вбудовується у звичну реляційну БД — менше overhead.

Порівняння варіантів зберігання

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

REST endpoints:

• GET /api/gas/current — поточні рекомендації {slow, standard, fast, instant}
• GET /api/gas/history?period=24h — історія з агрегацією
• GET /api/gas/predict?blocks=5 — прогноз на N блоків
• GET /api/gas/networks — дані по мережах

WebSocket — клієнт отримує оновлення на кожний новий блок без polling. Мультичейн підтримка: окремий колектор для кожної мережі, для L2 (Arbitrum, Optimism, Base) враховуємо двокомпонентний газ.

Процес інтеграції:

1. Аудит — аналізуємо навантаження та необхідні мережі.
2. Архітектура — підбираємо RPC-провайдерів, схему бази.
3. Колектор — розгортаємо в Docker, налаштовуємо моніторинг.
4. API — генеруємо OpenAPI-документацію.
5. Тестування — звіряємо дані з Etherscan за тиждень.
6. Деплой — на ваш кластер Kubernetes або bare-metal.

Терміни та вартість

Розробка базової версії (Ethereum mainnet, історія + поточні рекомендації) — 5-8 днів. Мультичейн з передбаченнями та детальною аналітикою — 2-3 тижні. Вартість розраховується індивідуально під завдання — зв'яжіться з нами, оцінимо ваш проект. Звернувшись зараз, ви отримаєте консультацію інженера з архітектури gas tracker. Замовте розробку — почнемо з аналізу ваших даних.