בד Hyperledger עבור Dummies

פלטפורמת בלוקצ'יין לארגונים

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

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

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

ארכיטקטורה כללית של Hyperledger Fabric

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

לכתיבת חוזים חכמים (chaincode בהקשר של Hyperledger Fabric), השתמשנו ב-Golang (אם כי Hyperledger Fabric מאפשר שימוש בשפות אחרות). כדי לפתח אפליקציה מותאמת אישית, במקרה שלנו, השתמשנו ב-Node.js עם ה-Hyperledger Fabric SDK המקביל.

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

הארכיטקטורה הכללית נראית כך:

תמונה 1. ארכיטקטורה כללית של בד Hyperledger

יישום משתמש (Submitting Client) הוא יישום שאיתו משתמשים עובדים עם רשת הבלוקצ'יין. כדי לעבוד, עליך להיות מורשה ובעל זכויות מתאימות לסוגים שונים של פעולות ברשת.

עמיתים מגיעים בכמה תפקידים:

• Endorsing Peer הוא צומת המדמה ביצוע של עסקה (מבצע את קוד החוזה החכם). לאחר אימות וביצוע החוזה החכם, הצומת מחזיר את תוצאות הביצוע לאפליקציית הלקוח יחד עם חתימתו.
• Ordering Service הוא שירות מבוזר במספר צמתים, המשמש ליצירת בלוקים חדשים של הרישום המבוזר ויצירת תור לביצוע עסקאות. שירות ההזמנה אינו מוסיף בלוקים חדשים לרישום (תכונה זו הועברה ל-Committing Peers כדי לשפר את הביצועים).
• Committing Peer הוא צומת המכיל רישום מבוזר ומוסיף בלוקים חדשים לרישום (שנוצרו על ידי שירות ההזמנות). כל העמיתים המתחייבים מכילים עותק מקומי של ספר החשבונות המופץ. Committing Peer בודק את תקפות כל העסקאות בתוך הבלוק לפני הוספת בלוק חדש באופן מקומי.

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

הרישום המבוזר - לרגר - מורכב משני חלקים: WolrldState (נקרא גם State DataBase) ו-BlockChain.

BlockChain היא שרשרת בלוקים המאחסנת רשומות של כל השינויים שהתרחשו באובייקטי רישום מבוזרים.

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

WorldState הוא מסד נתונים, בגרסה הבסיסית - LevelDB או מורכבת יותר - CouchDB, המכיל צמדי מפתח-ערך, לדוגמא: שם פרטי - איבן, שם משפחה - איבנוב, תאריך רישום במערכת - 12.12.21/17.12.1961/XNUMX , תאריך לידה - XNUMX/XNUMX/XNUMX וכו'. WorldState והרישום המבוזר חייבים להיות עקביים בין כל המשתתפים בערוץ נתון.

מכיוון שה-Hyperledger Fabric היא רשת שבה כל המשתתפים מוכרים ומאומתים, היא משתמשת ברשות אישורים ייעודית - CA (Certification Authority). CA פועלת על בסיס תקן X.509 ותשתית מפתח ציבורי - PKI.

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

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

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

תרחיש ביצוע עסקה טיפוסי

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

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

1) ייזום עסקה

יישום משתמש, המשתמש ב-Hyperledger Fabric SDK, יוזם בקשת עסקאות ושולח את הבקשה לצמתים עם חוזים חכמים. הבקשה יכולה להיות לשנות או לקרוא מתוך רישום מבוזר (Ledger). אם נשקול דוגמה לתצורת מערכת הבדיקה שלנו לחשבונאות עבור סטודנטים באוניברסיטה, יישום הלקוח שולח בקשת עסקאות לצמתים של אוניברסיטאות A ו-B, הכלולים במדיניות האישור של החוזה החכם הנקרא. צומת A הוא צומת שנמצא באוניברסיטה הרושמת את הסטודנט הנכנס, וצומת B הוא צומת שנמצא באוניברסיטה אחרת. על מנת שעסקה תישמר ברישום מבוזר, יש צורך שכל הצמתים שעל פי ההיגיון העסקי חייבים לאשר את העסקה, יבצעו בהצלחה חוזים חכמים באותה תוצאה. הצומת יישום משתמש, המשתמש בכלי Hyperledger Fabric SDK, משיג את מדיניות האישור ולומד לאילו צמתים לשלוח בקשת עסקה. זוהי בקשה להפעיל חוזה חכם ספציפי (פונקציית chaincode) כדי לקרוא או לכתוב נתונים מסוימים לרישום מבוזר. מבחינה טכנית, ה-SDK של הלקוח משתמש בפונקציה המקבילה, שה-API שלה מועבר לאובייקט מסוים עם פרמטרים של טרנזקציות, וגם מוסיף חתימת לקוח ושולח את הנתונים הללו באמצעות מאגר פרוטוקול על גבי gRPC לצמתים המתאימים (המלווים עמיתים).

תמונה 2. ייזום עסקה

2) ביצוע חוזה חכם

