מדוע פריסת חוזה CosmWasm נכשלת ברשת בדיקה
פריסת חוזה CosmWasm היא לא פעולה אחת, אלא שרשרת: המודול נטען לרשת ומקבל מזהה קוד, ואז נוצר מופע עם כתובת משלו ומצב התחלתי. בדרך כלל נשבר המפגש בין השלבים האלה — הקוד כבר נמצא ברשת, העמלה נגבתה, אבל יצירת המופע נופלת: הודעת אתחול שהורכבה לא נכון, חוסר בגז, אי-התאמה לסכימה המצופה. שגיאת הפריסה של החוזה החכם נראית מיד, אך מצב הרשת כבר השתנה, ואי אפשר לחזור לנקודת ההתחלה.
סוג כשל נפרד הוא טרנזקציה תקועה. הלקוח לא המתין לאישור, קיבל "לא נמצא" והפעיל פריסה חוזרת, בעוד הטרנזקציה המקורית נכנסה לבלוק באותו רגע.
ברשת נשארים שני מופעים עם כתובות שונות, ומכאן מתחיל העיקר: מודולים אחרים ושירותים חיצוניים ממשיכים לפנות לכתובת הישנה, שאיש כבר לא משרת אותה.
היקר מכל הוא אי-התאמה של סכימת הנתונים בעת עדכון החוזה: הלוגיקה חדשה, אבל הרשומות באחסון נשארו בפורמט הקודם. הקריאה נכשלת בפענוח, המפתחות מותאמים ידנית, נדרשת שכבת מעבר ובדיקה חוזרת של אינווריאנטים — וחלק מהקריאות עד אז התייתמו יחד עם הכתובת הישנה.
לכן פריסת חוזה CosmWasm מתכננים כפעולה עם מצב ניתן לבדיקה ושלבים הפיכים — נסביר כיצד זה נסגר.
מה נותנת פריסה מנוהלת של חוזים ברשת הראשית
מה מודדים לפני תחילת העבודה
לפני השינוי הראשון קובעים ברשת הייצור שלושה מדדים: זמן פריסת החוזה, שיעור הטרנזקציות המוצלחות וזמן התאוששות לאחר תקלה. המדידה נעשית לפי לוגים של תעבורה אמיתית, ולא לפי רשת בדיקה — רק שם רואים באיזה שלב מיגרציית המצב נתקעת וכמה קריאות נופלות בגלל פסק זמן.
אותם מספרים הופכים לבדיקת קבלה: לאחר העבודה משווים אותם למקוריים, ולא "לפי תחושות". את המדדים מודדים בכל שחרור, כדי לראות ירידה בביצועים לפני שהמשתמשים יבחינו בה.
אילו סוגי כשלים נעלמים
פריסה מנוהלת מוציאה את עדכון הלוגיקה מהמטפלים לתקנון נפרד: תחילה נפרסת מיגרציית המצב, אחר כך מוחלפת כתובת הקוד, לאחר מכן מורצת בדיקת האינווריאנטים — ורק לאחר מכן נפתחת התעבורה.
סדר השלבים קבוע, לכן עדכון שיושם חלקית הופך לבלתי אפשרי: או שכל השרשרת עברה, או שהרשת נשארה בגרסה הקודמת.
כך נעלמים שלושה סוגי כשלים: סכימת נתונים לא תואמת, קטיעה באמצע העדכון ומפתח ניהולי שנשאר במצב ביניים. בחוזים מנוהלים Cosmos זה ניכר במטריקות: שיעור הטרנזקציות המוצלחות מתקרב לגבול העליון, זמן הפריסה מתקצר פי כמה, וההתאוששות לאחר תקלה מצטמצמת לחזרה לגרסה הקודמת.
מצבי פריסה של חוזים: השוואה ומגבלות
ב-CosmWasm פריסה היא שתי טרנזקציות: store מקבע את קוד הבייט ומוציא code id, instantiate יוצר מופע עם מצב התחלתי ורשומת admin ב-ContractInfo. בחירת המצב מצטמצמת לשני צירים: מי חותם על הפעולות האלה והאם admin נשאר אצל החוזה לאחר ההפעלה. השילובים נבדלים לא "במידת האמינות", אלא במה שיהיה צריך לעשות בשגיאה הראשונה בלוגיקה.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| פריסה ישירה במפתח אחד | בדיקת השערות, חוזי עזר ללא יתרה ותפקידים | מפתח פרטי — נקודת כשל יחידה: חשיפתו מאפשרת החלפת admin ומשיכת כספים |
| פריסה באמצעות ריבוי חתימות | חוזים עם יתרה, שבהם חתימה אחת אינה קבילה | סבב תיאומים לכל פעולה; החלפת הרכב החותמים משפיעה גם על admin של החוזה |
| חוזה ניתן לעדכון (admin + migrate) | פיתוח פעיל, יש MigrateMsg וחזרה לאחור מתורגלת | admin יכול להחליף לוגיקה; יש לתת גרסה למצב, אחרת המיגרציה מאבדת נתונים |
| חוזה בלתי ניתן לשינוי (admin = null) | גרסאות סופיות עם לוגיקה קבועה | תיקון שגיאה — רק כתובת חדשה והעברת מצב ידנית |
מה מחליט admin לפני ההפעלה הראשונה
admin — הכתובת היחידה שיכולה לקרוא ל-migrate, ולא ניתן למנות אותו מאוחר יותר מבחוץ: SetContractAdmin נשלח רק על ידי החוזה עצמו. לכן את הכתובת קובעים מראש — בדרך כלל זה ארנק עם חתימת סף או מודול ניהול של הרשת, ולא מפתח אישי של המפתח.
אם אין צורך ביכולת עדכון, מסירים את admin באמצעות ClearAdmin מיד לאחר ההפעלה, והחוזה הופך לבלתי ניתן לשינוי.
סדר העבודות: מביקורת קוד ועד העברת ניהול
פריסת חוזי CosmWasm — לא פקודה אחת, אלא רצף עם נקודות ביקורת. החוזה חי כמופע נפרד עם קוד בלתי ניתן לשינוי וכתובת מנהל, לכן שגיאה בשלב הטעינה יקרה יותר מריליס רגיל: אי אפשר להחליף כתובת או לבטל קריאות בדיעבד. את סדר העבודות בונים כך שכל שלב נבדק לפני המעבר לשלב הבא.
- ביקורת החוזה החכם והמצב הנוכחי. מנתחים את קוד המקור, התלויות והאחסון, קובעים תפקידים ונקודות פנייה לכתובות חיצוניות — בפלט מתקבלים רשימת סיכונים והחלטה מה מתקנים לפני הפריסה.
- סכימת פריסה וכתובות. קובעים את מספר המופעים, מי מקבל הרשאות מנהל ומיגרציה, וכיצד התפקידים מתחלקים בין חשבון שירות לריבוי חתימות.
- בנייה ובדיקה ברשת בדיקה. בונים ארטיפקט מתלויות מקובעות, טוענים לרשת בדיקה ומריצים אתחול, מיגרציה, סכומים גבוליים וקריאות חוזרות — ה-hash של הקוד חייב להתאים לזה שיעבור לרשת הראשית.
- העברה לרשת הראשית. טוענים את הקוד, יוצרים מופע, מגדירים הרשאות בשלבים עם בדיקת מצב לאחר כל טרנזקציה; את המנהל מחזיקים בריבוי חתימות, ולא במפתח חם.
- בדיקת קריאות. מריצים תרחישים אמיתיים מהממשק ומחוזים חיצוניים: כתובות, תגובות לשגיאות, מגבלות עמלות.
- העברת ניהול. מוסרים כתובות, סכימת תפקידים, תקנון עדכון וחזרה לאחור, סדר פעולות בעת תקרית.
תצורות, סכימות ותקנונים: מה נשאר אצלכם
פריסת חוזי CosmWasm ברשת הראשית מסתיימת לא בעובדה ש"זה עובד", אלא בקבוצת ארטיפקטים שלפיהם אפשר להפעיל ולפתח את המערכת בלעדינו. כל סעיף להלן הוא מסמך עבודה, ולא דוח למראית עין: לפיו מהנדס חדש משחזר את הפריסה, וצוות התחזוקה רואה מה ואסור לגעת בו והיכן.
- תצורות פריסה — פרמטרים של הרשת, קודי חוזים, כתובות מופעים וסדר האתחול. לפי הקובץ הזה הפריסה חוזרת אחד לאחד, בלי להשוות להיסטוריית התכתבות.
- תיעוד החוזה — ייעוד כל הודעה, הרכב המצב הנשמר ומה משתנה בעת הקריאה. מספיק כדי להבין את הלוגיקה בלי לקרוא את קוד המקור.
- סכימת כתובות ומודולים — איזה חוזה עם איזה חוזה מתקשר, היכן עובר גבול האמון, אילו כתובות משויכות לאוצר ולמקורות נתונים חיצוניים.
- מדיניות גישה ותפקידים — מי הבעלים, למי יש זכות למיגרציה, כיצד בנוי הרב-חתימה ואילו פעולות דורשות כמה חתימות.
- תקנון עדכון — רצף המיגרציה, בדיקות לפני העלאה, חלון חזרה לאחור ותנאים שבהם עוצרים את העדכון.
- סדר שחזור מפתחות — סכימת פיצול ואחסון של חלקים, מי מחזיק אותם וכיצד מרכיבים חתימה כאשר משתתף אחד הולך לאיבוד.
- הוראות לצוות שלכם — פעולות טיפוסיות: הוצאת מופע חדש, בדיקת מצב, ניתוח שגיאות בלוגים, פנייה לתמיכה.
כל זה נמצא במאגר שלכם לצד הקוד, ולא בארכיון התכתבות: בעת החלפת ספק או הרחבת הצוות ההקשר נשאר אצלכם.
עדכון חוזה ללא השבתה: נתונים לפני ואחרי
שירות מאגרי הלוואות ב-CosmWasm: הלוגיקה בחוזים חכמים, המצב — במודולים המקושרים במפתחות. את העדכון הוציאו ידנית: עצרו את קליטת הטרנזקציות, פרסו בנייה חדשה, העבירו את המצב ובדקו שהקישורים בין המודולים לא התפצלו. כל שחרור דרש חמישה עשר שלבים ידניים, וכל אחד השאיר פתח לטעות.
מה שינינו
העברנו את השחרורים לעדכון ללא השבתה דרך המנגנון התקני מיגרציה של חוזה: חוזה-מהגר משנה את המצביע לקוד ומעביר במפורש את המצב מהסכימה הישנה לחדשה. לפני ההעלאה המיגרציה מורצת על עותק של מצב הייצור — אי-התאמה בבדיקות עוצרת את השחרור לפני שהוא מגיע למשתמשים. החלפת הגרסה מתבצעת לפי דגל, והחזרה לקוד הקודם — קריאה אחת.
| מדד | לפני | אחרי |
|---|---|---|
| זמן פריסה | שעתיים של עבודה ידנית | 12 דקות של מעבר תקנוני |
| שיעור קריאות כושלות ברגע העדכון | 4-6% | 0 |
| זמן התאוששות לאחר כשל בעדכון | שעות, מצילום מצב של הרשת | דקות, חזרה לגרסה הקודמת |
| פעולות ידניות בשחרור | 15 | 3 |
כעבור חודשיים העדכון הפסיק להיות אירוע: שחרורים יוצאים כמה פעמים בשבוע, ותרחיש החזרה לאחור נבדק בתרגילים לפני כל שינוי גדול. המדדים נשענים לא על הקפדה של מהנדס בודד, אלא על כך שהמיגרציה ובדיקת המצב מתוארות בקוד.
במה מיגרציה של חוזה CosmWasm שונה מפריסה חדשה
פריסה חדשה של חוזה CosmWasm — פעולה על הקוד: קוד המקור מקבל מזהה משלו, והמופע יוצר כתובת חוזה נפרדת עם אחסון ריק. בעת מיגרציה הקוד של המופע הקיים מוחלף, אך כתובת החוזה נשארת כשהייתה — קריאות חיצוניות, אינטגרציות וטוקנומיה התלויות בה ממשיכות לעבוד בלי תצורה מחדש.
שימור המצב במיגרציה לא קורה מעצמו. המטפל מקבל הודעת בקרה ומחליט מה לעשות עם האחסון: להעביר מפתחות, להרחיב מבנים או להשאיר כפי שהם. אם הלוגיקה החדשה קוראת רשומות בפורמט אחר, הטרנזקציה או תיכשל, או תכתוב זבל במקום נתונים.
לכן גרסת סכימת הנתונים מוצאת למטא-נתונים של החוזה: בכניסה למיגרציה היא נבדקת מול המצופה, והעברת המפתחות מורצת על עותק של מצב הייצור, ולא על מופע ריק. רק כך רואים שהרשומות הישנות נקראות כראוי על ידי הלוגיקה החדשה.
מיגרציה או פריסה חדשה — הבחירה תלויה בשאלה אם פריסת האחסון משתנה. תיקון לוגיקה בלי החלפת פורמט הנתונים — זו מיגרציה: הכתובת והקשרים נשמרים, והיקף העבודה מינימלי. החלפת מודל הנתונים, פיצול החוזה לכמה חוזים או העברה למבנה אחר דורשים פריסה חדשה עם העברת מצב בסקריפט נפרד.
קחו בחשבון את אי-ההפיכות: אי אפשר לחזור לקוד הקודם ברשת, והסרת ההרשאה הניהולית הופכת את החוזה לבלתי ניתן לשינוי לנצח. לכן לפני מיגרציה מתעדים צילום מצב של האחסון ומזהה הקוד הקודם לשחזור חירום — אחרת שגיאה בפענוח הנתונים תישאר ברשת יחד עם הנכסים.
ספקות טכניים: גישות, מפתחות ועומס יתר על הרשת
לפני פרסום החוזה ברשת הראשית כמעט תמיד עולה אותה קבוצת שאלות: למי מהמהנדסים יש זכות לעדכן את הקוד, היכן פיזית נמצא מפתח המנהל, כמה בדיקות צריך לעבור לפני הפעלה בייצור ומה יקרה אם הרשת תהיה עמוסה ברגע הפריסה. להלן תשובות מורחבות לחמישה ספקות, שאותם לרוב מסירים לפני תחילת העבודה.
כיצד מחלקים גישות בתוך הצוות?
הרשאות לפריסה, מיגרציה וניהול מחלקים לפי תפקידים: מהנדס מוציא בנייה ומריץ אותה ברשת בדיקה, אך אינו יכול לשנות פרמטרים של חוזה חי. פעולות קריטיות עוברות רק באישור של כמה חתימות, וכל פעולה מתועדת ביומן — רואים מי ומתי הוציא עדכון.
היכן נשמר מפתח המנהל?
מפתח המנהל לא נמצא לא במאגר, לא בהתכתבות ולא במחשב העבודה של המפתח. משתמשים באחסון חומרה עם חתימה לפי סכימת "כמה מתוך כמה", ובעת החלפת הרכב הצוות מבצעים רוטציה: המפתח הישן מבוטל, וההרשאות מועברות לקבוצה החדשה.
כמה בדיקות עובר החוזה עד לרשת הראשית?
הפריסה מורצת שלוש פעמים: ברשת מקומית — על לוגיקה ותנאי גבול, ברשת בדיקה ציבורית — על עמלות אמיתיות וזמן אישור, ואז שוב על עותק של מצב הייצור. חובה לבדוק את תרחיש המיגרציה והחזרה לגרסה הקודמת — הוא חייב לעבוד לפני ההתחלה.
מה קורה בעת עומס יתר על הרשת?
הטרנזקציה עשויה לא להיכנס לבלוק או להיתקע. סקריפטי הפריסה אידמפוטנטיים, החזרה מתבצעת עם אותו רצף פעולות ואינה יוצרת כפילויות. אנחנו עוקבים אחר מילוי הבלוקים ובזמן קפיצת פעילות מעבירים את השחרור לחלון שקט — התוצאה אינה תלויה ברגע ההפעלה.
מה אם הפריסה נפסקה באמצע?
מצב שיושם חלקית מתועד ביומן, ואנחנו רואים את נקודת העצירה. לאחר מכן או שמשלימים את השלבים שנותרו, או שחוזרים לגרסה הקודמת של החוזה — שני המסלולים תורגלו מראש ברשת בדיקה.
נדון במשימה: מה צריך כדי להפעיל את החוזה שלכם
כדי שאומדן הזמנים יתבסס על עובדות, ותוכנית הפריסה תהיה ברת ביצוע, אנחנו צריכים לראות את החוזה ואת הסביבה שלו כפי שהם. תארו את המשימה בצורה חופשית: באיזה שלב הקוד, מה כבר נפרס ברשת בדיקה, אילו תפקידים והרשאות מתוכננים. להלן מה נבקש כדי לחזור עם הצעה לזמנים ולשלבים, ולא עם מילים כלליות.
מספיקות טיוטות, סכימות נוכחיות והערות — אנחנו נביא אותן לסדר.
- מצב החוזה הנוכחי: קוד מקור, סכימת הודעות, מה כבר נבנה ונפרס ברשת בדיקה, אילו בדיקות עוברות.
- דרישות ליכולת עדכון: האם נדרשות מיגרציות מצב, מי מחזיק את מפתח המנהל, האם מותרת השבתה ברגע העדכון.
- סכימת תפקידים וגישות: בעל החוזה, הזכות לשנות פרמטרים ולעצור את הפעילות, כיצד מתוכננת העברת הניהול לצוות שלכם.
- מגבלות עומס: מספר הפניות הצפוי, תקופות שיא, דרישות לזמן תגובה ולהתנהגות בעת כשל של צומת.
- תלויות חיצוניות: קריאות לחוזים אחרים, מקורות נתונים, ערוצים בין-רשתיים, ארנקים ורשתות נדרשים.
- זמנים וקבלה: תאריך הפעלה רצוי, מוכנות הקוד לבדיקה בלתי תלויה, מי מקבל את התוצאה ולפי אילו קריטריונים.
- סדר ההעברה: למי עוברים המפתחות והגישות, איזה היקף תיעוד נדרש כדי לתחזק את החוזה בכוחות עצמכם.
כתבו מה כבר קיים ומה צריך לקבל בסוף, — נחזור עם אומדן זמנים ותוכנית פריסה.