נופל: שכבת ה-Ethereum Finality-As-A-A-Service

בדיעבד, רול-אפים הופיעו כפתרון קנה המידה הסופי עבור Ethereum וטכנולוגיה מבוזרת בכללותה. תשעה חודשים לאחר שדרוג ה-Dencun של Ethereum, שמטרתו קנה מידה של זמינות אוסף נתונים, תפוקת העסקאות עלתה על מאתיים עסקאות בשנייה - המייצגת עלייה של פי חמישה מהשנה עד היום. שני האוסף המובילים, Arbitrum ו-OP Mainnet, השיגו ביזור שלב 1 - מעבר למספר רשתות אלטרנטיביות בולטות של שכבה 1 במדדי ביזור - כאשר אוסף נוסף עשוי להתמקד בביזור שלב 2 בשנת 2025. טכנולוגיית הוכחת אפס ידע התקדמה כדי לאפשר אימות של Ethereum -עסקאות שוות בעלות תת-סנט , הקמת מסלול לאימות יעילה של אלפי סטנדרטים עסקאות משתמש בבלוקצ'יין Ethereum העכשווי.

עם זאת, התקדמות זו מציבה אתגרים חדשים. צוותים מרובים מפתחים בלוקצ'יין עצמאיים על גבי Ethereum, עם יכולת פעולה הדדית מוגבלת ביניהם. מגבלה זו נובעת בעיקר מהסיום הבלתי תדיר של רולאפים, מה שמונע תקשורת חוצת שרשרת משמעותית. יתר על כן, אוסף אופטימיים, המארחים כיום את רוב הפעילות של המערכת האקולוגית ו-Total Value Locked (TVL), מתמודדים עם אילוצים טכניים אינהרנטיים המונעים תקשורת ישירה מחוץ לגשרים משותפים, ויוצרים מחסום משמעותי בפני יכולת פעולה הדדית בין רשתות מרכזיות כמו ארביטראם ובסיס.

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

בין הפתרונות הבולטים, שבדרך כלל מסתמכים על אורקלים אופטימיים (Across), קונצנזוס מפעילים מיוחדים (Stargate דרך LayerZero), או אמון רצף מרכזי (Polymer Hub), השכבה המהירה הסופיות של Nuffle Labs (NFFL) מציגה איזון משכנע בין יעילות, אבטחה , ויישור Ethereum. מאמר זה בוחן את הגישה החדשנית של NFFL לאפשר אימות מצב צולב באמצעות מנגנון ה-Restaking של EigenLayer ו-NEAR DA, בוחן את מפת הדרכים של התכנון והפיתוח הארכיטקטוני שלה, ומנתח יישומים פוטנציאליים והשלכותיהם על המערכת האקולוגית.

רענון על רולאפים

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

רולאפ הוא בלוקצ'יין שמשתמש בבלוקצ'יין עצמאי אחר לצורך הזמנת עסקאות, זמינות נתונים והסכמה, תוך ביצוע עסקאות חיצונית באופן שניתן לאמת על ידי הבלוקצ'יין האב. בעוד שהגדרות רבות מתייחסות לשרשרת האב כשכבה 1 (L1) ולאוסף שכבה 2 (L2), מסגרות מסוימות אינן דורשות מ-L2s להשתמש ב-L1 לזמינות נתונים. לשם הבהירות, מאמר זה מתמקד במיוחד ב-rollups ולא בקטגוריית L2 הרחבה יותר.

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

הזמנת עסקאות

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

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

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

(רצף מבוסס מאפשר לכל אחד להיות סיקוונסר, אבל האצווה שלהם משמשות רק את הצמתים כשהם מפורסמים ב-L1. זה כמעט לא פותח סיכון של השבתה ברצף במחיר של הכללת עסקה איטית יותר (תרחיש הטוב ביותר הוא 12 שניות של L1 לכל לַחסוֹם).)

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

זמינות נתונים

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

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

לפני השדרוג של Dencun, אוסף Ethereum פרסם נתוני עסקאות בנתוני הקלט (נתוני שיחות) של רצף שיחות ב-L1. לכן, כל העסקאות חייבות להיות פורסמו לבלוקצ'יין של L1 לנצח. זה עשוי להישמע הגיוני, מכיוון שאנו רוצים שכל הצמתים, כולל אלה העתידיים, יוכלו לשחזר את מצב ה-rollup. עם זאת, זה מאוד לא יעיל, מכיוון שה-Ethereum L1 לא יכול לאחסן נתונים גדולים בפנקס החשבונות שלו, בעוד ש-rollups, הנתיבים המהירים של Ethereum, הם עתירי נתונים מאוד. במקום זאת, אנו יכולים לגרום לחוזה החכם של ה-Rollup לאמת את תקפותן של העסקאות הרצופות, כך שהצמתים עוקבים באופן מיידי אחר המצב בחוזה, במקום לשחזר אותו מכל העסקאות החל מההתחלה.

