פריסה מקצועית של חוזים חכמים ב-TON מהתחלה ועד הסוף

מדוע פריסת חוזים חכמים ב-TON נכשלת בפרודקשן

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

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

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

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

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

מה נותנת פריסה מנוהלת: אפקט בגדלים מדידים

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

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

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

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

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

דרכי פריסה: ידנית, בצינור, מנוהלת

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

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

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

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

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

1. ביקורת תצורה. מנתחים את קוד המקור, הגדרות הבנייה ופרמטרי הרשת: החוזה חייב להיבנות באופן משוחזר, והכתובות, ההרשאות והמגבלות — להיות מתוארים במפורש, ולא «מהזיכרון».
2. תכנית פריסה. מקבעים את סדר פרסום החוזים והתלויות ביניהם: איזה חייב להתקיים קודם כדי שהבא באתחול נכון.
3. הגדרת סביבות והרשאות. מפרידים בין רשת הבדיקה לרשת הראשית, מחלקים מפתחות לפי תפקידים, מגבילים את ארנק הפרסום להרשאות וליתרה המינימליות הנדרשות.
4. בדיקה לפני פרסום. מריצים תרחישים ברשת הבדיקה: אתחול, קריאות למתודות, סירוב גישה, הרצה חוזרת. משווים את המצב והאירועים לצפויים.
5. פרסום. פורסים בקפדנות לפי התכנית, שומרים כתובות ו-hash-ים של עסקאות — לפיהם מאשרים בהמשך שברשת מונחת בדיוק הבנייה שנבדקה.
6. קבלה ברשת. בודקים את החוזים דרך סיירים ציבוריים, קוראים למתודות המפתח, משווים את המצב בפועל לתוצאת הרצת הבדיקה.
7. מסירה לתפעול. מוסרים כתובות, תכנית, הוראות לעדכון ולחזרה, הרכב המפתחות וסדר הפעולות בעת אירוע; נשארים בקשר כשמשתנים פרמטרים או מתווספים חוזים.

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

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

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

הפורמט נבחר לפני הפריסה: להחליף את מודל הניהול על חוזה פעיל יקר יותר מלקבוע אותו מראש.

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

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

מה שינו

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

מה קרה בסוף

שיעור הפרסומים שעוברים בהרצה הראשונה עלה מ-82% ל-99.4%, מספר האירועים ברבעון ירד מתשעה לאחד. זמן השחזור הצטמצם מארבעים דקות לארבע: החזרה היא מעבר לתמונת המצב הקודמת, ולא תחקיר ידני של הסיבות תחת לחץ. הפעולות הידניות בשחרור הצטמצמו לשתיים — הפעלה ואישור — במקום שתים עשרה.

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

מה לעשות אם החוזה כבר נפרס ופועל

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

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

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

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

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

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

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

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

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

האם השחרור נבדק ברשת הבדיקה לפני היציאה למבצעית?

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

האם הצוות שלנו יוכל לתחזק את החוזה בלעדיכם?

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

נדון במשימה ונחזור עם הערכה ותכנית

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

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

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