מדוע push protocol נשבר בשיאי תנודתיות
כאשר השוק נע בכיוון אחד, תור ההתראות על ליקווידציות גדל מהר יותר מקצב העיבוד שלו.
Push protocol, הבנוי סביב צומת-שולח אחד, מתחיל לצבור אירועים: תחילה זמן האספקה גדל משניות לדקות, לאחר מכן חלק מההודעות על ליקווידציות הולכות לאיבוד בעת הפעלה מחדש של השירות, ומיד לאחר מכן מגיעות כפילויות — אותו טריגר מעובד שוב.
עבור פוזיציה שנסגרת בכפייה, ההבדל בין "נודע מיד" לבין "נודע כעבור עשר דקות" הוא ההבדל בין החלטה מנוהלת לבין עובדת אובדן הביטחונות.
הסיבה כמעט תמיד אחת: המערכת מחושבת לעומס ממוצע, ולא לעומס שיא. תנודתיות השוק אינה גידול הדרגתי, אלא זינוק פי עשרות בדקות: האירועים נעשים רבים יותר מקיבולת התור, הניסיונות החוזרים מתחילים להתחרות באירועים חדשים, והרפליקות של הצמתים מתפצלות במצבן.
ניטור ליקווידציות ברגע כזה הופך למקור רעש: חלק מההתראות מגיעות באיחור, חלק — בעדיפות שגויה, וחלק אינן מגיעות כלל.
בעיה נפרדת — סדר ואידמפוטנטיות. אם אירוע ליקווידציה מעובד פעמיים, המשתמש מקבל שתי התראות על אותו דבר, ואם העיבוד מתבצע במקביל ללא מפתח דה-דופליקציה, הקשר הסיבתי הולך לאיבוד: התראה על ירידת בריאות הפוזיציה מגיעה אחרי ההתראה על הליקווידציה עצמה. בשיא זה נראה כמו כאוס, אף שכל רכיב בנפרד פועל כשורה.
אנו מנתחים תקלות כאלה בשלושה צירים: היכן בדיוק הולך האירוע לאיבוד, מה קורה לתור בעת זינוק, וכיצד המערכת מתנהגת בעת כשל של צומת אחד. להלן — כיצד זה נסגר ברמת ארכיטקטורת האספקה, ולא בתיקונים קוסמטיים בקוד השליחה.
מה נותן ערוץ התראות אמין לפרוטוקול DeFi
מהירות תגובה לאירוע קריטי
התראה על ירידת בטחון מתחת לסף מגיעה תוך שניות, ולא אחרי שהמפעיל מרענן את הדשבורד. זה משנה את סוג התגובה: במקום "נודע לנו אחרי 10-15 דקות", הצוות מקבל חלון שבו הליקווידציה עדיין ניתנת לניהול — אפשר להוסיף בטחון, לסגור חלקית את הפוזיציה או להעביר אותה למצב הגנתי.
בשוק תנודתי, ההבדל בין "הספקנו" ל"לא הספקנו" הוא ההבדל בין פעולה מתוכננת לליקווידציה כפויה עם סליפג'.
שיעור האירועים שנמסרו
ערוץ עם אישור קבלה וחזרות שומר על מסירת אירועים קריטיים ברמה הקרובה לשלמה: אם המכשיר במצב לא מקוון או האפליקציה סגורה, ההתראה מגיעה דרך מסלול גיבוי. בנפרד מוגדרת עדיפות — אירוע על ליקווידציה לא עומד באותה תור עם רעש אינפורמטיבי ולא הולך לאיבוד מאחוריו. שגיאות מסירה נראות בלוגים, ולא מתבררות בדיעבד מניתוח תקלה.
פחות ניטור ידני
התורן מפסיק להחזיק גרפים פתוחים ולבדוק את מצב הפוזיציות ידנית — הוא מגיב לאירוע. זה מסיר מהצוות את המשמרת השגרתית ומפחית את מחיר הטעות: אדם לא יפספס אות בגלל עייפות או מעבר בין לשוניות. הזמן שהתפנה הולך לניתוח סיכונים ולהגדרת ספים, ולא להסתכלות.
התאוששות צפויה
בעת תקלה בערוץ, האירועים לא הולכים לאיבוד: הם מצטברים ונמסרים לאחר שחזור הקשר, ולכן חלון תגובה שהוחמץ לא נוצר. זמן ההתאוששות לאחר כשל הוא מדיד — מרגע התקלה ועד להתראה הראשונה שנמסרה, ומדד זה נשמר בדקות, ולא בשעות. סוגי הכשלים מצטמצמים למקרים נדירים, וכל אחד מהם מנותח לפי לוגי המסירה, ולא לפי השערות.
דרכי מסירת אירועים: השוואת מצבי פעולה
יש להעביר אירוע חיסול למשתמש בתוך שניות, אחרת הפוזיציה תיסגר ללא השתתפותו. אך "למסור התראה" אינו מנגנון אחד, אלא כמה מצבים בעלי עלות בעלות שונה: חלקם מספקים תגובה מיידית, אחרים — הבטחת מסירה, ואחרים — תלות מינימלית בתשתית. הבחירה תלויה במה שקריטי יותר עבור הפרוטוקול: מהירות, אמינות או פשטות.
להלן — השוואה בין גישות שביניהן באמת בוחרים בעת בניית ניטור חיסולים ואירועי פרוטוקול.
| אפשרות מסירה | מתי מתאימה | מגבלות |
|---|---|---|
| שליחה ישירה לערוץ (push protocol) | נדרשת תגובה בתוך שניות: חיסול, שינוי ריבית, הפעלת סף | דורשת מנוי של המשתמש; כאשר הערוץ אינו זמין ההתראה אובדת ללא ניסיון חוזר |
| תור עם אישור מסירה | אירועים קריטיים שבהם חשוב עצם הקבלה: סטטוס הלוואה, ביצוע פקודה | השהיה על אישור; נדרש מעקב אחר מצב כל הודעה |
| סקירת מצב לפי בקשה | המשתמש עצמו בודק את הפוזיציה; לוחות מחוונים ברקע | השהיה עד לבקשה הבאה; אינה מתאימה לאירועים דחופים |
| Webhooks למערכות חיצוניות | אינטגרציה עם שירותים פנימיים, CRM, בוט של הצוות | תלות בזמינות הנמען; נדרשת שליחה חוזרת בעת כשל |
| פרסום בזרם אירועים משותף | אנליטיקה, ביקורת, כמה צרכנים של אותו אירוע | אין адресность; הצרכן עצמו מסנן את הנדרש |
המגבלה המרכזית של כל מצב — אינה התעבורה, אלא מצב המנוי וניסיון חוזר בעת כשל. שליחה ישירה מהירה, אך אינה שורדת אי-זמינות של הערוץ; תור אמין, אך מוסיף השהיה. בפועל משלבים מצבים: אירוע דחוף יוצא ישירות, ואישור וניסיון חוזר נלקחים על ידי התור.
בעת התרחבות צוואר הבקבוק אינו מספר הערוצים, אלא נפח האירועים לנמען. סינון בצד השולח — לפי כתובת, סוג אירוע, סף — מפחית את העומס פי כמה, והפרדת הזרמים לדחופים ולמידעיים אינה מאפשרת להתראות קריטיות לטבוע ברעש.
כיצד אנו מיישמים ניטור ליקווידציות: שלבי העבודה
ניטור ליקווידציות אינו "להפעיל התראות", אלא לבנות שרשרת מהאירוע ברשת ועד להודעה במכשיר המשתמש, כך שאף שינוי קריטי לא יאבד.
אנו מתחילים בביקורת של הסכימה הנוכחית: בוחנים אילו פוזיציות בכלל מנוטרות, היכן מקור הנתונים, כיצד נקבע סף בריאות ההלוואה, ומאתרים מקומות שבהם האות עלול שלא להגיע או להגיע באיחור.
- ביקורת הסכימה. מנתחים את החוזים, האורקלים והלוגיקה של חישוב יחס הבטוחה. מתעדים אילו אירועים אנו מחשיבים כקריטיים: התקרבות לסף, עצם הליקווידציה, שינוי ריביות, השהיית הפרוטוקול.
- תכנון המסלול. קובעים מאין אנו לוקחים את הנתונים — מיומני הרשת או מאינדקסר משלנו — וכיצד אנו מקשרים את כתובת הארנק לערוץ המסירה. בשלב זה מחליטים מה נשלח באופן מיידי ומה נצבר.
- הגדרת טריגרים. מגדירים תנאי הפעלה עם מרווח מתחת לסף, כדי שהמשתמש יקבל התראה לפני הליקווידציה ולא אחריה. מחריגים כפילויות והתראות שווא בעת תנודות חדות בשוק.
- בדיקת המסירה. בודקים את כל המסלול על אירועים אמיתיים וסינתטיים: בקרת השהיה, שליחה חוזרת בעת כשל, נכונות הטקסט והקישורים לפעולה. בנפרד בודקים את ההתנהגות כאשר אחד הערוצים אינו זמין.
- תיעוד. מתארים את סכימת הזרימות, הספים, פורמטי ההודעות וסדר שינוי הכללים — כדי שצוות הלקוח יוכל בעצמו להוסיף סוגי אירועים חדשים.
- מסירה לתפעול. מגדירים ניטור של מערכת ההתראות עצמה: רואים כמה אירועים נתפסו, כמה נמסרו, והיכן האות הולך לאיבוד. מוסרים הרשאות ונוהל תגובה לכשלים.
כל שלב מסתיים בתוצאה ניתנת לבדיקה, ולכן ההשקה אינה הופכת ל"הפעלנו ומקווים". תארו את הסכימה שלכם — נחזור עם הערכה ותוכנית עבודה.
ארטיפקטים ותצורות שאתם מקבלים
אנחנו מעבירים לא "גישה לשירות", אלא מעגל התראות עובד שצוותכם יכול לתחזק בלעדינו. כל מה שמתואר להלן — נמצא במאגר שלכם ובתשתית שלכם, עם היסטוריית שינויים.
- תרשימי זרימה: מסלול האירוע מהמקור (on-chain לוג, אינדקסר, אורקל מחיר) ועד להתקן המשתמש — עם נקודות כשל, חזרות ודה-דופליקציה.
- כללי סינון: אילו אירועים מפעילים שליחה (סף בריאות הפוזיציה, גודל ליקווידציה, שינוי סטטוס הזמנה), אילו נחסמים כרעש, וכיצד מגדירים ספים ללא עריכת קוד.
- תבניות הודעות: טקסטים ומבנה payload עבור ליקווידציה, התקרבות לסף, ביצוע פקודה וכשלים — עם לוקליזציה ומשתנים לפוזיציה ספציפית.
- תצורות ערוצים: עדיפויות ומסלולי משלוח חלופיים, התנהגות בעת שלילת הרשאות ובעת התקן לא פעיל, מגבלות תדירות למשתמש.
- נהלי תפעול: מה לעשות בעת הצפת אירועים, כיצד לכבות כללים רועשים, סדר בדיקה לאחר שינוי חוזים או מקור מחירים.
- ניטור והתראות לצוותכם: מדדי משלוח, שיעור כפילויות שנזרקו, השהיה מהאירוע ועד השליחה, התראות על ירידה.
- תיעוד והעברה: תיאור האינטגרציה, צ'ק-ליסט לחיבור אירוע חדש, ניתוח תקלות וכללי החזרת תצורה לגרסה קודמת.
בנפרד אנחנו מגדירים את הגבולות: היכן מסתיימת הזירה שלנו (משלוח וסינון) ומתחילה שלכם (לוגיקת ניהול סיכונים). זה מסיר מחלוקות בעת ניתוח מדוע המשתמש לא קיבל התראה.
קייס: איך האיצו את התגובה לליקווידציות פי 4
מה היה לפני
הפרוטוקול על Push Protocol שלח התראות על התקרבות לסף הליקווידציה, אבל הערוץ עבד כ"שידור רחב": זרם אחד לכל הפוזיציות, בלי עדיפות ובלי דה-דופליקציה.
בתקופות של תנודתיות תור האירועים התנפח, חלק מההתראות הגיעו באיחור, וחלק אבדו בעת חיבור מחדש של הלקוח — המפעיל נודע על פוזיציה קריטית רק לאחר שהליקווידציה כבר התרחשה.
ניתוח האירועים נעשה ידנית: המהנדס הוציא לוגים, הצליב האשים של טרנזקציות עם רשומות במסד הנתונים ושחזר את הכרונולוגיה. על אירוע אחד הושקעו כמה שעות, ושיעור האירועים שאבדו הגיע עד 12% — ובמקביל, כמעט בלתי אפשרי היה לאתר פספוס בדיעבד.
מה שינו
בנינו מחדש את המינוי לאירועים: פיצלנו את הזרמים לפי רמות סיכון (התקרבות לסף, אזור קריטי, עצם הליקווידציה) והוספנו אישור מסירה — הלקוח מסמן קבלה, ואירועים שלא אושרו עוברים לשליחה חוזרת עם מרווח הולך וגדל.
דה-דופליקציה לפי מזהה הפוזיציה הסירה כפילויות בעת חיבור מחדש, וחוצץ בצד השולח שומר על האירועים בעת ניתוק קצר.
במקביל הסרנו את הניתוח הידני: כל אירוע נכתב ליומן עם חתימת זמן וסטטוס מסירה, ופערים בין המצב הצפוי למצב בפועל של הפוזיציה מודגשים אוטומטית.
מה נהיה
| מדד | לפני | אחרי |
|---|---|---|
| השהיית תגובה לאירוע קריטי | דקות | שניות |
| שיעור האירועים שאבדו | עד 12% | מתחת ל-1% |
| זמן ניתוח ידני של אירוע | שעות | דקות |
| כפילויות התראות בעת חיבור מחדש | באופן קבוע | לא קיימות |
מהירות התגובה לליקווידציות עלתה פי 4, והמפעיל הפסיק להיות צוואר בקבוק: המערכת עצמה מראה אילו פוזיציות דורשות תשומת לב, ושומרת היסטוריית מסירה מלאה.
במה שונה פרוטוקול push מניטור polling?
ניטור polling בנוי בצורה פשוטה וישירה: השירות פונה כל N שניות לצומת או לאינדקסר ושואל "מה חדש בכתובות שלי". הפשטות מטעה — המרווח הוא בעצם ההשהיה. עד שהבקשה הבאה נשלחת, האירוע כבר התרחש, אבל אתם לא יודעים עליו.
עבור ליקווידציה ב-DeFi זה חלון של כמה שניות, שבמהלכן הפוזיציה יורדת מתחת לסף, ואת ההחלטה מקבל לא השירות שלכם אלא מליקווידטור זר.
פרוטוקול push הופך את המודל: המנוי נרשם פעם אחת, וההתראה מגיעה ממקור האירוע ברגע הופעתו בבלוק. ההשהיה נקבעת לא לפי הטיימר שלכם אלא לפי זמן המסירה — שניות לעומת מרווח הסקר. ההבדל בולט במיוחד באירועים נדירים: polling או תופס אותם באיחור, או שאתם מקצרים את המרווח ומשלמים על כך.
העומס הוא הצד השני. בסקר, כל לקוח מייצר זרם בקשות ללא תלות בשאלה אם יש אירועים: אלף מנויים במרווח של כמה שניות — זה רקע קבוע שגדל באופן ליניארי עם מספר הכתובות ואינו פוחת בשוק רגוע.
מודל push שולח תעבורה רק כשהאירוע באמת התרחש, ולכן בתקופות שקטות התשתית כמעט אינה בשימוש, ובתקופות תנודתיות — היא מתרחבת לפי המצב בפועל, ולא לפי לוח זמנים.
מכאן ההבדל בעלות התשתית. Polling מחייב להחזיק רזרבה של בקשות תחת מרווח שיא, כלומר אתם משלמים על התרחיש הגרוע ביותר מסביב לשעון. Push מעביר את עיקר העבודה לצד המקור ולמתווך המסירה, והשירות שלכם עוסק בעיבוד — הוא זקוק להספק מחשוב תחת זרם ההתראות בפועל, ולא תחת זרם היפותטי.
יש גם פשרה: סכימה היברידית, שבה push מכסה אירועים קריטיים — ליקווידציות, העברות גדולות, שינוי פרמטרים — ואילו polling נשאר לצורך השוואת מצב ושחזור לאחר החמצות. כך מוסר הסיכון המרכזי של מודל push: אם המסירה כשלה, השוואה תקופתית תחזיר את התמונה המעודכנת.
הבחירה בין הגישות היא בחירה בין השהיה צפויה לעומס צפוי; עבור ניטור ליקווידציות כמעט תמיד מנצח push עם גיבוי polling.
ספקות טכניים נפוצים לגבי אינטגרציה
אינטגרציה של פרוטוקול push לתוך מוצר DeFi כמעט תמיד נתקלת באותן שאלות: איך זה משתלב בסטאק הנוכחי, מה עם אבטחת מפתחות ומנויים, האם המערכת תעמוד בעומס ברגע של ליקווידציות המוניות והאם ניתן לחזור אחורה אם משהו השתבש. להלן מה שנשאל לרוב בשלב ההערכה.
עד כמה פרוטוקול ה-push תואם לסטאק הנוכחי שלנו?
הפרוטוקול אינו דורש לכתוב מחדש חוזים או להחליף רשת — הוא מתחבר כשכבת מסירה נפרדת. בצד הבקאנד אנו מוסיפים שירות שולח, שמאזין לאירועים דרך צומת RPC או אינדקסר ומעביר אותם לערוץ. אם כבר יש לכם אינדקסר (The Graph, או כזה משלכם), הוא הופך למקור הטריגרים, ואין צורך בתשתית כפולה. את התאימות בודקים ברשת בדיקה לפני הפרודקשן.
כיצד מובטחת אבטחת מפתחות ומנויים?
המפתחות הפרטיים של השולח נשמרים במנהל סודות או במודול חומרה, ואינם נכנסים לקוד ולריפוזיטורי. המנוי של המשתמש נרשם על הארנק שלו — אנחנו לא מקבלים גישה לכספים, אלא רק לכתובת למסירה.
את הערוצים מפרידים לפי הרשאות: שירות אחד שולח התראות על ליקווידציות, אחר על אירועי הפרוטוקול, ופגיעה באחד אינה פותחת את השני.
האם המערכת תעמוד בעומס בזמן ליקווידציות המוניות?
עומס שיא הוא בדיוק הרגע שבו מאות פוזיציות עוברות ליקווידציה בו-זמנית. אנחנו מציבים תור בין מקור האירועים לשליחה, כדי שפרץ לא יהפוך למפולת בקשות, ומגבילים את הקצב לפי כתובת. תעדוף: התראות קריטיות (סיכון ליקווידציה) עוברות ראשונות, אינפורמטיביות — בהשהיה. זה נותן מסירה צפויה גם בשעות שיא.
מה עם חזרה אחורה אם האינטגרציה השתבשה?
האינטגרציה מבודדת: השבתת שירות השולח אינה פוגעת בחוזים ובמוצר הראשי. אנחנו שומרים את הקונפיגורציה בריפוזיטורי, ולכן חזרה למצב קודם היא החלפת גרסה, ולא עריכה ידנית. לוגי המסירה נשמרים, כדי לנתח את התקרית ולהבין אילו התראות נשלחו ואילו לא.
אם המקרה שלכם לא נכנס לרשימה — תארו את המשימה, ונחזור עם הערכה ותוכנית אינטגרציה.
נדון במשימה שלכם ונחזור עם תוכנית
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, עלינו להבין את הארכיטקטורה שלכם ואת התרחישים שבהם push protocol יעבוד. ספרו לנו אילו אירועים קריטיים: התקרבות לסף ליקווידציה, שינוי ריבית, ביצוע פקודה, תנועה בפוזיציה? מכך תלוי אילו מנויים ופילטרים אנחנו מגדירים בחוזה ואיך בונים את המסירה.
שלחו נתוני מקור — לפיהם אנחנו מחשבים את היקף העבודה והסיכונים:
- תיאור הפרוטוקול: רשתות, חוזים חכמים, היכן נשמר מצב הפוזיציות;
- רשימת האירועים שעליהם נדרשת תגובה, והעדיפות שלהם;
- דרישות להשהיה: כמה מהר ההתראה צריכה להגיע למשתמש;
- ערוצי מסירה: web, אפליקציית מובייל, מסנג'רים, e-mail;
- עומס צפוי: מספר ארנקים פעילים ואירועים בשיא;
- גישות: רשת בדיקה, מאגר קוד, תיעוד לחוזים;
- מגבלות תשתית ואבטחה, אם ישנן.
בתגובה תקבלו תוכנית עבודה עם שלבים, הרכב המנויים והפילטרים, תרשים זרימת האירועים מהחוזה לערוץ המסירה והערכת לוחות זמנים. בנפרד נדון כיצד בודקים אמינות: תרחישי בדיקה בתנועות חדות של השוק, טיפול באירועים שהוחמצו וכפולים, נסיגה במקרה של כשל במסירה.
הלאה — הצעדים הבאים: נתאם את ההיקף, נקבע את השלבים ונתחיל את הראשון. תארו את המשימה — נחזור עם הערכה ותוכנית.