פיתוח גשש גז מוכן לשימוש: מערכת ניטור גז בבלוקצ'יין

פיתוח גשש גז נראה פשוט במבט ראשון: רק לשלוף eth_gasPrice ולהציג אותו. בפועל, פרוטוקולי DeFi מפסידים עד 30% מעמלות בגלל תזמון לקוי או התעלמות ממרכיבי EIP-1559. אנחנו בונים לא דשבורד אלא מערכת הנדסית: אנו אוספים baseFee ו-priorityFee לכל בלוק, מאחסנים אותם ב-TimescaleDB, חוזים 5–10 בלוקים קדימה, ומשרתים דרך REST API עם WebSocket. במשך 5 שנים, בנינו גששי גז ליותר מ-30 פרויקטים, כולל DEXים מרכזיים וקבוצות מחקר. הנה מה שיש מתחת למכסה המנוע ומה אתה מקבל מוכן לשימוש.

איך גשש גז עובד מתחת למכסה המנוע?

EIP-1559: הנוסחה המרכזית

אחרי EIP-1559 (ההארד פורק של לונדון), מחיר הגז מורכב משני חלקים:

• baseFeePerGas — העמלה הבסיסית, נשרפת. נקבעת על ידי הפרוטוקול: אם בלוק מלא ביותר מ-50%, העמלה הבסיסית עולה ב-12.5%; אם פחות מ-50%, היא יורדת. צפויה 1–2 בלוקים קדימה.
• maxPriorityFeePerGas (טיפ) — תשר לכורה/לוולידטור. מונע על ידי השוק: אתה מתחרה על הכללת הבלוק.

עלות עסקה אמיתית: min(maxFeePerGas, baseFeePerGas + priorityFee) * gasUsed. גשש גז חייב לעקוב אחר שני המרכיבים בנפרד, לא רק אחרי המחיר הסופי.

איסוף נתונים: קולקטור ואחסון

המקור הראשי הוא eth_feeHistory. הוא מחזיר baseFee, gasUsedRatio, וסטטיסטיקות אחוזונים של 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) 

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) נותן את המחיר הנוכחי בזמן הבקשה. נתוני Mempool (עסקאות ממתינות) משמשים לניתוח תחרות בזמן אמת.

אנו מאחסנים נתונים ב-TimescaleDB, אידיאלי לסדרות זמן:

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'); 

מדיניות שמירה: נתונים לכל בלוק למשך 7 ימים, מצטברים שעתיים לשנה, מצטברים יומיים ללא הגבלת זמן.

מה כלול בגשש גז מוכן לשימוש?

אנו גם מבטיחים דיוק נתונים: אנו כותבים בדיקות לקולקטור, מנטרים דרך Tenderly, ומשתמשים ב-Slither לאימות חוזים חכמים (אם חוזים הם חלק מהמערכת).

אילו סוגי נתונים גשש גז אוסף?

מעבר למרכיבים הבסיסיים, אנו אוספים מדדים לכל בלוק: מספר עסקאות, עמלות priority ממוצעות וחציוניות לפי אחוזונים, מלאות בלוק (gasUsedRatio). זה מאפשר לא רק המלצות בזמן אמת אלא גם התפלגויות היסטוריות — לדוגמה, ההסתברות להיכלל בבלוק עם תשר נתון. עבור מערכות ריבוי רשתות, עמלת נתונים L1 (עבור 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 } 

עמלת העדיפות מונעת על ידי השוק וקשה יותר לחיזוי. אנו משתמשים ב-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 

אנו גם מתחשבים בדפוסי זמן: גז זול יותר בשעות 02:00–08:00 UTC. אנו מציגים "חלון אופטימלי" לעסקאות שאינן דחופות.

למה לבחור ב-TimescaleDB לאחסון?

TimescaleDB היא הרחבה של PostgreSQL לסדרות זמן. היא מחלקת אוטומטית לפי זמן, יוצרת מצטברים רציפים, ומאפשרת שאילתות חלון מהירות. חלופות (InfluxDB, ClickHouse) דורשות מחסנית נפרדת; TimescaleDB משתלבת במסד נתונים רלציוני מוכר — פחות תקורה.

השוואת אחסון

API ואינטגרציה

נקודות קצה REST:

• eth_gasPrice — המלצות נוכחיות {slow, standard, fast, instant}
• 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'); — היסטוריה מצטברת
• 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 } — תחזית ל-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 — נתונים לפי רשת

WebSocket מספק עדכונים בכל בלוק חדש ללא סקרים. תמיכה בריבוי רשתות: קולקטור נפרד לכל רשת; עבור L2 (Arbitrum, Optimism, Base), אנו מתחשבים בגז דו-מרכיבי.

תהליך אינטגרציה:

1. ביקורת — ניתוח עומס ורשתות נדרשות.
2. ארכיטקטורה — בחירת ספקי RPC, סכימת מסד נתונים.
3. קולקטור — פריסה ב-Docker, הגדרת ניטור.
4. API — יצירת תיעוד OpenAPI.
5. בדיקות — הצלבה עם Etherscan למשך שבוע.
6. פריסה — ל-Kubernetes cluster שלך או לשרת פיזי.

לוחות זמנים ועלות

גרסה בסיסית (Ethereum mainnet, היסטוריה + המלצות נוכחיות) — 5–8 ימים. ריבוי רשתות עם חיזויים ואנליטיקה מפורטת — 2–3 שבועות. העלות מחושבת באופן אישי לפי הצרכים שלך — צור קשר להערכת פרויקט. פנה אלינו עכשיו וקבל ייעוץ מהנדס על ארכיטקטורת גשש גז. הזמן פיתוח — נתחיל בניתוח הנתונים שלך.