כתמים

שדרוג Dencun של Ethereum במרץ האחרון הציג " בלובים " - תאים זמניים של נתונים המאוחסנים מחוץ לבלוקצ'יין ונגזמים (נמחקים על ידי המאמתים של הרשת) לאחר ~18 ימים. מכיוון שגשרי אוסף מאפשרים לשחזר את המצב מבלי לבצע מחדש עסקאות, מאפיין זה הפך להיות שימושי מאוד עבור אוסף נתונים, אשר עברו מ- calldata ל-blobs זמן קצר לאחר השדרוג. אם כבר מדברים על מספרים, לפני דנקון, ה-TPS הכולל של ה-TPS היה בסביבות 50. כיום, זה למעלה מ-200, עם מגבלות תיאורטיות של 400-800 TPS, תלוי באוסף .

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

גשר מעוגן (קונצנזוס)

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

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

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

הסדר רולאפ

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

תפקידו של המציע משתנה באופן משמעותי בהתבסס על גישת אימות המצב של האוסף. קיימות שתי מתודולוגיות שונות באופן מהותי, המגדירות שתי קטגוריות של אוסף: אופטימי ואפס ידע (ZK).

רולאפים אופטימיים

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

כדי למנוע עדכוני מדינה לא חוקיים, הגשר מיישם תקופת אתגר (בדרך כלל 7 ימים) שבמהלכה שחקנים מיוחדים המכונים "אתגרים" יכולים לערער על ההצעה על ידי הגשת הוכחת הונאה . הוכחה זו מוכיחה שעסקאות בוצעו בצורה שגויה על ידי ביצוע מחדש של העסקה השנויה במחלוקת ב-L1 והשוואת תוצאות.

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

אוסף של אפס ידע

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

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

הסדר, סופיות ויכולת פעולה הדדית

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

שקול כיצד זה משפיע על השימוש בעולם האמיתי: משתמש שרוצה להשתמש בבטחונות המבוססים על ארביטרום כדי לקחת הלוואה ב-Base חייב תחילה לגשר על הנכסים שלו ולהמתין עד 7 ימים לפני שניתן יהיה להשתמש בהם. סוחר שיבחין בהזדמנות ארביטראז' בין בריכות Uniswap ברזולים שונים יראה את ההזדמנות נעלמת הרבה לפני שיוכל לבצע עליה. אפליקציה למשחקים שרוצה לאפשר לשחקנים לסחור בפריטים בפריסות אוסף שונות תתמודד עם UX בלתי מקובל עם עיכובים כה ארוכים.

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

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

מהם הפתרונות הקיימים לנזילות ולפיצול מדינה?

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

• אבטחה - עד כמה חזקות הערבויות שאימות המדינה נכון
• מהירות - כמה מהר ניתן לאמת מצב על פני רשתות
• עלות - כמה יקר לתחזק את הפתרון ולהשתמש בו

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

האתגר הבסיסי הוא ביסוס "מקור אמת" מאובטח לגבי מדינות אוסף שיכולות:

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

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

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

הבנת שכבת הסופיות המהירה של נופל (NFFL)

שכבת הסופיות המהירה של Nuffle (NFFL) מייצגת גישה חדשנית לאפשר אינטראקציות צולבות מאובטחות על ידי אספקת אימות מצב מהיר בין אוסף רשימות. במקום להכריח מפתחים לבחור בין אבטחה למהירות, NFFL ממנפת את ה-ETH המחודש של EigenLayer כדי ליצור שכבת סופיות מהירה מאובטחת קריפטו-כלכלית שיכולה להעיד על מצבי אוסף בתוך שניות.

