טון: טלגרם רשת פתוחה. חלק 2: בלוקצ'יין, ריסוק

טקסט זה הוא המשך לסדרת כתבות שבהן אני בוחן את מבנה הרשת המבוזרת (ככל הנראה) Telegram Open Network (TON), שהוכנה לקראת יציאתו השנה. IN החלק הקודם תיארתי את הרמה הבסיסית ביותר שלו - האופן שבו צמתים מתקשרים זה עם זה.

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

היום נסתכל על המרכיב העיקרי של TON - הבלוקצ'יין.

מושגים בסיסיים

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

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

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

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

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

בלוקצ'יין בטון: מה זה ולמה?

כפי שהוזכר במאמר הקודם, blockchain הוא מבנה נתונים, שהאלמנטים (בלוקים) שלו מסודרים ל"שרשרת", וכל בלוק עוקב בשרשרת מכיל hash של הקודם. ההערות שאלו את השאלה: למה אנחנו צריכים בכלל מבנה נתונים כזה כשכבר יש לנו DHT - טבלת hash מבוזרת? ברור שניתן לאחסן נתונים מסוימים ב-DHT, אבל זה מתאים רק למידע לא "רגיש" מדי. לא ניתן לאחסן יתרות מטבעות קריפטו ב-DHT - בעיקר בגלל היעדר בדיקות על יושרה. למעשה, כל המורכבות של מבנה הבלוקצ'יין גדלה על מנת למנוע הפרעה לנתונים המאוחסנים בו.

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

כיצד מתכננת TON לפתור את שתי הבעיות הנ"ל?

תוכן בלוקצ'יין. שרשראות עבודה.

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

• איזון;
• קוד חוזה חכם (רק עבור חוזים חכמים);
• אחסון נתוני חוזים חכמים (עבור חוזים חכמים בלבד);
• סטָטִיסטִיקָה;
• (אופציונלי) מפתח ציבורי להעברות מהחשבון, כברירת מחדל account_id;
• תור של הודעות יוצאות (כאן הן מוזנות להעברה לנמען);
• רשימה של ההודעות האחרונות שנשלחו לחשבון זה.

כפי שצוין לעיל, הבלוקים עצמם מורכבים מטרנזקציות - הודעות המועברות לחשבונות account_id שונים. עם זאת, בנוסף ל-account_id, הודעות מכילות גם שדה של 32 סיביות workchain_id - מה שנקרא מזהה שרשרת עבודה (שרשרת עבודה, בלוקצ'יין עובד). זה מאפשר לך לקבל מספר בלוקצ'יין עצמאיים זה מזה עם תצורות שונות. במקרה זה, workchain_id = 0 נחשב למקרה מיוחד, אפס שרשרת עבודה - היתרות בו הן שיתאימו למטבע הקריפטוגרפי TON (גרם). סביר להניח שבהתחלה שרשראות עבודה אחרות לא יהיו קיימות כלל.

שרשראות. פרדיגמת ריסוק אינסופית.

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

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

לכן, שרידי שרשרת משלבים חשבונות לפי הקידומות הבינאריות של המזהים שלהם: אם שרשרת יש קידומת של 0110, אז הוא יכלול טרנזקציות של כל account_id שמתחילות במספרים אלו. זֶה shard_prefix יכול להיות באורך מ-0 עד 60 סיביות - והעיקר שהוא יכול להשתנות באופן דינמי.

ברגע שאחד משרשרת הרסיסים מתחיל לקבל יותר מדי עסקאות, הצמתים שעובדים עליו, על פי כללים שנקבעו מראש, "מפצלים" אותו לשני ילדים - הקידומות שלהם יהיו קצת יותר ארוכות (ועבור אחד מהם הביט הזה יהיה שווה ל-0, ועבור השני - 1). לדוגמה, shard_prefix = 0110b יתפצל ל 01100b ו 01101ב. בתורו, אם שני שרשראות "שכנות" יתחילו להרגיש בנוח מספיק (לזמן מה), הם יתמזגו שוב.

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

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

תיקון שגיאות. בלוקצ'יין אנכי.

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

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

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

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

בלוקצ'יין אחד שישלוט בכולם

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

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

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

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

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

מקור: www.habr.com