אינטגרציה של Avail: היכן נשברת זמינות הנתונים ב-rollup
הבעיה עם זמינות הנתונים ב-rollup מתגלה לא ברגע פרסום הבלוק, אלא מאוחר יותר — כאשר המשתמש יוזם משיכת כספים ואינו יכול להוכיח את תקינות המצב.
ה-sequencer מספק את שורש המצב ואת ההוכחה, אך נתוני העסקאות עצמם נמצאים מחוץ לרשת: אם אין מהיכן להשיג אותם, אימות הנתונים של L2 הופך לבלתי אפשרי, והמשיכה נתקעת בתור לפרק זמן בלתי מוגבל.
האינטגרציה של Avail סוגרת בדיוק את הפער הזה — שכבת ה-DA שומרת את נתוני הבלוקים כך שניתן לבקש ולאמת אותם באופן עצמאי.
המכניקה של הכשל נראית צפויה. ה-rollup מפרסם חבילת עסקאות, מבצע commit לשורש ברשת הראשית, אך גוף הבלוק נשאר אצל מפעיל אחד או באחסון שאינו נגיש.
כל עוד הכול פועל כשורה, איש אינו שם לב לכך; ברגע שהמפעיל יוצא למצב לא מקוון, משנה את מדיניות האחסון או פשוט מפסיק לספק את הנתונים, המשתמשים מאבדים את היכולת לאסוף הוכחה. מכאן והלאה — גידול במספר המחלוקות, בירורים ידניים ונזק תדמיתי שקשה יותר לתקן מאשר את הכשל עצמו.
המחיר של ארכיטקטורה כזו נמדד לא בזמני השבתה, אלא באמון: משיכת כספים שאמורה לארוך שעות נמתחת לימים, וחלק מהעסקאות דורשות התערבות של הצוות. זמינות הנתונים של rollup מפסיקה להיות תכונה מופשטת והופכת לסיכון ממשי עבור כל מי שמחזיק כספים במערכת.
מפרקים כיצד זה נסגר באמצעות האינטגרציה של Avail — מפרסום הנתונים בשכבת ה-DA ועד לאימות עצמאי בצד המשתמש.
מה נותן שכבת DA: מצבי פרסום ומגבלותיהם
היכן בדיוק מתפרסמים נתוני ה-rollup
כל בלוק rollup יוצר שני זרמי נתונים שונים: שינויי מצב דחוסים, שאותם מאמת הגשר, וטרנזקציות "גולמיות", שמהן כל משתתף יכול להרכיב מחדש את המצב מאפס. כל עוד הנתונים הגולמיים נמצאים רק על צמתי המפעיל, ה-rollup נשאר מהימן: אם המפעיל נעלם או איבד את ההיסטוריה, אין במה לשחזר את השרשרת.
זמינות נתונים חיצונית מסירה את התלות הזו — ההיסטוריה מובטחת כזמינה לצד שלישי, וזמן השחזור של ה-rollup מפסיק להיות תלוי בתשתית של מפעיל אחד.
מצבי פרסום ומה הם נותנים
אחסון מקומי. המפעיל מחזיק את ההיסטוריה אצלו: מהיר וללא תלויות חיצוניות, אך מחלקת הכשל "המפעיל אינו זמין" אינה סגורה. מתאים לרשתות בדיקה ולמעגלים סגורים, שבהם חוג המאמתים ידוע והאמון כבר קיים.
שכבת DA חיצונית. הנתונים מתפרסמים ברשת זמינות נפרדת, ששומרת אותם ומאשרת את הזמינות באופן קריפטוגרפי. שחזור צומת מההיסטוריה הופך לאפשרי ללא מעורבות המפעיל, ועלות הזמן שבו המערכת מושבתת יורדת: את השרשרת מרים כל מי שיש לו גישה לשכבת ה-DA. המגבלה — נדרשת אינטגרציה והבנה של מודל האישורים.
מצב היברידי. נתונים קריטיים לגשר עוברים לשכבה חיצונית, ונתונים משניים כבדים נשארים מקומית. זה מפחית את נפח הפרסומים, אך מסבך את הלוגיקה: חלק מהערבויות לזמינות כעת שונות עבור סוגי נתונים שונים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אחסון מקומי | מעגלים סגורים, רשתות בדיקה, חוג מאמתים מהימן | השחזור תלוי במפעיל, מחלקת הכשל "המפעיל אינו זמין" אינה סגורה |
| שכבת DA חיצונית | rollup ציבוריים, שבהם חשובה זמינות עצמאית של ההיסטוריה | נדרשת אינטגרציה, כללים משל עצמה לאישור זמינות |
| היברידי | נפחים גדולים של נתונים משניים בדרישות מחמירות לגשר | ערבויות שונות לזרמים שונים, תחזוקה מורכבת יותר |
האינטגרציה של Avail בהשוואה הזו היא דוגמה לשכבה חיצונית, שבה הזמינות מאושרת ברמת הרשת עצמה, ולא בהבטחה של המפעיל. Avail
מה זה משנה בפועל
לאחר העברת הפרסומים לשכבה חיצונית, שחזור צומת מההיסטוריה מפסיק להיות פעולה של "להתקשר למפעיל ולבקש גיבוי" — הוא הופך להיות משוחזר מנתונים הזמינים לכל משתתף. זה מקצר את זמן השחזור של ה-rollup ומסיר מחלקת כשל שלמה הקשורה לנקודת אחסון יחידה.
שלבי יישום שכבת DA: מביקורת ועד מסירה
אינטגרציה של Avail אינה מסתכמת בחיבור ספרייה: שכבת DA משנה את האופן שבו ה-rollup מפרסם נתונים ואת האופן שבו ה-sequencer מוכיח את זמינותם. לכן העבודה מתנהלת לפי סדר הנדסי — מביקורת הסכימה הנוכחית ועד מסירת הפתרון עם תיעוד. להלן השלבים שאנו עוברים בכל פרויקט.
- ביקורת פרסום הנתונים. מנתחים מה בדיוק ה-rollup כותב כעת לשכבה הבסיסית: בלוקים שלמים, רק את הפרש המצבים או חבילות דחוסות. בוחנים את תדירות הפרסום, גודל המטען המועיל והתנהגות ה-sequencer בעת עיכוב אישורים. התוצר — מפת זרימת נתונים ורשימת צווארי בקבוק.
- תכנון הסכימה. קובעים אילו נתונים עוברים לשכבת DA ומה נשאר בשכבה הבסיסית לצורך אימות. מקבעים את פורמט ה-commitments, את סדר הצמדתם לבלוקים ואת הכללים שלפיהם הצומת ישחזר את המצב מנתונים חיצוניים.
- הגדרת האינטגרציה. מרימים את לקוח שכבת ה-DA, מגדירים פרסום וקריאה, ומחברים ל-sequencer ולצומתי האימות. את התצורה שומרים במאגר — הסביבות משוחזרות בפקודה אחת.
- בדיקת כשל. מריצים תרחישים שבהם שכבת ה-DA אינה זמינה או מגיבה בעיכוב: כיצד מתנהג ה-rollup, האם נתונים הולכים לאיבוד, האם נסיגה לאחור אפשרית. בנפרד בודקים שחזור מצב מנתונים שפורסמו על צומת נקי.
- הרצות עומס. בוחנים כיצד גדל זמן הפרסום בעומס שיא והיכן גבול תפוקת המערכת. לפי התוצאות מתאימים את גודל החבילות ואת המרווחים.
- תיעוד. מתארים את סכימת הזרימות, פרמטרי התצורה, סדר הפעולות בעת תקלה ואת הליך הנסיגה לאחור.
- מסירת הפתרון. עוברים עם הצוות שלכם על כל צומת, עונים על שאלות בנוגע לתפעול ומוסרים גישות וחומרים.
נדון במשימה שלכם — נחזור עם הערכה ותוכנית עבודה לפי שלבים.
במה שונה שכבת DA חיצונית מפרסום ברשת הראשית?
פרסום ברשת הראשית משמעותו שכל בייט של נתוני ה-rollup מונח בבלוקים של L1 ונשמר שם לנצח — כל משתתף יכול לשחזר את המצב מההיסטוריה. שכבת DA חיצונית (במקרה שלנו — אינטגרציית Avail) מוציאה את הנתונים לרשת נפרדת, ששומרת אותם לזמן מוגבל ומאשרת זמינות באופן קריפטוגרפי.
ההבדל עקרוני: במקרה הראשון ערבות הזמינות נובעת מהקונצנזוס של הרשת הראשית, ובשני — מהתחייבויות כלכליות של שכבת ה-DA וממנגנון erasure coding.
השאלה המרכזית היא מי אחראי לכך שהנתונים אכן זמינים. ברשת הראשית זו תכונה של הפרוטוקול עצמו: אם בלוק התקבל, הנתונים נמצאים אצל כל הצמתים המלאים.
שכבת DA חיצונית בונה את הערבות אחרת — ועדות חותמות על attestation לכך שהנתונים מפוזרים ל-chunks וניתנים לשחזור, ולקוחות קלים מאמתים דגימה. כל עוד ה-attestation תקף, ה-rollup יכול לקדם את המצב קדימה; אם הנתונים אבדו, הרשת עוצרת את משיכת הכספים, אך אינה מאבדת יתרות שכבר נרשמו.
מכאן הקשר הישיר למשיכת כספים. בסכמה עם פרסום ברשת הראשית, המשיכה ממתינה לפיינליזציה של L1 — זה חלון האתגר, שנמדד בשעות ובימים.
עם שכבת DA חיצונית, המשיכה נשענת על אישור זמינות מהוועדה של ה-DA, ולא על פיינליזציה מלאה של L1: החלון מתקצר לדקות, ועלות הפרסום יורדת בסדר גודל, מפני שהנתונים אינם מתחרים על מרחב הבלוקים של הרשת הראשית.
גם המגבלה הוגנת: אתם יורשים את מודל האמון בשכבת ה-DA. אם הוועדה מפסיקה להנפיק attestation או שהנתונים אובדים לפני תום תקופת השמירה, ה-rollup נעצר — המשיכה מוקפאת עד לשחזור.
בדיוק משום כך בפרודקשן משלבים שכבת DA חיצונית עם «עוגן» תקופתי לרשת הראשית: שורשי מצב קריטיים ו-hashes של batches מפורסמים ב-L1, והנתונים הכבדים חיים בשכבת ה-DA. כך נשמרים גם המהירות וגם היכולת לחזור אחורה.
מקרה בוחן: כיצד rollup הפסיק לאבד נתונים בעומס שיא
רשת rollup בעומס שיא הפסיקה להספיק לפרסם נתונים על המצב ברשת הראשית: התור לשליחה גדל מהר יותר משהספיקו לפרק אותו. משתמשים ראו עסקאות מאושרות, אך משיכת הכספים נתקעה — לא היה ממה להרכיב את ההוכחה, מכיוון שבלוקי הנתונים הנדרשים לא היו זמינים לאיש מלבד המפעיל עצמו.
זוהי נקודת כשל קלאסית: כל עוד הנתונים מועטים, הכול עובד, ובשיא ה-rollup הופך לגשר מהימן עם קישור חד-כיווני.
מה היה לפני השינויים
הנתונים פורסמו ישירות לרשת הראשית — כל בלוק חיכה בתורו לכתיבה. בעת זינוק בפעילות שיעור הבלוקים הבלתי-זמינים הגיע ל-12–15%: הצמתים לא יכלו לקבל את הנתונים בזמן וסימנו את הבלוק כחסר. שחזור של בלוק אחד כזה ארך עד 40 דקות — היה צורך ליזום ידנית פרסום חוזר ולהמתין לאישור.
המשיכות התקועות הצטברו: במהלך שבוע של עומס שיא נצברו עד כמה עשרות פעולות שלא הושלמו, וכל אחת דרשה טיפול ידני.
מה שינו
הוציאו את פרסום הנתונים לשכבה נפרדת של זמינות וחיברו אותה ל-rollup כמקור חיצוני. כעת בלוק הנתונים מפורק תחילה לחלקים ומפוזר ברשת האחסון, ורק לאחר אישור הזמינות נרשם ברשת הראשית. ההוכחה מורכבת מהחלקים הללו — המפעיל כבר אינו צריך להיות המחזיק היחיד של הנתונים. הוגדרה יתירות: אם צומת אחסון אחד אינו מגיב, הבלוק מורכב מהעותקים הנותרים.
| פרמטר | לפני | אחרי |
|---|---|---|
| שיעור הבלוקים הבלתי-זמינים | 12–15% בשיא | פחות מ-0,5% |
| זמן שחזור בלוק | עד 40 דקות | 2–4 דקות |
| משיכות תקועות בשבוע | עשרות | מקרים בודדים |
| התערבויות ידניות | קבועות | אינן נדרשות |
מה נהיה
עומס שיא הפסיק להיות איום: ה-rollup מפרסם נתונים במקביל לעיבוד העסקאות, והתור אינו גדל. משיכות הכספים עוברות ללא עיכובים, מכיוון שההוכחה תמיד מורכבת מחלקים זמינים. עמידות בפני כשלים עלתה — אובדן של צומת אחסון אחד אינו עוצר את הרשת, הבלוק משוחזר מהעותקים הנותרים. המפעיל אינו עוד נקודת כשל יחידה.
לארגון שכבה כזו אנו משתמשים ב-Avail — הוא מספק ארכיטקטורה מודולרית, שבה זמינות הנתונים מופרדת מהביצוע ומהקונצנזוס. הדבר מאפשר להרחיב את האחסון באופן בלתי תלוי בתפוקת הרשת הראשית ולא לשכתב את לוגיקת ה-rollup עם גידול העומס.
התלבטויות לפני אינטגרציה: תאימות, חזרה לאחור, הרשאות גישה
לפני תחילת האינטגרציה של Avail, לקוחות מעלים לרוב שלוש שאלות: האם שכבת ה-DA תשבור rollup שכבר פועל, האם ניתן לחזור לסכמת פרסום הנתונים הקודמת, ומי מקבל גישה לנודים ולמפתחות. אנו עונים על כל אחת באופן ענייני.
מה אם ה-rollup הנוכחי כבר כותב נתונים לשכבת DA אחרת? התאימות של שכבת ה-DA נפתרת ברמת המתאם: אנחנו לא כותבים מחדש את הלוגיקה של הסקוונסר, אלא מוסיפים פרסום בלובים ב-Avail במקביל או במקום הערוץ הקודם. המעבר הוא פרמטר תצורה נשלט, ולא מיגרציה עם עצירת הרשת. אם ה-rollup פועל על OP Stack או Arbitrum Orbit, המתאם משתלב בתצורה הקיימת ללא פורק של הלקוח.
איך בנויה החזרה לאחור של האינטגרציה? את החזרה לאחור אנחנו שומרים בשתי רמות: חזרה לשכבת ה-DA הקודמת דרך אותו פרמטר תצורה, וחזרה לגרסת המתאם לפי תגית האימג'. את שני התרחישים אנחנו מתרגלים על רשת בדיקה לפני השחרור — השחזור אורך דקות, ולא חלון של השבתה.
למי ואילו הרשאות גישה ניתנות? את הרשאות הגישה והתפקידים אנחנו מפרידים לפי עקרון ההרשאות המינימליות: חשבונות נפרדים לפרסום נתונים, לקריאה ולניהול הנודים. מפתחות החתימה נשמרים באחסון מבודד, וסבב החלפת מפתחות וביקורת הפניות מוגדרים מראש.
מה קורה לנתונים שכבר פורסמו בעת החלפת שכבת ה-DA?
בלובים היסטוריים נשארים בשכבה הקודמת וזמינים לבדיקה — אנחנו לא מוחקים ולא כותבים עליהם מחדש. נתונים חדשים עוברים ל-Avail, והמאמת קורא את שני המקורות לפי תקופה. זה מסיר את הסיכון לאובדן הוכחות בעת שינוי סכמת הפרסום.
מה אם לצוות אין נודי Avail משלו? אנחנו מרימים לקוח קל או מתחברים לספקים חיצוניים — הבחירה מתועדת בתיעוד עם תיאור מצבי כשל. איך בודקים שהנתונים באמת זמינים? במסירה נכללים סקריפט לבדיקת דגימת בלובים ודוח על פרסומי בקרה.
בסיום המסירה הלקוח מקבל:
- תצורות המתאם ופרמטרי המעבר של שכבת ה-DA;
- תרשימי זרימת נתונים מהסקוונסר ועד המאמת;
- מדיניות הרשאות גישה ותפקידים עם מטריצת הרשאות;
- נוהל לסבב החלפת מפתחות וביקורת פניות;
- הוראות לחזרה לאחור עם בדיקות שלב-אחר-שלב;
- תיעוד של מצבי כשל וניטור;
- דוח פרסומי בקרה ובדיקות זמינות.
תארו את תצורת ה-rollup שלכם ואת שכבת ה-DA הנוכחית — נחזור עם הערכת תאימות, תוכנית מעבר והרכב הארטיפקטים למקרה שלכם.