כיצד להפוך אסימונים צולבים לנתחים שוב: חלק א'

מָבוֹא ה-maxis המודולרי אומר שהעתיד של הקריפטו הוא מיליון (או יותר) דומיינים מחוברים ומשתמשים המדלגים בין בלוקצ'יין כמו אליס המטיילת בארץ הפלאות. למה להישאר עם שרשרת אחת אם אתה יכול לגשת לטכנולוגיה מתקדמת, יישומים חדשים, החזרות ירח על הימור/הקצאת נזילות, ביצועים גבוהים ודמי עסקה נמוכים במיוחד בבלוקצ'יין אחרים? אבל המעבר בין בלוקצ'יין הוא הרבה יותר מסובך מהטיול של אליס בארץ הפלאות, בעיקר בשל מגבלות הגלומות בגישות הנוכחיות לפעילות הדדית של בלוקצ'יין (למשל, גשרים צולבים שרשרת). בפרט, גשרים חוצי שרשרת כיום אינם מאובטחים (2.5 מיליארד דולר אובדים בפריצות לגשרים), איטיים, יקרים או מוגבלים בפונקציונליות - או מציגים שילוב של מאפיינים מהרשימה. בעיות אחרות שמטרידות את תעשיית הגישור הן עדינות יותר אך עדיין מספיקות כדי להפוך את חלומו של המקסי המודולרי על מערכת אקולוגית מרובת שרשרת לסיוט עבור משתמשים ומפתחים - דוגמה לכך היא כיצד אסימונים ניתנים לשינוי (כמו ERC-20s) הופכים ללא ניתנים להפעלה. כאשר מגשרים לרשתות שונות באמצעות פרוטוקולים צולבים שרשרת שונים ומכאן פגיעה בתכונותיו כנכס שניתן להעברה. במאמר זה, נחקור פתרון המבקש לשמר את יציבות האסימון על פני רשתות ללא קשר למקום שבו קיים חוזה המקור של האסימון: ERC-7281: Sovereign-Bridged Tokens. ERC-7281 מרחיב את ERC-20 - התקן דה פקטו ליצירת אסימונים ניתנים לשינוי ב-Ethereum - כדי לאפשר הטבעה וצריבה של ייצוגים קנוניים של אסימוני ERC-20 בדומיינים מרוחקים על ידי מספר גשרים שאושרו על ידי מנפיקי אסימונים. זה מבטיח שמשתמשים המגשרים על אסימון ERC-20 יקבלו גרסאות ניתנות להחלפה של האסימון ביעד (כלומר, שני אסימונים ניתנים להחלפה 1:1), גם כאשר אסימונים נשלחים לרוחב שרשרת דרך מסלולים/גשרים שונים. חשוב לציין, פרוטוקולים המאמצים את ERC-7281 שומרים על שליטה על אסימונים מגושרים (בניגוד לסטטוס קוו שבו הגשר שולט על אסימון מגושר) ויכולים להגביל את פעולות ההטבעה כדי להפחית את החשיפה במקרה של כשל בגשר. בוא נשתמש ב-USDC כדוגמה לאי-פטירות בין אסימוני ERC-20 זהים בתיאוריה על פני רשתות שונות. , כגון Arbitrum, Base, Optimism, מקובל להשתמש בגשר הקנוני כדי להעביר אסימוני ERC-20 פופולריים מה-Ethereum L1 לרשתות אלו. גרסאות אלו של אסימוני L2 שמקורם ב-L1 נקראות בדרך כלל רק "מגושר [הכנס שם אסימון]". ברשתות Ethereum Layer 2 (L2) במקרה של USDC, הסמלים הנפוצים הם USDC.e, USDC.b וכן הלאה. עם הזמן, Circle מרחיבה את פריסות ה-USDC שלה לרשתות אחרות, כולל L2s, בהן ה-USDC כבר חי דרך הגשר הקנוני. למרות ששני האסימונים הללו מוטבעים על ידי אותה ישות ויש להם אותו מחיר, הם שונים מבחינה טכנית, אסימונים בלתי ניתנים לביצוע, ולכן אינם "ניתנים להפעלה הדדית" - בעוד שניתן לגשר על USDC מקורי באמצעות גשר ה-CCTP של Circle, ה-USDC המגושר יכול להיות רק מגושר בחזרה ל-L1 דרך הגשר הקנוני. ERC-7281 מתקן זאת על ידי הצגת הרחבת ERC-20 שבה הפורסים של האסימון יכולים להקצות ולפרמטר מקורות גישור שונים עבורו. בדוגמה שלמעלה, Circle יכול לפרוס אסימון USDC אוניברסלי בכל ה-L2s, כאשר הגשרים הקנוניים (למשל, Circle Mint, Circle CCTP וגשרים מאושרים אחרים) מוקצים כולם כמסוגלים להטביע את האסימונים לפי ההיגיון שלהם. כדי למזער את הסיכונים לפריצה של מנטות, המפעיל יכול להגביל את מספר האסימונים שכל כורך יכול להטביע ולשרוף בפרק הזמן הספציפי - כאשר לגשרים אמינים יותר, כמו ה-L2 הקנוני, יש גבולות גבוהים יותר, וגשרים עם הסכמה מרוכזת הנמוכים יותר. בעוד ERC-7281 אינו הניסיון הראשון ליצור אסימונים חוצי שרשרת ניתנים לשינוי, הוא מתקן בעיות הקשורות להצעות קודמות - כגון נעילת ספקים, אובדן ריבונות למנפיקי אסימונים, עלויות גבוהות של אתחול נזילות עבור אסימונים מגושרים, תשתית תקורה, וחשיפה מוגברת לכשלים בגשרים. דוח זה בן שני חלקים יבחן את הרציונל להכנסת תקן אסימון מגשר ריבוני ויספק סקירה מקיפה של מפרט ERC-7281 (הידוע גם בשם xERC-20). כמו כן, נדון ביתרונות החיוביים ובחסרונות הפוטנציאליים של יישום ERC-7281 עבור משתמשים, מפתחים, ספקי תשתית ושחקנים אחרים במערכת האקולוגית של Ethereum. רענון על גשרי בלוקצ'יין לפני שצולל לבעיה של אסימונים מגושרים שאינם ניתנים לשינוי, זה עוזר להבין מדוע קיימים אסימונים מגושרים מלכתחילה. זה, בתורו, מצריך הבנת המניע ותפעול של גשרי בלוקצ'יין - שכן מפעילי גשרים הם אלו שאחראים ליצירת גרסאות אסימון מגושרות. . מלבד מידע כספי גרידא, גשרים יכולים להעביר כל מידע שימושי כמו שיעורי אסימונים ומצב חוזה חכם ברשתות אחרות. עם זאת, העברת נכסים (אסימונים) משרשרת אחת לאחרת היא מקרה השימוש הנפוץ ביותר עבור משתמשים המקיימים אינטראקציה עם גשר כיום. גשר הוא מנגנון להעברת מידע בין בלוקצ'יין גישות להקלה על העברות נכסים חוצות שרשרת משתנות, אך זרימות עבודה של גישור סמליות עוקבות בדרך כלל אחר אחת משלוש דפוסים ברמה גבוהה: מנעול ומנטה גשרים משתמש רוצה לגשר בין אסימון מהרשת המקורית שלו או ה"ביתית" שלו (שם הוא הונפק בתחילה) לרשת אחרת. שני הבלוקצ'יין אינם ניתנים להפעלה הדדית, שכן כל שרשרת מיישמת ארכיטקטורות ועיצובי פרוטוקול שונים, מה שמונע מהמשתמש להעביר אסימונים ישירות מכתובת ארנק בשרשרת A לכתובת ארנק בשרשרת B. מפעיל הגשר מפקיד אסימונים שהופקדו על ידי המשתמש בשרשרת המקור בחוזה חכם ויוצר ייצוג "עטוף" של האסימון המקורי באמצעות חוזה אסימון שנפרס בשרשרת היעד. כאשר המשתמש מעוניין לגשר בכיוון ההפוך (שרשרת יעד → שרשרת מוצא), הוא מחזיר את האסימונים העטופים לגשר בשרשרת היעד, המאמת זאת לפי ההיגיון בגשר (למשל הוכחות ZK או מניין חיצוני) ומשחרר את האסימונים המקוריים מהפקדון בשרשרת הביתית. גשרים צריבה וטבעה במקום לנעול אסימונים בנאמנות, גישה זו שורפת (הורסת) את האסימונים בשרשרת המקור; לאחר מכן, הגשר מטביע כמות שווה בשרשרת היעד; עבור הנסיעה ההפוכה, האסימונים המגושרים נשרפים בשרשרת היעד לפני שנטבעים אסימונים חדשים בשרשרת המקור; זה שומר על אספקת האסימונים הכוללת תוך הפעלת העברות צולבות שרשרת. החלפות אטומיות גישה זו מחליפה ישירות נכסים בשרשרת המקור בנכסים בשרשרת היעד עם גורם אחר. החלפות אטומיות פועלות באמצעות קרנות נעילה הדדית עם אותו ערך סודי כדי לפתוח אותן, מה שאומר שאם בכל צד הסוד נחשף, ניתן לחשוף אותו גם בצד השני. זה נותן לחילופים את תכונת האטומיות. אטומיות פירושה שההחלפה מסתיימת במלואה (משני הצדדים) או לא בכלל, מונעת הונאה או העברות חלקיות/כושלות. הגישה הראשונה (נעילה ומנטה) היא כיום הנפוצה ביותר. השקילות הערך בין אסימון מקורי לבין הייצוג העטוף המקביל שלו שנטבע על ידי גשר היא המאפשרת למשתמשים "להעביר" נכסים בין שרשרת ולהשתמש באסימון בשרשרת נפרדת מהמקום שבו הוא הופק לראשונה. עם זאת, עיצובים חדשים - כגון גישור מבוסס כוונות - הפכו פופולריים למדי. "כוונות" מאפשרות למשתמשים להביע את התוצאות הרצויות עבור עסקאות ("החלפה של 100 USDC ב-100 DAI") במקום להתאר שלבים ספציפיים להשגת תוצאות. כוונות הופיעו כפתיחת UX רבת עוצמה מכיוון שהן מפשטות מאוד את חוויית ה-onchain עבור אנשים והופכות קריפטו לקל יותר לשימוש, במיוחד בשילוב עם . פתרונות הפשטה של שרשרת מאפשרות למשתמשים להעביר אסימונים בין רשתות מבלי לדאוג לגבי המורכבות הבסיסית של גישור. בגשרים מבוססי כוונות, משתמשים מפקידים כספים בשרשרת המקור ומציינים את התוצאה הרצויה בשרשרת היעד ("כוונתם"). מפעילים מיוחדים הנקראים "מילוי" או "פותרים" יכולים להגשים כוונה זו על ידי שליחת האסימונים המבוקשים למשתמש בשרשרת היעד מראש. לאחר מכן המפעילים מוכיחים שההעברה התרחשה כדי לתבוע את הכספים הנעולים בשרשרת המקור כהחזר. כוונות צולבות שרשרת כמה גשרים מבוססי כוונות ממנפים מנגנוני נעילה ונעילה מתחת למכסה המנוע. במקרה זה, הגשר מטביע אסימונים עטופים שנשלחים אל חומר המילוי שהגשים את כוונת המשתמש - או ישירות אל המשתמש אם אף חומר מילוי לא נכנס פנימה. בעוד שגשרים מבוססי כוונות מוסיפים שכבה נוספת של יעילות דרך רשת הפותרים שלהם, הם עדיין מסתמכים ביסודו על אותם עקרונות כמו גשרי מנעול ונעילה מסורתיים. אנו יכולים לחשוב על כל אסימון עטוף, בין שנוצר באמצעות גישור מסורתי או מבוסס כוונות, כעל IOU ממפעיל הגשר המבטיח לשחרר סכום מהאסימון הבסיסי מחוזה הנאמנות. הערך של נכסים עטופים אלה מתאם ישירות ליכולת (הנתפשת) של מפעיל הגשר לעבד בקשות ממחזיקים למשוך אסימונים מקומיים שהופקדו בשרשרת הביתית של האסימון. הגשר המורשה לנעול את האסימונים הבסיסיים בשרשרת המקור ולהטביע את הייצוגים העטופים שלהם בשרשרת היעד מבטיח שהאספקה הכוללת של האסימון נשארת קבועה. עבור יחידה אחת של האסימון הבסיסי, מוטבעת בדיוק יחידה אחת של האסימון העטוף המתאים, ולהיפך. אם אפליקציה מקבלת אסימון עטוף כאמצעי החלפה או משתמשת בנכסים עטופים כמטבע, מפתחי האפליקציה והמשתמשים סומכים על ספק הגשר שיבטיח את הנכסים ה"אמיתיים" המגבים את האסימון העטוף. למה אנחנו צריכים גשרים? היכולת לבצע עסקות עם גרסה סינתטית של נכס בשרשרת מרוחקת - המתאפשרת על ידי גשרים היוצרים ייצוגים של הנכס - היא תכונה רבת עוצמה ומאפשרת למפתחים ולמשתמשים כאחד לנצל את היתרונות של יכולת פעולה הדדית בין שרשרת. חלק מהיתרונות הללו כוללים גישה ליותר נזילות, חשיפה למשתמשים חדשים וגמישות למשתמשים (שיכולים ליצור אינטראקציה עם אפליקציות מועדפות מרשתות שונות ללא חיכוך). כדי להבין טוב יותר איך זה עובד בפועל ומדוע זה חשוב הן למפתחים והן למשתמשים, בואו נבחן דוגמה קונקרטית באמצעות בורסה מבוזרת בדיונית בשם BobDEX. דוגמה זו תדגים כיצד אסימונים עטופים מאפשרים הרחבה צולבת שרשרת תוך הדגשת היתרונות והסיבוכים הפוטנציאליים שעלולים להיווצר: BobDEX היא בורסה אוטומטית של יוצר שוק (AMM) שבוב יצר ב-Ethereum כדי לאפשר החלפות ללא אמון בין נכסים שונים. ל-BobDEX יש אסימון מקורי, $BOB, המשמש כאסימון ממשל ואסימון תגמול LP. במקרה האחרון, BobDEX מנפיקה אסימוני BOB לספקי נזילות (LPs), המזכה את המשתמשים המספקים נזילות למאגר באחוז מהעמלות ששולמו על ידי משתמשי DEX המחליפים נכסים שהופקדו במאגר. נתח השוק של BobDEX גדל באופן משמעותי, אך המגבלות של Ethereum L1 מעכבות צמיחה נוספת. לדוגמה, חלק מהמשתמשים לא רוצים להשתמש ב-BobDEX ב-Ethereum עקב עמלות גז גבוהות ועיכובים בעסקאות; באופן דומה, משתמשים אחרים רוצים חשיפה למחיר של אסימוני $BOB מבלי שיאלצו להחזיק אסימוני $BOB מקוריים ב-Ethereum. כדי לפתור את הבעיה, בוב פורס גרסה של BobDEX ב-Arbitrum (אוסף שכבה 2 (L2) בתשלום נמוך ובתפוקה גבוהה) ופורס גרסה עטופה של אסימון BOB (wBOB) ב-L2 דרך גשר ארביטרום-את'ריום. BobDEX ב-Arbitrum זהה ל-BobDEX ב-Ethereum, אלא שהוא משתמש ב-wBOB - לא באסימוני BOB מקוריים - לתגמולים ולניהול LP. ההבדל באסימוני יישומים (BOB עטוף לעומת BOB מקורי) אינו משנה מנקודת המבט של משתמשים (למשל, ספקי נזילות) באינטראקציה עם BobDEX ב-Arbitrum. מכיוון שאסימוני wBOB מגובים באסימוני BOB בפועל המוחזקים בגשר ארביטרום-את'ריום, מחזיקי אסימוני wBOB יכולים להחליף בקלות לאסימוני BOB ERC-20 מקוריים ב-Ethereum על ידי אינטראקציה עם חוזה הגשר. המצב הוא win-win עבור בוב והמשתמשים: בוב יכול למשוך יותר משתמשים, במיוחד משתמשים שרוצים עמלות דלק נמוכות ואישור עסקה מהיר בעת מסחר ב- BobDEX LPs יכולים להרוויח תגמולים מאספקת נזילות ל- BobDEX מבלי להתמודד עם עלויות הגז הגבוהות של Ethereum וזמני האישור הארוכים הודלרים יכולים לקנות אסימוני wBOB בשוק כדי להרוויח משינויים במחיר של אסימוני BOB מבלי ליצור אינטראקציה עם חוזה BOB ERC-20 על Ethereum היתרונות של גישור מתרחבים גם לשיפור החדשנות הניתנת לחיבור ולפתיחת מקרי שימוש חדשים הממנפים את הנזילות של אסימון מגושר. לדוגמה, אליס יכולה ליצור פרוטוקול הלוואות בשם AliceLend on Arbitrum שמקבל wBOB כערבות מלווים כדי להרחיב את השימושיות של wBOB וליצור שוק חדש . להלוואות והלוואות מלווים המספקים נזילות ל-AliceLend בטוחים בקבלת הפקדות: אם משתמש אינו עומד בהלוואה, AliceLend ממכר באופן אוטומטי אסימוני wBOB שהופקדו כבטחונות כדי להחזיר למלווים. במקרה זה, קונים של בטחונות wBOB מחוסלים מקבלים על עצמם את התפקיד של LP ב-BobDEX ויש להם אותה ערובה שניתן להחליף אסימוני wBOB 1:1 לאסימוני BOB מקוריים. גישור צולב שרשרת במתכונתו הנוכחית סיפק פתרון בר ביצוע להבטחת והקלה על יישומים חדשים (למשל, הלוואות חוצות שרשרת ו-DEXs חוצי שרשרת). אבל המערכת האקולוגית המגשרת כרגע מתמודדת עם מגבלות שמעכבות צמיחה נוספת, כמו אי-פנגביליות של אסימונים חוצי שרשרת - נחקור את הבעיה הזו בפירוט בהמשך. יכולת פעולה הדדית בין Ethereum L2s (שנכללו בעבר בסילו) מדוע אסימונים מגושרים הופכים לבלתי ניתנים לשינוי? זרימת הגישור של נעילה ונעילה שתוארה קודם לכן נראית פשוטה על הנייר, אך, במציאות, דורשת הרבה מאמץ הנדסי ותכנון מנגנון כדי לעבוד בצורה נכונה: הוא להבטיח שגרסאות עטופות של אסימון מגושר תמיד מגובות באסימונים מקוריים הנעולים בשרשרת המקור. אם תוקף מטביע ייצוגים של אסימון בשרשרת מרוחקת מבלי להפקיד אסימונים מקוריים בשרשרת המקור, הוא יכול להפוך את הגשר לחדל פירעון על ידי החלפת אסימונים עטופים (מוטבעים במרמה) באסימונים מקוריים בשרשרת הביתית ומניעת משתמשים לגיטימיים - שהפקידו ב חוזה הגשר לפני הטביעת אסימונים עטופים - ממשיכת פיקדונות. האתגר הראשון הוא בעל ניואנסים יותר ונובע מאופיים של אסימונים מגושרים: שני ייצוגים של אסימון שהוטבע על ידי ספקי גשרים באותה רשת מרוחקת לא ניתנים להחלפה 1:1 באחר. אנו יכולים להשתמש בדוגמה נוספת של שני משתמשים המנסים להחליף אסימונים המגושרים דרך מסלולים שונים כדי להמחיש היבט זה של הבעיה הקשורה בהעברת אסימונים על פני שרשראות: האתגר השני אליס מגשרת בין USDC מאת'ריום לארביטרום דרך גשר הארביטראם הקנוני ומקבלת 200 USDC.e ב-Arbitrum, בעוד שבוב מגשר בין USDC לארביטרום דרך אקסלאר ומקבל 200 axlUSDC ב-Arbitrum. אליס ובוב מתקשרים בהסכם לאליס לשלוח 200 USDC לבוב (בתמורה ל-200 USDT) כדי שבוב יוכל למשוך 400 USDC ל-Ethereum. בוב מנסה למשוך 400 USDC דרך axlUSDC ומקבל רק 200 USDC, יחד עם הודעה שמסבירה שלגשר יש רק 200 USDC שהוא יכול לתת לבוב. בוב מבולבל מכיוון שאסימוני ERC-20 העטופים אמורים להיות "ניתנים לשינוי" ולא אמורים להפגין פערים שמונעים מאף אחד להחליף אסימוני ERC-20 1:1 בכל יישום. בוב לומד שיעור קשה על גישור צולב שרשרת: "אסימון ERC-20 ניתן להחלפה" לא תמיד אומר "אתה יכול להחליף את האסימון הזה 1:1 עם אסימוני ERC-20 אחרים בין יישומים". הניסיון של בוב לעשות עסקים מסוכנים עם אליס - מסוכן מכיוון שאליס אולי לא תחזיר את האסימונים - משתבש באופן מרהיב. מדוע בוב לא יכול למשוך 400 USDC אם הוא ואליס קיבלו גרסאות עטופות של אותו נכס בסיס בשרשרת היעד? תזכרו שהזכרנו שאסימונים שהונפקו ברשתות שונות אינם תואמים, כך שהייצוג של אסימון מקורי שמונפק בשרשרת לא מקומית הוא IOU מהגשר המבטיח להחזיר סכום מהאסימונים המקומיים (תלוי בכמה נשאר) כאשר המשתמש מעוניין לגשר חזרה לשרשרת המקורית של האסימון. ערכו של כל אסימון מגושר קשור אפוא לספק הגשר האחראי על החזקת פיקדונות בשרשרת הביתית ומייצגי הטבעה בשרשרת היעד; ספק הגשר של בוב יכול לשלם לבוב רק 200 USDC שכן זה הסכום שיש לו כספים לכסות מהפיקדון שלו; לא ניתן למשוך את ה-200 USDC של אליס דרך ספק הגשר של בוב מכיוון שהוא מעולם לא קיבל את הפיקדון או הנפיק IOU לאליס. אליס חייבת למשוך את ה- USDC הנעול שלה מהארביטרום ב-Ethereum ולגשר דרך ספק הגשרים של בוב לפני שבוב יוכל לגשת לאסימונים הנותרים. הדילמה של בוב ואליס מצביעה על בעיה בגישור בין תחומים שבהם ייצוגים מרובים שאינם ניתנים לשינוי של נכס בסיס מוטבעים על ידי ספקי גשרים מתחרים. הבעיה הנוספת עם ייצוגי ERC-20 שונים של אותו נכס היא שלא ניתן לסחור בהם במאגר נזילות אחד. באמצעות הדוגמה הקודמת, אם יש לנו axlUSDC ו- USDC.e בשרשרת ורוצים להחליף אותם ל-ETH ולהיפך, עלינו לפרוס שני מאגרי נזילות - ETH/axlUSDC ו-ETH/USDC.e. זה מוביל לבעיה שנקראת "פיצול נזילות" - מצב שבו למאגרי המסחר יש נזילות קטנה יותר ממה שיכלו להיות להם אחרת, כי ישנן מספר מאגרים שמתאימות בעצם לאותו צמד מסחר. הפתרון הוא שתהיה גרסה "קנונית" אחת של אסימון שמסתובב בשרשרת היעד, כך שבוב ואליס יוכלו להחליף אסימונים מבלי שכל אדם ייסוג מהגשר בשרשרת המקור. קיום אסימון קנוני לכל שרשרת מועיל גם למפתחים, מכיוון שמשתמשים יכולים לעבור במהירות בין מערכות אקולוגיות מבלי להתמודד עם בעיות סביב נזילות האסימון. אז, איך אנחנו ממשיכים להטמיע גרסאות קנוניות של אסימון בכל שרשרת שהיא מצפה לשמש בה ולהעבירה? הסעיף הבא מסביר כמה מהגישות הפופולריות ליצירת אסימונים קנוניים בשרשראות מרובות. הטמעת אסימונים קנוניים על פני רשתות שונות יצירת אסימון קנוני לכל שרשרת אינה פשוטה, וקיימות אפשרויות מרובות עם פשרות ויתרונות משתנים. כשיוצרים אסימון קנוני לכל שרשרת, אנחנו צריכים בדרך כלל לחשוב על מי לסמוך לגבי קיומם של IOUs המגבים את הערך של אסימון מסוים. נניח שאתה היוצר של אסימון ואתה רוצה שהוא יהיה שמיש וניתן להעברה על פני רשתות שונות מבלי להיתקל בבעיות סביב יציבות; יש לך ארבע אפשרויות: אסימוני מנטה קנוניים באמצעות גשרי רול-אפ/שרשרת צד קנוניים טביעת אסימונים קנוניים באמצעות ספק גשרים של צד שלישי אסימונים קנוניים נענע דרך גשר מנפיק אסימונים הנפקה ישירה מרובת שרשרת עם החלפות אטומיות שלוש האפשרויות הראשונות מסתמכות על מנגנוני גישור שונים כדי להקל על תנועה צולבת שרשרת של אסימונים. עם זאת, בתור יוצר אסימון, אתה יכול גם לבחור לעקוף את הגישור לחלוטין על ידי הנפקת האסימון באופן מקורי בכל שרשרת נתמכת. לפי גישה זו, במקום להסתמך על אסימונים עטופים או תשתית גשר, אתה מקיים פריסות אסימונים נפרדות אך מתואמות על פני שרשראות - עם החלפות אטומיות המאפשרות חילופי אמון בין שרשראות. עם זאת, גישה זו דורשת תשתית מתוחכמת כדי לשמור על נזילות על פני רשתות ולהקל על החלפות אטומיות. המורכבות של ניהול פריסות מקומיות מרובות הגבילה היסטורית גישה זו לפרוטוקולים גדולים יותר עם משאבים טכניים משמעותיים. 1. אסימונים קנוניים מנטה באמצעות גשרי רולאפ/שרשרת צד קנוניים אם לשרשרת יש גשר קנוני (מעוגן), אתה יכול להקצות את הזכות להטביע ייצוגים של האסימון של הפרוטוקול שלך למשתמשים שרוצים לגשר מהשרשרת המקורית. עסקאות המנותבות דרך הגשר הקנוני של הרשת (הפקדות ומשיכות) מאומתות בדרך כלל על ידי ערכת האימות של הרשת, המספקת ערבויות חזקות יותר לכך שההפקדות בשרשרת הביתית מחזירות באופן אמין את כל הייצוגים המוטבעים. למרות שהגשר הקנוני טבע את הייצוג הקנוני של אסימון, ייצוגים אחרים עדיין יהיו קיימים. זה קורה פשוט בגלל שלגשרים קנוניים יש לרוב מגבלות שמונעות מהם להציע למשתמשים את החוויה הטובה ביותר. לדוגמה, גישור מ-Arbitrum/Optimism ל-Ethereum דרך הגשר הקנוני של האוסף כרוך בעיכוב של שבעה ימים, מכיוון שעסקאות חייבות להיות מאומתות על ידי מאמתים - ואולי להתווכח על ידי , אם אינה חוקית - לפני שכבת ההסדר של האוסף (Ethereum--מסדיר אצווה עסקה. הוכחת הונאה משתמשי אוסף שרוצים יציאות מהירות יותר חייבים להשתמש בספקי גשר אחרים שיכולים לקבל בעלות על יציאות ממתינות ולספק נזילות מראש בשרשרת היעד הרצויה של המשתמש. כאשר גשרים כאלה משתמשים במודל המנעול המסורתי, בסופו של דבר אנו מקבלים ייצוגים עטופים מרובים של אסימון שהונפקו על ידי פרוטוקולים שונים ומתמודדים עם אותן בעיות שתוארו קודם לכן. לשרשראות צד עם ערכות אימות עצמאיות יש זמן אחזור נמוך יותר מכיוון שהמשיכות מבוצעות ברגע שפרוטוקול הקונצנזוס של ה-sidechain מאשר חסימה המכילה עסקת משיכה. גשר ה-PoS Polygon הוא דוגמה לגשר קנוני המחבר רשת צד לדומיינים שונים (כולל אוסף Ethereum ו-Ethereum mainnet). הערה: אנו מתייחסים לשרשרת Polygon PoS המקורית, לא שתשתמש ב-Ethereum לצורך יישוב. מצולע יהפוך ל-L2 לאחר השלמת המעבר משרשרת צד מאובטחת על ידי מאמתים חיצוניים לתוקף המאובטח על ידי קונצנזוס Ethereum. לשרשרת ה-validium המתוכננת עם זאת, גשרים של שרשרת צד חולקים גם חולשה עם גשרים קנוניים של רול-אפ: משתמשים יכולים לגשר רק בין זוג שרשראות מחוברות. הם לא יכולים לגשר ל-blockchains אחרים באמצעות הגשר הקנוני. לדוגמה, אתה לא יכול לגשר מ-Arbitrum לאופטימיות היום באמצעות גשר הארביטרום או גשר מ-Polygon ל-Avalanche דרך גשר Polygon PoS. 1.1. נענע אסימונים קנוניים באמצעות גשרי נזילות הסתמכות על הגשר המקורי של רולאפ להעברת אסימונים קנוניים מלווה בכמה בעיות, כמו נזילות לקויה ועיכובים בתנועת נכסים. פרוטוקולים עוסקים בבעיה זו על ידי עבודה עם גשרי נזילות כדי להקל על משיכות מהירות וגישור עם אחזור נמוך*. במסגרת הסדר זה, גשרי נזילות מאושרים (א) מטביעים ייצוגים עטופים של אסימון פרוטוקול בשרשרת המקור (ב) מחליפים אסימונים עטופים לייצוג הקנוני ביעד באמצעות מאגר נזילות בבעלות פרוטוקול. הייצוג הקנוני של האסימון בשרשרת היעד הוא בדרך כלל הגרסה המוטבעת על ידי ה-sidechain/Rollup Bridge הקנוני, אם כי קיימים חריגים (כפי שנראה בהמשך). לדוגמה, הגרסה הקנונית של USDT על אופטימיות היא opUSDT שהוטבעה על ידי גשר האופטימיות. כל גשר נזילות מתפקד כמו DEX עם יוצר שוק אוטומטי (AMM) לביצוע החלפות בין זוגות נכסים המופקדים במאגרי נזילות שונים. כדי לתמרץ מתן נזילות, מאגרי AMM חולקים חלק מעמלות ההחלפה למחזיקים שנועלים אסימונים קנוניים בחוזי המאגר. זה דומה לדגם של Uniswap; ההבדל הבולט היחיד הוא שצמדי נכסים הם בדרך כלל הייצוג של גשר הנזילות של אסימון מול הייצוג הקנוני. לדוגמה, משתמש שמגשר בין USDT לאופטימיות באמצעות Hop יצטרך להחליף hUSDT ב-Optimism באמצעות מאגר huSDT:opUSDT. זרימת העבודה לגישור באמצעות גשר נזילות ייראה כך: נעל אסימונים מקוריים בשרשרת המקור ייצוג גשר מנטה של אסימון מקומי על שרשרת היעד החלף ייצוג מגשר עם ייצוג קנוני בשרשרת היעד באמצעות מאגר AMM שלח אסימונים קנוניים למשתמש תהליך זה דומה לכל גשרי הנזילות (Across, Celer, Hop, Stargate וכו'). עם זאת, זה בדרך כלל מופשט הרחק ממשתמש הקצה - במיוחד על ידי פותרים/מילויים - וירגיש כמו עסקה בודדת למרות שהיא כוללת חלקים נעים רבים. בעת גישור חזרה לשרשרת המקור, המשתמש צורב את הייצוג הקנוני או מחליף את האסימון הקנוני עם ייצוג הגשר דרך ה-AMM לפני צריבת הייצוג ומספקת הקבלה על הוכחת השריפה. לאחר האישור, המשתמש יכול למשוך את האסימונים המקוריים שננעלו בהתחלה. (בדיוק כמו הפעולה הקודמת, הפרטים המלוכלכים של העברת אסימונים חזרה לשרשרת המקורית מוסתרים מהמשתמש ומנוהלים על ידי פותרים). גישור נזילות מצוין, בעיקר בגלל שהוא פותר את בעיית ההשהיה בגישור רול-אפ; לדוגמה, Hop מאפשרת לגורמים מיוחדים הידועים בשם "Bonders" להעיד על תקפות עסקת המשיכה של משתמש ב-L2 ולקדם את עלות המשיכה מגשר L1 של האוסף. כל בונדר מפעיל צומת מלא עבור שרשרת L2 ויכול לקבוע אם עסקת היציאה של משתמש תאושר בסופו של דבר ב-L1, מה שמקטין את הסיכון שמשתמש יוזם משיכה במרמה ויגרום להפסדים עבור הבונדר. גשרי נזילות גם מאפשרים למשתמשים לעבור בין רשתות נוספות, בניגוד לגשרים קנוניים; לדוגמה, Hop מאפשרת למשתמשים לגשר בין ארביטראם לאופטימיות מבלי צורך לסגת תחילה ל-Ethereum. בדיוק כמו גישור מהיר L2 → L1, גישור מהיר L2 → L2 מחייב את Bonders להפעיל צומת מלא עבור שרשרת המקור L2 כדי לאשר משיכות לפני החזית של עלות הטבעת האסימונים עבור משתמש בשרשרת היעד L2. זה מאפשר יותר קומפוזיציה בין אוסף אוסף ומשפר באופן דרסטי את חווית המשתמש, מכיוון שמשתמשים יכולים להעביר אסימונים על פני אוסף ללא בעיות. אבל לגישור נזילות יש גם חסרונות שמשפיעים על התועלת של שימוש בגשר המעוגן של שרשרת כדי להטביע את הייצוג הקנוני של אסימון בשרשרת L2/L1. אנו דנים בחסרונות של גישור מבוסס נזילות בסעיף הבא: חסרונות של גשרי נזילות 1. החלקה החלקה היא הבדל בכמות האסימונים הצפויה והמתקבלת בעת אינטראקציה עם AMM. החלקה מתרחשת עקב תמחור של AMMs על פי הנזילות הנוכחית במאגר - התמחור הוא כזה שנשמר שיווי משקל בין יתרת המאגר של כל נכס בזוג לאחר השלמת ההחלפה, שיכול להשתנות בין הזמן שבו משתמש יוזם מסחר וההחלפה מבוצעת. נזילות נמוכה לנכסים מגושרים יכולה גם להגביר את ההחלקה; אם למאגר אין מספיק נזילות כדי לאזן מחדש צד אחד של המאגר, סחר גדול עשוי להזיז את המחיר בפער גדול ולגרום למשתמשים לבצע החלפות במחירים גבוהים יותר. ארביטראגים צפויים לעזור לתקן פערים בין מאגרים הסוחרים באותו נכס, אך עשויים להיות מונעים מעסקאות ארביטראז' הכוללות אסימונים עם פעילות/ערך מסחר נמוך. הדבר משפיע גם על מפתחים שבונים יישומים צולבים שרשרת, שכן הם חייבים לקחת בחשבון מקרי קצה שבהם מתרחשת החלקה. המשתמש אינו יכול להשלים פעולה חוצת שרשרת עקב קבלת כמויות נמוכות יותר של אסימון בשרשרת יעד אחת או יותר. יישומים כמו אגרגטורים של גשרים (שאינם יכולים לדעת אם לגשר נזילות תהיה מספיק נזילות כדי לכסות החלפה בשרשרת היעד ללא החלקה) עוקפות את הבעיה על ידי ציון סובלנות החלקה מקסימלית ושימוש בה כדי לספק הצעות מחיר שסופקו למשתמשים. למרות שזה מונע החזרות של עסקאות, משתמשים תמיד מאבדים אחוז מסוים מהאסימון המגושר - ללא קשר לנזילות במאגרי ה-AMM של גשר. 2. מגבלות נזילות אתגר מהותי עם גשרי נזילות הוא הדרישה המוחלטת לנזילות מספקת בשרשרת היעד. שלא כמו גשרי נעילה מסורתיים שבהם טביעת אסימונים מגובה ישירות בנכסים נעולים, גשרי נזילות תלויים באסימונים זמינים במאגרי AMM כדי להשלים העברות צולבות שרשרת. כאשר הנזילות יורדת מתחת לסף קריטי, מנגנון הגישור כולו יכול למעשה להפסיק לתפקד. פעולות הגשר עלולות להיפסק לחלוטין אם הנזילות יורדת מדי, ולמנוע מהמשתמשים להשלים את ההעברות המיועדות; משתמשים עשויים להיאלץ לפצל העברות גדולות לעסקאות קטנות יותר כדי למנוע דלדול נזילות המאגר; בתקופות של תנודתיות גבוהה או לחץ בשוק, ספקי נזילות עשויים לסגת ממאגרים, בדיוק כאשר יש צורך ביותר בפונקציונליות הגשר; האתחול של צמדי אסימונים חדשים הופך למאתגר במיוחד, מכיוון שנדרשת נזילות ראשונית משמעותית כדי להפוך את הגשר לתפעולי. דרישת הנזילות יוצרת תלות מעגלית: גשרים זקוקים לנזילות ניכרת כדי לתפקד בצורה מהימנה, אך משיכת ספקי נזילות דורשת הדגמה עקבית של שימוש בגשר ויצירת עמלות. בעיית תרנגולת וביצה זו חריפה במיוחד עבור אסימונים חדשים או שנסחרים בתדירות נמוכה יותר, אשר עשויים להתקשות לשמור על נזילות מספקת על פני מספר רשתות. 3. תמריצים שגויים גשר נזילות מועיל במידה שהוא יכול לכסות החלפות מהייצוג המגושר לאסימון הקנוני בשרשרת היעד מבלי שהמשתמשים יגרמו להחלקה מוגזמת; עלויות הגז של האינטראקציה עם הגשר קובעות גם את ערך גשר הנזילות מנקודת מבטו של המשתמש. לפיכך, מגשרים וצוותי פרויקטים, המנפיקים אסימון, נותנים עדיפות לגשרים בהתבסס על כמות הנזילות ועלויות העסקה. אמנם זה מבטיח למשתמשים שמגשרים על אסימונים של פרויקט או באמצעות אגרגטור גשר כדי לשלוח אסימונים צולבים שרשרת בעלי UX טוב יותר, בחירת גשרים על סמך נזילות מציבה את הגשרים שאינם יכולים להוציא על תמריצים של ספקי נזילות (LP) בעמדת נחיתות. יתרה מכך, בחירת גשרים המבוססים על עמלות עסקה טהורות מטה את התחרות לטובת גשרים הנוקטים בגישה ריכוזית להפחתת עלויות תפעול ויכולים לגבות עמלות נמוכות יותר על עסקאות גישור. בשני המקרים, הגשרים אינם מתחרים על המדד החשוב ביותר, ככל הנראה: אבטחה. גשרים מבוססי נזילות גם פוגעים בנכסים בעלי זנב ארוך עם פעילות מסחר נמוכה יותר (מה שהופך אותם פחות בסבירות למשוך LPs). מנפיקי אסימונים עם זנב ארוך (או אסימונים חדשים עם נפחי גישור נמוכים) יצטרכו להקים מאגרי AMM ולחזק את נזילות האתחול כדי לכסות החלפות של אסימונים מקומיים (מגושרים באמצעות גשר נזילות) כנגד הייצוג הקנוני של האסימון של המנפיק או לעבוד עם לגשר בין מפעילי הגשר כדי להגדיל את התמריצים הפיננסיים עבור LPs לספק נזילות לנכס זה. 4. UX גישור גרוע גשרי נזילות הם שיפור בגשרים קנוניים אך אינם נטולי בעיות UX גם כן. מלבד החלקה מתמשכת בהחלפות צולבות שרשרת, ייתכן שמשתמשים לא יוכלו להשלים עסקת גישור מיידית בשרשרת היעד מכיוון שלגשר אין מספיק נזילות מאגר כדי לכסות את המסחר עם האסימון הקנוני בשרשרת היעד. ברידג'ים לא יכולים לדעת כמה נזילות עבור צמד נכסים תהיה קיימת עד שההודעה של משתמש להחלפת אסימונים תגיע לשרשרת היעד, ולכן מקרה הקצה הזה הוא לרוב בלתי נמנע. למשתמשים יש שתי אפשרויות במצב זה (שתיהן לא אופטימליות): . זה לא אופטימלי בגלל העיכוב שנגרם בעסקאות גישור ומכיוון שמשתמש לא יכול לדעת אם הוא יקבל את אותה כמות אסימונים שצוטטה בתחילה, שכן נזילות המאגר יכולה להשתנות באופן שרירותי בפרקי זמן קצרים מאוד. המתן עד שלגשר תהיה מספיק נזילות כדי להשלים את ההחלפה ולמשוך אסימונים קנוניים . זה לא אופטימלי מכיוון שרוב היישומים יעדיפו להשתלב עם הייצוג הקנוני של אסימון מקורי (למשל, opUSDT שהוטבע על ידי גשר האופטימיות) וייתכן שלא יקבלו את הנכס העטוף של המשתמש. קבל את ייצוג האסימון הקנייני של הגשר (למשל, hUSDT עבור Hop Bridge) 2. נענע אסימונים קנוניים דרך גשר צד שלישי קנוני Dapp מרובה שרשרת יכול לעקוף את הנושא של אסימונים מגושרים שאינם ניתנים לשינוי על ידי בחירת גשר כדי להטביע ייצוגים קנוניים של האסימון של ה-Dapp בכל שרשרת שבה ה-Dapp נפרס. בדומה לגשרים קנוניים המטביעים ייצוגים מאושרים של האסימון של הפרויקט, גישה זו מחייבת מיפוי של אסימונים המוטבעים ברשתות מרוחקות לחוזה האסימון שנפרס בשרשרת הביתית של הפרויקט - כדי להבטיח שאספקת האסימון תישאר זהה ברחבי העולם. על ספק הגשר לעקוב אחר ההטבעה והשריפת של אסימון ולוודא שפעולות ההטבעה והצריבה יישארו מסונכרנות עם אספקת האסימון בשרשרת הביתית. בודד שימוש בספק גשר יחיד מציע גמישות רבה יותר עבור צוותי פרויקטים, במיוחד מכיוון שגשרים של צד שלישי מקבלים תמריץ לתמוך בגישור בין מגוון רחב יותר של מערכות אקולוגיות בהשוואה לגשרים קנוניים שמתחברים רק לשרשרת אחת לכל היותר. אם קיים גשר בכל הרשתות שבהן אפליקציה פרוסה, משתמשים יכולים לעבור במהירות בין שרשרת ללא צורך לסגת חזרה לשרשרת הביתית; ספק גשר צריך רק להבטיח שהאסימונים שהוטבעו בשרשרת יעד A נשרפו לפני שמשתמש מטביע אסימונים בשרשרת יעד B ואסימונים קנוניים בשרשרת B ימופו (מחדש) לאסימון בשרשרת הביתית. גם הבעיה של אסימונים מגושרים שאינם ניתנים לשינוי מתבטלת; בתנאי שמשתמשים מגישים דרך ספק הגשרים המאושר, הם תמיד יכולים להחליף אותם 1:1 עם אסימונים מגושרים אחרים. גישה זו מתקנת עוד יותר את הבעיות של גישור מבוסס נזילות במודל הגשר הקנוני: משתמשים אינם סובלים מהחלקה בעסקאות גשר מכיוון שספק הגשר אינו צריך להמיר את הייצוג שלו מול ייצוג קנוני באמצעות AMM - האסימון של ספק הגשר הוא הייצוג הקנוני של האסימון המגושר בכל תחום. הערך של ייצוגים אלה מוצמד לערך האסימונים שננעלו על ידי ספק הגשר בשרשרת המקורית של האסימון. משתמשים סובלים מעיכובים מועטים או לא בגישור מכיוון שספק הגשר יכול להטביע ייצוגים עטופים בשרשרת היעד מיד לאחר הגעת הודעת mint() ליעד. מפתחים יכולים לבצע מיקור חוץ של ניהול פריסות אסימונים מרובות שרשרת כדי לגשר בין מפעילים מבלי לדאוג לגבי תוכניות תמריצים של נזילות AMM או אספקת נזילות. כמה דוגמאות לאסימונים של ספק גשר בודד בטבע כוללות את Omnichain Fungible Token (OFT) של LayerZero, שירות Interchain Token של Axelar (ITS), xAsset של Celer ו-AnyAsset של Multichain. כל הדוגמאות הן בעצם אסימונים קנייניים ואינן תואמות את הייצוגים של אותו אסימון שנשלח דרך ספק גשר אחר. פרט עדין זה מדגיש כמה בעיות בגישה זו לטיפול באסימונים מגושרים. כלומר את הדברים הבאים: נעילת ספק אובדן ריבונות חשיפה גבוהה לכשלים בגשרים אובדן התכונות המותאמות אישית של האסימון בשרשראות היעד מוגבל לרשתות הנתמכות של הספק חוסר יכולת לשמור על אותה כתובת סמלית בכל הרשתות הרצויות, מה שעלול לפגוע באבטחת המשתמש או להפוך אותם לפגיעים להתחזות חסרונות של שימוש בגשרים קנוניים של צד שלישי 1. נעילת ספק בחירה בספק גשר יחיד כדי להטביע ייצוגים קנוניים ברשת אחת או יותר חושפת את המפתחים לסיכון של נעילת ספקים. מכיוון שכל ספק גשר יוצר ייצוג קנייני התואם רק לתשתית שלו (ולפרויקטים משולבים של מערכת אקולוגית), המודל של ספק גשר יחיד נועל למעשה מנפיק אסימון לשירות גישור ספציפי ללא אפשרות לעבור לגשר אחר בעתיד. אפשר להחליף ספקי גשרים, אבל עלויות המעבר גבוהות מספיק כדי למנוע מרוב הפרויקטים ללכת בדרך זו. כדי לתת רעיון גס, נניח שמפתח (שנקרא לו בוב) הנפיק אסימון (BobToken) ב-Ethereum ובוחר ב-LayerZero OFT כדי להטביע גרסאות קנוניות של BobToken על אופטימיות, ארביטר ובסיס. ל-BobToken יש אספקה קבועה של 1,000,000 אסימונים, ואסימונים מגושרים המוטבעים באמצעות LayerZero מהווים 50% מהאספקה הכוללת של BobTokens במחזור. ההסדר העסקי ממשיך בצורה חלקה עד שבוב מחליט שעדיף למשתמשים לגשר על BobTokens באמצעות שירות גשר מתחרה (למשל, Axelar). עם זאת, בוב לא יכול פשוט לקום ולומר, "אני עובר לאקסלאר ITS כדי להטביע ייצוגים קנוניים של BobToken על אופטימיות, בסיס וארביטרום"; מכיוון שאסימוני OFT ואסימוני ITS אינם תואמים, בוב מסתכן ביצירת כאבי ראש הן למשתמשים ותיקים והן למשתמשים חדשים מכיוון ששני BobTokens אינם ניתנים להחלפה (מציג מחדש את הבעיה שתיארנו קודם לכן). יתרה מכך, יישומים המשולבים עם הגרסה של LayerZero של BobToken לא יכולים לקבל את הגרסה של Axelar של BobToken כתחליף - מה שמקטע נזילות עבור BobToken ברשתות שונות שבהן קיימות ייצוגים מתחרים של BobToken. כדי לאפשר את המעבר, בוב צריך לשכנע את המשתמשים לפרוק ייצוגים עטופים של BobToken שהוטבעו דרך LayerZero על ידי שליחת עסקה ששורפת אסימוני OFT מגושרים ופותחת את הנעילה של BobToken ב-Ethereum. משתמשים יכולים כעת לעבור לייצוג הקנוני החדש של BobToken על ידי נעילת אסימונים עם Axelar ב-Ethereum וקבלת BobTokens קנוניים (הממופים לאספקת חוזה האסימון ב-Ethereum) בשרשרת היעד. זה גם עתיר עלות וגם כרוך בתיאום ותקורה תפעולית מסיבית עבור צוותי ניהול פרויקטים של DAO, כך שהיצמדות לספק הנבחר היא בדרך כלל האפשרות הבטוחה ביותר. עם זאת, זה משאיר מפתחים כמו בוב במצב בעייתי שכן נעילת ספקים לא מאפשרת להחליף אם ספק גשר לא מצליח לקיים את תנאי ההסכם, יש לו חבילת תכונות מוגבלת, חסר אינטגרציות מרחיבות של מערכות אקולוגיות, מציע UX גרוע וכו' זה גם מספק לגשרים עם מינוף כמעט אינסופי: ספק הגשר יכול לעשות דברים שרירותיים כמו מגבלת תעריף של משתמשים לגשר על BobTokens ללא סיבות ברורות, להעלות. דמי גישור, או אפילו לצנזר פעולות גישור. ידיו של בוב קשורות במקרה הזה, שכן ביצוע הפסקה נקייה מגשר צד שלישי קנוני פגום מורכב כמו להישאר בקשר העסקי. 2. אובדן ריבונות לפרוטוקולים החלק המסכם של הסעיף הקודם על נעילת ספקים מדגיש בעיה נוספת בשימוש בגשר צד שלישי קנוני: מנפיקי אסימונים מחליפים את השליטה באסימונים מגושרים קנוניים בתמורה לנוחות רבה יותר ושיפורי UX. כדי להשתמש בדוגמה הקודמת: BobToken ב-Ethereum נמצא לחלוטין בשליטתו של בוב מכיוון שהוא שולט בחוזה האסימון הבסיסי של ERC-20, אבל BobToken על אופטימיות, ארביטר ובסיס נשלטים על ידי LayerZero, שבבעלותה חוזה OFT שמנפיק ייצוגים קנוניים של BobToken על הבלוקצ'יין האלה. בעוד שבוב עשוי לצפות מ-LayerZero ליישר ייצוגים קנוניים עם העיצוב המקורי של האסימון המקורי, ייתכן שזה לא תמיד המקרה. בתרחישים הגרועים ביותר, ההתנהגות של BobToken ב-Ethereum עשויה לסטות משמעותית מזו של BobToken באופטימיות מכיוון שספק הגשר מיישם גרסה שונה בתכלית של חוזה האסימון - מה שיוצר בעיות עבור משתמשי הפרוטוקול. בעיה זו עשויה להחמיר גם על ידי דינמיקה של סוכן עיקרי, כאשר המטרות והאינטרסים של פרוטוקול ושל ספק הגשר מתפצלים. 3. חשיפה גבוהה לכשלים בגשרים בגישה הראשונה, שבה אסימונים מגושרים בשרשרת דרך הגשר הקנוני של כל שרשרת, הסיכון למנפיק האסימון מניצול המשפיע על גשר אחד מוכל לגשר זה. לדוגמה, נניח שהאקר מצליח להתפשר על גשר נזילות אחד ולהטביע כמויות אינסופיות של אסימון עטוף מבלי להפקיד בטחונות. במקרה זה, הוא יכול למשוך רק עד לכמות הנזילות המקסימלית הזמינה עבור הנכס העטוף במאגרי נזילות (לדוגמה, הטבעת CUSDT על אופטימיות → החלפת CUSDT עבור opUSDT קנונית → משיכת opUSDT ל-Ethereum דרך גשר מהיר → החלפה ב-USDT מקורי על Ethereum) . במודל הגשר הקנוני של צד שלישי, הסיכון למנפיק אסימונים מניצול המשפיע על הגשר השותף שווה ערך לכמות האסימונים הכוללת שתוקף מטביע ברשתות מרוחקות שבהן יש לפריסה לגשר המושפע. זה אפשרי מכיוון שכל ייצוג קנוני בכל הרשתות ניתן להחלפה 1:1 באסימונים קנוניים שהונפקו ברשתות אחרות: נניח שתוקף מתפשר על גשר של צד שלישי בשרשרת B ומטביע 1000 אסימונים (כאשר האסימון מונפק תחילה בשרשרת A) מבלי להפקיד בטחונות. האסימונים של התוקף בשרשרת B אינם ממופים לחוזה השרשרת הביתית, כך שהוא אינו יכול לסגת משרשרת A. ובכל זאת, הוא יכול לגשר לשרשרת C ולהחליף 1000 אסימוני שרשרת B ב-1000 אסימוני שרשרת C - זכור, כל שרשרת צולבת האסימון תואם וניתן לשינוי מכיוון שהם מקורם מאותו שירות גשר. אסימוני שרשרת C ממופים לחוזה שרשרת הבית שכן הם הוטבעו באופן לגיטימי על ידי משתמשים שננעלו אסימונים בשרשרת A (השרשרת הביתית של האסימון), מה שמאפשר לתוקף לשרוף אסימונים בשרשרת C ולמשוך אסימונים מקומיים בשרשרת A ואפשר להשלים. את מסלול הטיול על ידי החלפת האסימונים באמצעות CEX או פיאט הרמפה. 4. אובדן תכונות אסימון מותאמות אישית בעת שימוש בגשר קנוני של צד שלישי, מנפיקי אסימון מאבדים לעתים קרובות את היכולת ליישם תכונות מותאמות אישית או התנהגויות אסימון הקיימות בפריסה המקורית שלהם. זה קורה מכיוון שספקי גשרים נוטים להשתמש בחוזי יישום סטנדרטיים של ERC-20 שעשויים לא לתמוך בפונקציונליות מיוחדת הקיימת ביישום האסימון המקורי. תכונות אסימונים נפוצות כמו האצלת הצבעה (ZK), מנגנוני בסיס מחדש (stETH, USDM), יכולות עמלה על העברה (ממקוינים), פונקציות של רשימה שחורה ורשימה הלבנה (USDT, USDC), העברות הניתנות להשהיה וכללי טביעה מיוחדים או הרשאות מיוחדות. משם כאשר אסימונים מגושרים דרך ספק צד שלישי, שכן הגרסה המגושרת תשתמש בדרך כלל ביישום ERC-20 בסיסי. אובדן פונקציונליות זה יוצר חוסר עקביות באופן שבו האסימון פועל על פני רשתות שונות ועלול לשבור אינטגרציות התלויות בתכונות מותאמות אישית אלו. הסטנדרטיזציה של אסימונים מגושרים, על אף שהיא פשוטה יותר מנקודת המבט של ספק הגשר, מפחיתה למעשה את יכולות האסימון ויכולה לפגוע ביכולתו של המנפיק לשמור על התנהגות אסימונים עקבית על פני כל המערכת האקולוגית הרב-שרשרת של היישום שלהם. בעיות כאלה יכולות להפוך הרחבות חוצות שרשרת לסיוט עבור מפתחים ולהוות מכשול להגשמת החלום של אפליקציות שחיות על מספר רשתות. 5. רשתות נתמכות מוגבלות מנפיקי אסימונים הופכים להיות תלויים בכיסוי הרשת ובתוכניות ההרחבה של ספק הגשרים שבחרו. אם ספק הגשר אינו תומך ברשת בלוקצ'יין מסוימת שמנפיק האסימון רוצה להתרחב אליה, הם עומדים בפני שתי אפשרויות לא אופטימליות: המתן שספק הגשר יוסיף תמיכה לשרשרת הרצויה, דבר שעשוי להימשך זמן רב או לעולם לא יקרה עקב עלויות גבוהות של אינטגרציה (לדוגמה, שוויון ה-EVM של ZKsync Era שהוביל את ה-Dapps רבים לעולם לא לפרוס עליו) השתמש בספק גשר אחר עבור השרשרת הספציפית הזו, מה שמציג מחדש את הבעיה של אסימונים בלתי ניתנים לשינוי ופיצול נזילות מגבלה זו יכולה להשפיע באופן משמעותי על אסטרטגיית הצמיחה של פרוטוקול ועל היכולת להגיע למשתמשים חדשים ברשתות מתפתחות. ספקי גשרים עשויים לתעדף תמיכה ברשתות פופולריות תוך הזנחה של רשתות קטנות יותר או חדשות יותר שיכולות להיות חשובות מבחינה אסטרטגית עבור מנפיק האסימון. 6. כתובות אסימון חוצות שרשרת לא עקביות ספקי גשרים של צד שלישי עשויים לפרוס אסימונים מגושרים עם כתובות שונות בכל שרשרת בשל המוזרויות של מחסנית הטכנולוגיה שלהם - לדוגמה, אין תמיכה ב- . חוסר עקביות בכתובות, בתורו, יוצר בעיות UX רבות: CREATE2 : על המשתמשים לאמת כתובות אסימונים שונות בכל שרשרת, מה שמגביר את הסיכון לאינטראקציה עם אסימונים הונאה; סיכוני אבטחה : מפתחים חייבים לנהל רשימות של כתובות אסימון חוקיות עבור כל רשת; מורכבות האינטגרציה : שחקנים גרועים יכולים להערים בקלות רבה יותר על משתמשים באמצעות אסימונים מזויפים מכיוון שאין כתובת עקבית שאפשר לבדוק מולם. סיכון מוגבר לדיוג חסרונות אלו, בשילוב עם הסוגיות שנדונו בעבר של נעילת ספקים, אובדן ריבונות וחשיפה גבוהה לכשלים בגשרים, מדגישים את המגבלות המשמעותיות של הסתמכות על גשרים קנוניים של צד שלישי לפריסת אסימונים חוצי שרשרת. הבנה זו עוזרת להציב את הקרקע מדוע נחוצים פתרונות חלופיים כמו ERC-7281 כדי להתמודד עם אתגרים אלו בצורה מקיפה יותר. 3. אסימוני מנטה קנוניים דרך גשר מנפיק אסימון אם מפתח רוצה לשמור על שליטה מקסימלית בפריסות חוצות שרשרת של אסימון של פרויקט, הוא יכול לנהל את הנפקת ייצוגים קנוניים של האסימון ברשתות מרוחקות. זה מתואר כ"סמוך על מנפיק האסימון", שכן הערך של כל ייצוג מגושר של האסימון קשור לאסימונים הנעולים בשרשרת הביתית של האסימון על ידי הפרוטוקול האחראי להנפקת הגרסה המקורית של האסימון בשרשרת המקור. כדי שגישה זו תעבוד, מנפיק האסימון חייב להקים תשתית לניהול ההטבעה והצריבה של אסימונים מגושרים בין שרשרת (תוך הבטחה שהאספקה העולמית תישאר מסונכרנת באמצעות מיפוי קנוני). דוגמאות בולטות לייצוגים קנוניים של אסימון שהונפק על ידי יוצר האסימון הן ו-Circle's של MakerDAO. Teleport Cross-Chain Transfer Protocol (CCTP) טלפורט מאפשרת למשתמשים להעביר DAI קנוני בין Ethereum לאוסף Ethereum שונים באמצעות פעולות נתיב מהיר ואיטי. DAI נשרף על שרשרת אחת ומוטבע על שרשרת המטרה. CCTP מתפקד באופן דומה ומאפשר העברות צולבות של שרשרת של USDC מקורי (הונפק על ידי Circle) באמצעות מנגנון צריבה ונענע. בשני המקרים, מנפיק האסימון שולט בהטבעה ובשריפה של ייצוגים קנוניים של אסימון. גישה זו מציעה שליטה מלאה באסימונים מגושרים לפרוטוקולים. והוא פותר את הבעיה של ייצוגים בלתי ניתנים לניתוק של אותו אסימון בצורה היעילה ביותר האפשרית - קיימת רק גרסה קנונית אחת של האסימון (שנטבעה על ידי המנפיק בשרשרת היעד), מה שמבטיח למשתמשים אותה חוויה באמצעות אסימון בכל מערכת אקולוגית שמנפיק האסימון תומך בו. עם גישה זו, יישומים נהנים גם מביטול פיצול נזילות שנגרם על ידי ייצוגים לא רשמיים ומגושרים של אסימון של פרוטוקול הצף באותה מערכת אקולוגית. מפתחים יכולים גם לבנות יישומים חוצי שרשרת חזקים יותר (למשל, החלפות צולבות שרשרת והלוואות צולבות שרשרת) שכן גשרים קנוניים של מנפיקי אסימונים מאפשרים תנועה יעילה בהון, חלקה ומאובטחת של אסימונים בין רשתות. עם זאת, החיסרון של גשרים קנוניים של מנפיקי אסימונים הוא שמודל זה אפשרי רק עבור פרויקטים עם מספיק הון כדי לכסות את התקורה של פריסת שרשרת צולבת אסימונים ותחזוקת תשתית (אורקלים, שומרים וכו') הנדרשות לביצוע צולב טביעה ושריפה של שרשרת. יש לכך גם את ההשפעה הבלתי רצויה במקצת של צימוד הדוק בין האבטחה של נכסים מגושרים למודל האבטחה של הפרוטוקול. מערכת היחסים הזו (בין גרסאות מגושרות של אסימונים של פרוטוקול לאבטחת הפרוטוקול) היא ידידותית מכיוון שהבטיחות של אסימונים מקוריים המגבים ייצוגים קנוניים כבר תלויה באבטחת הפרוטוקול, כך שמשתמשים ומפתחים חיצוניים לא לוקחים על עצמם הנחות אמון חדשות. זה נכון במיוחד לגבי המופעלים על ידי מנפיקים כמו Circle and Maker (כיום Sky) - משתמשים כבר סומכים על מנפיקי stablecoin שיהיו להם מספיק נכסים כדי לכסות פדיון של stablecoins עבור מטבעות פיאט, כך שלא קשה לתת אמון באבטחה של stablecoin bridge. גשרי stablecoin אבל זה גם מייצג נקודת כשל מרכזית - אם תשתית הגשר של מנפיק האסימונים נפגעת, הערך של כל הייצוגים הקנוניים שמסתובבים במערכת האקולוגית הרב-שרשרת בסכנה. זה גם מרמז שרק אפוטרופוסים מרכזיים (למשל, Circle במקרה של USDC) יכולים ליישם את המודל הזה של הנפקת אסימונים מגושרים קנוניים. מחשבות אחרונות כפי שמוצג בדוח זה, ניתנות נכסים חוצי שרשרת היא חלק חשוב מפעילות הדדית של אוסף עם השלכות על חווית המעבר בין רשתות שונות. היכולת של אסימונים להישאר ניתנים לשינוי כאשר הם מגשרים לרשתות מרוחקות משפיעה גם על חווית המפתחים מכיוון שמקרי שימוש מסוימים תלויים בתכונה זו. הוצעו פתרונות שונים כדי לפתור את הבעיה של אסימונים צולבים שרשרת בלתי ניתנים לניתוק - שרבים מהם כיסינו בדוח זה. זה כולל טביעת אסימונים קנוניים באמצעות גשרים מקוריים (מעוגנים), שימוש בגשר ייעודי של צד שלישי להטבעת אסימונים קנוניים על פני רשתות מרובות, ושימוש בגשר בבעלות פרוטוקול כדי להקל על תנועת אסימונים ולשמור על יציבות. בעוד שגישות אלו פותרות בעיות ספציפיות, הן אינן מצליחות לטפל בכל הבעיות והשימוש בהן כדי לאפשר ניתוק נכסים חוצי שרשרת דורש כמה פשרות לא רצויות. האם נוכל למצוא גישה טובה יותר? התשובה היא כן. ERC-7281 היא גישה חדשה לשינויי נכסים חוצי שרשרת המפחיתה פשרות הקשורות לגישות קיימות. הידוע גם בשם , ERC-7281 מאפשר לפרוטוקולים לפרוס ביעילות אסימונים קנוניים על מספר רשתות מבלי להחליף אבטחה, ריבונות או חווית משתמש. xERC-20 העיצוב הייחודי של ERC-7281 מאפשר לגשרים מרובים (ברשימת הלבנה) להטביע גרסאות קנוניות של אסימונים של פרוטוקול בכל שרשרת נתמכת תוך שהוא מאפשר למפתחי פרוטוקולים להתאים באופן דינמי את מגבלות ההטבעה על בסיס גשר. תכונה זו פותרת רבות מהבעיות הקשורות להצעות היסטוריות לאסימונים קנוניים מרובי שרשרת - כולל פיצול נזילות, יישור תמריצים, חששות UX, סיכוני אבטחה לגשר, התאמה אישית (של אסימונים חוצי שרשרת) ועוד. החלק הבא - והאחרון - בדוח שני החלקים שלנו על ניתוק נכסים חוצי שרשרת יכסה בפירוט את ERC-7281 ויבדוק כיצד תקן האסימון xERC-20 יכול להועיל למפתחים ולמשתמשים. נשווה את ERC-7281 לעיצובים אחרים עבור אסימונים קנוניים מרובי שרשרת, נחקור את הגישה של xERC-20 לאסימונים קנוניים מרובי שרשרת, ונדגיש שיקולים לפרוטוקולים ולמפתחים המעוניינים להתבסס על התקן. הישארו מעודכנים! הערת המחבר: גרסה של מאמר זה פורסמה במקור. כאן