פרסינג בלוקצ'יין: היכן נשבר איסוף הנתונים מהרשת
איסוף נתונים מהרשת נראה כמו משימת תרגול: להתחבר לצומת, לשלוף בלוקים, לפרסר עסקאות. בפועל, דילוג על בלוקים ופערים ביתרות צפים שבועות לאחר ההשקה, כאשר המספרים בדוחות כבר אינם תואמים את מצב השרשרת. נבחן היכן נשבר הפרסינג של הבלוקצ'יין ומדוע אין לכך תיקון על ידי חזרה על הבקשה.
דילוג על בלוקים קשור לעיתים רחוקות לרשת עצמה. הצומת מגביל את טווח השליפה לבקשה אחת, החיבור נקטע באמצע, וההפעלה מחדש מתחילה לא מהסמן השמור, אלא מהבלוק האחרון בזיכרון.
אם נקודת הביקורת נכתבת באופן אסינכרוני, לאחר קריסה התהליכים מתפצלים, וחור בהיסטוריה מתגלה רק באמצעות השוואת סיכומים.
פערי היתרות נגרמים לא מההעברה, אלא ממה שאינו נראה בעסקה. העברות פנימיות, קריאות לחוזים ואירועים מהלוגים יש לפרסר בנפרד — אחרת היתרה מתאמתת במטבע הראשי ואינה מתאמתת בטוקנים. כאב נפרד: מימושים לא תקניים של טוקנים ומספר שונה של ספרות עשרוניות, כאשר הסכום קיים אך אין במה לפרש אותו.
המקום השלישי — בנייה מחדש של השרשרת. בלוקים שכבר נכתבו למסד הנתונים נופלים מהענף הקנוני, וחישובים מחדש מעליהם נתקעים וגוררים איתם את כל האגרגציה. זה נפתר על ידי המתנה לסופיות (finality), כתיבה אידמפוטנטית ודה-דופליקציה לפי מפתח הכולל את אינדקס האירוע, ולא רק את ההאש של העסקה. להלן — כיצד אנו בונים צינור (pipeline) שבו כשלים אלו נראים מוקדם יותר משהמספרים מתפצלים.
מה נותן איסוף ופרסינג מדויק של נתוני הרשת
אנו בודקים את התוצאה לפי ארבעה סימנים מדידים — הם נראים במוניטורינג, ללא ניתוח לוגים ידני. אם אפילו אחד מהם נחלש, הפרסינג עובד פורמלית, אך הנתונים לדוחות ולהשוואות כבר אינם אמינים.
- רעננות הנתונים. הפיגור מראש השרשרת נמדד ביחידות בלוקים ולא בעשרות, ואינו גדל תחת עומס שיא: המרווח בין הופעת הבלוק לכתיבה לאחסון נשמר יציב.
- שלמות ההיסטוריה. בטווח המעובד אין גבהים שהוחמצו: כל עסקה, שינוי יתרה וקריאה לחוזה משויכים לבלוק שלהם, והפער מול המקור במספר הרשומות הוא אפס.
- עמידות בפני בנייה מחדש. בעת נסיגת השרשרת בכמה בלוקים, רשומות מהענף שבוטל מסומנות כלא תקפות ומחושבות מחדש — הדוחות אינם "נסחפים" לאחר הבנייה מחדש.
- עומס על הצומת. הקריאה מתבצעת במנות לפי טווחים, עם שמירת הסמן וחזרות בעת קטיעה: הצומת אינו נחנק מבקשות, וההשלמה ממשיכה מהגובה האחרון שעובד.
- יכולת אימות. הפיגור, מספר הדילוגים ושיעור הניסיונות החוזרים מוצגים במטריקות, ולכן איכות הנתונים מאושרת במספרים, ולא בהבטחות.
אנו בודקים את סכימת הפרסינג על רשתות אמיתיות — מ-Ethereum והרשתות התואמות לה ועד רשתות עם מודל אישורים שונה. את מערך השוואות הבקרה אנו מתאימים לכל מקרה: במקום מסוים די בהשוואה מול סייר בלוקים ציבורי, ובמקום אחר נדרש חישוב מחדש תקופתי של קטע נבחר מההיסטוריה במלואו.
מצבי פרסינג בלוקצ'יין: זרימה, מנה, לפי דרישה
את מצב איסוף הנתונים קובעת המשימה, ולא להפך. עיבוד זרימה של בלוקים נדרש במקום שבו הרעננות חשובה: האירוע מופיע מיד לאחר האישור ועובר לעיבוד ללא המתנה. טעינה באצוות של ההיסטוריה — כאשר יש לשחזר מצב על פני קטע ארוך או לאנדקס מחדש נתונים לאחר שינוי בלוגיקת הפרסינג. שאילתה לפי דרישה סוגרת בדיקות נקודתיות, שבהן מעבר מלא אינו משתלם.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| עיבוד זרימה של בלוקים | לוחות חיים, התראות, מוניטורינג כתובות | נדרשת עמידות בפני בנייה מחדש של השרשרת ודילוגים, המצב נשמר בנפרד |
| טעינה באצוות של ההיסטוריה | אכלוס ראשוני, אינדוקס מחדש לאחר שינוי לוגיקה | ריצה ארוכה, מגבלות הצומת על עומק השליפה, חובה אידמפוטנטיות של חזרות |
| שאילתה לפי דרישה | בדיקות נקודתיות נדירות, יתרה או קריאה לחוזה בנקודת זמן | אינו מתרחב לפי נפח, ההשהיה תלויה בזמינות הצומת |
| אינדוקס חוזים | שליפות קבועות לפי אירועים וכתובות, אנליטיקה | נדרשת סכימת אחסון וכלל מיגרציות, נפח המסד גדל יחד עם ההיסטוריה |
כיצד המצבים משתלבים
בפועל משלבים ביניהם: מעבר באצוות ממלא את האינדקס לפי חוזים וכתובות, הזרימה מדביקה אותו בבלוקים חדשים, ושאילתות נקודתיות קוראות מחלון הנתונים שכבר נאסף. דרישות משותפות לכל סכימה — אידמפוטנטיות של חזרות, נקודת ביקורת של הבלוק האחרון שעובד וטיפול נפרד בבניות מחדש של השרשרת. בלי זה, פערים ביתרות ואירועים שהוחמצו צפים כבר בצד הדוחות.
כיצד אנו מטמיעים פרסר: שלבי העבודה ההנדסית
העבודה מתנהלת באיטרציות של שבועיים עד שלושה: כל אחת סוגרת מקור נתונים אחד ומסתיימת בחפץ ניתן לבדיקה — לא דוח, אלא אינדקס עובד שאפשר כבר לבנות מולו שאילתות. סדר השלבים זהה גם לרשת אחת וגם למערך של כמה.
- ביקורת מקורות. עורכים מלאי ממה אנו שולפים נתונים: צומת מלא או ארכיוני, האם הוא מספק מצבים היסטוריים, האם יומני אירועים של חוזים זמינים, והאם רוחב הפס מספיק לעומק ההיסטוריה הנדרש. כאן גם מקבעים את רשימת הישויות המטרה — עסקאות, יתרות, קריאות לחוזים — ואת מה שנחשב בהן לחובה ומה לאופציונלי.
- תכנון סכימת האינדוקס. את הסכימה בונים מהשאילתות, ולא ממבנה הבלוקים: מפצלים טבלאות לפי טווחי גבהים, מוציאים אינדקסים נפרדים לכתובת, לטוקן ולהעברות פנימיות. מראש מחליטים מה נשמר בצורה חמה (hot) ומה מאגדים.
- איסוף ונרמול. מגדירים טיפול בבניות מחדש של השרשרת ועיבוד חוזר של הטווחים שנפגעו, והופכים את הכתיבה לאידמפוטנטית לפי מפתח של בלוק ופעולה. בנפרד מנהלים סמן פיגור מראש השרשרת.
- בדיקת שלמות. משווים את התוצאה מול מקור בלתי תלוי: סכומי בקרה לפי בלוקים, מספר אירועים, יתרות סופיות של כתובות. כל פער נכנס לתור ניתוח עם התשובה הגולמית השמורה, כדי שאת הסיבה ניתן יהיה לשחזר.
- ריצות עומס. מריצים אינדוקס מחדש של קטע היסטורי גדול ושאילתות מקבילות, בודקים היכן זה נשבר, ומכווננים חזרות והגבלת קצב הפניות לצומת.
- מסירת נהלים. מוסרים הוראות תחזוקה: כיצד להוסיף חוזה חדש, מה לעשות בפיגור הסמן, כיצד להריץ מחדש טווח לאחר תקלה וכיצד להחזיר סכימה אחורה.
המפתח לצפיות הוא שלכל שלב יש קריטריון קבלה מדיד: עומק ההיסטוריה שאונדקסה, שיעור הבלוקים שהושוו, הפיגור המותר. לפיהם גם נראה בהמשך, שלאחר שינויים ברשת הפרסר ממשיך להתאים.
מה אנו מוסרים לידיים: קונפיגורציות, סכימות, נהלים
אנו מוסרים לא "קופסה שחורה", אלא מתאר עבודה שהמהנדס שלכם יוכל להריץ, לקרוא ולשנות בלעדינו. לשם כך, האספקה כוללת מערך קבוע של חפצים — מקונפיגורציות ועד נהלים המתארים לא רק עבודה תקינה, אלא גם התאוששות לאחר תקלה.
- קונפיגורציות עבודה של שירותים: פרמטרי חיבור לצמתים, עומק אישורי הבלוק, גודל המנה בחישוב מחדש, מגבלות משימות מקבילות.
- סכימת מעבר על בלוקים: גובה התחלה, אחסון נקודות ביקורת, התנהגות בעת דילוג על טווח ובעת נסיגת השרשרת.
- סכימת זרימת הנתונים: הנתיב מהמקור לטבלאות המנורמלות, מקומות הדה-דופליקציה, ההעשרה והמסירה דרך ממשק תכנותי.
- מודל אחסון: תיאור טבלאות וקשרים, אינדקסים לשליפות לפי כתובת, חוזה ותקופה, מדיניות ארכוב של חתכים ישנים.
- מדיניות גישה: תפקידים והפרדת הרשאות לקריאה ולחישוב מחדש, סדר רוטציה של מפתחות, יומן קריאות.
- תיעוד הפרסר: ייעוד השדות, פורמט האירועים, פענוח סטטוסים פנימיים, דוגמאות לשאילתות טיפוסיות.
- נוהל חישוב מחדש: מתי להריץ מעבר חוזר, כיצד להגביל את העומס כדי לא לשבש את הסנכרון הנוכחי.
- מערך בדיקות ומטריקות: פיגור מהרשת, שיעור שגיאות הפרסינג, פערי יתרות, ובנוסף הוראה למקרה של אירוע חירום.
הקבלה מתבצעת בפועל: פורסים את המתאר בצד שלכם, מריצים חתך היסטורי ומשווים סכומי בקרה לפי מדגם של כתובות. אם הפער חורג מהסבילות — מנתחים את הסיבה לפני המסירה, ולא אחריה.
מקרה בוחן: אינדוקס רשת ללא דילוגי בלוקים
מה היה לפני
הלקוח — שירות אנליטי לרשת עמוסה: יתרות כתובות, היסטוריית עסקאות, סטטיסטיקה לפי חוזים. הפרסינג של הבלוקצ'יין נבנה על סקירה של צמתים ציבוריים "לגובה הנוכחי" — נרשם מה שהספיקו לקבל.
בעת פיגור של הצומת או ארגון מחדש, בלוקים נפלו בשקט: את הפער בגבהים מצאו לפי תלונות משתמשים, ולא לפי המוניטורינג. בהשוואה מדגמית של 500 כתובות, פערים מול סייר בלתי תלוי Etherscan הופיעו ב-3-4% מהמקרים, בימי שיא — עד 9%.
מה שינינו
את הצינור בנו מחדש: במקום סקירה "לגובה האחרון" — מנוי על זרימת בלוקים בתוספת השלמה ברקע לפי טווחי גבהים. כל בלוק שנרשם שומר גובה, האש והאש של ההורה, ולכן הפער בשרשרת נראה מיד ואינו מוסתר על ידי הבלוק הבא.
ארגונים מחדש מטופלים בנסיגה לעומק שנקבע במדיניות לרשת, עם אינדוקס מחדש של הטווח שנפגע. הגובה המאושר האחרון נקבע באחסון — הפעלה מחדש של השירות אינה יוצרת לא דילוגים ולא כפילויות.
מה נהיה
פערים על אותו מדגם — אפס. את השלמות אישרו במעבר רציף על כל הגבהים ובהשוואה עמוד אחר עמוד של סכומי בקרה: מספר הבלוקים שאונדקסו תאם למקור בלתי תלוי, ו"חורים" בהיסטוריה אין.
ההשהיה בהופעת העסקה בממשק החיצוני הצטמצמה מדקות לשניות, וחוסר הסנכרון ביתרות יצא ממחלקת הפניות לתמיכה.
במה נבדל צומת ארכיוני מלקוח קל
ההבדל הוא שלקוח קל שומר רק כותרות של בלוקים ומערך קטן של מצבים מאושרים, ואת גופי העסקאות והמצבים ההיסטוריים הוא מבקש מצמתים אחרים לפי הצורך. צומת ארכיוני מחזיק את כל השרשרת מהבלוק הראשון ויודע לספק מצב בכל גובה — בדיוק זה נקרא עומק ההיסטוריה.
לפרסינג בלוקצ'יין זה קריטי. לקוח קל לא יוכל לשחזר מצב של חוזה בגובה של שנה שעברה: מצבי ביניים אינם נשמרים בו, ולוגי האירועים זמינים רק עבור המרווח שהצומת הספיק לעבד.
חישוב מחדש מלא של יתרות, שחזור בעלי טוקנים בבלוק נבחר באופן שרירותי או תחקור קריאות פנימיות על לקוח קל פשוט אינם מבוצעים.
מחיר הארכיון — דיסק וזמן. נפח ההיסטוריה גדל באופן לינארי ולעולם אינו קטן, והסנכרון הראשוני מאפס אורך ימים, ולא שעות. לקוח קל מתחיל לעבוד מהר וכמעט אינו תופס מקום, אך משלם על כך בתלות בספקי נתונים ובעומק מקוצץ — הוא מתאים לצפייה באירועים נוכחיים, ולא לשליפות היסטוריות.
לכן הבחירה של מקור הנתונים אצלנו תמיד נגזרת מהמשימה, ולא מנוחות ההפעלה. אם נדרש ביקורת של זרימות כספים, השוואת סנאפשוטים לגובה מסוים או ניתוח אירוע בדיעבד — מרימים צומת ארכיוני, ומעליו אינדקסר משלנו עם רפליקה.
כשמספיק לעקוב אחר בלוקים חדשים ולספק נתונים בזמן אמת, די בלקוח קל עם ספק חיצוני כערוץ גיבוי. סכימה היברידית עולה יותר בתחזוקה, אך מסירה את הסיכון העיקרי — אובדן שקט של ההיסטוריה, שבגללו יש להתחיל את החישוב מחדש מאפס.
ספקות טכניים נפוצים של לקוחות
הספקות אצל לקוחות הם בדרך כלל אותם ספקות: מה יקרה בעת ניתוק החיבור לצומת, האם לא ניתקל במגבלות של המקורות והאם כתובות וסכומים מעסקאות שפורסרו לא ידלפו. להלן — כיצד מקומות אלו בנויים בסכימת הפרסינג שלנו.
מה יקרה אם הצומת ייפול או שהרשת תחזיר בלוקים אחורה?
הפרסר שומר נקודת ביקורת לפי מספר והאש של הבלוק האחרון שעובד, וכל רשומה אידמפוטנטית לפי מפתח "רשת + האש עסקה + אינדקס אירוע" — פרסינג חוזר של הטווח אינו יוצר כפילויות. בעת נסיגה עמוקה מעומק האישורים, הטווח נקרא מחדש, ותור החזרות משלים את שהוחמץ ללא התערבות ידנית.
האם לא ניצור עומס על מקורות הנתונים?
עובדים דרך מאגר צמתים עם רוטציה והגבלת קצב בקשות, ואת שליפת הלוגים לוקחים בטווחי בלוקים, ולא עסקה אחר עסקה. עם גידול הזרימה מוסיפים צמתים משלנו — הציבוריים נשארים כגיבוי למקרה של הידרדרות.
כיצד מובטחת פרטיות הנתונים?
הפרסינג מתבצע בתשתית שלנו או שלכם, מפתחות הגישה מונחים במאגר סודות ואינם נכנסים לקונפיגורציות. כתובות, סכומים וקשרים בין ארנקים אינם מועברים לצדדים שלישיים, הייצוא נשאר במתאר שלכם, והיומנים נכתבים ללא נתונים אישיים.
עד כמה קשה להוסיף רשת חדשה?
הליבה מופרדת מהמתאמים של הרשת: האחסון, הנרמול וספק הנתונים עוברים שימוש חוזר, ומוסף רק השכבה של קבלת בלוקים ופרסינג לוגים. לרשתות עם מודל אירועים דומה זהו תיקון של מתאם אחד, ולרשתות לא תקניות — מפרסר נפרד.
נדון במשימה שלכם לאיסוף נתונים מהרשת
כדי לחזור עם הערכת לוחות זמנים ותוכנית עבודה, יש להבין במדויק את הרכב הנתונים ואת גבולות המשימה. חלק מהנתונים הראשוניים נסגור בשיחה בעצמנו, אך ככל שהקלט קונקרטי יותר, כך יהיו פחות תיקונים בשלב הקבלה.
- מטרת הפרסינג. מה אמור להתקבל בפלט: חלון דוחות, מוניטורינג כתובות, אנליטיקה לפי חוזים או ייצוא למערכת שלכם. מכך תלוי עומק הפרסינג של הבלוקצ'יין וסכימת האחסון.
- הרכב הנתונים. אילו רשתות וישויות נדרשות — עסקאות, העברות טוקנים, יתרות, אירועי חוזים; לאיזו תקופה ובאיזו תדירות לעדכן.
- מקורות גישה. צמתים מלאים משלכם או חיצוניים, מגבלות על קצב הבקשות, והאם יש מפתחות לסיירי הרשת.
- המתאר הנוכחי. היכן לאחסן את התוצאה: מסד קיים, אחסון, החלפת קבצים; מהן המגבלות בעומס ובהרשאות גישה.
- מורכבות החוזים. האם אירועים תקניים מספיקים או שנדרש פרסינג של קריאות פנימיות, טוקנים לא תקניים ושחזור סכומים לפי הלוגים.
- דרישות להשוואה. עד כמה השלמות קריטית: האם פיגור מהרשת מותר, והאם נדרשים חישובים מחדש בעת ארגונים מחדש של השרשרת.
- מגבלות. דרישות ענפיות, הפרדת גישה לכתובות, כללי אחסון של שיוכים.
תארו את המשימה בצורה חופשית — נדון בפרטים ונחזור עם הערכת לוחות זמנים, הרכב נתונים ותוכנית עבודה לפי שלבים. אם חלק מהתשובות עדיין אינן מוכנות, נבחן אותן בשיחה הראשונה ונקבע אותן בכתב.