הגדרת פורק רשת ראשית לבדיקת חוזים חכמים

פורק mainnet: למה בדיקות מקומיות לא תופסות כשלים

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

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

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

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

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

מה נותנת סביבה מבודדת: מהירות, חזרתיות, שליטה

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

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

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

אפשרויות לארגון סביבת בדיקה: השוואת גישות

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

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

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

שלבי הגדרת פורק mainnet: מביקורת ועד מסירה

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

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

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

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

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

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

מקרה בוחן: העברת בדיקות לסביבה מבודדת ומטריקות לפני ואחרי

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

מה שינו

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

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

מטריקות לפני ואחרי

• שיעור התרחישים שנכשלו בגלל הסביבה, ולא בגלל הקוד: 41% → 5%
• הרצה מלאה של מערך הבדיקות: 34 דק' → 9 דק'
• כשלים ביציאה לאור: כל גרסה רביעית → כל גרסה עשרים

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

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

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

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

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

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

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

ספקות טכניים: תשובות לשאלות נפוצות על הסביבה

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

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

איך מתעדכן הצילום והאם אפשר לחזור אחורה?

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

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

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

האם אפשר להסתפק בלי שירותים חיצוניים בסביבה?

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

נדון במשימה: איך נבנה תוכנית עבודה לסביבה

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

לצורך הדיון במשימה די להעביר:

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

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

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