בבסיסו, NFFL פועל כשירות אימות פעיל (AVS) הפועל על EigenLayer. רשת מבוזרת של מפעילים, שכל אחד מהם מפעיל צמתים מלאים עבור אוסף משתתפים, מאמת ומעיד על עדכוני מדינה. עדויות אלה מגובות על ידי ה-ETH המחודש של המפעילים, ויוצרים תמריצים כלכליים חזקים להתנהגות כנה. על ידי שילוב זה עם שכבת זמינות הנתונים של NEAR לאחסון נתוני בלוק יעיל, NFFL מאפשר ליישומים לאמת בצורה מאובטחת מצב צולב שרשרת תוך 2-3 שניות - בסדרי גודל מהר יותר מהתיישבות גשר קנונית.

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

המערכת מציגה שלושה חידושים מרכזיים:

1. רשת מפעילים מבוזרת המשיגה קונצנזוס לגבי מצבי אוסף על ידי השוואת מעברי מצב המבוצעים מקומית מול נתוני חסימה שפורסמו ל-NEAR DA
2. מערכת משימות מבוססת נקודות ביקורת המאפשרת צבירה ואימות יעילים של אישורי מפעיל תוך שמירה על אחריות באמצעות מנגנוני החיתוך של EigenLayer
3. מנגנון אחסון נתונים באמצעות NEAR DA המאפשר שליפה קלה של נתוני אוסף מאושרים בכל האוסף

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

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

סקירה כללית של רכיבי הליבה של NFFL

סט מפעיל

בליבה של NFFL נמצאת רשת המפעילים שלה - מערכת מבוזרת שמרחיבה את האבטחה של Ethereum כדי לאפשר אימות צולב מהיר. במקום ליצור עוד רשת סמויה הדורשת הנחות אבטחה משלה, NFFL בנויה כשירות אימות פעיל (AVS) ב-EigenLayer, מה שמאפשר לה להתחבר ישירות לאקו-סיסטם האימות הקיים של Ethereum.

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

כאשר אוסף מפרסם נתוני בלוק חדשים ל-L1, ממסרים מעבירים אותם ל-NEAR DA. המפעילים מאחזרים את נתוני הבלוק דרך שני המקורות ומוודאים שהם שווים. נסביר עוד מדוע פרסום נתוני אוסף ב-NEAR DA הכרחי כדי להפוך יישומים המשתמשים ב-NFFL לנוחים יותר עבור משתמשים ומפתחים.

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

לביטחון הכלכלי של מערכת כזו יש תכונה מאוד מעניינת שנובעת ממכניקת החיתוך של EigenLayer:

ב-EigenLayer, Actively Validated Services יכולים ליישם מנגנון אימות המסוגל לזהות אישורים לא חוקיים של מפעילים, ולחתוך (לחסל) את הפקדתם לאחר מכן. מכיוון ש-NFFL קצת "מסדרת פשרה" במצב מחוץ לשרשרת לפני שהתיישבו בגשר, ניתן לזהות הונאה באופן אובייקטיבי על ידי המתנה לעיכוב בפשרה והודעה לחוזה AVS על חוסר עקביות בתפוקה באישור ובגשר.

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

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

זרימת הודעות

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

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

• עדכון שורש מצב הודעות מכילות אישור של מפעיל לגבי מצב אוסף בגובה בלוק מסוים. כל הודעה כוללת לא רק את שורש המצב עצמו אלא גם הפניה לעסקת NEAR DA המכילה את נתוני הבלוק, ויוצרת קישור שניתן לאימות בין המצב המאושר לבין הנתונים הבסיסיים שלו.

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

  
  

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

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

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

שירות אגרגטור

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

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

תהליך צבירת החתימות פועל באופן הבא:

• מפעילים חותמים באופן עצמאי על הודעות המעידות על עדכוני מדינה

• חתימות אלו נשלחות לצובר לאיסוף

• האגרגטור מאמת את תקפות החתימה ועוקב אחר המניין

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

• יישומים יכולים להביא את האישורים האלה דרך ה-API של הצבר

  
  

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

צבירת חתימות

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

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

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

אגרגטור ומחסומים

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

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

חוזי רישום

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

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

כאשר אפליקציה צריכה לאמת מצב של אוסף אחר - למשל, פרוטוקול הלוואות בודק בטחונות ב-Arbitrum מ-Optimism - היא מגישה את האישור הרלוונטי לחוזה הרישום המקומי שלה. אישור זה כולל את חתימת ה-BLS המצטברת שדיברנו עליה קודם, יחד עם שורש המצב הספציפי עליו הוכח וההפניה לעסקת NEAR DA הקשורה אליו.

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

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

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

סיווג תקלות ותכנון אבטחה ב-NFFL

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

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

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

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

תהליך האתגר משתנה בהתאם לסוג התקלה וההודעה המאתגרת:

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

