פריסת L2 באמצעות שירות רולאפ ב-Conduit וב-Caldera

Rollup-as-a-Service: היכן נשברת רשת L2 משלך

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

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

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

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

למעשה, rollup-as-a-service הוא העברת התפקידים האלה למתאר מנוהל: פלטפורמות כמו Conduit ו-Caldera מצמצמות פריסת L2 לקונפיגורציה, ולא לבניית תשתית מאפס. בהמשך נפרק לפי הסדר את נקודות הכשל של הרולאפ — ואיך זה נסגר בצד השירות.

מה נותן רולאפ מנוהל: זמינות, זמן משיכה וכשלים

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

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

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

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

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

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

Rollup-as-a-Service, L2 משלך או היברידי: השוואת מצבים

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

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

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

הטמעת L2: מביקורת המתאר ועד מסירה לתפעול

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

1. ביקורת המתאר. עורכים מלאי של השירותים שיקראו ויכתבו מצב, צמתים, מאגרי מפתחות, מגבלות נוכחיות ונקודות כשל. בפלט — מפת תלויות ורשימת צווארי בקבוק שצריך להסיר לפני הפריסה.
2. תכנון הסכימה. מגדירים פרופיל רשת למשימה: רוחב פס, מודל עמלות, אופן הוצאת הנתונים לשכבה הבסיסית, תפקידים והרשאות. קובעים מה נלקח כשכבה מוכנה של Rollup-as-a-Service — למשל, Conduit — ומה אנחנו מפתחים בעצמנו.
3. הגדרה ופריסה. מקימים את הרשת, הצמתים ושירותי העזר, מפעילים ניטור, לוגים והתראות לפי מדדי מפתח: גובה בלוקים, השהיית שילוב עסקאות, עומק התור.
4. אינטגרציה עם המתאר הקיים. מחברים אינדקסרים, ארנקים, שירותים פנימיים וגשרים, מריצים תרחישי מקצה לקצה ברשת בדיקה עם פורמטי נתונים אמיתיים.
5. בדיקת עומס ל-L2. נותנים פרופיל קרוב לשיא: פרצי עסקאות, כשל של צומת בודד, התחברות מחדש של לקוחות. קובעים זמן התאוששות והתנהגות המערכת בקצה היכולת.
6. מסירה לתפעול. מוסרים קונפיגורציות, סכימות, נהלי עדכון וחזרה לאחור, ומאמנים את צוות הלקוח. מכאן הרשת חיה בצד שלהם, ואנחנו מתחברים לליווי.

מה נשאר אצל הלקוח: סכימות, הרשאות ונהלים

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

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

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

מקרה בוחן: איך L2 הפסיקה ליפול בעומס שיא

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

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

התוצאה במדדים: שיעור העסקאות המוצלחות בשיאים — מ-92% ל-99.8%; משיכת נכסים — משעות לדקות, השלב הידני יצא מהתהליך; מספר האירועים ירד פי כמה. במקום תורנויות שבועיות נשארו התראות בודדות, שנסגרות לפי הנוהל.

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

במה רולאפ מנוהל שונה מרשת עצמאית?

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

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

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

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

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

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

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

היכן נשמרים נתוני L2 ומי מנהל את המתאר?

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

נדון במשימה: נתאים מצב פריסה ל-L2

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

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

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