צמתים (Endoring Peers), לאחר שקיבלו בקשה לבצע עסקה, בודקים את חתימת הלקוח ואם הכל תקין, הם לוקחים אובייקט עם נתוני הבקשה ומריצים סימולציה של ביצוע חוזה חכם (פונקציית chaincode) עם הנתונים האלה. חוזה חכם הוא ההיגיון העסקי של עסקה, סט מסוים של תנאים והוראות (במקרה שלנו מדובר באימות של תלמיד, האם מדובר בתלמיד חדש או שהוא כבר רשום, אימות גיל וכו'). כדי לבצע את החוזה החכם, תזדקק גם לנתונים מ-WorldState. כתוצאה מהדמיית חוזה חכם על ה-Endoring peer, מתקבלות שתי קבוצות של נתונים - Read Set ו-Write Set. Read Set ו-Write Set הם ערכי WorldState המקוריים והחדשים. (חדש – במובן המתקבל במהלך הדמיית חוזה חכם).

תמונה 3. ביצוע חוזה חכם

3) החזרת נתונים לאפליקציית הלקוח

לאחר ביצוע הדמיה של החוזה החכם, Endorsing Peers מחזירים לאפליקציית הלקוח את הנתונים המקוריים ואת תוצאת הסימולציה, כמו גם את RW Set, חתום בתעודה שלהם. בשלב זה, לא מתרחשים שינויים ברישום המבוזר. אפליקציית הלקוח בודקת את חתימת ה-Endorsing Peer, וכן משווה את נתוני העסקה המקוריים שנשלחו והנתונים שהוחזרו (כלומר, היא בודקת האם הנתונים המקוריים שעליהם בוצע הדמיה של העסקה עווות). אם העסקה הייתה רק לקריאת נתונים מהרישום, אזי אפליקציית הלקוח מקבלת בהתאם את ה-Read Set הדרוש וזה בדרך כלל משלים את העסקה בהצלחה מבלי לשנות את הרישום המבוזר. במקרה של עסקה שחייבת לשנות נתונים ברישום, יישום הלקוח בודק בנוסף את יישום מדיניות האישורים. ייתכן שאפליקציית לקוח אינה בודקת את התוצאה של ביצוע מדיניות ה-Endorsement, אך פלטפורמת Hyperledger Fabric במקרה זה מספקת בדיקת מדיניות על צמתים (Committing Peers) בשלב הוספת עסקה לרישום.

תמונה 4. החזרת נתונים ליישום הלקוח

4) שליחת ערכות RW לעמיתים בהזמנה

אפליקציית הלקוח שולחת את העסקה יחד עם הנתונים הנלווים לשירות ההזמנה. זה כולל את ה-RW Set, חתימות עמיתים אישור ומזהה הערוץ.

שירות הזמנות – בהתבסס על השם, תפקידו העיקרי של שירות זה הוא לארגן עסקאות נכנסות בסדר הנכון. כמו גם היווצרות בלוק חדש של הרישום המבוזר ואספקה ​​מובטחת של בלוקים חדשים שנוצרו לכל צמתי Commiting, ובכך להבטיח עקביות נתונים על כל הצמתים המכילים את הרישום המבוזר (Committing peers). יחד עם זאת, שירות ההזמנה עצמו אינו משנה את הרישום בשום צורה. שירות הזמנות הוא מרכיב חיוני של המערכת, ולכן הוא מקבץ של מספר צמתים. שירות ההזמנות אינו בודק את תקפות העסקה, הוא פשוט מקבל עסקה עם מזהה ערוץ מסוים, מסדר עסקאות נכנסות בסדר מסוים ויוצר מהן בלוקים חדשים של הרישום המבוזר. שירות הזמנה אחד יכול לשרת מספר ערוצים בו זמנית. שירות ההזמנות כולל אשכול קפקא, השומר על תור העסקאות הנכון (הבלתי ניתן לשינוי) (ראה נקודה 7).

תמונה 5. שליחת ערכות RW להזמנה עמיתים

5) שליחת בלוקים שנוצרו ל-Committing Peer

בלוקים שנוצרים בשירות ההזמנות מועברים (משדרים) לכל צמתי הרשת. כל צומת, לאחר שקיבל בלוק חדש, בודק את תאימותו למדיניות האישורים, בודק שכל העמיתים הנותנים קיבלו את אותה תוצאה (Write Set) כתוצאה מהדמיית החוזה החכם, וכן בודק האם לערכים המקוריים יש השתנה (כלומר, Read Set - נתונים שנקראו על ידי החוזה החכם מ-WorldState) מרגע תחילת העסקה. אם כל התנאים מתקיימים, העסקה מסומנת כתקינה, אחרת, העסקה מקבלת את הסטטוס לא חוקי.

תמונה 6. שליחת בלוקים שנוצרו ל-Committing Peer

6) הוספת בלוק לרישום

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

תמונה 7. הוספת בלוק לרישום

שירות הזמנה

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

נלקח מתוך kafka.apache.org

• תמונה 8. מבנה נושא שירות הזמנה*

קישורים שימושיים

Youtube - בניית בלוקצ'יין לעסקים עם פרויקט Hyperledger
Hyperledger Fabric Docs
מארג Hyperledger: מערכת הפעלה מבוזרת לבלוקצ'יין מורשים

תודות

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

מקור: www.habr.com