ניתן לערער על הודעות בודדות לאחר תקופת המחסום שלהן על ידי הוכחת תוכן ההודעה לא חוקי. לְדוּגמָה:

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

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

יישומים מהעולם האמיתי של NFFL

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

שלום פרוטוקול

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

שקול משתמש שרוצה לשלוח הודעה ברשת מס' 1 שתיקרא ברשת מס' 2. התהליך מתחיל כשהם שולחים עסקה ברשת מס' 1 תוך הקלטה של ה"שלום!" הודעה במצב הרשת. בשלב זה, ההודעה קיימת רק ברשת מס' 1 ובדרך כלל תדרוש המתנה להסדר הגשר הקנוני (אפשרי שעות או ימים) לפני שניתן יהיה לאמת אותה על ידי אוסף אחר.

זה המקום שבו NFFL נכנס לתמונה. כאשר הבלוק המכיל את ההודעה הזו מופק, הוא נשלח ל-NEAR DA על ידי הממסר של הרשת. מפעילי NFFL, שמריצים צמתים מלאים עבור שתי הרשתות, מוודאים שנתוני בלוק זה תואמים למה שצומת הרשת #1 שלהם חישב באופן מקומי. לאחר האימות, הם חותמים על הודעות המעידות על שורש המדינה החדש.

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

עכשיו מגיע החלק המעניין - צריכת ההודעה ברשת מס' 2. החוזה של פרוטוקול Hello ברשת #2 יכול לקבל עסקה המכילה:

• הוכחת האחסון המציגה את ההודעה קיימת במצב של רשת מס' 1
• אישור ה-NFFL המוכיח את המצב הזה תקף
• הפניה לעסקת NEAR DA המכילה את נתוני הבלוק

הפרוטוקול מנתב את הנתונים הללו לחוזה הרישום של Network #2, המאמת את חתימת האישור מול הרשומה של מפעילי NFFL. אם זה חוקי, זה מוכיח שההודעה קיימת במצב המאומת של רשת מס' 1, מה שמאפשר לפרוטוקול לעבד אותה בבטחה.

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

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

גישור אסימונים מהיר וזול

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

הגשרים המובילים של ימינו ממחישים את הפערים הללו בבירור. Stargate, המופעלת על ידי LayerZero, משיגה עלויות נמוכות יחסית, אך לוקחת 10-30 דקות להשלמת העברות בגלל שרשת המפעילים שלה צריכה להשיג ולמסור קונצנזוס על פני מספר רשתות. Across מספק העברות כמעט מיידיות אך בעלויות גבוהות פי 10-100, בעיקר בשל תפוקות UMA אורקל יקרות ומחזורי איזון מחדש איטיים (במשך 6 שעות) המשפיעים על יעילות הנזילות.

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

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

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

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

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

פרוטוקול הלוואות מרובות שרשרת

הלוואות צולבות שרשרת מייצגות אולי את היישום המיידי המשכנע ביותר של NFFL. פרוטוקולי ההלוואות הנוכחיים עומדים בפני מגבלות משמעותיות עקב פיצול השרשרת. קח את Aave - למרות פריסה על פני מספר אוסף, כל פריסה פועלת בבידוד (מה שיוצר מספר בעיות).

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

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

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

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

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

DEX חוצה שרשרת: פרוס פעם אחת, השתמש בכל מקום

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

קחו בחשבון את הפריסה האחרונה של Uniswap V3 ב-ZKsync - למרות התרגשות וזרימת כספים משמעותיים מהנפילה לאחרונה של ZK, מאגרים רבים נותרו בלתי שמישים במשך ימים לאחר ההשקה בגלל נזילות לא מספקת. בינתיים, פריסות אותו פרוטוקול ב-Arbitrum, Base ורשתות מבוססות אחרות שומרות על נזילות עמוקה, עמלות נמוכות ותמחור יעיל עבור אלפי זוגות.

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

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

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

כך עשוי משתמש ב-Base לקיים איתו אינטראקציה:

1. אליס רוצה להחליף 10,000 USDC עבור ETH on Base

2. ממשק ה-Base של ה-DEX שואל את מצב מאגר ה-Arbitrum באמצעות אישורי NFFL

3. אליס רואה שהיא יכולה לקבל תמחור טוב יותר ממה שמציעה הבריכות המפוצלות של בייס

4. היא מאשרת את המסחר בבסיס

