פרסינג טוקנים חדשים: זיהוי, ניתוח וסיכונים

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

שירותי פיתוח בלוקצ'יין

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

פרסור טוקנים: היכן זרימת הנתונים נשברת

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

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

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

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

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

מה משנה איסוף מנוהל: מהירות, שלמות, יציבות

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

מהירות זיהוי: שניות מהבלוק עד הרשומה

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

שלמות הרשומה: החמצות נספרות, לא משוערות

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

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

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

פחות בדיקה ידנית: מסננים במקום ניתוח שורה־שורה

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

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

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: איך הסרנו החמצות בזרימת האירועים

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

בניתוק חיבור החלון פשוט אבד, ובארגון מחדש של השרשרת חלק מהרשומות שכבר נשמרו התגלגלו אחורה — במסד נותרו טוקנים 'תלויים'. בזרימה של כ-200 אלף אירועים ביממה שיעור ההחמצות הגיע ל-3.2%, הרשומה הופיעה לאחר 40–90 שניות, ומהנדס תורן השווה דגימה ביד 6–8 פעמים בשבוע.

מה שינינו

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

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

מדד לפני אחרי
שיעור האירועים שהוחמצו 3.2% פחות מ-0.05%
השהיית הופעת הרשומה 40–90 שנ' 2–4 שנ'
בדיקות ידניות 6–8 בשבוע דגימה מתוכננת פעם בחודש

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

במה זיהוי טוקן שונה מהניתוח שלו?

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

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

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

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

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

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

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

אילו התראות שווא נשארות?

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

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

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

לשם מה כמה מקורות אם אחד יציב?

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

עד כמה הנתונים מפגרים אחרי זמן אמת?

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

מה עם תמיכה לאחר המסירה?

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

נדון במשימה: מה להבהיר לפני ההתחלה

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

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

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