אסימוני OFT מרובי-שרשרת: פיתוח ואינטגרציה עם LayerZero

פיתוח טוקן Omnichain: היכן שרשרת אחת נשברת

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

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

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

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

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

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

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

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

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

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

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

אפשרויות העברה: נעילה-והנפקה, בריכה, עטיפה

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

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

שלבי העבודה: מאודיט קונפיגורציה ועד להשקה

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

רצף השלבים

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

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

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

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

5. העברת ניהול. הזכויות עוברות לחתימה מרובה, כותבים נוהל שינויים והוראות לתרחישי חירום לצוות.

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

פנקסי הנפקת טוקן, מדיניות זכויות ותיעוד

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

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

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

מקרה בוחן: הסרנו תחשבנות כפולה בהעברת נכס

מה היה

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

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

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

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

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

במה שונה גשר מהנפקה נייטיבית בשתי רשתות?

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

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

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

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

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

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

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

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

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

איך מוסיפים רשת חדשה אחרי ההשקה?

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

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

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

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

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

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

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

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

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