בדיקת חוזים חכמים ברשת בדיקה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

השוואת סביבות בדיקה: סביבה מקומית, רשת בדיקות, פורק של הרשת

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

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

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

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

כיצד אנו בונים את תהליך הבדיקה מהאודיט ועד למסירה

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

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

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

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

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

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

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

תיעוד, תרשימים ותקנונים לריצות חוזרות

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

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

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

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

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

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

מה נחשף ברשת בדיקות

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

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

מה השתנה לאחר העלייה לאוויר

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

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

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

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

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

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

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

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

ספקות טכניים נפוצים לגבי רשתות בדיקות וכיסוי

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

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

מה לעשות עם מקורות נתונים חיצוניים?

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

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

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

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

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

מה לשלוח להתחלה:

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

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