הגדרת Tenderly Web3 Actions: אוטומציה של אירועי on-chain

Tenderly Web3 Actions: היכן נשברת העיבוד הידני של אירועים

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

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

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

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

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

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

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

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

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

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

מצבי הפעלה של מטפלי Web3: השוואת גישות

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

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

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

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

סדר ההטמעה: מביקורת אירועים ועד מסירה

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

1. ביקורת אירועי החוזה. מפרקים את ה-ABI והלוגים: רשימה מלאה של חתימות, שדות עם אינדקס למסננים, ובנפרד — אירועים מפרוקסי, מספריות ומטוקנים קשורים.
2. סכימת עיבוד האירועים. מסמנים מה מפעיל פעולה ומה רק נכתב ליומן, וקובעים מפתח אידמפוטנטיות «האש טרנזקציה + אינדקס הלוג» — מסירה חוזרת לא תכפיל את הפעולה.
3. תופעות לוואי. קובעים לאן הולכת התוצאה: קריאת HTTP חיצונית, כתיבה לבסיס נתונים, התראה. סודות — רק במשתני סביבה, וקריאות — בתוך מגבלת הזמן של הרצת הפעולה.
4. בדיקת המטפל ברשת בדיקה. מריצים על פורק: האירועים הנדרשים, פליטה חוזרת, החזרת בלוק, שירות חיצוני שאינו זמין. כל תרחיש — הרצה עם תוצאה צפויה.
5. הטמעת האוטומציה ברשת הפעילה. מפעילים בהדרגה: כתובת אחת או סוג אירוע אחד, ואחר כך מרחיבים. יומן ההרצות והתראה על הפעלות לא מוצלחות חושפים שגיאת מסנן כבר בדקות הראשונות.
6. מסירת הפתרון לצוות. מוסרים את המאגר, סכימת האירועים והמסננים, משתני סביבה, הרשאות גישה ותקנון: כיצד להוסיף אירוע, להשבית פעולה, לחזור לגרסה קודמת.

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

מה נשאר במאגר לאחר ההטמעה

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

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

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

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

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

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

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

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

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

במה נבדלת מינוי לאירועים מסקירה מחזורית

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

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

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

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

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

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

ספקות טכניים נפוצים לפני ההתחלה

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

האם המטפל יכול להיות מופעל שוב על אותו אירוע?

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

האם אתם מקבלים גישה למפתחות פרטיים?

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

האם האוטומציה תעבוד עם חוזים שכבר פרוסים?

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

מה יקרה בעומס יתר של הרשת או בשיא אירועים?

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

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

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

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

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