הגדרת תגובה אוטומטית לאירועים בבלוקצ'יין

תגובה אוטומטית לאירועים: היכן ההגנה נשברת

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

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

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

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

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

האפקט מההטמעה: זמן תגובה והיקף הנזקים

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

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

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

חלופות תגובה: טיפול ידני, חוקים, אוטומט

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

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

כיצד אנחנו מטמיעים תגובה אוטומטית

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בירור האירוע ב־StreamPay הראה שני צווארי בקבוק: הגילוי נשען על אדם, ובין «שמו לב» ל«עצרו» לא הייתה אף נקודת בלימה אוטומטית.

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

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

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

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

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

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

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

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

ספקות טכניים: התראות שווא ותיקון חוקים

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

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

כיצד מתקנים חוקים כשהלוגיקה של החוזה משתנה?

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

למי יש גישה למפתחות לצורך תגובה?

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

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

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

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

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