הגדרת Tenderly Simulator: היכן נכשלת בדיקת טרנזקציות
בדיקות עוברות ברשת בדיקה, הריליס יוצא לרשת הראשית — והטרנזקציה הראשונה כבר מוחזרת. נאלצים לנתח לפי אירוע בסייר, שבו רואים רק שורת שגיאה בלי הקשר: איזו קריאה פנימית החזירה אותה ולמה המצב בזמן השליחה היה שונה מהצפוי. כל כשל כזה אחרי פריסה — תרחיש שנעצר, ניתוח ידני ופריסה חוזרת.
רשת הבדיקה אינה משחזרת את העיקר: מצב חוזים עדכני, נזילות בבריכות, תשובות אורקלים וסדר הטרנזקציות בתור. הרצה מקומית מוסיפה משלה — תמונת מצב מיושנת, כתובות אחרות, מגבלות גז שונות. בסופו של דבר הבדיקה מאשרת את תקינות הקוד, אבל לא את ההתנהגות בתנאים אמיתיים.
סימולציה של טרנזקציות על פורק של הרשת הראשית מסירה את הפער הזה. Tenderly Simulator מריץ את הקריאה על בלוק מסוים מול המצב האמיתי: רואים היכן בדיוק נעצרת ההרצה, כמה גז צורכת כל קריאה מקוננת ואילו כתובות חיצוניות מגיבות לא כמצופה. פרופיילינג גז מראה מיד את המרווח עד המגבלה בבלוק — מראש ברור אילו תרחישים לא יעברו כשהרשת עמוסה.
עבור דיבוג חוזים זה משנה את סדר העבודה: שגיאה משוחזרת ומתוקנת לפני פריסה, ולא אחריה. אנחנו מכניסים את הסימולציה כשלב חובה בצינור הבנייה — על כל קומיט מורצים תרחישי מפתח, וכשלים אחרי ריליס מפסיקים להיות הפתעה.
מה נותנת סימולציה לפני שליחה: זמן, צריכת גז, כשלים
כשל ברשת הראשית עולה ביוקר: הטרנזקציה עוברת בדיקה מקומית, יוצאת לרשת ונופלת בקריאה לחוזה חיצוני — הגז נצרך, המצב לא השתנה, והניתוח אורך שעות. מניסיון המהנדסים שלנו, רוב הכשלים האלה ניתנים לשחזור מראש, אם מריצים את הקריאה על עותק של מצב הרשת העדכני.
בדיקה לפני שליחה מבוססת על סימולציה: Tenderly מרים פורק של הרשת עם יתרות אמיתיות, אחסון וקוד חוזים — הטרנזקציה מבוצעת בדיוק כפי שהצומת יראה אותה. אפשר להחליף יתרת ארנק, לנטרל קריאה חיצונית נפרדת, להחזיר את המצב לעומק הרצוי ולראות היכן נשברת הלוגיקה. סוג הכשלים בקריאות לחוזים זרים נעלם כמעט לחלוטין.
פרופיילינג גז הופך את הצריכה לכמות מדידה: רואים איזו קריאה או לולאה צורכת הכי הרבה, איך עולה העלות כשמגדילים את נפח נתוני הקלט ואיזה מרווח להקצות. במקום הימור «בעין» עם תשלום יתר כפול — חישוב לתרחיש מסוים.
מחזור הבדיקה מתקצר כך: הסימולציה מוטמעת באינטגרציה רציפה, וכל סט שינויים מורץ על הפורק אוטומטית. דוח על צריכת גז וחריגות מגיע תוך דקות, בלי דיבוג ידני ברשת הבדיקה; ניתוח תקלה מתבצע לפי צעדי שחזור, ולא לפי ניחושים.
מצבי עבודה של Tenderly Simulator: פורק וסטנד מקומי
עובד במספר מצבים, והם נבדלים לא בממשק, אלא במקור שממנו נלקח המצב והאם אפשר להחזיר אותו. פורק של הרשת הראשית יוצר עותק של המצב האמיתי בבלוק מסוים: רואים יתרות בפועל, נזילות בבריכות והתנהגות של חוזים שכבר נפרסו. סטנד מקומי עולה מאפס — חשבונות צפויים, היסטוריה נקייה, סנאפשוטים מיידיים.
רשת בדיקה ציבורית קרובה יותר לתנאי ייצור בהרכב המשתתפים, אבל המצב בה זר ומשתנה בלי אזהרה. צומת משלנו נותן שליטה מלאה על הסביבה, אך דורש משאבים לסנכרון. בחירת מצב היא תמיד בחירה בין אמינות הסביבה לבין יכולת שחזור של ההרצה.
מתי איזה מצב
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| פורק של הרשת הראשית | בדיקת אינטגרציות עם חוזים חיצוניים, ניתוח תקלה בבלוק מסוים | תמונת מצב: שינויים חדשים ברשת הראשית לא נראים בה, צריך פורק חדש |
| סטנד מקומי | דיבוג לוגיקה, תרחישים עם כשלים וערכי קצה | אין תלויות חיצוניות אמיתיות — התנהגותן מוחלפת בסטבים |
| רשת בדיקה ציבורית | חזרה על פריסה, בדיקת חיבור שירותים בסביבה משותפת | גישה משותפת, חוסר יציבות, סט נתונים מוגבל |
| צומת משלנו | הרצות כבדות קבועות בלי מגבלות חיצוניות, קוד סגור | משאבים לסנכרון ותמיכה, אין כלים מוכנים לפרופיילינג גז |
בפועל משלבים מצבים: לוגיקה בודקים על הסטנד, אינטגרציות — על הפורק, הרצות כבדות קבועות — על הצומת שלנו.
שלבי הטמעה: מביקורת חוזים ועד מסירת נהלים
סדר העבודה כאן אינו פורמליות: אם מתחילים בהגדרת הסימולטור בלי להבין בקריאות חיצוניות, ההרצות יעברו בהצלחה על נתונים חסרים, והפערים יצופו כבר ברשת הראשית. לכן הולכים מהמלאי לנהלים — כל שלב נשען על התוצרים של השלב הקודם.
- ביקורת חוזים וקריאות חיצוניות. אוספים מפה של כתובות, פרוקסים והמימושים שלהם, ספריות, אורקלים, קריאות בין חוזים ולשירותים חיצוניים. בנפרד מסמנים מקומות שבהם צריכת הגז תלויה במצב — שם הסימולציה נדרשת בראש ובראשונה.
- סכמת סביבות. מקבעים רשתות וענפים של הרשת הראשית, בלוקים שמהם נלקח המצב, מקומות אחסון מפתחות ורמות גישה. בלי זה תוצאות ההרצות לא ניתנות לשחזור.
- הגדרת הסביבה. מרימים Tenderly Simulator, מחברים לצומת ארכיוני, מפרסמים חוזים ומגדירים פרמטרים של טרנזקציות: שולח, מגבלות גז, ערך.
- בדיקת תרחישים. מריצים מסלולים מוצלחים, כשלוניים וגבוליים — שינוי הרשאות, השהיה, קריאה חוזרת, מיצוי גז. על כל קריאה מצלמים פרופיל צריכת גז ומשווים לחישובי; חריגה מהסף נחשבת לפגם.
- הטמעה בצינור אינטגרציה רציפה. סימולציות מורצות על כל שינוי בחוזים ובודקות צריכת גז, הרשאות ואירועים צפויים. רגרסיה חוסמת מיזוג עד לניתוח הסיבות.
- מסירת נהלים. מוסרים תיעוד על סביבות, רשימות בדיקה להרצה, כללי תגובה לחריגות וסדר עדכון תמונות מצב — מכאן והלאה הצוות מנהל את התהליך בעצמו.
מה מוסרים לידיים: קונפיגורציות, סכמות, נהלים
לא מוסרים צילומי מסך, אלא מערך ניתן לשחזור על בסיס Tenderly Simulator: הצוות שלכם פורס את הסביבה, מריץ את אותו תרחיש ומקבל את אותה תוצאה. כל מה שהגדרנו נמצא במאגר לצד קוד החוזים — עם היסטוריית שינויים וללא חלקים סגורים בפניכם.
- קבצי קונפיגורציה של סביבות: פרופילים נפרדים לרשת הראשית, לרשת הבדיקה ולפורק המקומי, וגם מצבי הרצה מהיר ומלא.
- סכמות קשרים בין חוזים: מפת קריאות בין חוזים, פרוקסים וספריות, נקודות תלות חיצוניות ואורקלים.
- מדיניות גישה: תפקידים בפאנל, מפתחות להרצת סימולציות באינטגרציה רציפה והרשאות לעריכת קונפיגורציות.
- תרחישי סימולציה: סט טרנזקציות על הפורק — מסלולים מוצלחים, כשלים, צריכת גז לפי מתודות ומצבי קצה.
- תיאור בדיקות: אילו תנאים נחשבים חוסמים לפני פריסה ואיך לקרוא דוח על פער מול התוצאה הצפויה.
- נוהל לפני פריסה: סדר ההרצה, סף לצריכת גז, מי מאשר את התוצאה ומה נרשם בהיסטוריה.
- הנחיות תפעול: איך לעדכן את הפורק כשמשתנה הרשת הראשית ומה לעשות בעת פער.
מעבירים יחד עם המערך סשן ניתוח: המהנדסים שלנו עוברים על הקונפיגורציות והתרחישים ועונים על שאלות. אחרי זה שינויים בבדיקות תבצעו בעצמכם — בלי לפנות אלינו על כל שינוי.
תרגול: כשל נתפס על עותק של הרשת לפני שליחה
לפני הטמעת הסימולציה על כשלים נודע בדיעבד: הטרנזקציה יצאה לצומת חי, נפלה בגלל מיצוי גז או החזרה בקריאה פנימית — ורק אז התחיל הניתוח. שחזור המצב לקח שעות עבודה של מהנדסים, ומספר הקריאות הכושלות שהגיעו לרשת הצטבר לעשרות בשבוע.
ההרצה הועברה לעותק של הרשת הראשית ב-Tenderly: מצב, יתרות ואורקלים נמשכים למועד הבלוק האחרון, והתרחישים משוחזרים באותן קריאות שמגיעות מהממשק. פרופיילר הגז מפרק את הצריכה לפי כל צעד, ולכן צוואר הבקבוק נראה לפני פריסה, ולא בלוגים אחריה.
מה נתנה העברת הבדיקות לבנייה
מדידות גז הפכו לחלק מהבנייה: אם הצריכה בתרחיש חורגת מהמרווח שהוקצה, הבנייה לא עוברת בדיקה והתיקון חוזר למחבר. אותה הרצה תופסת גם כשלים — מגבלת גז שגויה, קריאה לחוזה מושבת, סדר קריאות שבור בפעולה מרוכזת.
במהלך רבעון הקריאות הכושלות שהגיעו לרשת ירדו מעשרות בשבוע ליחידות, והחזרות פריסה לא היו כלל. כשל אחד נתפס על העותק: ענף חדש העלה את צריכת הגז בשליש, ובצומת חי הפעולה הייתה נופלת בוודאות — התיקון נכתב מחדש לפני הפריסה.
במה נבדל פורק הרשת הראשית מסטנד מקומי?
פורק מרים עותק של הרשת הראשית במספר הבלוק הנבחר: המצב נקרא מצומת ארכיוני, ולכן טוקנים, בריכות ואורקלים זמינים מיד עם יתרות אמיתיות וערכים באחסון החוזים. סטנד מקומי מתחיל מג'נסיס ריק — יש בו רק את מה שאתם פרסתם והגדרתם. מכאן הפער הראשון: בסטנד אינטגרציה דורשת סטב, ובפורק היא מתנהגת כמו ברשת הייצור.
בידוד המצב בנוי באופן שונה. בפורק הכתיבות מקומיות ומוחזרות אחרי ההרצה, אבל נתוני הקלט מגיעים מבחוץ: אם לא מקבעים את מספר הבלוק, הרצה חוזרת תיתן תוצאה אחרת. הסטנד דטרמיניסטי לחלוטין, אך אינו משקף את מה שבאמת מונח בשרשרת.
הפער העיקרי — קריאות חיצוניות. אורקל בפורק מחזיר את הערך האחרון שפורסם ואינו מתעדכן, לכן אין במה לבדוק תרחיש של תנועת מחיר חדה.
גשרים, הודעות בין-שרשרתיות ופניות לשירותים חיצוניים אינם מגיבים: בסטנד מחליפים אותם בסטב עם התנהגות מוגדרת, וזה מתאים לבדיקות שליליות, אבל לא להערכת עומק הבריכה והחלקה.
מה לבחור לפי המשימה. לוגיקת חוזה, הרשאות גישה, ערכי קצה — סטנד: ההרצה מהירה יותר, צריכת הגז צפויה, שום דבר לא נמשך מבחוץ. חיבור לפרוטוקולים זרים, פרופיילינג גז על מצב אמיתי, ליקווידציות ותרחישי ארביטראז' — רק פורק, אחרת המספרים לא על הרשת.
מסקנה מעשית: הפער נוצר לא בגלל המצב, אלא בגלל מקורות חיצוניים קפואים — לכן קבעו את מספר הבלוק של הפורק, וכל מה שתלוי באורקלים חיים — או לדמות, או לסמן כלא בדוק.
התנגדויות טכניות נפוצות לגבי סימולציית טרנזקציות
לפני תחילת העבודה הלקוח בדרך כלל שואל שלוש שאלות: האם הסימולציה תואמת את הרשת האמיתית, מה לעשות עם חוזים שכבר נפרסו ואיך להטמיע בדיקות בתהליך הקיים. להלן תשובות קצרות, שבדרך כלל מסירות ספקות בשלב ההערכה.
עד כמה תוצאת הסימולציה תואמת את הרשת האמיתית?
ההרצה מתבצעת על פורק של המצב העדכני: קוד החוזים, היתרות והאחסון נלקחים מהרשת, ולא ממודל מקורב. פער נשאר בשני מקומות — טרנזקציות פרטיות בממפול ותחרות על גז בין בלוקים.
לכן את התרחיש מריצים עם מרווח בעמלה ועל כמה בלוקים עוקבים: אם התוצאה תלויה בסדר הטרנזקציות, זה נרשם כסיכון לפני ריליס, ולא אחריו.
החוזים כבר נפרסו — הסימולציה תעבוד?
כן. הפורק מורם מהכתובת הנוכחית של החוזה, אין צורך לבנות מחדש ולפרוס שוב. מחברים את הקוד שפורסם, מוסיפים תרחישים לבדיקה ופרופיילינג גז לכל קריאה. אם קוד המקור לא תואם לבייטקוד — סיפור נפוץ בחוזים זרים — מודיעים מיד: זו מגבלה של השיטה, לא הגדרה שאפשר לסגור בדיעבד.
איך להטמיע בדיקות בתהליך שלנו וכמה זה ייקח?
הבדיקות מוגדרות כשלב נפרד בבנייה: סט תרחישים מורץ על הפורק בצינור אינטגרציה רציפה, וכשל עוצר את הריליס לפני פריסה. מכם נדרשת גישה למאגר ויכולת להריץ מכולות — את השאר אנחנו סוגרים.
לפי היקף העבודה: מערך בסיסי בפרויקט פעיל נפרס בתוך כמה ימים, והרחבת הכיסוי למסלולים קריטיים מתבצעת באיטרציות לפי השינויים.
נדון במשימה: נבנה סכמת סימולציה לצינור שלכם
כדי שהערכת העבודה תישען על עובדות ולא על מילים כלליות, אנחנו צריכים תקציר קצר של המערך שלכם: רשתות ופורקים, מאגר, סכמת הבדיקות הנוכחית ומה שכבר מורץ אוטומטית. תארו את המשימה בצורה חופשית — נחזור עם תוכנית הטמעה לפי שלבים וסכמת בדיקות עובדת.
מה מבהירים בהתחלה:
- אילו רשתות ופורקים מכסים בסימולציה, ואילו משאירים לשליחת טרנזקציות חיה.
- איך בנוי הצינור כיום: מה מורץ על כל קומיט, מה לפני ריליס, היכן נשארים צעדים ידניים.
- אילו תרחישים קריטיים: העברות, ליקווידציות, קריאות לחוזים חיצוניים, עדכוני פרוקסי.
- אילו הרשאות קיימות ואילו נדרשות: מפתח ל-Tenderly Simulator, הרשאות למאגר ולסוכני בנייה, מגבלות הסביבה.
- מה נחשב כשל בבדיקה: סף לצריכת גז, פער במצב, היעדר אירוע צפוי בלוגים.
- אילו תוצרים צריכים להישמר: פרופיל גז, יומן סימולציה, דוח על הבדלי מצב.
בתשובה נשלח תוכנית הטמעה עם שלבים ולוחות זמנים, הערכת עבודה לפי בלוקים וסכמת בדיקות עם נקודות חזרה. אחר כך — שיחה עם מהנדס שיוביל את העבודה: 40–60 דקות לעניין, בלי מצגות. תארו את המשימה — נחזור עם הערכה ותוכנית.