פריסת חוזים חכמים ב-Fantom: היכן זה נשבר ולמה
פרסום חוזה ברשת Fantom נראה כמו פקודה אחת, אבל דווקא כאן צצות שגיאות שאינן נראות בסביבת בדיקות. להלן היכן לרוב נשברת פריסת חוזים חכמים ב-Fantom ולמה צוותים מגלים על הבעיה רק אחרי שהקוד כבר עלה לרשת הראשית.
הסיבה הראשונה — אי-התאמה בין גרסת המהדר והגדרות האופטימיזציה בין הבנייה המקומית לפרסום. קוד הבייט מתקבל שונה, הקוד הפרוס אינו תואם לקוד המקור שמוגש לבדיקה, והאימות מפסיק לעבור.
שגיאה נפוצה שנייה בפרסום חוזה — חריגה לא מטופלת בבנאי או בספרייה מחוברת: העסקה מתבטלת כולה, והמשאב שנגבה אינו מוחזר.
קבוצה נפרדת — פעולות כתיבה. אם מגבלת המשאב נקבעת לפי העין, קריאה עם שינוי מצב נכשלת עם הודעה שאין מספיק משאב לפעולה, למרות שקריאה של אותו חוזה עוברת. קריאה אינה משנה מצב ועולה באופן משמעותי פחות, וכתיבה לאחסון היא החלק היקר ביותר בקריאה, והרזרבה עבורה מחושבת בנפרד.
לכך מתווסף גם ההבדל בין Opera ל-Sonic: כללי תשלום עבור שמירת נתונים ברשתות אלו שונים, ופרמטר שנבחר עבור אחת אינו עובר בשקט באחרת.
התרחיש היקר ביותר — החוזה נפרס למקום הלא נכון. הכתובת נקבעת לפי כתובת השולח ומספר העסקה שלו, ולכן פרסום חוזר מאותו מפתח נותן כתובת חדשה, בעוד החלק הלקוח, הסקריפטים והפרוקסי ממשיכים להסתכל על הישנה. אינטגרציות חיצוניות עובדות עם קוד מיושן, והפער צף רק בנתונים, ולא בשלב הפריסה.
כל ארבע הנקודות נסגרות בתהליך, ולא בקשב של מהנדס אחד: בנייה משוחזרת, חישוב משאב לכתיבה והעברה מפורשת של הכתובת לקונפיגורציה. על כך נדבר בהמשך.
מה משתנה אחרי פריסה מנוהלת
פריסה מנוהלת של חוזים הופכת שחרור שינויים מפעולה ידנית לתהליך משוחזר: הבנייה יוצאת ממצב מקובע של המאגר, הבדיקות מורצות על עותק מקומי של הרשת, ורק אחר כך הקוד עולה לרשת הראשית.
זמן הוצאת השינוי נמדד בעשרות דקות במקום ימים של המתנה לחלון, וכך גם ברשתות הענף Opera ו-Sonic Fantom — ההבדל נשאר רק בפרמטרי הפרסום.
ראשית נעלם סוג הכשלים הקשור לאדם ליד הטרמינל: רשת מבולבלת, כתובת ספרייה לא נכונה, אתחול שהוחמץ, פרסום חוזר מעל גרסה פעילה. שגיאות כאלו לא נתפסות בסקירה, כי הן מתגלות ברגע החתימה.
כשהפרסום מבוצע על ידי אותו תרחיש מאומת עם ארגומנטים קבועים וקוורום מפתחות במקום חתימה בודדת, הסתברות הטעות יורדת לאפס, ולא "מצטמצמת".
הלוגיקה והאחסון מופרדים: עדכון משנה את המימוש מאחורי הפרוקסי, והמצב נשאר במקום. לכן העברת חוזה לגרסה חדשה אינה מחייבת עצירת השירות והעמסת נתונים מחדש — הארנקים והאינטגרציות ממשיכים לעבוד באותן כתובות. גם החזרה לאחור אינה תקלה, אלא החלפת מצביע למימוש הקודם, אם הבדיקות לאחר הפרסום הראו סטייה.
יציבות פעולת החוזה נשענת על נראות: שיעור הקריאות המוצלחות, צריכת הגז לפעולה ואירועי החוזה עוברים לניטור עם התראות על סטייה מהנורמה. זה נותן לא "שקט נפשי", אלא משהו קונקרטי: התקלה נראית לפני פניות משתמשים, ולא אחריהן.
מצבי פרסום: Opera, Sonic ורשתות הבדיקה של Fantom
אותו קוד בייט ברשתות שונות במשפחה מתנהג אחרת: משתנים מזהה הרשת, המטבע לתשלום גז, סט הצמתים הציבוריים וכתובת סייר הבלוקים. חוזה עם מזהה מקודד או כתובת שירות חיצוני יפרס פורמלית, אבל לא יעבוד. לכן אנו קובעים את מצב הפרסום לפני הבנייה, ולא אחריה.
ארבע אפשרויות שביניהן באמת בוחרים בפרויקטים:
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| Opera, הרשת הראשית | השקה תעשייתית: טוקן, חישובים, לוגיקה ציבורית | החזרה לאחור רק במנגנוני החוזה, תיקונים — בגרסה חדשה |
| Sonic, הרשת השנייה במשפחה | קווי מתאר חדשים על מחסנית מוכרת וכלים מוכרים | כתובות, מצב ונכסים משל עצמה — נדרשת העברה |
| רשת בדיקות Fantom | בדיקת תרחישים, תפקידים ותשלום גז לפני השקה | נתונים ושירותים חיצוניים אחרים, ההתנהגות שונה |
| סטנד מקומי על עותק מצב | איטרציות מהירות, רגרסיה, בדיקת עדכון | אינו משחזר תחרות על בלוקים והשהיות |
המסלול обычно такой: סטנד מקומי, רשת בדיקות, ואז Opera או Sonic — הבנייה וסט הבדיקות בכל השלבים זהים. מזהי רשתות, כתובות צמתים ומפתחות מוציאים לקונפיגורציה, ולכן המעבר אינו דורש תיקונים בקוד. השוואת רשתות הפריסה נעשית עניינית: מה נבדק, איזה סוג כשלים נסגר ומה נותר להשקה הראשית.
איך עוברת העברת חוזים: שלבי עבודת הנדסה
העברת חוזים ב-Fantom אינה פרסום מחדש של קוד, אלא העברת הרשאות, תפקידים וקשרים בין חוזים. טעות בסדר הפריסה או בפרמטרים ההתחלתיים מסתיימת בפרסום חוזר ובאובדן מצב, ולכן כל שלב מסתיים בארטיפקט שניתן לבדוק.
- ביקורת חוזים. מפרקים את קוד המקור ואת הכתובות שכבר נפרסו: קריאות חיצוניות, תלות באורקלים ובחוזים של צד שלישי, תפקידי בעלים, מנגנוני עדכון. מתעדים מה עובר יחד עם הקוד ומה דורש אתחול מחדש.
- סכימת פרסום חוזים. בונים גרף תלויות: ספריות ומודולים עזר נפרסים לפני הראשיים, כי הכתובות שלהם נרשמות בבנאים. הסכימה קובעת את סדר העסקאות, הפרמטרים ההתחלתיים והבעלים.
- בניית ארטיפקטים. מהדרים לרשת היעד, משיגים בנייה משוחזרת, שומרים קוד מקור ומטא-נתונים — בלי זה אימות הקוד בסייר הרשת לא יעבור.
- בדיקה בקווי מתאר לבדיקות. מריצים תרחישי מחזור חיים: הנפקה, העברות, שינוי הרשאות, השהיה, סיום חירום. משווים התנהגות לפריסה הנוכחית וסוגרים פערים לפני היציאה לרשת הראשית.
- פרסום ברשת הראשית. מבצעים לפי הסכימה, תוך בקרה על צריכת הגז והתוצאה של כל עסקה; לאחר הפריסה מאמתים כתובות, הרשאות ומצב התחלתי.
- העברת קווי המתאר לתפעול. מוסרים כתובות, ממשקים, מטריצת תפקידים, נוהל עדכון וחזרה לאחור, הגדרות ניטור אירועים — צוות הלקוח ממשיך להפעיל את המערכת בלי השתתפותנו.
מה הלקוח מקבל לידיו אחרי הפרסום
פרסום חוזה ברשת אינו נקודת סיום, אלא רגע מסירת המערכת לתפעול. הלקוח מקבל לא רק כתובת בסייר, אלא גם סט ארטיפקטים שבאמצעותם הצוות שלו יוכל לפתח ולתחזק את החוזים בלי המחבר.
- קונפיגורציות חוזים — קבצים עם פרמטרים לרשתות Opera ו-Sonic: כתובות תלויות, מגבלות גז, ערכים שנבדלים בין סביבות.
- סכימת אינטראקציה בין חוזים — גרף קריאות בין החוזה הראשי, הספריות והשירותים החיצוניים, עם נקודות החלפה מסומנות של רכיבים.
- מדיניות גישה למפתחות — הפרדה בין מפתח פריסה, מפתח מנהלי ומפתח תפעולי, חתימה דרך מולטיסיג, סדר רוטציה ושמירת גיבויים.
- נוהל עדכון חוזה — סכימת עדכניות, סדר אישור שינויים, חלון השהיה למשתמשים ותנאי שחרור גרסה חדשה.
- נוהל חזרה לאחור — איך לחזור למימוש הקודם, אילו נתונים עוברים מיגרציה ומי מקבל החלטה על חזרה לאחור.
- תיעוד חוזים — תיאור שיטות ציבוריות, אירועים ואינואריאנטים שעליהם נשענת האינטגרציה.
- מטריצת תפקידים — למי מהעובדים ולאיזו רמת ניהול יש גישה לאחר המסירה.
הכול נאסף למאגר של הלקוח עם הוראות שחזור: לפרוס עותק של קווי המתאר, לבצע קריאות בקרה, להשוות מצב לצפוי. התמיכה אינה תלויה בשאלה אם מחבר החוזים נשאר בצוות.
מקרה בוחן: העברת חוזים בלי השבתה ואובדן מצב
הלקוח — פרוטוקול של מאגרי נזילות ב-Fantom. החוזים נפרסו ידנית: כל תיקון לוגיקה חייב כתובת חדשה, העברת יתרות ידנית והשוואת מצב לפי יומנים. עד האיטרציה השלישית הפרסום ארך עד שש דקות, בעומס שיא 3-4% מהפניות הסתיימו בכשל, ופערי יתרות בין גרסאות חיפשו ביומנים ידנית.
מה עשינו
את הלוגיקה הוצאנו מאחורי שכבת פרוקסי: הכתובת למשתמשים ולאינטגרציות נשארת קבועה, ורק המימוש משתנה. לפני המעבר בנינו תמונת מצב והרצנו מיגרציה על עותק מקומי של הרשת — עם אותם נתונים ואותו סדר קריאות.
המעבר עצמו ארך בלוק אחד: חלק מהקריאות נשארו על הלוגיקה הקודמת, חדשות עברו למעודכנת, והחזרה לאחור מתבצעת בהחזרת המצביע למימוש הקודם.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| זמן פרסום | 4-6 דקות | 20-40 שניות |
| פניות עם כשל | 3-4% | פחות מ-0.5% |
| העברת מצב | ידנית, לפי יומנים | תמונת מצב והשוואת האשים |
| חזרה לגרסה קודמת | הנפקה מחדש של החוזה | החזרת מצביע |
שלמות המצב אושרה בהשוואת האשים לפני ואחרי — אין פערים, פניות המשתמשים לא נפסקו. עדכונים בהמשך יוצאים לפי תרחיש מעובד: תמונת מצב, חזרה על עותק הרשת, מעבר בבלוק אחד.
במה שונה פריסה ב-Opera מזו שב-Sonic?
שתי הרשתות מאותה משפחה — תואמות EVM, ואותו קוד בייט של החוזה נפרס ב-Fantom Opera וב-Sonic בלי לשכתב את הלוגיקה. ההבדל מתחיל מתחת לרמת הקוד: במודל החישוב עבור פעולות, במגבלות הבלוק ובאופן שבו הרשת מתחשבת במצב שהחוזה תופס. מכך תלויים גם פרופיל העומס לאחר ההשקה, וגם אופן ארגון אחסון הנתונים.
ב-Opera התשלום על פעולות מחושב לפי סכימה מוכרת: גז על חישובים ועוד גז על כתיבה למצב, ומגבלת הבלוק מגבילה את נפח העסקאות. ב-Sonic חשבונאות האחסון עובדה מחדש — המקום התפוס משולם בנפרד מהחישובים, ותפוקה גבוהה יותר.
עבור חוזים עם טבלאות רשומות גדולות זה משנה את התמונה: כדאי לבחור אסטרטגיית אחסון לפני הפריסה, ולא אחרי הגל הראשון של משתמשים.
אי אפשר להעביר חוזה פעיל בעסקה אחת: כתובות ומצב ברשתות בלתי תלויים, ומזהה רשת שונה שולל חזרה על חתימה. בפועל פורסים את אותו קוד בייט מחדש ומעבירים נתונים בנפרד — בתמונת מצב או דרך גשר, אם חשובה רציפות היתרות של המשתמשים. לכן בוחרים רשת לפני הפריסה הראשונה: החלפת זירה מאוחר יותר משמעה מיגרציה עם כל הבדיקות שלה.
ספקות טכניים לפני תחילת העבודה
לפני תחילת העבודה צוותים טכניים שואלים אותן שאלות: מה לעשות עם חוזה שכבר נפרס, איך לבדוק קוד זר ולמי מגיעים המפתחות. להלן תשובות ישירות לרשתות Fantom, בלי מילים כלליות.
איך לבדוק חוזה אם קוד המקור אינו זמין?
משווים את קוד הבייט לקוד המקור שפורסם, אם הוא זמין; בהיעדרו משחזרים את הלוגיקה לפי קוד מפורק ובודקים התנהגות בקריאות על עותק מקומי של הרשת. בנפרד מתעדים רשימת כתובות והרשאות שהחוזה יכול לשנות — זה מראה את משטח הסיכון האמיתי.
אפשר לעדכן חוזה אחרי פרסום?
כן, אם הסכימה הונחה מראש: הלוגיקה מועברת לחוזה נפרד מאחורי כתובת-מתווכת קבועה, והמצב והיתרות נשארים במקום. אם החוזה בלתי ניתן לשינוי — עדכון בלתי אפשרי, ואנחנו מתכננים מיגרציה עם העברת נתונים לכתובת חדשה.
היכן נשמרים מפתחות הפריסה?
המפתח נשאר אצל הלקוח על התקן חומרה, ואנחנו מקבלים רק כתובת ועסקאות חתומות. עבור פעולות קריטיות מגדירים סכימה עם כמה חתימות, ותפקיד המנהל מופרד מחשבון שביצע את הפרסום.
מה לעשות עם חוזה שכבר נפרס?
אין צורך לשכתב אותו: מתחברים לכתובת הקיימת, מפרקים את הממשק והמצב. בהמשך — או הוספת חוזה תואם מעל, או מיגרציה עם העברת יתרות והרשאות, עם בדיקה על עותק הרשת לפני העסקה הראשית.
נדבר על המשימה: מה צריך כדי להתחיל
תחילת העבודה על חוזים מתחילה לא בקוד, אלא בניתוח המשימה ונתוני המוצא. ככל שהקלט קונקרטי יותר, כך פחות הנחות בהערכה ותוכנית הפריסה מדויקת יותר — לרשת Fantom הנבחרת, לקווי מתאר לבדיקות ולעדכוני לוגיקה עתידיים.
כדי לחזור עם הערכה ותוכנית, ולא עם ניסוחים כלליים, די במינימום כזה:
- לוגיקה וגבולות החוזה: מה הוא שומר ואילו פעולות מתיר — פריסה, תשלומים, גישה לפי תפקידים, עצירה ועדכון קוד.
- תפקידים והרשאות: מי הבעלים, למי נדרשות סמכויות ניהול, מי חותם על עסקאות ואיך פועלים באובדן מפתח.
- העברת גישות לרשת: צמתים ושירותי שליחת עסקאות, חשבונות בדיקה, הרשאות לפרסום ואימות קוד.
- כתובות קיימות: חוזים שכבר פעילים, אם האינטגרציה נכנסת למערכת חיה, ושירותים חיצוניים להחלפת נתונים.
- אחסון מפתחות: איך חותמים כיום על פעולות, היכן נמצאים הסודות, מי מורשה להם ולפי איזה נוהל.
- דרישות לבדיקות: אילו תרחישים חייבים להיות מכוסים בבדיקות ואיזה סט בדיקות נדרש לפני הוצאה לרשת הראשית.
- תמיכה לאחר ההשקה: האם נדרשים עדכוני לוגיקה, ניטור עסקאות וניתוח תקלות.
גישות מתקבלות בערוץ מאובטח, סודות אינם נשלחים בהתכתבות — סדר ההעברה מתאמים מראש. לאחר מכן חוזרים עם הערכה, תוכנית עבודה לפריסה לפי שלבים ורשימת סיכונים עם נקודות שבהן נדרשת החלטה שלכם.
תארו את המשימה — נציע לוחות זמנים ופורמט להתחלה.