פיתוח מערכת חיזוי מחיר גז לאתריום

משתמש רוצה לשלוח עסקה אבל לא יודע כמה היא תעלה בעוד 30 דקות או שעתיים. התשובה הפשוטה 'בדוק את ה- baseFee הנוכחי' לא עובדת — הוא משתנה כל 12 שניות וחסר תועלת בטווחי זמן ארוכים יותר. אנו מפתחים מערכות חיזוי מחיר גז turnkey עבור פרויקטי DeFi, תוך שימוש ב-ML וניתוח on-chain. הניסיון שלנו: 5+ שנים, 10+ פרויקטים. המערכת אוספת נתונים היסטוריים על פני מספר חודשים, בונה מודל המבוסס על XGBoost או Prophet, ומספקת תחזיות דרך REST API. אנו מספקים תיעוד, הדרכה ותמיכה לאחר הפריסה. אנו מבטיחים דיוק תחזית ואינטגרציה לתוך המחסנית שלך. קבלו ייעוץ לבחירת מודל התחזית המתאים לפרויקט שלכם.

איך תמחור הגז עובד אחרי EIP-1559?

מנגנון הגז הפך לשני מרכיבים:

• baseFee — עמלת בסיס הנקבעת אלגוריתמית ונשרפת לצמיתות. משתנה במקסימום של ±12.5% מבלוק לבלוק בהתאם לשאלה אם הבלוק הקודם מולא ביותר או פחות מ-50% (target_gas_used = block_gas_limit / 2).
• maxPriorityFee (טיפ) — טיפ ל-validator. המשתמש קובע אותו בעצמו; השוק קובע את הרמה המינימלית המקובלת.
• maxFeePerGas — המקסימום שהמשתמש מוכן לשלם. בפועל משולם baseFee + min(tip, maxFeePerGas - baseFee).

הנוסחה לשינוי baseFee:

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

זה המפתח: baseFee מחושב דטרמיניסטית מנתוני on-chain. אם אתה יודע את ניצול הגז של כל בלוק, אתה יכול לשחזר במדויק את ה- 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 ל-baseFee_new = baseFee_old * (1 + 0.125 * (gas_used - target_gas) / target_gas) ולכל בלוק בקשו בנוסף 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 данным } עם הדגל newHeads כדי לקבל עסקאות.
3. אספו נתונים למשך 3-6 חודשים לפחות — מספיק כדי ללכוד תנאי שוק שונים (bull/bear, NFT-mints).
4. אופציונלי: הירשמו ל-mempool דרך Mempool.space API או Blocknative לחיזוי קצר-טווח מדויק יותר.

איך עובד החיזוי קצר-הטווח (1-10 בלוקים, ~12-120 שניות)?

מודל דטרמיניסטי: ה- baseFee הבא מחושב בדיוק מהנוכחי בתוספת הניצול הנוכחי. עבור 5-10 בלוקים, אנו יכולים להחיל שרשרת מרקוב המבוססת על דפוסי ניצול היסטוריים.

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 בלוקים, אנו משתמשים בסימולציית מונטה קרלו עם התפלגות ניצול מנתונים היסטוריים.

איך עובד החיזוי לטווח-בינוני (10 דקות - שעתיים)?

כאן הדטרמיניזם מסתיים ו-ML מתחיל. XGBoost / LightGBM עם מאפייני זמן עובדים היטב עבור נתונים טבלאיים:

• מאפיינים: baseFee נוכחי, ממוצע נע על פני 10/30/60 בלוקים, שעה ביום (קידוד sin/cos), יום בשבוע, מספר עסקאות ממתינות ב-mempool, מגמת ניצול אחרונה
• יעד: baseFee אחרי N בלוקים

LSTM / Transformer — לוכדים טוב יותר דפוסים ארוכי-טווח אך מורכבים יותר לתחזוקה. עבור מערכת מעשית, gradient boosting לרוב מספיק.

מדד איכות: לא RMSE אלא מעשי — באיזה אחוז מהמקרים משתמש שהגדיר את מחיר הגז המומלץ נכנס לבלוק הבא לעומת שילם יותר מדי לעומת נתקע.

בפרויקט DeFi אחד, הפחתנו עסקאות שנכשלו ב-40% וחסכנו למשתמשים 25% על עמלות גז על ידי שילוב חיזוי לטווח-בינוני.

איך עובד החיזוי לטווח-ארוך (2-48 שעות)?

באופקים כאלה, עונתיות הזמן שולטת. Prophet (פייסבוק) מטפל היטב בדפוסים יומיים ושבועיים:

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) 

דיוק מעשי באופק של 24 שעות: ±30-50% מהערך החציוני. מספיק כדי לתת עצות כמו "הגז יהיה נמוך משמעותית מחר בבוקר UTC". פרטים נוספים ב-Prophet.

טבלה 1: השוואת מודלי חיזוי

טבלה 2: השוואת מקורות נתונים

המלצות לתרחישים ספציפיים

המערכת צריכה להמיר תחזיות להמלצות מעשיות:

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

תרחיש חסכוני: "אם לא ממהרים — חכו עד 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 דקה אחת, חיזוי ארוך-טווח — TTL 15 דקות. Redis.

מה כלול בעבודה

• תיעוד ארכיטקטורה ו-API (Swagger/OpenAPI)
• גישה ללוח מחוונים לניטור דיוק תחזית (Grafana)
• הדרכה של צוות הלקוח על שימוש במערכת
• תמיכה טכנית למשך חודש לאחר הפריסה
• אינטגרציה עם התשתית הקיימת (ענן, CI/CD)

ציר זמן ריאלי לפיתוח מערכת עם חיזוי ML ו-API: 8-12 שבועות. העלות מחושבת באופן אישי. צרו קשר כדי לדון בפרויקט שלכם — נכין הערכה תוך יומיים.