אינטגרציה עם Glassnode API לאנליטיקה on-chain

אינטגרציה של Glassnode API: איפה אובדים נתוני און-צ'יין

אינטגרציה של Glassnode API מתחילה לא בקבלת מפתח, אלא במבנה הזרימה: ההתחברות לנתוני הבלוקצ'יין מתבצעת либо באמצעות מנוי לבלוקים חדשים, либо בדגימה תקופתית של מדדים לפי כתובות ואגרגטים.

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

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

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

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

מה נותן זרם מדדי רשת מסודר

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

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

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

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

התחברות ל-Glassnode: דגימה, מנוי, רפליקה

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

השוואת מצבים

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

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

שלבי יישום: מביקורת ועד תפעול

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

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

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

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

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

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

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

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

מה מוסרים לידיים: סכימות, הרשאות גישה, נהלים

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

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

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

מקרה בוחן: אנליטיקת ארנקים בלי לאבד היסטוריה

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

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

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

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

מה השתנה

• שיעור הבלוקים שאבדו: 6–7% בכל ניתוק → אפס, ההשלמה מתבצעת אוטומטית.
• שחזור היסטוריה לאחר ניתוק: כ-40 דקות של פעולות ידניות → 2–3 דקות בלי מעורבות מהנדס.
• אי-התאמות בהשוואה מול הצומת: עד 2% מהדגימות → פחות מ-0.1%, כל אחת מנותחת נקודתית.

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

במה מנוי לאירועים שונה מדגימה תקופתית?

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

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

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

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

שאלות טכניות נפוצות על התחברות לאנליטיקה

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

האם אפשר לבנות מחדש את היסטוריית הנתונים?

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

כיצד נבדקת שלמות הנתונים?

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

מה קורה כאשר המקור אינו זמין?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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

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