פיתוח פרוטוקול ריסטייקינג על EigenLayer עד מסירה

פיתוח פרוטוקול ריסטייקינג: היכן נשברת המכניקה

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

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

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

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

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

מה נותן סטייקינג חוזר: אפקטים מדידים ולוחות זמנים

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

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

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

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

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

אפשרויות מימוש: מודולים מוכנים, פורק, קוד עצמאי

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

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

סדר העבודות: ביקורת, סכימה, בנייה, בדיקה, מסירה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

במה שונה ריסטייקינג מסטייקינג רגיל?

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

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

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

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

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

ספקות טכניים: משיכת כספים, קנסות, ביקורת

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

מי משלם את קנסות הוולידטור?

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

כיצד מתבצעת ביקורת חוזים ועדכון לוגיקה?

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

נדון במשימה: כיצד אנו מעריכים את היקף העבודה

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

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

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

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