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

פריסת חוזים חכמים ב-Base: היכן התהליך נשבר

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

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

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

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

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

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

מה נותן שחרור צפוי: אפקטים מדידים

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

זמן פרסום והחזרה לגרסה קודמת

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

תיאור אחד לכל הרשתות

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

שיעור ההפצות המוצלחות

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

הוצאה נשלטת של עמלת הרשת

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

פורמטי פריסה של חוזים חכמים: מה לבחור

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

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

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

שלבי העבודה: מביקורת הקוד ועד העברת השליטה

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

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

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

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

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

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

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

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

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

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

• קונפיגורציות סביבה. פרופילים נפרדים לרשת המקומית, לרשת הבדיקות ול-Base mainnet: כתובות צמתי RPC, מזהי רשתות, פרמטרי gas, דריסות להרצות חוזרות. מעבר בין סביבות — במשתנה אחד, בלי עריכת קוד.
• סכמת אחסון מפתחות. היכן נמצאים מפתחות הפורס, מי ומבעד לאיזה מעגל חתימה מפעיל אותם, כיצד בנוי ה-multisig עם סף אישורים ו-timelock לקריאות ניהוליות. בנפרד — סדר הרוטציה ומה עושים במקרה של חשיפה.
• מדיניות גישה ותפקידים. מטריצת "תפקיד → אילו פונקציות של החוזה נגישות": בעלים, מפעיל, משהה, אוצר. עם ציון אילו תפקידים אפשר להעביר ואילו מקובעים כבלתי ניתנים לשינוי באתחול.
• תיאור תהליך הפרסום. הרצה צעד-אחר-צעד: בניית ארטיפקטים, הרצה יבשה על fork של המייננט, בדיקת הכתובות הסופיות ופרמטרי הבנאי, הפרסום עצמו, ואישור אימות קוד המקור בסייר.
• הוראות החזרה לאחור. מה מועבר להשהיה, אילו קריאות מבטלות מצב, כיצד מחזירים את התעבורה לכתובת הקודמת ובאיזה סדר מסירים הרשאות. עם ציון אילו פעולות בלתי הפיכות — כדי שההחלטה תתקבל במודע.
• תקנון השחרור. מי יוזם, מי מאשר, אילו בדיקות חובה לפני הפרסום, כיצד מתעדים את יציאת הגרסה והיכן נשמר יומן השינויים של החוזה.
• תוכנית התאוששות. פעולות במקרה של אי-זמינות הצומת, פער במצב ותקלה בחוזים קשורים: נקודות כניסה, אחראים, רצף הצעדים.

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

מקרה בוחן: העברת פרויקטים לשחרור מנוהל

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

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

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

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

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

עדכון מול פתרון פרוס: כיצד לא לאבד נתונים?

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

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

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

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

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

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

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

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

מה יקרה אם מפתח החתימה אבד?

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

איך לוודא שהקוד שפורסם תואם לקוד המקור?

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

מי אחראי לצריכת עמלת הרשת בתנועה כושלת?

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

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

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

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

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