פיתוח טראקר לניטור שחרורי טוקנים

פיתוח טראקר טוקנים: מדוע שחרורים שוברים את הניטור

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. ביקורת מקורות נתונים. עוברים על קונטרקטי הווסטינג, כתובות אוצר ומולטיסיג, טבלאות הקצאה מתוך מסמכי הטוקנומיקה. את לוחות הזמנים המוצהרים מצליבים עם ההעברות בפועל ברשת, והפערים מוציאים כרשימה נפרדת.
2. סכמת עדכון נתונים. המודל: טוקן, קטגוריית בעלי הטוקנים, סוג ווסטינג (cliff, לינארי, היברידי), תאריך ונפח השחרור, כתובת נמען, מקור. לכל מקור — תדירות סקירה משלו וכלל חישוב מחדש משלו.
3. הגדרת האיסוף. אינדוקס של אירועי הקונטרקט ויתרות הכתובות: מנוי לבלוקים חדשים בתוספת בנייה מחדש תקופתית של ההיסטוריה. הכתיבה אידמפוטנטית — עיבוד חוזר של בלוק אינו מכפיל נפחים.
4. בדיקת התכנסות. משווים את לוח הזמנים המחושב עם תנועות הטוקנים בפועל. פער מעל המותר — אות לבדיקה ידנית, ולא משימה נדחית.
5. הגדרת התראות. סף לפי נפח, חלון לפני האירוע, ערוצי מסירה ודה-דופליקציה — כדי ששחרור גדול לא ייטבע ברעש של טרנזקציות קטנות.
6. מסירה לתפעול. נוהל מילוי המקורות, הוראה לתקלת איסוף, הפרדת הרשאות וניטור רעננות הנתונים: נראה לא רק האירוע, אלא גם שהאיסוף חי.

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

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

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

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

מקרה בוחן: ניטור שחרורים לפרויקט רב-רשתי

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

מה היה לפני

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

מה שינו

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

מה נהיה

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

מה לעשות אם השחרורים כבר מתקיימים, ואין חשבונאות?

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

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

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

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

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

ספקות טכניים: דיוק הנתונים ועדכון קונטרקטים

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

מה לעשות בעת עדכון קונטרקט או החלפת כתובת?

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

ההתראה תגיע לפני השחרור?

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

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

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

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

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

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