אימות חוזים חכמים: היכן נשבר האמון בקוד
אימות חוזים חכמים עונה על שאלה אחת צרה אך מכרעת: האם הבייט-קוד שבאמת מבוצע ברשת תואם לקוד המקור שפורסם. בדיקה ב-BscScan משווה את ההאש של בנייה חוזרת עם הקוד של החוזה שנפרס — אם יש התאמה, כל מהנדס בודק את הלוגיקה במקום להאמין לתיאור בתיעוד.
זה נשבר באופן שגרתי. אי-התאמה בבנייה נובעת מגרסה אחרת של המהדר, דגלי אופטימיזציה ששונו, שורת מטא-נתונים שנשארה בארטיפקט או תלות שנשכחה. פורמלית זה אותו קוד, אבל ההאש שונה — האימות לא עובר, ובעמוד החוזה מוצג חוזה לא מאומת.
המחיר — סיכון למחזיקים, שקוראים לא את הקוד אלא את הממשק. קיומה של פונקציית הנפקה נוספת, מגבלות על העברה, רשימות חסימה, בעלים נסתר או פרוקסי שניתן לעדכן בלי קוד מקור של החוזה — לא ניתן לבדוק. האפשרות למשוך כספים או לשנות עמלות באופן חד-צדדי נשארת בלתי נראית עד הרגע שבו משתמשים בה.
נשארות האינטגרציות. פרוטוקולי שותפים, אגרגטורים וארנקים קוראים אירועים וקריאות דרך הממשק; בלי קוד מאומת הם מסמנים את החוזה כלא מאומת, מסרבים לרישום או לא מחברים אותו לניתוב. בהמשך נפרט איך זה נסגר — מארטיפקטי בנייה ועד למדיניות הבדיקות בתהליך השחרור.
מה נותן קוד המקור שפורסם של החוזה
פרסום קוד מקור הוא לא „וי“ בכרטיס הטוקן, אלא שינוי מצב העבודה עם כל הלוגיקה של החוזה. כל עוד הקוד נמצא בבייט-קוד, כל בדיקה מתחילה בהנדסה לאחור ומסתיימת בהנחות. אחרי האימות מופיע קוד מקור מאומת — מקור קנוני, שנבדק מול מה שבאמת מבוצע ברשת.
BscScan מקבל כמה מסלולי אימות: עם העברה מפורשת של הגדרות בנייה, עם התאמה אוטומטית לפי בניות דומות, עם חשיפת ייבואים.
ההבדל מהותי בניתוח תקרית: אם ארגומנטים של הקונסטרקטור לא נחשפו או שפרמטרי האופטימיזציה לא תאמו, חוזה שפורסם פורמלית עדיין לא מראה איך הוגדרו התפקידים, המגבלות והזכויות למשיכה.
מכאן מתחילים אפקטים נגזרים. רישום טוקן וחיבור לאגרגטורים נשענים על קוד מקור מאומת: בלעדיו הבקשה עוברת לבדיקה ידנית ותלויה שם עד שהתאמת הבייט-קוד נסגרת. ניתוח תקלות מתקצר מימים של טרייסינג לשעות — מהנדס פותח את הפונקציה הנדרשת ורואה היכן כשלה בקרת הגישה.
יכולת הבדיקה של הלוגיקה פועלת גם נגד הצוות עצמו: כל שינוי בחוזה שפורסם נראה לפי אי-התאמה מול קוד המקור המאומת. לכן המוניטין של הפרויקט מפסיק להישען על הבטחות. בחוזי פרוקסי אנחנו מפרסמים את שתי הכתובות — את העטיפה ואת המימוש, אחרת מאחורי נקודת הכניסה נשארת שכבה אטומה.
דרכי אימות חוזים חכמים: BscScan וחלופות
סייר בלוקים הוא המקום הראשון שאליו לקוח, מבקר או שותף מסתכל לפני אינטראקציה עם החוזה. כל עוד הכתובת לא מסומנת כמאומתת, אין למבקר דרך לקשר בין הבייט-קוד שנפרס לקוד מקור קריא, וכל שאלה „מה בדיוק מבוצע בכתובת“ נשארת בלי מענה.
BscScan והמקבילים שלו פותרים זאת באמצעות התאמה: משווים את תוצאת ההידור למה שנמצא ברשת ומתעדים התאמה.
דרכי המעבר בבדיקה אינן שוות. הבחירה תלויה בכך אם קוד המקור והגדרות הבנייה נשמרו, אם משתמשים בחוזה פרוקסי והאם צריך לחשוף את כל בסיס הקוד.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| פרסום קוד מקור | הקוד נפרס ישירות, קוד המקור ופרמטרי ההידור נשמרו | נחשפת כל הלוגיקה; אי-התאמה קלה בהגדרות הבנייה יוצרת אי-התאמה |
| אימות חלקי | קבוצת חוזים תואמת או שחלק מהקוד הועבר לספריות משותפות | הסייר מאשר רק את הקטעים התואמים, האמון נמוך יותר מאימות מלא |
| בדיקת בייט-קוד | קוד המקור אבד, אבל צריך לאשר את אי-שינוי הקוד שנפרס | מאשר את הכתובת והשלמות, אבל הלוגיקה נשארת לא קריאה |
| אימות לוגיקה מאחורי פרוקסי | החוזה ניתן לעדכון, הקריאות עוברות דרך פרוקסי נפרד | נבדק המימוש; חוזה הפרוקסי עצמו והרשאות המנהל נחשפים בנפרד |
גבולות הישימות נקבעים על ידי הארכיטקטורה: בחוזים מתעדכנים צריך לאמת את המימוש, לא את הכתובת שאליה המשתמשים מסתכלים.
שלבי בדיקה, בנייה ופרסום קוד
בדיקת קוד בסייר נופלת לרוב לא בגלל שגיאות בלוגיקה, אלא בגלל אי-התאמה בסביבות: הבנייה המקומית נעשתה עם דגלי אופטימיזציה אחרים, והבייט-קוד לא תואם למה שנמצא ברשת.
לכן העבודה מתבצעת ברצף קפדני — מקיבוע הסביבה ועד לאישור התוצאה ברשת, ואת ארטיפקטי הביניים אנחנו שומרים כדי שאפשר יהיה לחזור על הבדיקה בלעדינו.
- מקבעים את סביבת הבנייה: גרסאות מדויקות של המהדר, דגלי אופטימיזציה, הגדרות רשת. התצורה נשמרת לצד קוד המקור, לא בזיכרון של מישהו.
- בונים מסביבה נקייה — בנייה משוחזרת במכונה נפרדת בלי מטמונים מקומיים ובלי עריכות „במקום“. בפלט מתקבל ארטיפקט שחייב להתאים בייט-בייט לקוד שנפרס.
- משווים את סכום הביקורת לקוד ברשת. אי-התאמה אפילו של בייט אחד — סיבה לחפש את הגורם: גרסת מהדר, דגלים, מטא-נתונים שירותיים.
- מריצים ברשת בדיקה: פריסה של אותה בנייה ובדיקה שהמתודות והאירועים נקראים כראוי. לתפוס שגיאה כאן זול יותר מאשר בחוזה פעיל.
- מפרסמים את קוד המקור בסייר, במידת הצורך ב-BscScan: קוד, פרמטרי בנאי, ממשק החוזה. ממתינים לסטטוס מאומת, לא לסטטוס ביניים.
- בודקים את התצוגה: מתודות, אירועים וערכי הבנאי גלויים ותואמים למצופה. זה מה שמבקר חיצוני יראה.
- מעבירים ללקוח גישות, תצורת בנייה, הוראות לבדיקה חוזרת ודוח על התאמת סכומי הביקורת.
חבילת ארטיפקטים: סכמות, דוחות ונוהלים
עבודת האימות מסתיימת לא בפרסום קוד המקור בסייר BscScan, אלא במסירת חבילת תיעוד. לפיה מהנדס שלא השתתף בפרויקט יכול לפרוס את החוזה מחדש, לחזור על הבדיקה ולבצע שינוי בלי לשבור את ההתאמה המאושרת בין הקוד לבייט-קוד.
- סכמת החוזה: קשרים בין חוזים, תפקידים, נקודות קריאה חיצוניות ומקומות אחסון מצב.
- דוח בדיקה: פרמטרי הידור, האש בייט-קוד, הגדרות אופטימיזציה ותלויות — כל מה שצריך לציין באימות חוזר.
- נוהל עדכון: סדר הוצאת גרסה חדשה — מתיקון בענף ועד לבדיקה חוזרת של התאמה.
- הוראות לצוות: פעולות שלב-אחר-שלב בפריסה, בבדיקה ובחזרה לגרסה קודמת.
- תצורות ומשתני סביבה: רשת, כתובות, הרשאות גישה והפרדת תפקידים.
- צ'קליסט קבלה: סימנים המראים שהאימות הושלם, והדרך לבדוק אותם.
- יומן שינויים: אילו תיקונים בוצעו ואיך כל אחד השפיע על הכתובת ומצב החוזה.
החבילה נשמרת באותו מאגר שבו נמצא הקוד, ומנוהלת בגרסאות יחד איתו. נוהל מיושן שנשמר בנפרד גרוע מהיעדרו — הוא יוצר ביטחון שווא שהבדיקה עברה, בעוד הגרסה שפורסמה כבר הוחלפה.
מקרה בוחן: טוקן עם אי-התאמה בין הבנייה לקוד המקור
הפנייה הראשונה — טוקן עם מסחר פעיל, שבו ב-BscScan החוזה נשאר לא מאומת. קוד המקור במאגר היה, אבל הבייט-קוד שהועלה בפרסום לא תאם לו: הצוות שלח את הקוד לאישור שלוש פעמים ובכל פעם קיבל סירוב. הקונים לא ראו את פונקציות החוזה, והמבקר לא יכול היה לקשר את הדוח שלו לכתובת.
למה הבדיקה לא עברה
אי-התאמה נבעה לא מתוכן הקוד, אלא מסביבת הבנייה. הפרסום נעשה מענף מקומי של המהדר, בעוד הבדיקה מציבה את הענף העדכני; פרמטרי האופטימיזציה ועומק המעברים היו שונים מאלה שנשארו בארטיפקט, והייבואים נאספו לקובץ אחד בסדר הצהרות אחר. סיבה נפרדת — מטא-נתונים בזנב הבייט-קוד: בהם נמצא האש של ההגדרות, וכל הבדל שובר את ההשוואה.
את הפרמטרים שחזרנו מהבייט-קוד: עברנו על ענפי המהדר, שילובי אופטימיזציה, ענף היעד של המכונה הווירטואלית וסדר הקבצים בעת השטיחה, עד שההשוואה הבייט-בייטית תאמה ב-100%.
מה השתנה
- לפני: חוזה בלי קוד מקור מאומת, שלושה ניסיונות כושלים, בדיקה ידנית גזלה שעות מכל אינטגרטור.
- אחרי: הקוד אומת בניסיון הראשון, פונקציות ואירועים נקראים בסורק, דוח הביקורת מקושר לכתובת.
- לוחות זמנים: יומיים לניתוח הסביבה, הבדיקה עצמה — דקות.
- תוצאה לפרויקט: הממשק והאנליטיקה משכו את החוזה אוטומטית, השאלה „הראו את הקוד“ מצד שותפים ירדה מהפרק.
במה שונה בדיקת פרוקסי מבדיקת חוזה רגיל?
חוזה רגיל נפרס לכתובת בשלמותו: קוד המקור שפורסם והבייט-קוד הם אותו קוד שמבוצע בכתובת הזו. המאמת משווה אותם בייט-בייט, וההתאמה מאשרת גם את הלוגיקה וגם את מבנה האחסון. המשתמש קורא ב-BscScan בדיוק את מה שיבוצע בקריאה הבאה.
חוזה פרוקסי הוא עטיפה שמקבלת קריאה, מפנה אותה לחוזה המימוש ושומרת את המצב אצלה. האישור כאן מכסה רק את הניתוב: בודקים שהעטיפה לא מחליפה קריאות ועובדת כראוי עם האחסון. הלוגיקה עצמה נמצאת בכתובת אחרת ומאומתת בנפרד, והקשר „פרוקסי — מימוש“ נשאר מחוץ להשוואה האוטומטית.
חוזה מתעדכן מוסיף תנועה: המנהל יכול להצביע על מימוש חדש, והאישור שהתקבל קודם כבר לא מתייחס למצב הנוכחי. המשתמש רואה עטיפה מאומתת, אבל לא ערובה שמחר באותה כתובת לא יתחיל להתבצע קוד אחר. לכן בדיקת הלוגיקה של חוזים מתעדכנים היא לא פעולה חד-פעמית, אלא מעקב אחר החלפת מימושים.
מכאן גבולות הישימות: האימות מקבע את הקוד ברגע הבדיקה ולא אומר דבר על הרשאות המנהל. השאלה „מי ובאילו תנאים יכול להחליף מימוש“ נסגרת בנפרד — ניתוח תפקידים, השהיה לפני כניסה לתוקף, סף אישורים. בלי זה חוזה פרוקסי מאומת נותן תחושת שווא של אי-שינוי.
ספקות טכניים לפני בדיקת החוזה
אימות חוזים חכמים נכשל לא בגלל שגיאות בלוגיקה, אלא בגלל אי-התאמה בפרמטרי הבנייה: הבדיקה ב-BscScan משווה את הבייט-קוד ברשת לתוצאת הידור חוזר של קוד המקור. להלן הספקות שעולים בשלב הזה לרוב, ואיך אנחנו סוגרים אותם.
הבדיקה לא עוברת כשקוד המקור נכון — למה?
בדרך כלל ההגדרות של האופטימיזטור לא תואמות: אם הוא מופעל או לא וכמה מעברים הוגדרו. מספר מעברים שונה נותן בייט-קוד שונה באותה לוגיקה, ובבנייה לא סטנדרטית מתווספים נתיבי ייבוא משלה וסדר קבצים.
אנחנו משחזרים את התצורה לפי ארטיפקטי הבנייה ומקבעים אותה במאגר — גרסת המהדר, מספר המעברים, רשימת הקבצים — כדי שהבנייה הבאה תתאים לזו שנפרסה.
חלק מהקוד סגור — האם בדיקה אפשרית?
כן. אם הלוגיקה הועברה לספרייה חיצונית, מפרסמים את הקוד של החוזה עצמו, והספרייה מצוינת לפי כתובת ומאומתת בנפרד. כל מה שבאמת משפיע על הביצוע הופך לגלוי — סגור נשאר רק החלק שאתם בכוונה לא חושפים.
האם צריך לאמת את החוזה מחדש אחרי עדכון?
כן, עם שינוי הבייט-קוד האישור הקודם מפסיק להתאים לקוד ברשת. את המימוש החדש מאמתים בנפרד, את הישן משאירים בהיסטוריה — לפיו רואים מה בוצע לפני העדכון, וזה חשוב בניתוח מצבים שנויים במחלוקת.
מה משתנה עם החלפת רשת?
האישור קשור לרשם מסוים: כתובות, האשים ותוויות לא עוברים לרשת אחרת. אפילו בייט-קוד זהה ברשת חדשה מאומת מחדש, אחרת קוד המקור נשאר גלוי רק לנו, לא לקהילה ולצדדים שכנגד.
נדבר על בדיקת החוזה שלכם ולוחות הזמנים
כדי לחזור עם הערכת היקף מדויקת, ולא עם טווח „מכאן ומכאן“, אנחנו צריכים נתוני מקור על החוזה והבנה מה בדיוק אתם רוצים לראות מפורסם בסייר. תארו את המשימה בצורה חופשית — מספיק קישור לרשת, כתובת החוזה וכמה מילים על האם פרסתם אותו בעצמכם או שהקוד הגיע מצוות קודם.
לאחר מכן אנחנו משווים את הבייט-קוד לקוד המקור, מוצאים אי-התאמות בהגדרות הבנייה וחוזרים עם תוכנית עבודה: מה מתקנים, מה מעבירים כמו שזה, אילו בדיקות מריצים לפני פרסום. שלחו:
- כתובת החוזה, הרשת והכתובת שממנה בוצעה הפריסה;
- קוד מקור של כל החוזים, כולל ספריות וממשקים מחוברים;
- קובץ הגדרות המהדר שאיתו נבנה הבייט-קוד, או את הבנייה עצמה;
- רשימת ארגומנטים של הבנאי, אם החוזה קיבל אותם בעת הדיפלוי;
- חוזי ירושה ופרוקסי, אם הלוגיקה מפוזרת על כמה כתובות;
- גישה לפרופיל שלכם בסייר או אישור שאנחנו מפרסמים מהפרופיל שלנו;
- העדפות לגבי לוחות זמנים והאם צריך לפרסם חוזים קשורים במעבר אחד.
הערכת ההיקף אורכת מעבר אחד על קוד המקור: בודקים אם הבייט-קוד משתחזר בייט-בייט, אם יש ערפול, ואם נתיבי הקבצים תואמים. אחר כך אנחנו נוקבים בלוחות זמנים ומקבעים מה בדיוק בודקים לפני ואחרי הפרסום.
נדבר על המשימה — שלחו את מה שצוין למעלה, ונחזור עם הערכה ותוכנית עבודה.