מדוע מערכת מעקב airdrop נשברת בשיא העומס
שיא העומס הוא הרגע שבו תמונת מצב של יתרות נלקחת בבלוק שאינו זה שנקבע בכללי החלוקה. המשתתף מעביר טוקנים בין ארנקים בדקות האחרונות של החלון, תמונת המצב קוראת את המצב החדש כבר, ולחלוקה נכנסות כתובות שלא היו קיימות ברגע הקיבוע. מכאן זיכוי כפול: אותו הון נלקח בחשבון בשתי כתובות, והחלק היחסי הכולל עולה על מאה אחוזים.
נקודת הכשל השנייה היא אובדן אירועים. עם הזינוק החד במספר העסקאות, האינדקסר אינו מספיק לעמוד בקצב הבלוקצ'יין, וחלק מההעברות והוספות הנזילות נופלות מהחשבונאות. משתתף שעשה הכול לפי הכללים מקבל פחות מהתגמול המגיע לו, וערעורו נבחן ידנית לפי הלוגים.
אם החשבונאות מתנהלת בטבלאות, השחזור אורך ימים: להשוות אלפי כתובות בעיניים זה לא תהליך, אלא עבודה ידנית שלא מתרחבת ואינה נותנת ערובות לשחזוריות.
הבעיה השלישית היא היעדר אידמפוטנטיות. הרצה חוזרת של החלוקה לאחר תקלה מזכה את התגמולים פעמיים, ואי אפשר להחזיר זאת ללא צילום מצב. מערכת שאינה שומרת היסטוריית תמונות מצב ואינה יודעת לחשב מחדש את התוצאה מנתוני המקור, הופכת בתקרית הראשונה למקור להפסדים ולנזק תדמיתי.
מפרקים כיצד זה נסגר: תמונת מצב דטרמיניסטית לפי בלוק מסוים, פעולות זיכוי אידמפוטנטיות עם יומן, אינדקסר עמיד בעומס, והשוואת סכומים אוטומטית לפני שליחת עסקאות.
מה נותן טרקינג בנוי וחלוקת תגמולים
מהירות הסנאפשוט וחישוב החלוקות
הסנאפשוט של יתרות ופעילויות נלקח לפי גובה בלוק שנקבע מראש, ולא "בעין" ברגע תחילת החלוקה. זה מסיר את מקור המחלוקת העיקרי: כל המשתתפים רואים את אותו מצב רשת, וחישוב מחדש של החלוקות מתבצע לפי כלל דטרמיניסטי.
בפועל, חישוב סנאפשוט לפי כתובות עם היסטוריה של עשרות אלפי טרנזקציות מסתכם בדקות במקום שעות של הצלבה ידנית, והתוצאה משוחזרת בהרצה חוזרת באותו גובה בלוק — וזו בדיוק היכולת לבדוק.
שיעור שגיאות הזיכוי וטיפול במקרים שנויים במחלוקת
זיכויים שגויים כמעט תמיד מגיעים משלושה מקומות: העברות שלא נלקחו בחשבון בין כתובות של אותו משתמש, תגמולים על פעולות בפרוטוקולים מקושרים ומקרי קצה עם משיכות חלקיות.
כאשר כללי הזיכוי מתוארים באופן פורמלי ונבדקים בבדיקות אוטומטיות על נתונים היסטוריים, שיעור הזיכויים השגויים יורד ליחידות לאלף — השאר נתפס לפני פרסום הרשימה, ולא אחרי. מקרה שנוי במחלוקת נבחן לפי הלוג: רואים אילו פעולות של הכתובת נכנסו למדגם, אילו נחתכו ולפי איזה תנאי. הזמן לטיפול מתקצר משעות של התכתבות לכמה דקות — התשובה מגובה בנתונים, ולא בהבטחות.
עמידות בפני עומסי שיא
שיא העניין מגיע בשעות הראשונות לאחר ההכרזה — אלפי כתובות בודקות בו-זמנית את הזכאות לתגמול. מערכת הטרקינג עומדת בעומס כזה הודות לשמירת תוצאות במטמון ולהפרדה בין קריאה לכתיבה: בדיקת הזכאות לתגמול אינה מחשבת מחדש את כל ההיסטוריה, אלא מחזירה תשובה מוכנה מראש. זה מסיר את הסיכון שברגע הבולט ביותר ממשק הבדיקה יקרוס וחלק מהמשתתפים יעזבו בלי לקבל תשובה.
צפיות בחלוקה
טרקינג בנוי הופך את החלוקה מפעולה חד-פעמית לתהליך חוזר: הכללים, הסנאפשוט ובדיקת הזכאויות מתוארים ומשמשים מחדש בסבבים הבאים. הלקוח מקבל לא רשימת כתובות חד-פעמית, אלא מנגנון שמתרחב לקמפיינים חדשים בלי לכתוב את הלוגיקה מחדש מאפס.
אפשרויות ארכיטקטורה למעקב airdrop והמגבלות שלהן
בחירת הגישה קובעת עד כמה המערכת עמידה לחישובים מחדש וכמה מהר אתם מגיבים למחלוקת של משתתף. שלוש אפשרויות בסיסיות: לחשב ישירות לפי לוגים של הרשת, לנהל רישום בבסיס נתונים פנימי, או לשלב את שניהם עם התאמה תקופתית. להלן — מתי כל אחת עובדת והיכן היא נשברת.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| רישום לפי לוגים של הרשת | קמפיינים חד-פעמיים, מספר קטן של משתתפים, נדרשת שקיפות מקסימלית | כל חישוב מחדש — קריאה חוזרת של ההיסטוריה; בפעילות גבוהה צוואר הבקבוק הוא מהירות השליפה, לא הלוגיקה |
| בסיס נתונים פנימי | קמפיינים קבועים, כללי זיכוי מורכבים, נדרשות דוחות מהירים | הנתונים חיים בנפרד מהרשת: אי-התאמה עם עסקאות אמיתיות מצטברת בלי לשים לב |
| סכימה היברידית | תוכניות ארוכות טווח, snapshot תכופים, מקרים שנויים במחלוקת | דורשת נוהל התאמה וטיפול באי-התאמות — אחרת אבד המשמעות של ההיבריד |
היכן נשברת כל גישה
רישום לפי לוגים מדויק מעצם הגדרתו, אך מתקשה להתאים לקנה מידה: ככל שההיסטוריה ארוכה יותר והרשת פעילה יותר, כך כל snapshot יקר יותר. בסיס נתונים פנימי מהיר, אך סוטה מהרשת בעת ארגון מחדש ואירועים שהוחמצו — והאי-התאמה צפה ברגע ההפצה, כשכבר מאוחר לערער.
הסכימה ההיברידית מסירה את שתי הקיצוניות: שאילתות חמות עוברות דרך בסיס הנתונים, והתאמה תקופתית מאשרת שהפעולות שנרשמו תואמות את הלוגים. המפתח כאן — נוהל ההתאמה: באיזו תדירות, לפי איזה חלון ומה לעשות עם אי-ההתאמות שנמצאו. בלעדיו ההיבריד הופך לאותו בסיס נתונים פנימי, רק עם שכבה מיותרת.
מפרקים כיצד לבחור סכימה לתרחיש שלכם ולהטמיע התאמה כך שההפצה תעמוד בבדיקה.
שלבי יישום: מביקורת נתונים ועד מסירת נהלים
יישום מערכת airdrop-трекинга אינו התקנת תוכנה, אלא רצף של החלטות הנדסיות, שבו כל צעד נשען על זה שלפניו. להלן — כיצד נראה תהליך העבודה מהפירוק הראשון של הנתונים ועד לרגע שבו הצוות שלכם מנהל את המערכת באופן עצמאי.
- ביקורת מקורות. מפרקים מהיכן מגיעים הנתונים על מחזיקים ופעילות: צמתי רשת, אינדקסרים, ייצוא משירותי בורסות וארנקים. מתעדים אילו כתובות ואירועים בכלל זמינים, היכן הנתונים חלקיים ואילו פערים יש לסגור לפני ההתחלה.
- סכימת snapshot. קובעים את רגע קיבוע מצב הרשת ואת הכלל שלפיו כתובת נכנסת למדגם: יתרה מינימלית, החזקת פוזיציה, החרגת כתובות שירות וכתובות בורסה. סכימת ה-snapshot חייבת להיות משוחזרת — אותו בלוק נותן אותה תוצאה בהרצה חוזרת.
- כללי הקצאה. מנסחים את נוסחת ההפצה: משקלים לפי נפח, מקדמים עבור משך החזקה, ספי חיתוך. את הכללים מתארים כך שניתן יהיה לבדוק אותם על מדגם בדיקה ולהסביר למשתתף מדוע קיבל בדיוק סכום זה.
- הגדרה והרצה. מרכיבים מודול חישוב, מחברים מקורות, מגדירים תיעוד יומן (לוג) לכל עסקת הקצאה. כל שינוי בכללים עובר דרך ניהול גרסאות — הגרסה הישנה נשארת זמינה לצורך הצלבה.
- בדיקה על נתונים היסטוריים. מריצים את הכללים על snapshots קודמים ומצליבים את התוצאה עם הפצות בפועל. כך מתגלים הקצאות כפולות, כתובות שאבדו ומקרי קצה לפני שהם פוגעים במשתתפים אמיתיים.
- מסירת נהלים. מוסרים תיעוד על סכימת ה-snapshot, הנוסחאות וסדר עדכון הכללים, ומכשירים את הצוות שלכם לבצע חישובים ולטפל בהקצאות שנויות במחלוקת באופן עצמאי.
רצף כזה מסיר את הסיכון המרכזי — פער בין המובטח לבין מה שהוקצה בפועל. כל שלב מסתיים בארטיפקט שניתן לבדוק, ולא בהסכמה בעל פה.
מה הלקוח מקבל לידיו לאחר ההטמעה
ההטמעה נחשבת להסתיימה לא ברגע שבו המערכת הפעילה את החלוקה הראשונה, אלא כאשר צוות הלקוח יכול לבצע את הבאה באופן עצמאי — בלעדינו.
לכן אנו מוסרים לא "גישה לפאנל", אלא סט מלא של ארטיפקטים: קונפיגורציות, כללים, תרשימים ותקנות שלפיהם ניתן להפעיל את המערכת, לבדוק אותה ולפתח אותה.
- קונפיגורציית סנאפשוט — פרמטרים קבועים של נטילת מצב: רגע הקיבוע, עומק ההיסטוריה, רשימת הכתובות והחריגים, התנהגות בהפעלה חוזרת. הצילום משוחזר אחד לאחד, ולכן תוצאה שנויה במחלוקת תמיד ניתנת לחישוב מחדש.
- כללי חיוב — תנאי חלוקה פורמליים: משקלות, ספי חיתוך, מכפילים עבור פעילות, טיפול במקרי קצה. כל כלל מתואר כך שניתן לשנותו ללא עריכת קוד.
- תרשים זרימות נתונים — מהיכן מגיעים נתונים על יתרות ועסקאות, היכן מתבצעת ההתאמה, ולאן הולכת תוצאת החלוקה. ניתן לראות באיזה שלב נוצרת אי-התאמה וכיצד למקם אותה.
- תקנון התאמה — סדר בדיקת התוצאות: סכומי ביקורת, מדגם לבדיקה ידנית, קריטריונים לעצירת החלוקה בעת אי-התאמה. ההתאמה מתבצעת בשלבים, ולא "בעין".
- תיעוד לתמיכה — תיאור תקלות אופייניות, סדר חזרה לסנאפשוט הקודם, נקודות לוגינג, אנשי קשר אחראיים. מהנדס תורן מתמצא לפי ההוראות, ללא שיחה אלינו.
- הפרדת הרשאות — תפקידים לצפייה, הפעלה ושינוי כללים, יומן פעולות לכל פעולה. מי ומתי שינה את תנאי החיוב — נראה בדיעבד.
- תוכנית פיתוח — מה שמונח לסיבובים עתידיים: מקורות נתונים חדשים, מדדי פעילות נוספים, תרחישי חלוקה חוזרת.
את הסט אנו מוסרים לריפוזיטורי של הלקוח יחד עם היסטוריית השינויים — הארטיפקטים חיים בקונטור שלו, ולא אצלנו. תארו את המשימה: נחזור עם הערכה ותוכנית, איזה היקף של תיעוד ותקנות נדרש בדיוק עבור תהליך החלוקה שלכם.
מקרה בוחן: כיצד המעקב עמד בחלוקה ל-180 אלף כתובות
המשימה הייתה אופיינית לקמפיין airdrop: תמונת מצב (snapshot) לפי מספר מקורות פעילות, חישוב חלקים וחלוקת טוקנים ל-180 אלף כתובות. הניסיון הקודם באמצעות סקריפטים וטבלאות נכשל — חלק מהכתובות נכנסו למדגם פעמיים, וחלק נפלו עקב אי-התאמה בכללים בין המקורות. ניתוח השגיאות ארך שבועות, ואמון המשתתפים נפגע.
בנינו מחדש את המעגל: תמונת המצב נרשמת לפי כלל אחיד עם יומן של כל נתוני הקלט, חישוב החלקים מתבצע באופן דטרמיניסטי, וכל זיכוי מקבל מזהה שניתן לעקוב אחריו. מקרה שנוי במחלוקת מועלה כעת לפי המזהה הזה בתוך דקות — ניתן לראות אילו נתונים ואיזה כלל הניבו את התוצאה.
Chainalysis בניתוחים שלה הראתה לא פעם שדווקא שקיפות החישוב, ולא גובה התשלום, היא שקובעת אם המשתתפים יישארו בפרויקט לאחר החלוקה.
מה השתנה לפי המדדים. זמן חישוב תמונת המצב הצטמצם מימים אחדים של הצלבה ידנית לשעות על אותו היקף כתובות. שיעור הזיכויים השגויים ירד מאחוזים לשברי אחוז — היתרה נסגרת בבדיקה ידנית לפני שליחת הטרנזקציות.
ניתוח מקרה שנוי במחלוקת התקצר מימים לדקות, מפני שהמהנדס רואה את כל שרשרת החישוב, ולא משחזר אותה מתוך הלוגים.
הלקוח אישר את התוצאה בנפרד: החלוקה עברה ללא עצירות, מספר הפניות לתמיכה בנוגע לזיכויים היה נמוך פי כמה מהצפוי, והחזרה אחורה עבור כתובות שגויות בוצעה ממוקדת, מבלי לפגוע בשאר.
במה שונה סנאפשוט לפי לוגים של הרשת מסנאפשוט לפי מסד נתונים פנימי?
סנאפשוט לפי לוגים של הרשת נבנה מאירועים שהחוזה עצמו פולט: אנחנו אינדקסים לוגים בטווח בלוקים, מתאימים כתובות וסכומים, ומקבלים מצב בגובה הנדרש. מקור כזה הוא ראשוני — הוא אינו תלוי באופן שבו המערכת שלנו פירשה את הטרנזקציה, וכל משתתף יכול לשחזר את הדגימה באופן עצמאי.
הצד השני של המטבע — השהיה: בין שליחת הטרנזקציה לבין הכנסתה לבלוק מאושר חולף זמן, ובמקרה של ארגון מחדש של השרשרת חלק מהאירועים יש לקרוא מחדש.
סנאפשוט לפי מסד נתונים פנימי נלקח מהאינדקס שכבר נאסף: טבלת יתרות, היסטוריית פעולות, אגרגטים לפי ארנקים. הוא מוחזר באופן מיידי ואינו דורש פנייה לצומת, אך שלמותו מוגבלת למה שהאינדקסר שלנו הספיק לרשום.
אם המטפל פספס אירוע או קרס באמצע הטווח, במסד יישאר חור — והסנאפשוט יהיה תקין פורמלית, אך שגוי בהרכבו.
ההבדל המרכזי הוא בעלות ההצלבה. לוגים של הרשת יקרים יותר בשלב הקריאה, אך זולים בבדיקה: סכום בקרה לפי טווח בלוקים מתכנס אצל כל משתתף עצמאי. מסד נתונים פנימי זול בקריאה, אך דורש ביקורת נפרדת — הצלבה עם המקור הראשוני, איתור אי-התאמות לפי כתובות וניתוח מקרים שבהם האינדקס והרשת נפרדו.
בפועל אנחנו לא בוחרים מקור אחד, אלא בונים את החיבור ביניהם: לוגים של הרשת — תקן ונקודת שחזור, מסד נתונים פנימי — שכבת הגשה מהירה לחישוב חלקים. אי-התאמה ביניהם — אות לכך שהאינדקסר פיגר או איבד טווח; אז הסנאפשוט נבנה מחדש מהלוגים, ולא "מושלם" בעריכות במסד.
זה מסיר את הסיכון המרכזי של ההפצה — אי-שלמות שקטה, שבגללה חלק מהכתובות לא נכנסות לרשימה ומקבלות פחות מהמגיע להן.
ספקות טכניים לפני תחילת העבודה
לפני תחילת העבודה כמעט תמיד עולים אותם שאלות: מה לעשות עם תשתית המעקב שכבר פרוסה, כיצד לנהוג כאשר היסטוריית הארנקים חלקית, וכיצד לוודא שהחישוב בוצע כראוי. להלן ניתוח ללא מילים כלליות, עם היגיון הנדסי.
כבר פרוסה אצלנו תשתית מעקב — לכתוב הכול מחדש מאפס?
לא. תחילה אנו מתעדים את המצב הקיים: אילו אירועים נרשמים, באיזה פורמט, והיכן הנתונים הולכים לאיבוד. לאחר מכן או שאנו מוסיפים שכבות חסרות מעל הקיים, או שמעבירים את הנתונים לסכמה חדשה תוך שמירת ההיסטוריה. הפעלה מחדש מלאה מוצדקת רק אם המודל הנוכחי אינו מבחין בין סוגי פעילות ולא ניתן לשחזרו בדיעבד.
מה עושים עם נתונים חלקיים על ארנקים?
נתונים חלקיים הם הנורמה ולא היוצא מן הכלל: חלק מהכתובות הופיעו לאחר תמונת המצב, וחלק מהפעילויות לא עברו אינדוקס. אנו מסמנים רשומות כאלה בסטטוס נפרד, ולא משליכים אותן, ומחשבים את הזיכוי לפי כללים מוגדרים מראש להשלמת נתונים. כך החלוקה נשארת ניתנת לשחזור: עבור כל רשומה ניתן לראות אילו נתונים עמדו בבסיסה ומה היה חסר.
כיצד נבדקת תקינות החישוב?
החישוב נבדק מול חישוב מחדש בלתי תלוי על אותם נתוני קלט — פער בכל כתובת עולה לפני החלוקה ולא אחריה. בנוסף אנו מתעדים סכומי ביקורת לפי אצוות ויומן שינויים: אם כלל השתנה, ניתן לראות איזו גרסה הופעלה על איזו קבוצה. זה מאפשר לבטל אצווה מסוימת מבלי לפגוע באחרות.
כיצד מועברת ההיסטוריה בעת העברת נתונים?
ההעברה מתבצעת תוך שמירת מזהים מקוריים וחתימות זמן, כדי שרשומות ישנות וחדשות לא יוכפלו בעיבוד חוזר. לפני המעבר אנו מריצים חישוב מקביל על הנתונים הישנים והחדשים ומשווים את התוצאה — המעבר נחשב להשלים רק כאשר התוצאות תואמות. ביטול אפשרי בכל שלב, כל עוד תמונת המצב הסופית לא נקבעה.
אם המקרה שלכם אינו נכנס לאף אחד מהתרחישים הללו — תארו את המשימה, ונחזור עם הערכה ותוכנית עבודה.
נדון במשימת המעקב וההפצה שלכם
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, עלינו להבין את התצורה שלכם: היכן נמצא ה-snapshot (רשת עצמאית, תואמת EVM או מספר רשתות), כיצד נוצרת רשימת הכתובות, מי ועל סמך מה מקבל החלטה על הכללה בהפצה.
מכך נגזרת ארכיטקטורת המעקב: האם אנחנו מאנדקסים אירועים מהבלוקים ישירות, האם מאזינים ל-mempool כדי לתעד פעילות לפני הכללה בבלוק, או בונים סכימה היברידית עם אחסון מצב ביניים.
בנפרד נבהיר את כללי ההפצה: חלקים קבועים, משקלים לפי נפח פעילות, ספי חיתוך, טיפול בכתובות חוזה וב-multisig. כאן לרוב צצים פערים בין מה שתוכנן בטוקנומיקה לבין מה שבאמת ניתן לחשב על השרשרת — מוטב לסגור אותם לפני ההתחלה, ולא בשלב החלוקה.
לקראת הדיון נכין:
- טיוטת סכימת אינדוקס: אילו אירועים וקריאות לחוזים נכנסים למעקב, ובאיזו עומק אחסון;
- מודל snapshot: רגע הקיבוע, טיפול בארגוני שרשרת חוזרים (reorganizations), אידמפוטנטיות של הרצות חוזרות;
- כללי חישוב משקלים וספים — בצורה שניתן לבדוק על סט כתובות לבדיקה;
- אב-טיפוס של pipeline ההפצה עם מצב dry-run: תחילה הרצה על עותק של הנתונים, לאחר מכן טרנזקציות אמיתיות;
- מדיניות גישה למפתחות ולתפקידים: מי יוזם את החלוקה, מי מאשר, כיצד בנוי ביקורת הפעולות;
- תוכנית ניטור: התראות על פער בין הסכום המיועד להפצה לבין הנפח שנשלח בפועל;
- הערכה מקדימה של לוחות זמנים לפי שלבים — מהגדרת הדרישות ועד ההפצה הראשונה לבדיקה.
תארו את המשימה: הרשת, מספר הנמענים, שיטת תיעוד הפעילות הנוכחית ומה כבר מיושם. נחזור עם הערכה, תוכנית עבודה ורשימת חומרים שנדרשים מצדכם.