ניטור חוזים חכמים: היכן ההגנה נשברת
ביקורת בודקת את הקוד בנקודת זמן נתונה, אך לא את התנהגות החוזה בשטח. פגיעות גישה המוטמעת בלוגיקת התפקידים עוברת בשלום ניתוח סטטי — עד שמישהו קורא לפונקציה עם הרשאות של אחר. מניפולציה של אורקל אינה נראית בקוד המקור: המחיר מגיע מבחוץ, והתקיפה מתגלה רק בזרם העסקאות. ניטור חוזים חכמים סוגר בדיוק את הפער הזה — הוא מסתכל על מה שהחוזה עושה כעת, ולא על איך שהוא נכתב.
הלוואה מיידית היא הסוג המאלף ביותר של תקיפה. התוקף לוקח סכום עצום ללא בטחונות בעסקה אחת, מזיז את הבריכה או את האורקל, מוציא רווח ומחזיר את החוב — הכל בבלוק אחד. בקוד אין אף שורה שהשתנתה, ולכן בדיקה לפני ההרצה חסרת אונים כאן.
דבר כזה נתפס רק על אנומליות בעסקאות: זינוק חד בהיקף ההלוואות, סטייה של המחיר מהשוק, משיכת כספים לכתובת חדשה.
קטגוריה נפרדת — דליפות שקטות. הבעלים או מפתח אדמין שנפרץ מוציא בהדרגה נזילות דרך פונקציות לגיטימיות, וכל פעולה בנפרד נראית תקינה. כלל על יציאה מצטברת בחלון זמן מציג תמונה שאינה נראית בקריאות מפוזרות.
מפרקים כיצד זה נסגר: אילו אירועים ומדדים אנחנו אוספים, כיצד מכווננים ספים עבור פרוטוקול מסוים ומה קורה ברגע ההפעלה.
מה נותן ניטור רציף של החוזה
ניטור רציף הופך את אבטחת החוזה מבדיקה חד-פעמית לפני ההשקה לתהליך מתמשך. אנו מגדירים כללים לאירועים שמקדימים לאובדן כספים: משיכות חריגות מהבריכה, זינוק חד בהרשאות מנהל, קריאות לפונקציות קריטיות מחוץ לחלון הפעילות הרגיל.
הכלל מופעל על רצף עסקאות מסוים, ולא על סימן בודד, ולכן זמן גילוי האירוע מצטמצם משעות וימים לדקות — לעתים קרובות עוד לפני שהתקיפה מסתיימת.
המשימה ההנדסית העיקרית כאן היא לא כמות ההתראות, אלא הדיוק שלהן. אנו מכיילים את הספים על נתונים היסטוריים של החוזה: כמה התראות שווא נותן כל כלל, אילו אירועים משוכפלים, היכן האות טובע ברעש של פעילות לגיטימית.
לאחר הכיול, שיעור התראות השווא יורד לכמה אחוזים בודדים, וצוות התורנות מגיב לאיומים אמיתיים, ולא מטפל בשגרה. זה משפיע ישירות על המהירות: כשההתראות נמנות במאות, מתעלמים מהן, ואות מדויק אחד מפעיל תגובה.
אפקט נפרד — סוג הכשל שהוסר, שאותו לא ניתן לסגור באמצעות ביקורת. הביקורת בודקת את הלוגיקה במועד הבדיקה, אך אינה רואה מה קורה לחוזה בשטח: שינוי פרמטרים, פגיעה במפתח המנהל, מניפולציה של האורקל. הניטור סוגר בדיוק את הפער הזה — הוא תופס סטייה מהתנהגות תקינה, גם אם הקוד תקין פורמלית.
תגובה אוטומטית סוגרת את המעגל: על אות קריטי מופעלת השהיית החוזה, שלילת הרשאות או העברת הנזילות למצב מוגן. אנו מתכננים תרחישים כאלה מראש ובודקים אותם על עותק של הרשת, כדי שהתגובה לא תחסום פעולות לגיטימיות. הזמן מהאות ועד לעצירת התקיפה נמדד בשניות — וזה בדיוק ההבדל בין אירוע להפסד.
דרכי ניטור: השוואת גישות
הבחירה בדרך הניטור קובעת עד כמה מהר הצוות לומד על הבעיה וכמה עולה התחזוקה שלה. צופה חיצוני אינו דורש שינויים בחוזה, אך רואה רק את מה שנכנס ליומן האירועים. וו מובנה מעניק גישה למצב הפנימי, אך מגדיל את צריכת הגז ואת משטח התקיפה. סכמה היברידית עם אורקל אירועים מכסה את שני התרחישים, אך דורשת סנכרון קפדני.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| צופה חיצוני | החוזה כבר ברשת, אסור או יקר לשנות אותו; נדרש התחלה מהירה | רואה רק אירועים וקריאות; אינווריאנטים פנימיים נשארים מחוץ לשדה הראייה |
| וו מובנה | חוזה חדש שבו חשובה בדיקת המצב לפני ואחרי הפעולה | צריכת גז נוספת על כל עסקה; שגיאה בוו חוסמת את הלוגיקה הראשית |
| סכמה היברידית עם אורקל אירועים | פרוטוקול גדול עם מספר חוזים ומקורות נתונים חיצוניים | מורכבת יותר להגדרה: נדרשים כללי התאמה של אותות והגנה מפני התראות שווא |
בפועל, לרוב בוחרים בהיברידי: צופה חיצוני תופס אנומליות לפי אירועים, ווו קל משדר אינווריאנטים קריטיים. אורקל האירועים בהרכב הזה משמש כבורר — הוא מאשר שהאות הגיע ממקור מהימן ומסנן את הרעש. סכמה כזו מעניקה זמן תגובה בתוך בלוק אחד ואינה דורשת לכתוב מחדש את החוזה כולו.
אנו מתאימים את הדרך לחוזה הספציפי: אם הוא כבר פרוס, מתחילים בניטור חיצוני ומוסיפים בהדרגה ווים במקומות שבהם זה מוצדק. תארו את המשימה — נחזור עם הערכה ותוכנית.
כיצד אנו בונים מערכת ניטור
ניטור אינו מתחיל בהגדרת התראות, אלא בניתוח החוזה: אילו פונקציות משנות מצב, היכן מאוחסנים תפקידים ומגבלות, אילו אירועים החוזה כבר מפיק החוצה. מכך תלוי מה בכלל ניתן לנטר ללא התערבות בקוד.
אם החוזה אינו מפיק את האירועים הנדרשים, תחילה דנים כיצד לסגור את הפער — להוסיף אירוע בגרסה הבאה או לקרוא מצב מהרשת.
לאחר מכן מתכננים את הסכימה: אילו תנאים נחשבים לאירוע חריג, למי ולאן נשלח האות, מה נחשב להתראת שווא. חוק שצועק על כל עסקה גדולה — מהנדסים מפסיקים לקרוא אותו כעבור שבוע, ולכן הספים מכוילים לפי הפעילות האמיתית של החוזה.
- ביקורת החוזה. מנתחים את הלוגיקה, הרשאות המנהל, קריאות חיצוניות והאירועים הקיימים. מתעדים רשימת פעולות שאסור לפספס: החלפת בעלים, משיכת כספים, שינוי מגבלות, השהיה.
- תכנון הסכימה. מגדירים מקורות נתונים, הרכב החוקים, מסלולי ההתראות ורמות הקריטיות. בנפרד מתארים אילו התראות דורשות תגובה מיידית ואילו נכנסות לסיכום יומי.
- הגדרת החוקים. כותבים גלאים לתנאים הספציפיים של החוזה, קובעים ספים וחלונות צבירה, מחברים ערוצי התראה. כל חוק נבדק על נתונים היסטוריים — עליו לפעול באירוע חריג אמיתי ולשתוק בפעילות שגרתית.
- בדיקה ברשת בדיקה. מריצים תרחישים: החלפת תפקידים, משיכה גדולה, תדירות קריאות חריגה. מוודאים שהאות מגיע בזמן ומכיל מספיק הקשר לקבלת החלטה.
- כיול. בימים הראשונים עוקבים אחר זרם ההתראות ומכווננים את הספים, ומסירים רעש. המטרה — שמגיבים לאות, ולא מכבים התראות.
- מסירה. מוסרים הרשאות, תיאור החוקים והוראות תגובה לכל סוג אות. מראים כיצד להוסיף חוק חדש בעדכון הבא של החוזה.
- תמיכה שוטפת. לאחר שינויים בחוזה, החוקים נבחנים מחדש — אחרת הניטור מתרחק בשקט מהלוגיקה האמיתית.
תארו את החוזה והמשימות שלכם — נחזור עם הערכה ותוכנית עבודה.
כללי זיהוי וספי הפעלה
כלל זיהוי הוא תנאי שבו המערכת מרימה התראה, וסף הפעלה קובע את הרגישות: כמה גדול צריך להיות ההעברה, כמה אישורים להמתין, איזה אחוז שינוי להיחשב משמעותי.
אנו מכווננים אותם בהתאם לכלכלה של הפרוטוקול הספציפי, ולא "כברירת מחדל": עבור סטייבלקוין ועבור מאגר נזילות נמוכה, אותם מספרים יניבו או זרם של התראות שווא, או החמצה של תקיפה אמיתית.
- העברות גדולות. סף לפי סכום מוחלט ולפי חלק מהנפח הכולל של הטוקן במחזור; ענף נפרד להעברות לכתובות שאינן קשורות לפרוטוקול, ולמשיכת כספים מהאוצר.
- קריאות לפונקציות ניהוליות. החלפת בעלים של החוזה, העברת הרשאות מנהל, שינוי מגבלות, השהיה או ביטול נעילה של החוזה, עדכון מימוש מאחורי פרוקסי — כל אירוע עובר לערוץ נפרד בעדיפות גבוהה.
- שינויים במאגרי נזילות. ירידה חדה בעומק המאגר, משיכת נזילות חריגה בחלון זמן קצר, סטיית מחיר ממקור חיצוני ביותר מהאחוז שהוגדר.
- התפרצויות פעילות. עלייה במספר קריאות המתודה לדקה מעל קו הבסיס, סדרת עסקאות כושלות מכתובת אחת, פניות המוניות לחוזה מארנקים חדשים.
- שינויים בהרשאות ובתפקידים. הענקת תפקיד מינטר או שריפה, הופעת כתובת חדשה ברשימת המורשים, שינוי בלוגיקת העמלות.
- אותות טכניים. שגיאות באורקל, אי-התאמה בנתונים בין מקורות, ירידה בשיעור הקריאות המוצלחות מתחת לנורמה.
- ספי זמן. חלון תצפית (דקות או בלוקים), מספר אישורים עד להסלמה, תקופת שקט בין התראות חוזרות על אותו אירוע.
את הספים מוציאים לקונפיגורציה ולא לקוד: אותם מתקנים ללא בנייה מחדש וביקורת חוזרת של הלוגיקה. לאחר ההפעלה, הימים הראשונים מוקדשים לכיול — בוחנים כמה הפעלות מגיעות ואיזה חלק מהן שגוי, ומכווננים את המספרים עד שהאות נעשה נקי.
מקרה בוחן: הפחתת הנזק מתקיפה על פרוטוקול
פרוטוקול הלוואות על Ethereum עם נזילות בבריכות — צוות הלקוח הבחין באנומליה רק ארבעים דקות לאחר תחילת התקיפה: התוקף, באמצעות מניפולציה על מחיר האורקל, הוציא כספים מהבריכה, ועד לרגע התגובה הידנית חלק מהנזילות כבר אבד.
הניתוח הראה שהתראות על אירועי החוזה היו קיימות, אך ללא תגובה אוטומטית: המהנדס התורן ראה את ההתראה, ובזמן שבדק ידנית את העסקה, התוקף הספיק לבצע עוד כמה משיכות.
מה שינו
פרסנו ניטור של חוזים חכמים על Forta ו-OpenZeppelin Defender: גלאים עקבו אחר משיכות חריגות מהבריכה, שינויים חדים במחיר האורקל וקריאות לפונקציות ניהוליות. העיקר — חיברנו את הגלאים לחסימה אוטומטית: עם הפעלת הכלל, החוזה עבר למצב השהיה, ועסקאות חשודות נדחו עד לבדיקה ידנית. את סף ההפעלה כיווננו כך שפעולות גדולות לגיטימיות לא ייחסמו — בדקנו על נתונים היסטוריים.
תוצאה
בניסיון תקיפה חוזר דרך אותו וקטור, החסימה האוטומטית פעלה תוך שניות, ולא תוך דקות: עסקאות חשודות נדחו לפני משיכת הכספים, והנזק הוגבל לעלות הגז על קריאות כושלות. זמן התגובה לאירוע הצטמצם מעשרות דקות לשניות, ושיעור התקיפות שנעצרו ללא מעורבות אדם עלה לרוב התרחישים. הניתוח של כל הפעלה אורך דקות — המהנדס רואה את הקשר של העסקה ומחליט אם להסיר את ההשהיה או לא.
מעגל כזה אינו מחליף ביקורת, אך סוגר את החלון בין הגילוי לתגובה — בדיוק שם אובד עיקר הכספים.
במה שונה ניטור מביקורת אבטחה?
ביקורת אבטחה היא בדיקה חד-פעמית של הקוד לפני ההשקה: הצוות קורא את החוזה, מחפש חולשות, בודק את לוגיקת הגישה ואת ההנחות הכלכליות, ובסיומה מפיק דוח עם הבעיות שנמצאו והמלצות. הדוח מתעד את מצב הקוד בנקודת זמן מסוימת ועונה על השאלה "האם יש כאן פרצה שניתן לסגור לפני הדיפלוי". לאחר תיקונים לפי הערות הביקורת, החוזה נחשב לבדוק — אך רק בגרסה שנבדקה.
ניטור חוזים חכמים פותר משימה אחרת: הוא אינו מחפש שגיאות בקוד המקור, אלא צופה באופן רציף בהתנהגות של חוזה שכבר הופץ ברשת הראשית. ביקורת עונה "האם הקוד נכתב כראוי", ניטור — "האם החוזה מתנהג כמתוכנן, ממש עכשיו". אלו שאלות מהותית שונות, והן נענות בכלים שונים.
ההבדל הופך לקריטי לאחר הדיפלוי. הקוד יכול היה להיות נקי ברגע הבדיקה, אך מאז השתנו התנאים החיצוניים: חוזה האורקל התעדכן, הלוגיקה של הפרוטוקול המקושר השתנתה, מישהו קיבל גישה למפתח המנהל, הנזילות בבריכה גדלה והופיע תמריץ כלכלי לתקיפה. שום ביקורת אינה מסוגלת לתפוס שינויים כאלה — היא מסתכלת על חתך, לא על זרימה.
בקרה רציפה תופסת בדיוק את התרחישים האלה: משיכות כספים חריגות, קריאות לפונקציות מורשות, שינויים חדים ביתרות, פניות לכתובות חשודות. הכללים מוגדרים בהתאם ללוגיקה הספציפית של החוזה, ובעת הפעלה הצוות מקבל התראה בתוך דקות, ולא לומד על הבעיה מהחדשות.
לכן ביקורת וניטור אינם מחליפים זה את זה, אלא משלימים זה את זה: בדיקה חד-פעמית מפחיתה את הסבירות לשגיאה בקוד, בקרה רציפה מקצרת את זמן התגובה אם משהו השתבש ברשת הראשית. הפרקטיקה — לעבור ביקורת לפני ההשקה ולהעלות ניטור מיד, כדי שבין הבדיקה לתפעול בפועל לא יישאר אזור עיוור.
ספקות טכניים נפוצים
ניטור חוזים חכמים הוא צופה חיצוני, ולא קוד בתוך החוזה. סוכנים וכללי הגנה קוראים אירועים מהבלוקים ואת מצב החוזה מבחוץ, ולכן לא מתווספת אף שורת קוד לחוזה עצמו. צריכת הגז על הלוגיקה העסקית אינה משתנה: העסקאות מבוצעות בדיוק כפי שתוכננו, ובדיקות התנאים וההתראות מתבצעות מחוץ לשרשרת.
תאימות למכונות וירטואליות שונות נפתרת ברמת שכבת הניטור. עבור רשתות EVM הסוכנים נרשמים ליומני אירועים ולקריאות למתודות, ועבור סביבות שאינן EVM — לפורמטים מקוריים של בלוקים ולמצב החשבונות.
המשימה שלנו היא להביא את מודלי הנתונים לצורה אחידה, כך שהכללים וההתראות יעבדו באופן זהה ללא תלות במקום שבו החוזה פרוס.
העומס על הרשת מזערי: הצמתים נשאלים באמצעות מנוי לבלוקים חדשים, ולא בסריקה מתמדת של ההיסטוריה. בעת הצורך מתחברים לצומת ארכיוני רק לסנכרון ראשוני, ומשם הניטור ממשיך בזרימה.
האם הניטור יאט את החוזה או ייקר את עלות הקריאות?
לא. הניטור אינו מוטמע בהרצת העסקה, ולכן הגז וזמן התגובה נשארים כשהיו. הסוכנים קוראים נתונים שכבר אושרו ומגיבים בדיעבד — במקרה הגרוע ביותר חולף בלוק אחד בין האירוע להתראה.
האם זה יעבוד ברשת שאינה EVM?
כן, אך באמצעות מתאם נפרד למכונה הווירטואלית הספציפית. לוגיקת הכללים וערוצי ההתראות נשארים זהים, ורק מקור הנתונים משתנה. את התאימות בודקים ברשת בדיקה לפני העלאה לרשת הראשית.
מה יקרה אם הצומת שאליו מחובר הסוכן ייפול?
הניטור עובר לצומת גיבוי, והבלוקים שהוחמצו מושלמים לפי טווח. כללים קריטיים משוכפלים אצל ספק בלתי תלוי, כך שכשל בודד לא ישאיר את החוזה ללא השגחה.
בואו נדון במשימת הניטור שלכם
כדי לחזור עם הערכה ותוכנית יישום, ולא עם מילים כלליות, אנחנו צריכים מינימום של נתוני פתיחה על החוזה שלכם. ניטור חוזים חכמים הוא לא "להציב התראה", אלא להגדיר אילו אירועים נחשבים לתקרית, מי מגיב וכיצד, ומה נחשב לנורמה במצב רגיל. ככל שתתארו את החוזה והדרישות בצורה מדויקת יותר, כך יידרשו פחות סבבי תיאום.
מה לשלוח כדי שנדון במשימה באופן ענייני:
- כתובות החוזים והרשתות שבהן הם פרוסים, כולל סביבות בדיקה;
- קוד המקור או קוד מאומת וקישור לביקורת, אם הייתה כזו;
- רשימת הפונקציות הקריטיות: משיכת כספים, החלפת בעלים, עדכון לוגיקה, מינט;
- תפקידים והרשאות: מי הבעלים, אילו ארנקים הם אדמיניסטרטיביים, האם קיימת חתימה מרובה;
- אילו אירועים כבר נרשמים ביומן ולאן נשלחות כיום ההתראות;
- דרישות לתגובה: לאן לשלוח אות, תוך כמה זמן הצוות צריך לזהות אנומליה;
- פרופיל העומס הצפוי ותקופות שיא, שבהן הפעילות גדלה בחדות.
על בסיס הנתונים האלה אנחנו מרכיבים תוכנית יישום: אילו כללי זיהוי מכסים את הסיכונים שלכם, כיצד להגדיר התראות ללא התראות שווא, וכיצד לוודא שהמערכת תופסת סטיות אמיתיות ולא רעש. בנפרד אנחנו מתעדים מה אנחנו עושים בשלב ההשקה וכיצד אנחנו מעבירים לכם את השליטה.
תארו את המשימה — נחזור עם הערכה ותוכנית יישום.