אינטגרציה של Band Protocol: סקריפטים מותאמים לאורקל ומודל Pull

מה נשבר באינטגרציה של Band Protocol ללא סקריפטים משלכם

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

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

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

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

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

מה משתנה לאחר ההטמעה: אי-התאמות, השהיות, זמני השבתה

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

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

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

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

Band Protocol: מודל pull במקום עדכון לפי לוח זמנים

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

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

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

שלבי ההטמעה: ביקורת מקורות, סכמה, הגדרה, בדיקה

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

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

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

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

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

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

מקרה בוחן: אי-התאמות נתונים וזמן תגובה לפני ואחרי

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

לפני המעבר

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

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

אחרי המעבר

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

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

במה מודל pull שונה מעדכון תקופתי

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

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

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

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

ספקות טכניים: כשל במקור, מגבלות, מפתחות חתימה

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

האם אנחנו נתקלים במגבלות בקשות למקור?

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

למי נגישים מפתחות החתימה?

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

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

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

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

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