תכנון ארכיטקטורת פרויקט בלוקצ'יין

מדוע ארכיטקטורת פרויקט בלוקצ'יין נשברת עם גידול בעומס

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

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

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

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

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

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

מה משתנה לאחר ההטמעה: לוחות זמנים, יציבות, שליטה

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

זמן הוצאת שינויים

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

עמידות המעגל בזמן תקלה וזמן התאוששות

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

שיעור זמן ההשבתה של המערכת המבוזרת

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

סוג הכשל שהוסר

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

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

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

לפי אילו מאפיינים בוחרים את סוג רשת הבלוקצ'יין

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

היכן הגבול של כל וריאנט

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

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

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

סקר וסכימת המעגל

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

הגדרה, בדיקה ומסירה

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

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

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

תיעוד טכני למעגל

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

נהלי ליווי

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

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

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

מה שינינו

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

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

מטריקות לפני ואחרי

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

מה לעשות אם המעגל כבר פרוס ופועל

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

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

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

ספקות טכניים: פרטיות, ביטול טרנזקציות, אינטגרציות

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

האם אפשר לבטל פעולות שגויות?

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

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

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

מי וכיצד בודק את החוזים החכמים?

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

מה יקרה כשנדרש לשנות את הלוגיקה?

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

נדון במשימה ונחזור עם הערכה ותוכנית עבודה

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

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

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

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