מדוע פריסת חוזים חכמים ב-Aptos נכשלת בפרודקשן
פריסת מודולי Move ב-Aptos נכשלת לא בשלב כתיבת הלוגיקה, אלא בשחרור. באופן מקומי המודול מהודר ועובר בדיקות, ואילו ברשת הטרנזקציה נדחית — מפני שתצורת הסביבה, חשבון המשאב וכתובת הפרסום אינם תואמים את מה שנפרס בפועל. מהלוגים של הצומת אי אפשר לחלץ את הסיבה: הרשת מחזירה קוד כשל כללי, ולא את מקום אי-ההתאמה.
צוואר הבקבוק השני — ניהול מפתחות החתימה. כאשר הפרסום נעשה ידנית מארנק מקומי, המפתח הפרטי נמצא על מחשב המפתח, וכל טרנזקציה נחתמת בנפרד. כשמחליפים אחראי אין למי להעביר את המפתח, הרוטציה הופכת להשבתה, וסדר השחרורים משוחזר לפי הזיכרון של מישהו.
השלישי — היעדר בדיקת בייט-קוד לפני הפרסום. המודול עובר לרשת הראשית בלי הרצה ברשת הבדיקות, בלי השוואת הבייט-קוד שהתקבל לזה הצפוי ובלי אימות הרשאות הגישה. טעות בפרסום מודול במצב כזה עולה לא בבנייה מחדש, אלא בשינוי בלתי הפיך של מצב החשבון.
והאחרון: שחרור ידני של מודולים לא משאיר דרך חזרה. אי אפשר לגלגל אחורה מודול שפורסם — ניתן רק להוציא גרסה חדשה, ואם מנגנון העדכון לא הוטמע מראש, השחזור הופך למשימה נפרדת. אנחנו מפרקים כיצד זה נסגר.
מה נותן שחרור מנוהל של מודולים: בנייה, בדיקה, גלגול אחורה
שחרור מנוהל הוא צינור שבו כל גרסה נבנית ממקור מקובע, עוברת את אותה קבוצת בדיקות ומגיעה לרשת הראשית רק לאחר אישור ברשת הבדיקות. פרסום חבילה ב-Aptos הוא בלתי הפיך, ולכן גלגול אחורה של גרסת המודול מוכן מראש: הגרסה הקודמת נשארת פעילה ומוחזרת לפי נוהל מגובש, ולא נבנית ברגע התקלה.
- בנייה בסביבה מבודדת ונקייה: המודולים מהודרים מהמקור בלי עריכות ידניות — פער בין הגרסה המקומית לגרסת השחרור נשלל.
- אוטומציה של הבנייה לפי שינוי במאגר: אותה קבוצת פקודות מניבה תוצאה משוחזרת, ההוצאה לא תלויה במי שמפעיל את השחרור.
- בדיקות לפני הפרסום: ניתוח סטטי, בדיקות לוגיקה והרשאות גישה — שיעור הפרסומים המוצלחים מהניסיון הראשון עולה.
- הרצה ברשת הבדיקות: אותה חבילה עוברת תרחישי מפתח, כולל כשלים בהרשאות ובמכסות, וההתנהגות תואמת את הרשת הראשית.
- בדיקת תאימות האחסון: שינוי במבנה המשאבים נבדק למיגרציה, כדי שחשבונות שכבר נוצרו ימשיכו לפעול.
- גלגול אחורה מוכן של גרסת המודול: הגרסה הקודמת המקובעת והנוהל לחזרה — השחזור אורך דקות במקום בנייה מחדש.
זמן הוצאת הגרסה מתקצר פי כמה: צעדים ידניים הוחלפו בצעדים משוחזרים. סוג הכשלים בגלל גורם אנושי — עריכה בארטיפקט הבנוי, אישור שהוחמץ, פרסום של גרסה לא נכונה — נעלם, מפני שהצינור לא מניח לו לעבור.
אפשרויות פריסה של מודולים: השוואת גישות ומגבלות
ב-Aptos מודול מפורסם לחשבון ונשאר במצב הרשת: אי אפשר לבטל את הפרסום, ניתן רק להחליף את הקוד בעדכון הבא. לכן את מצב הפריסה בוחרים לא לפי נוחות, אלא לפי מבנה תהליך ההוצאה — מי מחזיק את המפתחות, כמה מסלולים נדרשים ובאיזו תדירות הלוגיקה משתנה לאחר השחרור.
הרשת מוסיפה מגבלות משלה: החשבון זקוק ליתרה לגז, גודל המודול מוגבל על ידי הפרוטוקול, והעדכון זמין רק אם מדיניות העדכון הופעלה בפרסום הראשון. לא ניתן להשפיע על התנאי הזה בדיעבד — הוא נקבע ברגע הפריסה. להלן שלושה מצבי פריסה וגבולות היישום של כל אחד.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| פרסום מודול ישיר | מסלול אחד, בדיקות לוגיקה מוקדמות, מחזור עריכות קצר | המפתח נשאר אצל המהנדס, אין היסטוריית שחרורים ולא שחזור בנייה, גלגול אחורה בלתי אפשרי — גרסה חדשה מחליפה את הקוד באותו חשבון |
| צינור שחרור | צוות של כמה מפתחים, הוצאות סדירות, בדיקות ופרודקשן | דורש תשתית בנייה וחתימה, אחסון מפתחות באופן מאובטח והרצת בדיקות לפני הפרסום |
| מסלול מנוהל | מוצר בפרודקשן, נדרשים תפקידים, ביקורת והפרדת סביבות | בלי נוהל גישה, רוטציית מפתחות ומסלול בדיקות נפרד הוא מאבד את משמעותו; התחזוקה מורכבת יותר |
בפועל משלבים בין המצבים: בניות טיוטה מפורסמות ישירות במסלול מבודד, ואילו לפרודקשן עוברת רק גרסה שעברה את הצינור. את הבחירה מקבעים בשלב התכנון — הפריסה הראשונה קובעת אילו עדכונים ותפקידים יהיו זמינים בהמשך.
סדר העבודה: מביקורת המודולים ועד העברת הניהול
כל שלב נסגר בתוצאה מקובעת — אין מתחילים את הצעד הבא עד שהקודם אושר. כך בכל קטע של הפרויקט רואים מה כבר נבדק והיכן נמצאת העבודה. להלן המסלול שפריסת החוזים החכמים ב-Aptos עוברת: מקריאת קוד המקור ועד העברת הניהול לצוות שלכם.
- ביקורת מודולים. אנחנו מפרקים את קוד המקור: מי מחזיק במשאבים, אילו פונקציות פומביות, היכן משתנה המצב, והאם קיימות הרשאות להוצאה ולשריפה של נכסים.
- מפת תלויות. מקבעים את הקשרים בין המודולים, המבנים המשותפים וסדר הפרסום — טעות בסדר מובילה לקריסה של כל הפריסה.
- תכנון הסביבות. קובעים מה נפרס ברשת הבדיקות ומה ברשת הראשית, ואילו פרמטרים משתנים ביניהן: כתובות, תפקידים, מכסות.
- הגדרת הסביבות. מכינים מפתחות והרשאות, מפרסמים מודולים, מאתחלים מצב, בודקים כתובות וקשרים ברשת הבדיקות.
- בדיקות. מריצים תרחישים בערכי קצה: חוסר בהרשאות, קריאה חוזרת, חריגה מהמכסות — לפני המעבר לרשת הראשית.
- קבלה. מציגים פעולות בקרה ברשת הראשית ומשווים את התוצאה למפת התלויות שנקבעה בשלב השני.
- העברת הניהול. מוסרים את המאגר, תרשים הסביבות, מדיניות הגישה למפתחות ונוהל עדכון המודולים.
התוצאה בכל שלב מתועדת בכתב, ולכן עד שלב הקבלה נשארת בידיכם תמונה מלאה של הפריסה, ולא אוסף של טרנזקציות מפוזרות.
מה מועבר לידיים שלכם: תצורות, תרשיםים, מדיניויות, נהלים
פרויקט נחשב מסור לא כאשר המודולים מפורסמים ברשת הראשית, אלא כאשר הצוות שלכם מעדכן אותם בלעדינו. לכן יחד עם הקוד אנחנו מוסרים ארטיפקטים שמתארים את הסביבות, ההרשאות וסדר השחרור: לפיהם מהנדס חדש נכנס לפרויקט ביום, ולא בשבוע.
- תרשים הסביבות של המודולים — כתובות ופרופילים של סטנד מקומי, רשת הבדיקות והרשת הראשית, סדר קידום המודול ביניהן וכללי סנכרון הנתונים.
- מדיניויות גישה — בעל המשאב הניהולי, הפרדת תפקידים, ספי חתימה מרובה, מקומות אחסון המפתחות ונוהל הרוטציה.
- נוהל השחרור — מדיניות עדכון המודולים, סדר האישור, חלונות פרסום, מי חותם ומה עושים בעדכון כושל.
- תיעוד המודולים — ייעוד, פונקציות פומביות, אירועים, אינווריאנטים ותלויות בין המודולים.
- תצורות — פרמטרים של בנייה ופרסום, פרופילים מקובעים, משתני סביבה, בנייה משוחזרת מסביבה נקייה.
- ניטור והתראות — אילו אירועי מודולים מנוטרים, אילו אינווריאנטים נבדקים ולמי מגיע אות על תקלה.
- העברת הפרויקט — מרשם כתובות, חלוקת הרשאות, הדרכת הצוות וערוץ לשאלות לאחר המסירה.
אלה מסמכי עבודה, ולא דוח למדף: את נוהל השחרור משתמשים בכל עדכון, ואת תרשים הסביבות — בהכנסת מהנדס חדש.
מקרה בוחן: העברת שחרורי המודולים למסלול מנוהל
אלינו הגיע צוות מוצר שהוציא מודולי Move ברשת Aptos: כמה שירותים, סט מודולים משותף וכעשרה מהנדסים עם גישה לפרסום. השחרורים יצאו ממחשבים מקומיים, ולכן גרסה שנבנתה על ידי מפתח אחד יכלה להיות שונה מהגרסה של זה שלצידו.
איך זה היה
שיעור הפרסומים המוצלחים עמד על כשני שלישים: כשלים נבעו מפרופילים לא תואמים, כתובות מודולים מיושנות ועריכות "תוך כדי תנועה". שחרור מלא ארך כמה שעות — רוב הזמן הוקדש להשוואה ולתיאום סדר ההוצאה. הצעדים הידניים מנו יותר מעשרה, והשחזור לאחר תקלה היה תלוי במי מהמהנדסים זמין, ויכל לארוך יום.
מה שינו ומה נהיה
הקמנו מסלול מנוהל: סביבת הבדיקות והסביבה הראשית הופרדו כך שהן כבר אינן חופפות, הבנייה הפכה למשוחזרת, ומפתחות הפרסום הועברו מהמחשבים המקומיים לאחסון מאובטח עם תפקידים.
כל צעד בהוצאה הפך לפקודה ניתנת לבדיקה — השוואת כתובות המודולים, סדר הפרסום והתאימות מתבצעת לפני השליחה, ולא אחריה.
שיעור הפרסומים המוצלחים הגיע ל-95% ומעלה, השחרור התקצר מכמה שעות לחצי שעה, ונותרו שני צעדים ידניים — הפעלה ואישור. השחזור לאחר תקלה נמדד בדקות: היומן מראה באיזה שלב ההוצאה נעצרה, והגרסה הקודמת של המודולים מוחזרת באופן צפוי. מהנדס חדש מבצע את הפרסום הראשון בעצמו, בלי ליווי.
במה שונה פרסום מודול מעדכון חבילה ב-Aptos?
פרסום ועדכון ב-Aptos הם אותה טרנזקציה של פרסום חבילה, וההבדל הוא רק במצב חשבון המפרסם. הפריסה הראשונה מניחה את המודול בכתובת החשבון ויוצרת שם משאב עם מדיניות עדכון; כל פרסום עוקב מושווה למצב הזה.
אם מודול בשם כזה כבר קיים בכתובת, הפרסום נכשל עם שגיאה על מודול קיים — יעבור רק עדכון עם אותה קבוצת כתובות בשמות במניפסט. את מדיניות העדכון בוחרים פעם אחת בפריסה הראשונה, ומכאן ואילך ניתן רק להחמיר אותה, עד לשריפת זכות העדכון. לכן את מבנה החשבון מתכננים לפני הפרסום, ולא אחריו.
| אפשרות | מתי נדרש | מגבלות |
|---|---|---|
| פרסום מודול | פריסה ראשונה, מוצר חדש, עותק נפרד תחת כתובת אחרת | שם המודול בכתובת צריך להיות פנוי; המדיניות נקבעת לתמיד |
| עדכון חבילה | פונקציות חדשות, תיקוני לוגיקה בחוזה פעיל | נדרשת זכות עדכון בחשבון; השינויים עוברים בדיקת תאימות גרסאות |
התאימות נבדקת לפי הסדר והסוגים של שדות המבנים, החתימות של הפונקציות הפומביות, פרמטרי הטיפוסים והצהרות friend. מאבדים אותה לרוב בשינוי של כתובת בשם במניפסט: המהדר רואה מודול חדש ומוציא עותק שני של החוזה במקום עדכון. המקרה הנפוץ השני — מחיקה של פונקציה פומבית שחוזים זרים קוראים לה.
הקוד והנתונים נשמרים בנפרד: העדכון משנה את המודול, אך המשאבים בחשבונות נשארים כשהיו. אם מבנה השדות השתנה, המצב הישן נקרא לפי הפריסה הקודמת, ולכן העברת הנתונים מוצאת לפונקציה נפרדת ונקראת יחד עם העדכון.
המהנדסים שלנו מניחים מראש מרווח תאימות ותרחיש גלגול אחורה — ואז העדכון לא הופך להוצאה מחדש של החוזה עם אובדן הכתובת וההיסטוריה.
ספקות טכניים לפני ההתחלה: הרשאות, גלגול אחורה, רשת הבדיקות
חלק מהשאלות צוותי הנדסה שואלים עוד לפני ההתחלה — מהתשובות תלויים פריסת התפקידים והרכב השחרור הראשון.
כיצד מפרידים בין ההרשאות למודול לאחר הפרסום?
אנחנו מפרידים את התפקידים מיד: חשבון הפרסום מוציא מודולים, החשבון הניהולי משנה פרמטרים, והתפעולי מבצע קריאות שגרתיות. מפתח המנהל עובר לחתימה מרובה עם סף, כדי שמהנדס אחד לא יוציא גרסה לבדו. את הניהול מוסרים ללקוח — אצלנו נשאר תפקיד רק לעדכונים לפי הנוהל.
מה עושים אם הגרסה החדשה של המודול תתגלה כלא מוצלחת?
את מדיניות העדכונים מקבעים לפני הפרסום הראשון: שינויים תואמים עוברים אוטומטית, לא-תואמים דורשים אישור מפורש. כתובת המודול לא משתנה, המצב נשאר במקומו — החזרה נעשית בפרסום הארטיפקט הקודם. לכן אנחנו מתכננים את תרשימי המשאבים עם מרווח לשינוי.
היכן בודקים את הקוד לפני הרשת הראשית?
ההרצה מתבצעת ברשת הבדיקות עם אותם פרמטרי מדיניות כמו ברשת הראשית. בדיקות אוטומטיות מכסות את הפונקציות הפומביות, ובנפרד אנחנו בודקים כשלים: חוסר בהרשאות, קריאה חוזרת, חריגה ממכסת החישוב. לרשת הראשית עובר ארטיפקט שתואם את הנבדק לפי סכום ביקורת.
כיצד מתחשבים במגבלות הרשת בעת הפריסה?
לטרנזקציה יש תקרה לחישוב ולנפח המטען השימושי — בחריגה הפרסום מתגלגל אחורה. את הצריכה אנחנו מודדים ברשת הבדיקות, פעולות כבדות מפצלים לחבילות ושומרים מרווח בתקציב, כדי ששיא לא יהפוך לכשל.
נדבר על המשימה: כיצד נבנה השלב הראשון של העבודה
הדבר הראשון שאנחנו עושים עם פנייה — מפרקים את המשימה עד לרמת המודולים. פריסת החוזים החכמים ב-Aptos מתחילה לא מהקוד, אלא מהבנה אילו מבנים ומשאבים של Move יושפעו, מי מחזיק בחשבון הפרסום והאם אין ברשת מודולים עם אותה כתובת. טעות בכתובת או במדיניות עדכון החבילה משמעה שלא ניתן יהיה להוציא גרסה חדשה של החוזה בהמשך.
כדי שהשלב הראשון של העבודה יארך ימים ולא שבועות, נדרש מכם מינימום:
- קישור למאגר ולענף עם הקוד העדכני;
- תיאור הלוגיקה העסקית: מה החוזה עושה בעת קריאה ואילו מצבים הוא משנה;
- מידע על החשבונות: מי מפרסם, האם נדרשת חתימה מרובה;
- רשימת התלויות החיצוניות — חוזים אחרים ומקורות נתונים;
- מגבלות הסביבה: רשת ראשית או רשת בדיקות, דרישות לבדיקות;
- מהנדס מצדכם שיענה על שאלות לגבי הקוד.
החלק שלנו בשלב הזה — פירוק מבנה המודולים והתלויות, בדיקת תאימות לענף הרשת העדכני, טיוטת מדיניות עדכון ותוכנית יישום עם סדר הפרסום. הערכת המשימה מגיעה כמסמך: הרכב העבודה לפי בלוקים, סיכונים ודרכים לסגירתם, רצף הצעדים וגבול השחרור הראשון. כך רואים היכן אנחנו עלולים לשבור חוזים שכבר פועלים וכיצד להימנע מכך לפני הפרסום.
תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית.