פריסת חוזים חכמים ב-Optimism: תצורה, אימות, גז

היכן נשבר הדיפלוי של חוזים חכמים ב-Optimism

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

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

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

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

מה נותן מחזור דיפלוי מנוהל של חוזים

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

מהירות הוצאת עדכוני חוזה: שעות במקום שבועות

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

שיעור הדיפלויים המוצלחים

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

שחזוריות של סביבות

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

צפיות של השליחה

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

דרכי דיפלוי: שליחה ידנית, תסריטים, פקטוריות

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

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

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

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

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

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

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

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

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

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

6. בדיקה לאחר הדיפלוי: אימות קוד המקור בסייר, קריאה למתודות מפתח, בדיקת אירועים, ומדידת עלות ה-gas לפעולות טיפוסיות.

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

ארטיפקטי המסירה: קונפיגורציות, סכימות, נהלים

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

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

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

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

מה היה צוואר הבקבוק

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

מה שינו

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

מדדים לפני ואחרי

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

במה נבדל הדיפלוי ברשת הבדיקה מדוכן מקומי?

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

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

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

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

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

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

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

ספקות נפוצים: רשת, gas, אבטחת מפתחות

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

ריכזנו את מה שצף לרוב בשלב ההסכמה — עם תשובות לעניין.

אילו פרמטרי שליחה אתם שולטים בהם?

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

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

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

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

נדון במשימה: מה לשלוח להערכה ולתוכנית

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

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

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