פיתוח gas tracker מפתח ביד: מערכת לניטור גז עבור רשתות EVM

למה gas tracker משקר: צווארי בקבוק בניטור gas

כמעט כל gas tracker נבנה ממה שיש בהישג יד: צומת ציבורי, כמה אגרגטורים, מטמון בצד השירות. כשהרשת שקטה, המקורות נותנים מספרים קרובים, ומערכת ניטור gas נראית מדויקת. ההבדל מתגלה בקפיצה — ואז בדיוק הפער בנתונים נעשה מורגש.

הסיבה הראשונה — השהיית עדכון. בעוד צומת אחד עוד לא ראה את זרם הטרנזקציות הממתינות, אחר כבר בנה מחדש את ההערכה, ובמסכים סמוכים עלות הטרנזקציה שונה פי כמה. המשתמש רואה לא את השוק, אלא את הפער במהירות סקירת המקורות.

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

השלישית — קיבוץ העמלה למספר אחד: אחרי המעבר של רשתות למכרז עם חלק בסיס וטיפים, התוצאה תלויה בשני המרכיבים, וטרקר שמציג רק "מחיר gas" לא מסביר למה באותו ערך הטרנזקציה מאושרת פעם בבלוק הבא ופעם בעוד שעה.

שכבה נוספת — התחשבות רק בהערכה, בלי השוואה להכללה בפועל של טרנזקציות בבלוקים ובלי טיפול בארגון מחדש של השרשרת. בגלל זה המספר בדשבורד והצריכה בפועל נבדלים באופן מערכתי, לא אפיזודי. נפרק איך זה נסגר בניטור gas עובד.

מה משתנה אחרי הטמעה: מהירות, דיוק, עמידות

דיוק הערכת gas מפסיק להיות קבוע עם מרווח. החישוב יוצא מעמלת הבסיס של הבלוקים האחרונים, מהתפלגות תוספות העדיפות ומפרופיל העומס של מאגר הטרנזקציות הממתינות — ההצעה נבנית לתרחיש מסוים (העברה, קריאה לחוזה, תשלום המוני), ולא לפי מכפיל אחיד להכול.

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

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

תחזית העלות נותנת חלון קדימה, לא תמונת מצב של "עכשיו". לפיה מתכננים פעולות המוניות ותשלומים: התור עובר לחלונות שקטים, לא לשיא, ועלות הביצוע מפסיקה להיות תלויה במי שלחץ על הכפתור ברגע מוצלח.

עמידות השירות היא תוצאה של הארכיטקטורה, לא הבטחה. כמה מקורות RPC עצמאיים, בקרת פיגור של צומת, חציצת התראות כערוץ אינו זמין ומסירה חוזרת בלי אובדן אירועים. כשל של מקור אחד לא הופך לשטח עיוור, וההידרדרות נראית במטריקות לפני שהיא נראית בתלונות.

דרכים לאיסוף נתוני gas: השוואת גישות

דיוק תחזית ה-gas נקבע לא לפי נוסחה, אלא לפי מקורות הנתונים: עמלת הבסיס מחושבת מחדש בכל בלוק, ועמלת העדיפות תלויה בתחרות ב-mempool. מקור אחד נותן תמונת מצב לרגע הבקשה ולא מציג דינמיקה — לפיו אי אפשר להבחין בין קפיצה חד-פעמית לעלייה מתמשכת. ההבדל בין הגישות טמון בהשהיה, בשלמות ובעלות התחזוקה, והוא בדיוק מה שקובע מה תוכלו להציג בממשק.

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

תדירות הסקירה מוגדרת בנפרד לעמלת הבסיס ולעמלת העדיפות: סקירה נדירה נותנת גרף חלק לאנליטיקה ולהיסטוריה, וסקירה תכופה — תגובה לקפיצות ברגע שליחת הטרנזקציה.

שלבי פיתוח: מביקורת מקורות ועד מסירה

פיתוח gas tracker הוא לא סקריפט אחד, אלא רצף עבודות הנדסיות, שבו טעות בהתחלה עולה הכי יקר: סכמת איסוף נתונים שגויה מתגלה רק תחת עומס, כשבנייה מחדש יקרה יותר מתכנון מאפס. לכן שלבי ההטמעה הולכים מביקורת מקורות למסירת המערכת, וכל שלב מסתיים בארטיפקט ניתן לבדיקה.

1. ביקורת מקורות. אוספים רשימה של צמתי רשת, סורקי בלוקים וספקי נתונים חיצוניים, ומשווים את הקריאות שלהם בעמלת הבסיס ובעמלת העדיפות לאותו פרק זמן. פער של אחוזים בודדים מעיד על שיטות מיצוע שונות — קובעים אחת, אחרת ההתראות יתחילו לסתור זו את זו.

2. סכמת איסוף נתונים. מגדירים מה נלקח: כל בלוק או רק בעייתיים, והאם בנפרד זרם הטרנזקציות הממתינות. מתכננים גיבוי — כשצומת ראשי נכשל, המעבר אוטומטי, בלי בלוקים שהוחמצו ובלי הפסקות בהיסטוריה.

