פיתוח מערכת ניטור והתראות עבור עסקאות whale

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

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

שאלות נפוצות

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

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1376
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1350
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    798
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1094
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1035
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1132

עסקאות לווייתן: מדוע העברות גדולות הולכות לאיבוד ללא ניטור

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

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

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

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

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

מה נותן ניטור רציף: מהירות תגובה ושלמות נתונים

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

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

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

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

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

גישות למעקב אחר עסקאות לווייתן: השוואת אפשרויות

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

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

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

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: קיצרנו את זמן הגילוי של העברות גדולות

איך היה

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

מה שינינו

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

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

מה הפך להיות

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

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

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

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

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

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

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

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

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

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

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

איך לשלול החמצת נתונים בזרימה?

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

מה קורה בעת אתחול מחדש של הצומת?

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

עד כמה חזק הרעש מתגובות שגויות?

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

כמה עבודה להוסיף בלוקצ'יין חדש?

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

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

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

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

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

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