פיתוח מערכת ניהול מאמתים Ethereum PoS

מדוע מערכת ניהול הוולידטורים נשברת ככל שהרשת גדלה

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

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

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

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

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

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

מה נותנת האוטומציה של צי הצמתים: אפקט מדיד

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

העלאת צומת לעבודה

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

התאוששות אחרי תקלה

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

אישורים מוחמצים

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

העומס על התורן

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

אפשרויות להרצת צמתים: השוואה בין מצבים ומגבלות

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

*שגיאת כתיב בטבלה — יש לתקן ל«סכמה היברידית».

מה מביאים בחשבון בבחירה

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

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

שלבי ההטמעה: מביקורת התשתית ועד למסירה

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

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

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

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

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

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

מקרה בוחן: איך צי הוולידטורים שרד את גידול העומס

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

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

מה השתנה

שיעור האישורים המוחמצים ירד מ-0.4% ל-0.03%, והפעולות הידניות — מ-6–8 שעות בשבוע לחצי שעה של בדיקת דוח. הצי גדל מ-40 ל-320 ולידטורים בלי להרחיב את הצוות: אותם שני מהנדסים מפעילים אותו באותו אופן, וחלון השחזור של צומת התקצר משעות לכמה דקות.

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

מה עושים אם חלק מהצמתים כבר פועלים ואי אפשר לעצור אותם?

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

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

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

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

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

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

התלבטויות טכניות: מפתחות, עמידות בכשלים, תורנות

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

מה עם עמידות בכשלים וגיבוי?

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

מי תורן אחרי המסירה וכיצד מתבצע שחזור חירום?

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

נדבר על המשימה: נחזור עם הערכה ותוכנית הטמעה

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

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

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