3. אחסון והתראות. מגדירים אחסון סדרות זמן עם עומק ארכיון וספים: עמלת בסיס מעל ערך נתון יותר מ-N דקות, קפיצה בתור ההמתנה, צריכת gas חריגה בבלוק. התראות יוצאות למסנג'ר, לכתובת callback ולפאנל הניטור.

4. בדיקה תחת עומס. מריצים את המערכת על זרם בלוקים אמיתי, כולל קפיצות פעילות וארגון מחדש של השרשרת. בודקים השהיה מהופעת הטרנזקציה ועד ההתראה, שלמות ההיסטוריה והתנהגות כשלא זמין אחד מהמקורות.

5. מסירת המערכת. פורסים בתשתית שלכם, מוסרים קונפיגורציות, סכמת נתונים, תיאורי ספים ומדריך. מלמדים את צוות התורנות לשנות ספים ומסלולי התראות בלי שנצטרך להיות שם.

ארטיפקטי מסירה: סכמות, קונפיגורציות, נהלים

אחרי המסירה נשאר ללקוח לא רק ניטור gas עובד, אלא גם ערכת מסמכים שלפיה הצוות יכול לפתח ולתחזק את המערכת בלעדינו. להלן מה נכלל במסירה ולפי אילו קריטריונים היא מתקבלת.

• תיעוד המערכת: סכמת זרימות נתונים מסקירת צמתי הרשת ועד כתיבה במאגר ושליחת התראה, עם רשימת נקודות כשל ופעולות לכל אחת מהן.
• קונפיגורציות שירותים: קבצי הגדרות של האספן, האגרגטור, המאגר והפאנל עם הסבר לכל פרמטר, ערכי ברירת מחדל וגבולות שמעבר להם משתנה התנהגות המערכת.
• כללי התראות: מטריצת "אירוע — סף — ערוץ — נמען" עם תנאי הפעלה, דיכוי חזרות וסדר הסלמה אם התורן לא הגיב.
• מדיניות גישה: תפקידים והרשאות בפאנל, מפתחות לצמתי הרשת ולמקורות חיצוניים, סדר סבב וביטול שלהם, הפרדת גישה בין משמרת תורנות לפיתוח.
• נוהל תפעול: תדירות עבודות תחזוקה, סדר עדכון רכיבים, בדיקת חיות נתונים, פעולות בעת הידרדרות וחזרה לקונפיגורציה קודמת.
• הוראות לתורן: תרחישים קצרים לאירועים נפוצים — החמצת נתונים, עלייה בהשהיות, הפעלה שגויה של התראה.
• סכמת פריסה וגיבוי: אילו נתונים נשמרים ובאיזו תדירות, איך מרימים סביבה מאפס וכמה זמן זה לוקח.

הקבלה מתבצעת לכל סעיף בנפרד: אנחנו מציגים מסמך, והצוות שלכם בודק אותו על המשימות שלו.

מקרה בוחן: איך הטרקר הפסיק לסטות מנתוני הרשת

לפני: השוואה ידנית

צוות שניהל חישובי gas לארנק עם כמה אלפי משתמשים פעילים החזיק את העלות ידנית: תורן כל 15 דקות השווה את שער הבסיס בסורק ציבורי Etherscan ותיקן את התוספת בהגדרות. כל עוד הרשת הייתה שקטה, הסכמה החזיקה, אבל בקפיצות הטרנזקציות נתקעו בהמתנה 20-40 דקות.

התחזית סטתה מהמחיר האפקטיבי בפועל ביותר מ-20% בערך בכל שליחה שמינית, ו-6-9 טרנזקציות ביממה נכשלו בגלל תוספת לא מספקת. המשתמש ראה "נשלח", אחר כך "נתקע", ואז שילם שוב.

אחרי: איסוף אוטומטי

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

שיעור השליחות עם פער מעל 20% ירד לאחת משישים, השהיית עדכון התחזית — מ-15 דקות ל-3-5 שניות, שיעור השליחות הכושלות — מ-7% ל-0.4%. התורן מטפל באזהרות במקום בתיקונים ידניים: המערכת עצמה מעלה את התוספת בעומס יתר ועוברת לצומת גיבוי אם הספק מחזיר נתונים מיושנים.

בקרה אוטומטית הפכה לחלק מהאמינות: אזהרה מגיעה כשהפער נמשך כמה בלוקים ברצף. תקלות שפעם המשתמש מצא בארנק, עכשיו תופס הניטור.

במה gas tracker שונה מסורק בלוקים?

סורק בלוקים עונה על השאלה "מה כבר קרה": הוא מציג בלוקים, טרנזקציות ואת העמלה ששולמה בפועל, אבל רק אחרי שהפעולה נכללה בשרשרת. לתכנון זה לא מספיק — עד שהמספר מופיע ברשימה, ההחלטה על המחיר כבר התקבלה.

