פריסת חוזה חכם: היכן זה נשבר ומה העסק מפסיד
פריסת חוזה חכם ברשת הראשית של Ethereum היא פעולה חד-כיוונית: לאחר אישור העסקה הקוד הופך לבלתי ניתן לשינוי, ואי אפשר להכניס בו תיקונים. רוב ההפסדים מתרחשים לא ברגע הפרסום, אלא בלוגיקה שנשלחה לשם: טעות בפרסום קוד בסביבת בדיקות נראית תמימה, וברשת הראשית היא מתגלגלת לנכסים אבודים.
אי-הפיכות של עסקאות היא תכונה של הרשת, ולא ליקוי של הכלים. אי אפשר לבטל עסקה שאושרה: המוצא היחיד הוא חוזה חדש והגירה, אם היא בכלל מובנית בארכיטקטורה. בלי מנגנון עדכון או עצירת חירום, בעל השירות מביט בבעיה מהצד, בלי מנופים.
היקר מכל היא פגיעות בלוגיקה: גלישה בחישובים, סדר בדיקות שמאפשר למשוך כספים פעמיים, גישה פתוחה לפונקציות קריטיות. המהדר מפספס את זה — הוא בודק תחביר, לא כוונות של המחבר. מחיר הטעות — כספים שנמשכו ואמון שנפגע במוצר.
נקודת כשל נפרדת — אובדן גישה לחשבון הפריסה. המפתח נמצא במקום אחד, עובר בהתכתבות, נשאר אצל קבלן המשנה — ואיתו הולכות הרשאות הבעלים של החוזה.
להלן נפרט כיצד זה נסגר: מהכנה ובדיקה ועד פרסום עם תרחישי ניהול חלופיים ותוכנית הגירה ברורה.
אפקט מדיד: זמן שחרור, חזרות לאחור, סוג כשלים
תהליך מנוהל נבדל לא בהבטחות אלא במדדים מדידים לפני ואחרי. להלן מה שמראה את האפקט של ביקורת, מסלול בנייה בנוי היטב והרצה מבוקרת ברשת הראשית Ethereum.
זמן שחרור עדכונים
החוזה נבנה באותה סביבה בכל איטרציה, הבדיקות מורצות אוטומטית לפני שהצוות בוחן את השינויים. הזמן מסיום הביקורת ועד לקוד ברשת הראשית מתקצר משבועות לימים — שחרור גרסה מפסיק להיות תלוי בשלבים ידניים של מהנדס מסוים.
תדירות תקינות
כל חוזה מקבל סט בדיקות שמכסה הסתעפויות לוגיקה וגבולות ערכים. שיעור המסלולים שהאוטומציה עוברת גדל, ומספר הפניות בגין תקינות לאחר ההרצה יורד: טעויות אופייניות נחסמות לפני הפרסום, לא אחריו.
זמן התאוששות השירות
תפקידים, הגבלות על שחרור ונוהל עצירה מתוארים מראש. כשמשהו משתבש, החזרה למצב הקודם אורכת דקות במקום שעות של תיאומים — מראש ברור מי מבצע ואיזו פעולה.
סוג הכשלים שנעלם
בנפרד נעלמת קבוצה שלמה של בעיות: אובדן שליטה, שחרור כפול, אי-התאמה בין כתובות והרשאות גישה. תרחישים אלה נסגרים על ידי סכימת הפריסה ובדיקות ברשת הבדיקות, ולכן לא מגיעים לרשת הראשית.
אפשרויות הצבת לוגיקה: השוואת גישות
בחירת הסביבה קובעת מי יכול לקרוא לחוזה, כמה עולה כתיבת מצב וכמה מהר עסקה הופכת לבלתי הפיכה. להלן ארבע אפשרויות שבאמת בוחרים ביניהן בפרויקטים, עם תנאי התאמה ומגבלות של כל אחת.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| רשת ראשית ציבורית | עבודה עם משתמשים חיצוניים, בדיקה ציבורית של הקוד, אינטגרציה עם פרוטוקולים זרים | כתיבת מצב משולמת בגז, הקריאות גלויות לכולם, טעות בלוגיקה אי אפשר לבטל — רק לשחרר גרסה חדשה |
| רשת בדיקות ומראה של הרשת הראשית | הרצת הגירות ותרחישי פריסה, תרגול הרשאות גישה לפני שחרור | המצב לא משחזר את הרשת הראשית, ההתנהגות תחת עומס וסדר העסקאות שונים — ניידות נבדקת חלקית |
| רשת פרטית עם גישה מוגבלת | חשבונאות פנימית בין משתתפים מוכרים, הנתונים לא יוצאים החוצה | אין בדיקה חיצונית, המשתתפים מאשרים אמון בנפרד, תמיכה בצמתים ובעדכונים מוטלת עלינו |
| שכבת שכבה שנייה | פעולות המוניות של משתמשים, שבהן חשובים עלות הכתיבה ומהירות האישור | הלוגיקה מפוזרת בין השכבות, מתווספת משיכת כספים לרשת הראשית, הניטור והבדיקות מסתבכים |
רשת הבדיקות הכרחית, אבל היא לא מחליפה ביקורת: היא תופסת טעויות פריסה, לא טעויות בכלכלת החוזה. אם הלוגיקה עובדת עם נכסים זרים, בין רשת הבדיקות לרשת הראשית אנחנו מציבים הרצה הדרגתית — רשימת כתובות מורשות והגבלת נפח פעולות בהתחלה.
איך עוברת פריסת חוזה חכם: שלבי עבודת הנדסה
פריסה ברשת הראשית היא פעולה בלתי הפיכה: לאחר הפרסום אי אפשר לשכתב את לוגיקת החוזה, אפשר רק להפעיל מנגנוני עדכון שהוטמעו מראש. לכן את סדר העבודות מקבעים לפני העסקה הראשונה ומריצים אותו כולו, ולא בשלבים נפרדים.
- ביקורת לוגיקה. מפרקים את החוזה לפי ענפי ביצוע: קריאות חיצוניות, הרשאות לשינוי פרמטרים, טיפול בהחזרים. את הממצאים סוגרים בתיקונים ובהרצה חוזרת — בפלט מתקבל דוח עם סטטוסים.
- סכימת פריסה. קובעים מה מפרסמים בנפרד ומה מחברים דרך פרוקסי, היכן נמצאות הספריות. את סדר העסקאות מקבעים מראש: כתובות שהשלבים הבאים תלויים בהן נוצרות ראשונות.
- הגדרת גישות וחתומים. תפקידי מנהל, מפעיל והשהיית חירום מפרידים למפתחות שונים, פעולות קריטיות — תחת ריבוי חתימות עם סף אישורים. מפתחות לא נשמרים במאגר ולא נכנסים לארטיפקטי הבנייה.
- בדיקה ברשת הבדיקות. חוזרים על הפרסום כולו: אתחול פרמטרים, הענקת תפקידים, הגירות. בנפרד מריצים תרחישי כשל — קריאה בלי הרשאה, ביצוע כפול, ביטול עסקה.
- פרסום ברשת הראשית. העסקאות עוברות בסדר מאושר עם בדיקת מצב אחרי כל אחת, קוד המקור מאמתים בסייר. כתובות והאשים משווים לפני העברתם לצוות.
- מסירת תיעוד. מוסרים סכימת פריסה עם קשרים, רשימת תפקידים וחתומים, סדר עדכון וחזרה לאחור, נוהל השהיית חירום.
הרכב התיעוד והגישות הנמסרים
אנחנו מוסרים לא ארכיון קבצים, אלא מערכת עבודה שצוותכם יכול לפתח בלעדינו. כל סעיף נבדק בקבלה: בלעדיו התחזוקה הופכת במהירות לניסיונות לנחש איך זה הוגדר.
- תצורות פריסה — כתובות של חוזים שנפרסו בכל רשת, פרמטרי אתחול, צמתי הגישה שבשימוש, הגדרות בנייה והאשים של קוד המקור שלפיהם נבדקה הקומפילציה.
- סכימות אינטראקציה — תרשימי קריאות בין חוזים, ארנקים ושירותים חיצוניים: מי קורא למי, אילו אירועים קורא הבקאנד, היכן נמצאות נקודות הכשל.
- מדיניות גישה ותפקידים — מטריצת הרשאות בחוזים ובארנקים: בעלים, מפעיל, עצירת פעולות, ריבוי חתימות; אילו פעולות זמינות למי ואילו ספי חתימות הוגדרו.
- נוהל עדכונים — סדר שחרור מימוש חדש: הכנה, הרצת בדיקות על העתק של הרשת, איסוף חתימות, חלון יישום ותוכנית חזרה לגרסה הקודמת.
- תיעוד על הקוד — ייעוד החוזים והפונקציות, אינווריאנטים נתמכים, מגבלות ידועות, הוראות לפריסה מקומית והרצת בדיקות.
- דוח ביקורת — ממצאים שנמצאו, סטטוס סגירתם וסיכונים שהתקבלו במודע, עם נימוק להחלטה.
- גישות ומפתחות — העברת הרשאות בעלים עם רוטציה: מפתחות חדשים נוצרים בצדכם, שלנו נשללים, היסטוריית הפעולות נשארת במרשם פתוח.
הקבלה נעשית לפי צ'ק-ליסט, לא "על סמך מילים": כל סעיף מאושר בהרצה — פריסה על העתק של הרשת, קריאת אירועים, תרגול תרחיש עדכון.
מקרה בוחן: איך סגרנו סוג כשלים בעדכון לוגיקה
הפרויקט — זירת מסחר עם לוגיקת החזקה מותנית של כספים: חוזה אחד החזיק יתרות, עמלה ותור מחלוקות. כל עדכון של נוסחת התעריפים חייב הגירת מצב ידנית: קליטת בקשות נעצרה ל-40 דקות, ואחרי השקה אחת לשבועיים-שלושה צצו אי-התאמות ביתרות. סוג הכשלים הזה לא נעים כי הנתונים כבר נכתבו מחדש — החזרת גרסת הלוגיקה הקודמת לא מספיקה.
הפרדנו לוגיקה ומצב: החלק המתעדכן נבנה על בסיס OpenZeppelin, הגישה להחלפת לוגיקה נסגרה בארנק ריבוי חתימות עם השהיה, וההחלפה עצמה — עסקה אחת עם נוהל חזרה שנבדק מראש.
לפני כל השקה תרחישי המחלוקות והתשלומים מורצים על העתק של הרשת הראשית עם מצב אמיתי, אי-התאמות ביתרות נבדקות אוטומטית לפני ואחרי.
מדדים לפני ואחרי
חלון העדכון התקצר מ-40 דקות לשעתיים-שלוש, השקות עם אי-התאמות יתרות פסקו — במקום כל שלישית, כעת אפס בכל תקופת התחזוקה. זמן התגובה לתקרית ירד מ-6-8 שעות ל-15 דקות: הניתוח כבר לא מתחיל בקריאה ידנית של לוגים, המהנדס התורן רואה אנומליה ביתרות ומחזיר את הלוגיקה הקודמת בעסקה אחת.
התחזוקה נמשכת: שחרורים מתוכננים, ניטור יתרות ובנייה מחדש של בדיקות לתרחישי מחלוקות חדשים.
מה עושים אם הלוגיקה שנפרסה כבר עובדת ברשת הראשית?
חוזה שנפרס ברשת הראשית בלתי ניתן לשינוי: בייטקוד שנכתב פעם אחת אי אפשר לשכתב. אם הלוגיקה לא הופרדה מראש לאחסון ולמימוש, עדכון לוגיקה שנפרסה מצטמצם לשחרור בכתובת חדשה והעברת מצב.
מכאן הכלל שאנחנו מנסחים לפני הפריסה הראשונה: יכולת עדכון מוטמעת בארכיטקטורה מראש, ולא מומצאת אחרי תקרית.
סכימת החלפה בלי השבתה נבנית על חוזה עטיפה: משתמשים ואינטגרציות תמיד פונים לכתובת אחת קבועה, הנתונים נמצאים שם, וכתובת המימוש מוחלפת בעסקה אחת. המעבר מתבצע כולו — או שהלוגיקה הקודמת פעילה, או החדשה.
מצב של "השירות נעצר וממתין" לא נוצר, ולכן עצירת שירות לעדכון מתוכנן אינה נחוצה ואסור שתהיה חלק מהסכימה.
תאימות לאחור — המגבלה העיקרית של החלפה כזו. הקוד החדש חייב לקרוא נתונים שכבר נכתבו באותו סדר ובאותם טיפוסים: מספיק להזיז את סדר השדות, והיתרות הישנות ייקראו כזרות.
לכן לפני המעבר אנחנו משווים את פריסת האחסון ומריצים את המימוש החדש על העתק של הרשת הראשית עם מצב אמיתי של חשבונות, לא על נתוני בדיקה ריקים.
מה אסור לעשות: לשנות חתימות של מתודות ציבוריות שכבר נשענות עליהן קריאות חיצוניות; לעשות שימוש חוזר בכתובת למשמעות אחרת של ערכים שנכתבו; לתקן נקודתית חוליה אחת בשרשרת חוזים קשורים — עדכון של אחד שובר את האחרים. בנפרד בודקים שהפונקציות הניהוליות מוגבלות ואינן מאפשרות להחליף מימוש בלי סדר מוסכם.
אם יכולת העדכון לא הוטמעה מלכתחילה, נשארת הפעלה מקבילה: גרסה חדשה מקבלת פעולות חדשות, המצב מועבר בחלקים, מעבר הקריאות מתבצע לאחר השוואת סכומים וסטטוסים. זה יקר יותר בהכנה, אבל עובר בלי עצירת שירות ובלי נתק למשתמשים.
ספקות טכניים: עונים לשאלות מהנדסים
כל חמש השאלות שלהלן — לא על הקוד, אלא על הנוהל סביבו. דווקא עליו נשברים פרויקטים שכתובים טכנית נכון. אנחנו עונים כפי שאנחנו מסבירים לפני ההתחלה.
מי מחזיק במפתחות לפרסום החוזה?
מפתח הפריסה לא נשמר במאגר, בהתכתבות או במחשב של המבצע. הוא נוצר במודול חומרה לחתימה שנשאר אצלכם, והשחרור עובר דרך ריבוי חתימות: לבד אי אפשר לא למשוך כספים ולא לשנות לוגיקה. עותק של משפט השחזור מתקבעים מראש באחסון מאובטח — אובדן גישה לחוזה הוא בלתי הפיך.
איך מחולקת הגישה בין צוותים?
תפקידים מחלקים לפי הרשאות מינימליות נדרשות: מנהל חוזה, מפעיל, צופה. חשבונות מונפקים לפעולות ספציפיות, וכל עסקה נכנסת ליומן עם ציון היוזם. ניתוח שינוי אפשרי בדיעבד ואינו תלוי במי שנשאר בצוות.
מה נבדק לפני הפרסום?
ניתוח סטטי, כיסוי בדיקות של ענפים עם לוגיקה כספית, בחינה ידנית של הרשאות וקריאות חוזרות, הרצה על העתק של הרשת. בנפרד בודקים תלות חיצונית: ספריות זרות ומקורות נתונים הם לרוב החור שלא נמצא בקוד שלכם.
מה קורה בזמן תקרית?
הנוהל מסוכם מראש: מי מחליט על השהיה, איך נעצר החוזה, היכן נמצאות הכתובות לשלילת הרשאות. התגובה נמדדת בדקות, לא בשעות, ולכן הסכימה והגישות מאושרות לפני הפרסום, לא ברגע הפעלת ההתראה.
מה כלול בתחזוקה לאחר המסירה?
מוסרים קוד מקור, סכימת כתובות, דוח בדיקות והוראות עדכון. בהמשך נשארים בתמיכה: עדכון תלויות, בדיקה חוזרת לפני שחרורים, ניתוח תקינות. תארו את המשימה — נחזור עם הערכה ותוכנית.
נדון במשימה: נשלח הערכה ותוכנית עבודה
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם טווח "מהתחלה ועד הסוף", אנחנו צריכים הרכב מינימלי של נתוני מקור. מאגר עם חוזים, ארטיפקטי בנייה ותצורת רשת אנחנו מנתחים בעצמנו — לא צריך להכין משהו במיוחד בשבילנו, מספיק מה שכבר יש לצוות.
לאחר מכן הסדר הוא כזה: מבהירים את הלא-ברור, מקבעים את היקף הבדיקות ואת סכימת השחרור, מתאמים לוחות זמנים ונקודות קבלה. להלן מה שצריך בקלט.
- מאגר או כתובות של חוזים שכבר נפרסו: נשווה גרסת מהדר, תלויות ונקודת כניסה.
- רשת ומתאר: ראשית או בדיקות, דרישות לאישורים, מי מחזיק במפתח הפורס.
- תפקידים וגישות: בעלים, מנהל, השהיה, עדכון חוזה — מה צריך להישאר ניתן לניהול אחרי ההרצה.
- דרישות לבדיקות: שיעור מסלולים תחת בדיקות, ניתוח סטטי, גלישות, כניסה חוזרת, הרשאות להנפקת טוקנים.
- סכימת שחרור: סדר שלבים, הגירת מצב, חזרה לגרסה קודמת בלי אובדן נתונים.
- קבלה: אילו מדדים נחשבים לתוצאה ובאיזו עמדת בדיקה בודקים.
- תשתית: צומת או ספק גישה לרשת, ניטור אירועים והתראות לאחר ההרצה.
מאשרים קבלה במהלך יום עסקים ומחזירים מיד רשימת הבהרות. אחרי התשובות שלכם נשלח הערכה ותוכנית עבודה עם שלבים, תלויות ולוחות זמנים לכל אחד — נדון במשימה ונתחיל.