אינטגרציה עם Gelato Network לאוטומציה של חוזים חכמים

Gelato Network: היכן נשברת האוטומציה של חוזים חכמים

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

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

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

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

מה נותנת אוטומציה מנוהלת של טרנזקציות

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

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

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

Gelato Network, מתזמן משל עצמך או היברידי: מה לבחור

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

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

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

גם המגבלות של הגישה כנות: אתם תלויים בתור של מישהו אחר, במגבלות קצב ובמדיניות ה-gas, ואת לוגיקת התנאי צריך להתאים למודל הקריאות שלהם.

איך זה מתחבר בפועל

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

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

שלבי הטמעת האוטומציה של חוזים חכמים

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

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

ערכת תצורות, סכמות ותקנונים

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

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

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

מקרה בוחן: איך הסרנו השבתות בתשלומים לפי לוח זמנים

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

מה היה לפני

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

מה שינינו

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

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

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

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

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

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

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

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

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

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

אילו הרשאות נדרשות לארנק?

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

מה יקרה אם המבצע אינו זמין?

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

כיצד מגדירים מגבלות וחזרות?

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

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

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

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

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

בתגובה תקבלו:

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

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