רישום מבוזר עבור ערכות גלגלים: חוויה עם Hyperledger Fabric

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

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

בעיה: הבלוקצ'יין עדיין לא מתרחב

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

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

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

Mainnet Ethereum פועל כעת ב-~30 tps. רק בגלל זה, קשה לתפוס אותו כבלוקצ'יין בשום צורה המתאימה לצרכים הארגוניים. בין הפתרונות המורשים ישנם מדדים המציגים 2000 tps (מִניָן) או 3000 טפס (בד היפרפלגר, יש קצת פחות בפרסום, אבל אתה צריך לקחת בחשבון שהמדד בוצע על מנוע הקונצנזוס הישן). היה ניסיון לעיבוד בד רדיקלי, שנתן את התוצאות לא הכי גרועות, 20000 tps, אבל עד כה זהו רק מחקר אקדמי, שמחכה ליישומו היציב. לא סביר שתאגיד שיכול להרשות לעצמו להחזיק מחלקה של מפתחי בלוקצ'יין ישלים עם אינדיקטורים כאלה. אבל הבעיה היא לא רק בתפוקה, יש גם חביון.

חֶבִיוֹן

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

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

נלקח מכאן: hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#swimlane

(1) הלקוח יוצר עסקה, שולח אותה לעמיתים המאשרים, האחרונים מדמים את העסקה (החל שינויים שבוצעו על ידי chaincode למצב הנוכחי, אך אל תתחייב לפנקס החשבונות) ומקבל RWSet - שמות מפתח, גרסאות וערכים ​נלקח מהאוסף ב-CouchDB, (2) נותני תמיכה שולחים חזרה RWSet חתום ללקוח, (3) הלקוח בודק אם קיימות חתימות של כל העמיתים הדרושים (הנותנים), ולאחר מכן שולח את העסקה לשירות ההזמנה , או שולח אותו ללא אימות (הבדיקה עדיין תתבצע מאוחר יותר), שירות ההזמנה יוצר חסימה ו- (4) שולח בחזרה לכל העמיתים, לא רק לאישורים; עמיתים בודקים שגרסאות המפתח בערכת הקריאה תואמות לגרסאות במסד הנתונים, שלכל הנותנים יש חתימות, ולבסוף מבצעים את החסימה.

אבל זה לא הכל. המילים "מזמין יוצר בלוק" מסתירות לא רק את הזמנת העסקאות, אלא גם 3 בקשות רשת עוקבות מהמנהיג לעוקבים ובחזרה: המנהיג מוסיף הודעה ליומן, שולח אותה לעוקבים, האחרון מוסיף אותה ליומן שלהם, שולח אישור לשכפול מוצלח למנהיג, המנהיג מחייב את ההודעה, שולח אישור התחייבות לעוקבים, עוקבים מתחייבים. ככל שהגודל וזמן היווצרות הבלוק קטנים יותר, כך שירות ההזמנה יצטרך ליצור קונצנזוס לעתים קרובות יותר. ל-Hyperledger Fabric שני פרמטרים ליצירת בלוק: BatchTimeout - זמן יצירת בלוק ו-BatchSize - גודל בלוק (מספר העסקאות וגודל הבלוק עצמו בבתים). ברגע שאחד מהפרמטרים מגיע לגבול, משתחרר בלוק חדש. ככל שיותר צמתי סדר, כך זה ייקח יותר זמן. לכן, עליך להגדיל את BatchTimeout ואת BatchSize. אבל מכיוון ש-RWSets הם בעלי גרסה, ככל שהבלוק שאנו עושים גדול יותר, כך הסבירות להתנגשויות MVCC גבוהה יותר. בנוסף, ככל שה-BatchTimeout גדל, ה-UX מתדרדר בצורה קטסטרופלית. התכנית הבאה לפתרון בעיות אלו נראית לי הגיונית וברורה.

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

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

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

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

