מדוע פיתוח L2 נתקע בתפוקה
התפוקה של כל בלוקצ'יין מהשכבה הראשונה קבועה: בלוק מכיל נפח נתונים מוגבל בהחלט, ואי אפשר להרחיב את המגבלה הזו באופן אדמיניסטרטיבי. ברגע שזרימת הפעולות עולה על הסף, העסקאות אינן נדחות — הן נכנסות לתור עסקאות וממתינות עד שמתפנה מקום בבלוק הבא.
מכאן נכנסת מכירה פומבית על המקום הזה. עלות העסקה מחושבת לפי העומס הנוכחי, לכן בעומס שיא — השקת טוקן, חלוקה המונית, זינוק בפעילות באפליקציה — התשלום עולה פי עשרות בדקות ספורות. משתמש ששלח אתמול פעולה בתשלום מינימלי רואה היום עלות מוגדלת ופשוט סוגר את הממשק.
המוצר נשבר לא ברגע הסירוב המפורש, אלא קודם לכן. השהיית האישור נמתחת משניות לעשרות דקות, הממשק מציג "המתנה" אינסופית, היתרות לא מסתדרות, ותרחישים המבוססים על סופיות מהירה — החלפה, הימורים, מכניקת משחק — הופכים לבלתי שמישים לאורך כל חלון השיא.
בחלונות כאלה הרשת מאבדת בדיוק את אותם משתמשים שהגיעו בשביל המהירות, והחזרתם לאחר מכן יקרה יותר משהיה מחזיק אותם.
נפרק כיצד זה נסגר: היכן נגמרת הקיבולת של השכבה הבסיסית ומה בדיוק נותנת רשת שכבה שנייה משלכם.
מה נותן רולאפ משלכם: מהירות, עלות, שליטה
התפוקה מפסיקה להיתקע ברשת של מישהו אחר
העסקאות מבוצעות בתוך השכבה שלכם, ולרשת הראשית נשלח רק חבילה דחוסה עם התוצאה. רשומה אחת שם נושאת אלפי פעולות, לכן התפוקה בעומס גדלה פי כמה, ולא באחוזים. כשזרימת המשתמשים מזנקת, קצב העיבוד נקבע על ידי צומת-המארגן שלכם, ולא על ידי התור המשותף.
העמלה נקבעת על ידכם, ולא על ידי מכירה פומבית ברשת הראשית
התשלום עבור פעולה נקבע לפי המדיניות של השכבה שלכם: תעריף אחיד לגז במקום מכירה פומבית שבה המחיר עולה מפעילות של אחרים. בשעות שיא העמלה לא מוכפלת — אפשר להגביל אותה מלמעלה עבור המשתמש ולשמור עליה צפויה בעת גידול פי כמה בזרימה. הוצאות השירות הופכות לניתנות לתכנון, ולא תלויות בתעבורה של אחרים.
סירוב שכבר לא עוצר את השירות
רולאפ משלכם מסיר סוג שלם של כשלים הקשור לעומס יתר על הרשת הראשית: הפעולות לא נתקעות בהמתנה להכללה בבלוק ולא הולכות לאיבוד בזינוק התשלום. אם הרשת הראשית מאטה, החבילות מצטברות ומאושרות מאוחר יותר, ומצב השכבה והפעולות של המשתמשים ממשיכים לזרום. השירות מפסיק להיות תלוי במה שקורה ברשת המשותפת.
זמן אישור צפוי
זמן האישור נקבע על ידי הארכיטקטורה, ולא על ידי העומס הנוכחי: הפעולה גלויה למשתמש כמעט מיד, והסופיות מושגת לאחר פרסום החבילה והאימות. בסכמות עם הוכחת תקפות הסופיות מגיעה בצעד אחד, ובסכמות עם חלון ערעור — לפי תקנון ברור. בשני המקרים ההשהיה אינה תלויה בתעבורה של אחרים.
השוואת גישות: רולאפים אופטימיסטיים והוכחות ZK
ארכיטקטורת השכבה השנייה נבחרת לא לפי "מודרניות" של הפתרון, אלא לפי אילו ערבויות מקבל המשתמש וכמה זמן הוא ממתין להחזרת הכספים. להלן שלושה וריאנטים שביניהם באמת בוחרים בתחילת הפרויקט.
סכמת אופטימיסטית וסכמת ZK נבדלות בשלושה צירים: סופיות החישובים, זמן משיכת הכספים ומודל האבטחה — מי בדיוק מוכיח את הנכונות ומה קורה בהתנהגות לא הוגנת של צומת.
ערוץ ייעודי עומד בנפרד: הוא לא יורש את ההגנה של השכבה הבסיסית במלואה, אך נותן שליטה על כללי הביצוע ועל התפוקה.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| רולאפ אופטימיסטי | עסקאות המוניות, העברת לוגיקת חוזים קיימת בלי לכתוב מחדש, השקה מהירה | משיכת הכספים ממתינה לסיום תקופת הערעור — בדרך כלל ימים; סופיות החישובים דחויה, יש צורך במשקיפים שמוכנים לערער על בלוק שגוי |
| הוכחות באפס ידיעה | דרושה סופיות מהירה וזמן קצר למשיכת הכספים, ערך גבוה של הפעולות | יצירת ההוכחות יקרה יותר מבחינה חישובית, חלק מהפעולות צריך להגביל; מורכב יותר להרכיב ולתחזק תת-מערכת הוכחה |
| ערוץ ייעודי | כללי גז משלכם, תפוקה צפויה, פעולות פרטיות | מודל אבטחה משל עצמו: את הנכונות מבטיחים מאמתי הערוץ, ולא השכבה הבסיסית; היציאה מהערוץ מורכבת יותר |
בפועל בוחרים את הסכמה לפי פרופיל העומס: היכן שחשובים תאימות ועלות ביצוע — מנצחת הדרך האופטימיסטית; היכן שסופיות מהירה היא קריטית — הוכחות באפס ידיעה.
פיתוח L2: ביקורת, סכמת רשת, הגדרה ומסירה
את הפיתוח של L2 אנחנו מתחילים לא מהקוד, אלא מניתוח של מה שכבר קיים: אילו תרחישים הרשת משרתת, מי ובאיזו תדירות כותב אליה, והיכן עובר הגבול בין השרשרת הראשית לשכבה השנייה. סדר כזה חוסך שבועות — לעצב מחדש את הסכמה לאחר הפעלת הצמתים יקר יותר מאשר לדייק אותה לפני העסקה הראשונה.
סדר העבודות
- ביקורת תרחישים. מנתחים את זרימות הפעולות, פרופיל עומס השיא, דרישות לזמן האישור ומי מחזיק במפתחות. קובעים אילו פעולות מוציאים לשכבה השנייה ואילו משאירים ברשת הראשית.
- תכנון סכמת הרשת. בוחרים את מודל ההרכבה וההוכחה, את מספר צומתי-המאמת, את טופולוגיית הפריסה, את כללי התשלום עבור חישוב ואת תפקידי הגישה. כאן גם קובעים כיצד הרשת תשרוד נפילה של צומת בודד.
- הגדרת צמתים. מרימים צמתים, מגדירים סנכרון, גישה למצב הרשת, ניטור וגיבויים. בנפרד בודקים שסדר ההפעלה משוחזר מאפס לפי ההוראות.
- חיבור לרשת הראשית. מגדירים העברת נכסים בין השכבות, השהיות משיכה וטיפול בנסיגות בעת ארגון מחדש של השרשרת.
- בדיקה בעומס. מריצים תרחישים שמשחזרים את פרופיל השיא, מודדים תפוקה וזמן תגובה, מכבים צמתים במכוון ובוחנים את ההתאוששות.
- קבלה ומסירה. מוסרים תיעוד, הרשאות, תקנוני עדכון וטיפול בתקלות, ומכשירים את הצוות — הרשת צריכה להיות מתוחזקת בלעדינו.
כל שלב נסגר בארטיפקט: דוח, סכמה, קונפיגורציה או פרוטוקול בדיקות. הקבלה מתבצעת לפי מדדים שסוכמו מראש, ולא לפי תחושה של "כאילו זה עובד".
ערכת תיעוד: סכמות רשת, מדיניות גישה, תקנונים
לאחר הפעלת הרשת נשאר לצוות לא רק מתאר עובד, אלא חבילת מסמכים שלפיה אפשר לתפעל אותה בלעדינו. אנחנו מוסרים אותה באותה צורה שבה אנחנו עצמנו משתמשים בה: בלי מילים כלליות, עם ערכים ונוהלים קונקרטיים. להלן מה שנכלל בערכה.
- קונפיגורציות צמתים — קבצי הגדרות של הסדרן, צמתי האימות וצמתי הגישה לרשת עם ניתוח שורה-שורה: אילו ערכים הם סטנדרטיים, אילו הותאמו לעומס שלכם ומה יקרה בעת סטייה.
- סכמת טופולוגיה — כיצד הצמתים מחוברים זה לזה, היכן עובר הגבול עם הרשת הראשית, אילו ערוצים משוכפלים ואילו נקודות כשל הושארו בכוונה.
- מדיניות גישה ותפקידים — מטריצת "תפקיד → פעולה → מפתח": מי מוציא עדכוני חוזים, מי מנהל ארנקים, מי רק קורא מדדים ולמה שתי הזכויות הראשונות לא צריכות להיות בידי אותו אדם.
- תקנון עדכון — סדר הוצאת גרסאות חדשות של חוזים וצמתים: הכנה, חלון עבודה, מי מאשר, כיצד נבדקת התוצאה ולפי איזה תרחיש מבצעים נסיגה.
- הוראות למשמרת תורנית — מה נחשב לסטייה, אילו אותות דורשים תגובה בתוך המשמרת, אילו ממתינים לבוקר, ובאיזה רגע מעירים את המפתחים.
- נוהל עבודה עם מפתחות — היכן נשמרים מפתחות החתימה, כיצד מתבצעת רוטציה ומה עושים בעת חשיפה.
- תוכנית התאוששות — מה ובאיזו תדירות מגובים, כמה זמן לוקח להרים את הרשת מאפס על תשתית נקייה ומי אחראי לנוהל.
כיצד הסרנו עומס שיא: מדדים לפני ואחרי
מה היה לפני המעבר
הלקוח — שירות עם זרימה של פעולות קטנות: זיכויים, הימורים, משיכות. בשעות שיא השכבה הבסיסית הפסיקה לקלוט חלק מהעסקאות: שיעור הפעולות הנדחות הגיע ל-8–9%, והאישור נמתח לדקה ויותר.
ניסיונות חוזרים רק הגבירו את הלחץ — התור לא הספיק להתפנות, והשירות נכנס לדגרדציה בדיוק כשהעומס היה מקסימלי.
מה שינינו ומה קיבלנו
פרסנו שכבה שנייה משלנו על רולאפים אופטימיסטיים: מאות פעולות של לקוחות נארזות לחבילה אחת, ול-Ethereum נשלח סיכום אחד. הוספנו תור עם עדיפויות והצבה חוזרת — תחת עומס יתר הפעולה ממתינה לתורה, ולא נופלת.
מדדים לפני ואחרי: שיעור הפעולות הנדחות ירד מ-8–9% ל-0.3%, האישור הממוצע התקצר מ-60 ל-2–4 שניות, וההתנהגות בשיא הפכה לאחידה. הרצת עומס עם פי שלושה מהתעבורה הרגילה הוחזקה 40 דקות — בלי גידול בתור ובלי התערבות ידנית של התורן.
העיקר — סוג שלם של כשלים נעלם: הפעולות כבר לא הולכות לאיבוד בגלל הצפת בלוק בשכבה הבסיסית. הניסיונות החוזרים חזרו למצב שגרתי, ותקריות שיא הפסיקו להיות סעיף קבוע בדוח התורנות.
במה רולאפ אופטימיסטי שונה מ-ZK-רולאפ?
שתי המשפחות פותרות משימה אחת: הביצוע עובר מהשכבה הראשית, ולרשת שכבת החישוב (Ethereum) נשלחים נתונים והוכחת נכונות של המצב. ההבדל הוא כיצד בנויה ההוכחה הזו — ממנה תלויים רגע האישור, הדרישות מהצד המאמת והיקף עבודות התחזוקה.
רולאפ אופטימיסטי מתייחס כברירת מחדל לאצוות העסקאות כנכונה ומשאיר חלון לערעור. כל עוד החלון פתוח, משיכת הכספים לשכבה הראשית ממתינה, אך אין מה לאמת בזמן אמת: די במשתתף ישר אחד שאם יש אי-התאמה יפרסם הוכחת מרמה. לצד המאמת מספיק צומת רגיל — אין צורך בציוד מיוחד, ועלות האימות קרובה לאפס.
ZK-רולאפ מצרף לכל אצווה הוכחה באפס ידיעה, והחוזה משנה מצב רק לאחר אימותה. האישור מגיע מהיר באופן ניכר ואינו תלוי בקיומם של משקיפים בקרבת מקום. אימות ההוכחה בשכבה הראשית זול, אך היצירה דורשת ציוד מתמחה אצל המפעיל — המשאב הזה הוא סעיף ההוצאות העיקרי של הסכמה.
התחזוקה שונה לא פחות. במודל האופטימיסטי המאמצים מופנים לכלכלת הערעור, לניטור ולהגנה מפני צנזורה בצד הסדרן. ב-ZK — לסכמות ההוכחה ולבדיקה שלהן: שינוי לוגיקה דורש עיבוד מחדש של הסכמה, אימות חוזר ונוהל עדכון קפדני, ולכן הצוות זקוק ליכולות קריפטוגרפיות משל עצמו.
את הסכמה בוחרים לפי סדר עדיפויות: מהירות אישור סופי ועצמאות ממשקיפים — לטובת ZK; תאימות לחוזים ולכלים קיימים, תחזוקה צפויה — לטובת המודל האופטימיסטי. תארו את התרחיש — נחזור עם הערכה ותוכנית לשתי הווריאנטים, עם ציון צוואר הבקבוק והדרך לסגור אותו.
ספקות טיפוסיים: אבטחה, משיכת כספים, תמיכה
לפני תחילת העבודות מהנדסי הלקוח שואלים אותן שאלות: כיצד מאושרת נכונות החישובים, מה יקרה בעת כשל של צומת-המארגן, כיצד מושכים כספים ומי יישאר עם הרשת לאחר ההשקה. להלן תשובות קצרות ולעניין.
סכמות מפורטות, כתובות חוזים ומטריצת הרשאות נפרט בשלב התכנון — על כל סעיף יישאר לכם מסמך, ולא הבטחה שבעל פה.
כיצד מאושרת נכונות החישובים ואבטחת החישובים?
בסכמת Optimistic התוצאה מתקבלת ללא אימות מיידי, אך נשאר חלון ערעור: כל משתתף מחשב מחדש את מעבר המצב ומגיש הוכחת שגיאה — חבילה מזויפת מתבטלת. בסכמת ZK מצורפת לכל חבילה הוכחת נכונות, והחוזה המאמת דוחה את החבילה אם החישובים אינם תואמים את שורש המצב.
מה יקרה בעת כשל של צומת-המארגן?
מחזיקים רזרבה חמה ומעבירים את תור העסקאות — ההשבתה נמדדת בדקות. אם כל הקבוצה תיכשל, המשתתפים שולחים עסקאות ישירות דרך החוזה של השכבה הבסיסית: השהיית האישור גדלה, אך המצב והכספים נשארים ברשת.
כיצד בנויה משיכת הכספים?
המשיכה דו-שלבית: ייזום בשכבה השנייה, ואחר כך אישור בבסיסית לאחר חלון הערעור. בווריאנט ZK ההמתנה קצרה יותר — הנכונות כבר אושרה על ידי ההוכחה. משיכה מהירה דרך גשרים חיצוניים מחברים בנפרד, עם הערכת הסיכונים והמגבלות שלהם.
מי מתחזק את הרשת לאחר ההשקה?
מוסרים תקנון: ניטור צמתים ותור, רוטציית מפתחות, עדכונים מתוכננים, ניתוח תקריות. בשבועות הראשונים אנחנו תורנים יחד עם הצוות שלכם, ומכאן — לפי רמת תמיכה טכנית שסוכמה עם זמן תגובה מוגדר.
נדון במשימה: נתאים סכמה ונחזור עם הערכה
כדי שההערכה תהיה עניינית ולא טווח לפי העין, אנחנו צריכים נתוני קלט מהלקוח. דווקא הם קובעים את הבחירה בין הסכמה האופטימיסטית להוכחות תקפות, את קונפיגורציית הצמתים ואת היקף התשתית הנלווית.
- תרחישים שלשמם דרושה שכבה שנייה: תשלומים, החלפה, לוגיקת משחק או חשבונאות פנימית — מכך תלויים מודל העמלות והדרישות לתפוקה.
- פרופיל עומס: מספר הפעולות הצפוי בשיא, שיעור ההעברות הפשוטות, זמן האישור המקובל על המשתמש.
- דרישות למשיכת כספים: איזה זמן משיכה סופית נחשב לנורמלי, האם נדרש גשר מהיר ומי מחזיק בנזילות בצד הרשת הראשית.
- מודל ניהול: מי הבעלים של החוזים, מי וכיצד מעדכן לוגיקה, אילו תפקידים נדרשים להשהיה ולעצירת חירום.
- אינטגרציות: ארנקים, בורסות, אינדקסרים, אנליטיקה ושירותים קיימים שהשכבה החדשה צריכה להתחבר אליהם.
- מגבלות בלוחות זמנים ובשלבים: התאריך שבו נדרש מתאר עובד, ומה מותר להוציא לשלב השני.
- דרישות לבדיקות: האם נדרשת ביקורת חיצונית, אילו דוחות, הרשאות וסכמת פריסה מצפה הצוות שלכם.
לאחר קבלת הנתונים האלה, נחזור עם הערכת היקף, תוכנית עבודה לפי שלבים ולוחות זמנים לכל אחד — מאב-טיפוס של המתאר ועד השקה ומסירה לתפעול. תארו את המשימה בפורמט נוח: התכתבות, שיחה או תקציר טכני קצר.