הגדרת Tenderly Fork לבדיקת חוזים חכמים

סטנד בדיקה על Tenderly Fork: היכן חוזים חכמים נשברים

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

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

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

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

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

מה נותן העתק מבודד של הרשת במקום טסטנט משותף

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

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

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

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

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

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

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

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

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

איך אנחנו פורסים את הסטנד: שלבי עבודה הנדסית

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

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

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

מה נשאר במאגר אחרי העברת הסטנד

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

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

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

קייס: הסרנו סוג כשלים בשחרור פרוטוקול

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

מה שינו

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

מה נהיה

• רגרסיה שהגיעה לרשת הראשית: 6 שחרורים מתוך 10 → 1 מתוך 10;
• זמן הכנת שחרור: שלושה שבועות → ארבעה ימים;
• שיעור התרחישים בבדיקות אוטומטיות: כ-40% → יותר מ-90%.

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

במה Tenderly Fork שונה מצומת מקומי

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

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

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

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

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

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

מה לעשות עם חוזים שכבר פרוסים ברשת?

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

אילו גישות נדרשות והאם זה חוסם את הפיתוח השוטף?

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

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

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

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

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