מערכת ניטור gas פועלת צעד אחד מוקדם יותר, לפני החתימה על הטרנזקציה. היא מחשבת עמלת בסיס ועמלת עדיפות, מעריכה באיזה מחיר הפעולה תיכנס לאחד מהבלוקים הקרובים, ושומרת את התחזית מעודכנת. ארנק או backend של השירות מקבל ערך מוכן ומציב אותו בשדה המחיר במקום לנחש.

ההבדל בין הכלים בולט במיוחד בהיסטוריית העלות. שאילתת מחיר חד-פעמית חסרת תועלת אם הפעולה לא דחופה: האגרגטור צובר נתונים ומראה חלונות עומס — מתי הרשת שקטה והעמלה נמוכה, ומתי היא מתייקרת באופן יציב. לפי ההיסטוריה הזו רואים באילו שעות כדאי להריץ פעולות באצווה: תשלומים, mint, rebalancing.

שכבה נפרדת — התראה על שיאים. הכללים עוקבים אחרי עלייה חדה בעמלת הבסיס ומתריעים לפני שהשירות שולח מקבץ טרנזקציות במחיר מופקע. ניתן להגדיר סף, חלון מיצוע ואופן התראה, ולכן המהנדס מקבל אות מראש ולא מטפל בהשלכות של תשלום יתר.

לסיכום: סורק בלוקים הוא ארכיון ומרשם עובדות, ו-gas tracker הוא כלי לקבלת החלטה על מחיר. הראשון מראה מה קרה; השני — כמה תעלה הפעולה ומתי כדאי לשלוח אותה.

שאלות טכניות נפוצות על ניטור gas

בשלב ההערכה השאלות נוגעות לא לממשק, אלא לנתונים: מאיפה מגיע מחיר ה-gas, מה קורה לו בעומס יתר ואיך הטרקר מתנהג בכשל צומת. להלן תשובות לספקות הנדסיים שצפים לרוב לפני תחילת העבודה.

איך מחברים רשת חדשה?

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

מה עושים עם איסוף מטריקות שכבר פרוס?

הטרקר מתחבר כמקור נוסף למאגר המטריקות הקיים דרך ממשק סטנדרטי. הגרפים וההתראות נשארים, ומתווספות להם מטריקות gas.

מה אם צומת המקור אינו זמין?

הסקירה מתבצעת במקביל דרך כמה ספקי צמתים עצמאיים, והקריאות מושוות זו לזו. בפער או בניתוק הזרם הנתונים מסומנים כלא אמינים ועוברים לגיבוי, ולא נתקעים על הערך האחרון.

האם נדרשת גישה לארנקים?

לא: די בנתונים ציבוריים על בלוקים ותור הטרנזקציות, המפתחות נשארים אצל הלקוח. גישה נדרשת רק לשליחה אוטומטית של טרנזקציות — זה שירות נפרד עם הרשאות מוגבלות.

נדון במשימה: אילו נתונים לשלוח להערכה

הערכת פרויקט gas tracker לא תלויה בהיקף הקוד, אלא בבהירות התמונה הנוכחית: איפה השירות כבר אוסף נתוני gas, ואיפה המטריקה חיה בראשו של התורן. ככל שנתוני הפתיחה מדויקים יותר, כך יהיו פחות הנחות בתוכנית העבודה, ונמנה מהר יותר לוחות זמנים והרכב שלבים.

מה לשלוח כדי שההערכה תהיה עניינית:

• רשימת רשתות והתפקידים שלהן: רשת ראשית, מערכי בדיקה, רשתות שכבה שנייה — איפה ניטור gas נדרש ואיפה הוא כרגע לא מכוסה.
• מקורות נתוני gas היום: צומת עצמאי, נקודות גישה ציבוריות או שירות חיצוני — ואיזה מהם נחשב למקור אמת בפער.
• איסוף המטריקות הנוכחי: מה כבר נכתב — שער בסיס, תוספת עדיפות, מילוי בלוק, מספר טרנזקציות — באיזה פורמט נשמר ועד כמה ההיסטוריה זמינה.
• פערים קריטיים: אילו מקרים אתם מחשיבים כתקלה — שיא שהוחמץ, פער בין המקור לאישור ברשת, השהיית התראה בכמה בלוקים.
• מערך פנימי: לאן צריכות להגיע ההתראות (פאנל ניטור, מערכת אירועים, צ'אט), מי הנמען ואיזו פעולה מצופה אחרי הפעלה.
• נפחים ותדירות: כמה טרנזקציות ביממה עוברות דרך השירות, האם נדרש ניתוח היסטוריה או שמספיק חלון נע של הבלוקים האחרונים.
• מגבלות גישה: מערך פריסה מותר, מקטעים סגורים, דרישות לאחסון מפתחות ויומנים.
• נכסים קיימים: סקריפטים עצמאיים, כללי התראות, סכמות נתונים — כדי לא לכתוב מחדש את מה שכבר עובד.

עם הסט הזה אנחנו חוזרים עם הערכה ותוכנית: הרכב שלבים, נקודות בדיקה בתעבורה אמיתית, סכמת נתונים וסדר ההעברה למערך עבודה. תארו את המשימה — נבהר את החסר ונציע תוכנית עבודה.