השלב הבא הוא להפוך את האינטראקציה של הלקוח עם המערכת לא-סינכרונית כך שהיא לא תחכה 15, 30 או 10000000 שניות, אותם נגדיר כ-BatchTimeout. אך יחד עם זאת, יש צורך לשמור על היכולת לוודא שהשינויים שיזמה העסקה נרשמים/אינם נרשמים בבלוקצ'יין.
ניתן להשתמש במסד נתונים לאחסון סטטוס עסקה. האפשרות הפשוטה ביותר היא CouchDB בשל קלות השימוש בו: למסד הנתונים יש ממשק משתמש מחוץ לקופסה, ממשק API של REST, וניתן להגדיר עבורו רפליקציה וריסוק בקלות. אתה יכול פשוט ליצור אוסף נפרד באותו מופע CouchDB שמשתמש ב-Fabric כדי לאחסן את מצב העולם שלו. אנחנו צריכים לאחסן מסמכים מסוג זה.

{
 Status string // Статус транзакции: "pending", "done", "failed"
 TxID: string // ID транзакции
 Error: string // optional, сообщение об ошибке
}

מסמך זה נכתב למסד הנתונים לפני שליחת העסקה לעמיתים, מזהה הישות מוחזר למשתמש (אותו מזהה משמש כמפתח) אם מדובר בפעולת יצירה, ואז השדות Status, TxID ו-Error הם מתעדכן ככל שמתקבל מידע רלוונטי מעמיתים.

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

בחרנו ב- BoltDB לאחסן סטטוסי עסקאות מכיוון שאנו צריכים לחסוך בזיכרון ולא רוצים לבזבז זמן על אינטראקציה ברשת עם שרת מסד נתונים נפרד, במיוחד כאשר אינטראקציה זו מתרחשת באמצעות פרוטוקול טקסט רגיל. אגב, בין אם אתה משתמש ב-CouchDB כדי ליישם את הסכימה שתוארה לעיל או פשוט כדי לאחסן מצב עולמי, בכל מקרה זה הגיוני לייעל את האופן שבו הנתונים מאוחסנים ב-CouchDB. כברירת מחדל, ב-CouchDB, הגודל של צמתי b-tree הוא 1279 בתים, וזה הרבה יותר קטן מגודל הסקטור בדיסק, מה שאומר שגם קריאה ואיזון מחדש של העץ ידרשו יותר גישה פיזית לדיסק. הגודל האופטימלי מתאים לתקן פורמט מתקדם והוא 4 קילובייט. כדי לבצע אופטימיזציה עלינו להגדיר את הפרמטר btree_chunk_size שווה ל-4096 בקובץ התצורה של CouchDB. עבור BoltDB התערבות ידנית כזו לא נדרש.

לחץ אחורי: אסטרטגיית חיץ

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

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

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

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

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

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

כלים אחרים

לא נאמר כאן שום דבר על chaincode, כי, ככלל, אין בו מה לייעל. קוד שרשרת צריך להיות כמה שיותר פשוט ומאובטח - זה כל מה שנדרש ממנו. המסגרת עוזרת לנו לכתוב קוד שרשרת בצורה פשוטה ובטוחה CCKit מ-S7 Techlab ומנתח סטטי להחיות^CC.

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

מסקנה

גישה זו מאפשרת להחליף בקלות את Hyperledger Fabric ב-Quorum, רשתות Ethereum פרטיות אחרות (PoA או אפילו PoW), להפחית משמעותית את התפוקה בפועל, אך במקביל לשמור על UX תקין (הן למשתמשים בדפדפן והן למערכות משולבות). כאשר מחליפים את הבד ב-Ethereum בסכימה, תצטרך רק לשנות את ההיגיון של השירות/המעצב מחדש מעיבוד התנגשויות MVCC להגדלה אטומית ושליחה מחדש. חציצה ואחסון סטטוס אפשרו לנתק את זמן התגובה מזמן היווצרות הבלוק. כעת תוכלו להוסיף אלפי צמתי הזמנה ולא לחשוש שבלוקים נוצרים לעיתים קרובות מדי ולהעמיס את שירות ההזמנה.

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

מקור: www.habr.com