פריסת חוזים חכמים ב-Tron: TVM, אנרגיה, TRC-20

פריסת חוזים חכמים Tron: היכן העסקה נשברת

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

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

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

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

מה משתנה לאחר פריסה מנוהלת

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

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

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

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

פריסה חד-פעמית מול השכרת אנרגיה

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

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

בפועל בוחרים בין ארבעה מצבים, והם אינם תחליפיים זה לזה.

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

שלבי יישום: מהאודיט ועד למסירה

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

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

מדיניות גישה, מפתחות ותיעוד

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

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

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

מקרה בוחן: חוזה שאיבד עסקאות

מה היה לפני ההתערבות

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

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

מה שינינו ומה נהיה

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

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

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

מה לעשות אם החוזה כבר פרוס ועובד באופן לא יציב?

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

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

ברשת Tron קריאות TVM צורכות אנרגיה, והעברת TRC-20 בנוסף מחייבת רוחב פס, ולכן בלי האצלת אנרגיה לכתובת השולחת חלק מהעסקאות נופלות באופן צפוי, והאנרגיה שנשרפה אינה מוחזרת.

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

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

התאימות לקוד הנוכחי נשענת על חתימות המתודות והאירועים של TRC-20 — כל עוד הן תואמות, ארנקים, בורסות ושירותים פנימיים ממשיכים לעבוד עם הכתובת החדשה בלי שינויים.

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

ספקות טכניים ומגבלות

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

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

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

איך לוודא שהחוזה נקרא כראוי בארנק?

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

האם יש מגבלות רשת שאפשר להיתקל בהן?

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

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

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

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

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