5. העסקה מבוצעת ב-Arbitrum, כשהתוצאה תאושר בחזרה ל-Base

   
   

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

פרוטוקול כזה יכול להשתמש בדפוס גישור שחקרנו קודם כדי לנהל בצורה חלקה את זרימת ההחלפה. בזמן המתנה של שניות ספורות, ניתן להרחיק לחלוטין את עובדת הגישור בפועל. זה מקרב אותנו בצורה מרגשת לתזה של "הפשטת השרשרת" שהפכה לאחרונה לפופולרית למדי בקהילת הקריפטו: אם זה לא משנה ל-dapp באיזו שרשרת אתה נמצא, למה שיהיה לך אכפת באיזו שרשרת אתה וכל האפליקציות האלה פועלים? משתמש יכול פשוט להמשיך לאתר האפליקציה, לחבר את הארנק שלו ולבצע פעולה רצויה. נַעֲשָׂה.

אבל NFFL מאפשר דפוס חזק עוד יותר - עטיפת פרוטוקולי DeFi הקיימים לגישה חוצת שרשרת. במקום לבנות מאגרי נזילות מתחרים, מפתחים יכולים ליצור פרוטוקולים "עוזרים" שהופכים את מאגרי ה-Uniswap האדירים של ארביטרום לנגישים מכל אוסף.

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

1. שאילת נזילות זמינה בכל מאגר ה-Arbitrum Uniswap באמצעות אישורי NFFL
2. מצא נזילות עמוקה לזוג הרצוי שלו במאגר ארביטרום מבוסס
3. בצע את המסחר מ-Base באמצעות פרוטוקול העטיפה
4. קבל את האסימונים שלו בבסיס ברגע ש-NFFL מעיד על השלמת ההחלפה

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

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

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

• עלויות גז עבור הפעולות הספציפיות שלהם
• מחסנית טכנולוגית - מכונה וירטואלית, AA, סוג רצף, DA וכו'.
• שיקולים רגולטוריים

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

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

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

מפת דרכים ופיתוח עתידי

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

אבטחת פרוטוקול

• הטמעת מנגנוני אתגר וקיצוץ מקיפים באמצעות EigenLayer
• הפעלת השתתפות מפעיל ללא הרשאה עם ניהול הימור חזק
• שיפור אימות מצב צולב שרשרת עם פרימיטיבים קריפטוגרפיים משופרים (BLS→ECDSA)

מדרגיות רשת

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

ניסיון במפתחים

• בניית SDK וכלי עבודה לאינטגרציה קלה
• הרחבת התמיכה עבור סוגי אוסף ו-VMs שונים
• יצירת תיעוד ודוגמאות למקרי שימוש נפוצים

בסעיפים הבאים, נסקור כמה מהשיפורים המתוכננים המשמעותיים ביותר בפירוט.

BLS ל-ECDSA

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

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

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

ערכות אופרטורים דינמיות

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

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

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

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

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

הורדת גלגלי האימון

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

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

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

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

  
  

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

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

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

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

העתיד של סופיות מהירה ב-Ethereum

בעוד ש-NFFL מספקת פתרון מיידי לאימות מצב צולב, כדאי לבחון כיצד הפרוטוקול משתלב במפת הדרכים הרחבה יותר של Ethereum. שאלת המפתח שרבים שואלים היא: "האם NFFL עדיין יהיה רלוונטי עם התקדמות טכנולוגיית ה-Rollup?"

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

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

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

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

מַסְקָנָה

NFFL מייצגת גישה חדשה לפתרון אחד האתגרים הדחופים ביותר במערכת האקולוגית המודולרית של Ethereum - המאפשרת אימות מצב צולב מאובטח ויעיל. על ידי מינוף ה-ETH המחודש של EigenLayer לאבטחה כלכלית ו-NEAR DA לאחסון נתונים יעיל, NFFL יוצר שכבת סופיות מהירה שיכולה לאמת מצבי אוסף בתוך שניות ולא שעות או ימים.

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

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

מפת הדרכים של הפרוטוקול מדגימה מחויבות לשיפור מתמיד. שדרוגים מתוכננים כמו המעבר לחתימות ECDSA והטמעה של מערכי מפעילים דינמיים ישפרו את הביזור והמדרגיות. הפעלת מנגנוני אתגר וקיצוץ מקיפים תחזק את ערבויות הביטחון. ואינטגרציה עם פתרונות DA נוספים מעבר ל-NEAR תהפוך את NFFL לאוניברסלי אפילו יותר.

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