ניטור AI של פרוטוקולי DeFi: זיהוי ניצול פרצות בזמן אמת

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

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

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

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

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

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

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

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

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

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

מצבי ניטור DeFi: השוואה ומגבלות

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

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

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

מה קובע את הבחירה

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

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

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

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

מה אנו מוסרים לידיים: כללים, תרשימים ונהלים

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

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

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

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

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

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

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

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

מדדים לפני ואחרי

במה בקרה זורמת נבדלת מביקורת חד-פעמית?

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

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

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

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

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

ספקות טכניים נפוצים לפני הפעלת הבקרה

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

כיצד אתם מדכאים התראות שווא?

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

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

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

מה יהיה העומס על הצמתים שלנו?

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

כיצד מתעדכנים כללים אם הפרוטוקול משתנה?

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

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

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

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

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

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

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

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