פיתוח מערכת ניטור פוזיציות DeFi עם התראות

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

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

שאלות נפוצות

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

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

ניטור פוזיציות DeFi: היכן נשבר הרישום

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

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

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

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

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

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

מה נותן בקרה רציפה של ביטחונות ותשואה

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

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

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

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

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

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

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

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

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

כיצד מתבצעת הטמעת המערכת: שלבי העבודה

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

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

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

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

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

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

מקרה בוחן: בקרת פוזיציות DeFi במקום גיליונות ידניים

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

מה היה לפני ההטמעה

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

מה שינו ומה נהיה

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

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

  • גילוי סיכון: מארבע שעות לשתי דקות;
  • שיעור הפעלות כוזבות: 40% → 6% — נותרו רק תנודות מחיר אמיתיות;
  • ניתוח אירוע: מיום ל-20 דקות, כל הכרונולוגיה כבר ביומן;
  • סיכונים שהוחמצו ברבעון: שלושה → אפס.

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

מה לעשות אם נתוני החשבונות אינם תואמים את השרשרת

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

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

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

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

מדיניות הרשאות, מכסות וערוצי התראות

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

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

מה קורה אם מקור הנתונים אינו זמין?

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

האם אפשר לתת לשירות גישת קריאה בלבד?

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

נדון במשימה שלכם ונחזור עם תכנית עבודה

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

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

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

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