Tenderly Debugger: הגדרה, מעקב ותרחישי דיבאג של עסקאות EVM

מדוע טרנזקציות נופלות בפרודקשן ואיך Tenderly Debugger עוזר

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

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

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

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

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

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

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

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

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

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

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

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

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

הגדרת Tenderly Debugger: שלבי העבודה מהאודיט ועד למסירה

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

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

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

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

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

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

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

פרוטוקול ברשת תואמת EVM קיבל כשלים של טרנזקציות משתמשים, ובלוגים של הצומת נותר רק execution reverted כללי בלי סיבה.

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

מה שינינו

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

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

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

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

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

במה שונה סימולציה מפורק רשת בדיבוג?

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

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

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

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

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

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

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

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

האם נדרשים מפתחות פרטיים וגישה לחשבון שלכם?

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

מה לעשות אם הרשת פרוסה בקונטור סגור?

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

איך נשמרים נתוני הדיבוג?

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

נדבר על המשימה: ממה נתחיל ומה נדרש בקלט

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

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

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