קנה מידה של בלוקצ'יין עם נתונים מחוץ לשרשרת

הועלה מחדש על ידי אפלטון

עוקב: 0

כאשר חשיש שווה מיליון מילים

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

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

לדוגמה, MultiChain 1.0 אפשר ליצור אחד או יותר בשם "זרמים" בשם blockchain ואז להשתמש בהם לאחסון ואחזור נתונים גולמיים. לכל זרם קבוצה של הרשאות כתיבה משלו, וכל צומת יכול לבחור בחופשיות לאילו זרמים להירשם. אם צומת מנויים לזרם, הוא אינדקס את התוכן של הזרם בזמן אמת, ומאפשר לאחזר פריטים במהירות על סמך הזמנתם, חותמת הזמן, מספר החסימה או כתובת המפרסם, וכן באמצעות "מקש" (או תווית) באמצעותו ניתן לתייג פריטים. MultiChain 2.0 (מאז אלפא 1) הרחיב זרמים לתמוך בנתוני Unicode או בנתוני JSON, כמו גם מספר מקשים לפריט ופריטים מרובים בעסקה. הוא הוסיף גם פונקציות סיכום כמו "מיזוג JSON" המשלבים פריטים עם אותו מפתח או מפרסם בדרך שימושית.

סודיות ומדרגיות

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

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

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

אם ניקח מקרה קל, בו כל פריט הוא מבנה JSON קטן של 100 בתים, תפוקת הנתונים הכוללת תהיה 100 קילובייט לשנייה, מחושבת מ- 500 × (100 + 100). זה מתורגם לרוחב הפס מתחת למגה מגה-ביט לשנייה, הנמצאת בנוחות של כל חיבור אינטרנט מודרני. הנתונים יצטברו בשיעור של כ- 1 טרה-בתים בשנה, שהם לא כמות קטנה. אבל עם כוננים קשיחים של 3 טרה-בייט עכשיו נפוץ, ו RAID בקרים המשלבים כוננים פיזיים מרובים לכונן הגיוני אחד, נוכל בקלות לאחסן 10-20 שנות נתונים בכל צומת ללא יותר מדי טרחה או הוצאה.

עם זאת, הדברים נראים שונים מאוד אם אנו מאחסנים פיסות מידע גדולות יותר, כמו תיעוד סרוק. סריקת JPEG באיכות סבירה של גיליון A4 עשויה להיות בגודל 500 קילובייט. הכפלו זאת ב -500 עסקאות בשנייה, ואנחנו בוחנים תפוקה של 250 מגה בייט לשניה. זה מתורגם ל -2 ג'יגה-ביט לשנייה של רוחב הפס, שהוא מהיר יותר מרוב הרשתות המקומיות, קל וחומר חיבורים לאינטרנט. בזול שירותי האינטרנט של אמזון מחיר שפורסם של 0.05 $ לגיגה-בייט, פירושו הוא שטר רוחב פס שנתי של 400,000 $ לצומת. והיכן כל צומת יאחסן את 8000 טרה-בייט של נתונים חדשים שנוצרים מדי שנה?

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

הפיתרון המהיר

אז איך נפתור את בעיית מדרגיות הנתונים? איך נוכל לנצל את הנוטוריזציה המבוזרת של ה- blockchain לנתונים, מבלי לשכפל נתונים אלה לכל צומת בשרשרת?

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

Hashes ממלאים תפקיד מכריע בכל מחסומי החסימה, על ידי זיהוי עסקאות וחסימות ייחודיות. הם גם עומדים בבסיס האתגר החישובי במערכות הוכחה לעבודה כמו ביטקוין. פונקציות חשיש רבות ושונות פותחו, עם שמות של gobbledygook כמו BLAKE2, MD5 ו- RIPEMD160. אך בכדי שניתן יהיה לסמוך על כל פונקציית חשיש, עליה לסבול בדיקה אקדמית נרחבת ובדיקה. בדיקות אלו מגיעות בצורה של ניסיון להתקפות, כמו "preimage" (מציאת קלט עם ה- hash הנתון), "preimage second" (מציאת קלט שני עם אותו hash כמו הקלט הנתון) ו"התנגשות "(מציאת כל שתי כניסות שונות עם אותו חשיש). לשרוד את הכפפה הזו רחוק מלהיות קל, עם היסטוריה ארוכה וטרגית של פונקציות חשיש שבורות המוכיחות את המקסימום המפורסם: "אל תגלגל את הקריפטו שלך."

כדי לחזור לבעיה המקורית שלנו, נוכל לפתור את מדרגיות הנתונים במחסומי החסימה על ידי הטמעת hashes של פיסות נתונים גדולות בתוך עסקאות, במקום הנתונים עצמם. כל חשיש פועל כ"מחויבות "לנתוני הקלט שלו, כאשר הנתונים עצמם מאוחסנים מחוץ לבלוקצ'יין או" מחוץ לשרשרת ". לדוגמה, באמצעות פונקציית ה- hash הפופולרית של SHA256, ניתן לייצג תמונת JPEG של 500 קילובייט על ידי מספר 32 בייט, צמצום של מעל 15,000 ×. אפילו בקצב של 500 תמונות לשנייה, זה מחזיר אותנו בנוחות לטריטוריה של דרישות רוחב הפס האפשריות ודרישות האחסון, מבחינת הנתונים המאוחסנים בשרשרת עצמה.

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

שאלת מסירה

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

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

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

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

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

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

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

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

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

נתונים מחוץ לשרשרת ב- MultiChain 2.0

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

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

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

והכי חשוב, כל זה קורה במהירות רבה. ברשתות עם השהיה נמוכה, חתיכות קטנות של נתונים מחוץ לרשת יגיעו למנויים בתוך שבריר שנייה מהעסקה שמפנה אותם. וליישומים בעלי עומס רב, הבדיקה שלנו מעלה כי MultiChain 2.0 alpha 3 יכול לשמור על קצב של מעל 1000 פריטים מחוץ לשרשרת או 25 מגהבייט של נתונים מחוץ לשרשרת שאוחזרו בשנייה, בשרת בינוני (Core i7) עם הגון חיבור לאינטרנט. הכל עובד בסדר עם פריטים מחוץ לשרשרת בגודל של עד 1 ג'יגה-בייט, הרבה מעבר למגבלה של 64 מגה-בייט לנתונים על-שרשרת. כמובן, אנו מקווים לשפר את המספרים הללו עוד ככל שאנו מבלים זמן במיטוב MultiChain 2.0 בשלב הבטא שלה.

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

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

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

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

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

אז מה הבא?

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

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

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

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

אנא פרסם הערות ב LinkedIn.

פרטים טכניים

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

מדיניות לפני זרם. כאשר נוצר זרם MultiChain, ניתן להגביל אותו באופן אופציונלי לאפשר רק נתונים על שרשרת או מחוץ לשרשרת. ישנן כמה סיבות אפשריות לעשות זאת, במקום לאפשר לכל מפרסם להחליט בעצמם. לדוגמה, פריטים ברשת מספקים ערבות לזמינות חיפוי ברזל, ואילו פריטים ישנים מחוץ לרשת עשויים להפוך לבלתי ניתנים לשינוי אם המו"ל שלהם והמנויים האחרים יורדים מהרשת. בצד ההפוך, לא ניתן "לשכוח" פריטים בשרשרת מבלי לשנות את ה- blockchain, ואילו פריטים מחוץ לשרשרת גמישים יותר. זה יכול להיות חשוב מבחינת כללי פרטיות הנתונים, כמו תקנות ה- GDPR החדשות של אירופה.
מטא נתונים ברשת. לגבי פריטים מחוץ לשרשרת, העסקה על גבי שרשרת עדיין מכילה מפרסמים של פריטים, מפתח (ים), פורמט (JSON, טקסט או בינארי) וגודל כולל. כל זה תופס מעט מאוד מקום ועוזר למפתחי אפליקציות לקבוע האם אי הזמינות של פריט מחוץ לשרשרת מעוררת דאגה לשאילתת זרמים מסוימת.
גבול דו-הופ. כשאתה מעביר שאילתות נתח בכל הרשת של עמיתים לעמית, יש חילוף בין נגישות לביצועים. אמנם יהיה נחמד שכל שאילתה תפיץ בכל מסלול בודד, אך הדבר יכול לסתום את הרשת ב"פטפטים "מיותרים. אז לעת עתה שאילתות נתח מוגבלות לשתי כשות, כלומר צומת יכול לאחזר נתונים מחוץ לשרשרת מכל עמית מעמיתיו. ברשתות הקטנות יותר שמתחת ל 1000 צמתים הנוטים לאפיין מחסומי חסימה ארגוניים, אנו מאמינים שזה יעבוד בסדר גמור, אך קל לנו להתאים את האילוץ הזה (או להציע אותו כפרמטר) אם יתגלה כשגוי.
אחסון מקומי. כל צומת MultiChain מאחסן נתונים מחוץ לשרשרת בתוך ספריית "הנתחים" של ספריית ה- blockchain הרגילה שלה, תוך שימוש בפורמט בינארי יעיל ואינדקס LevelDB. ספריית משנה נפרדת משמשת לפריטים בכל אחד מהזרמים המנויים, כמו גם לאלה שפורסמו על ידי הצומת עצמו. בתוך כל אחת מתיקיות המשנה הללו, נתחים כפולים (עם אותו חשיש) מאוחסנים פעם אחת בלבד. כאשר צומת מבטל את ההרשמה לזרם, הוא יכול לבחור אם לנקות את הנתונים מחוץ לשרשרת שאוחזרו עבור זרם זה.
מטמון בינארי. בעת פרסום חתיכות גדולות של נתונים בינאריים, בין אם ברשת או מחוץ לרשת, יתכן וזה לא מעשי עבור מפתחי יישומים לשלוח נתונים אלה לממשק ה- API של MultiChain בבקשה JSON-RPC יחידה. כך שמיישמת MultiChain 2.0 מטמון בינארי, המאפשר לבנות חלקים גדולים של נתונים על פני שיחות API מרובות, ואז לפרסם בשלב סופי קצר. כל פריט בזיכרון המטמון הבינארי מאוחסן כקובץ פשוט בספריית המשנה "מטמון" של ספריית ה- blockchain, ומאפשר לדחוף גיגה-בייט של נתונים ישירות דרך מערכת הקבצים.
פיקוח על ממשקי API. MultiChain 2.0 alpha 3 מוסיף שני ממשקי API חדשים לניטור השליפה האסינכרונית של נתונים מחוץ לשרשרת. ממשק ה- API הראשון מתאר את המצב הנוכחי של התור, ומראה כמה נתחים (וכמה נתונים) ממתינים או נשאלים או נשלפים. ממשק ה- API השני מספק נתונים סטטיסטיים מצטברים עבור כל שאילתות הנתחים והבקשות שנשלחו מאז הפעלת הצומת, כולל ספירת סוגים שונים של כישלונות.
סמן עם פרסום. בעת פרסום פריט מחוץ לרשת, MultiChain מבטיח כי העותק המקומי של הנתונים נכתב במלואו (או "סמוק") לכונן הדיסק הפיזי לפני העסקה שמפנה כי נתונים משודרים לרשת. אחרת, אם הצומת היה חסר מזל מספיק כדי לאבד את השלטון מיד לאחר שידור העסקה, נתוני הכבלים יכולים לאבד לצמיתות. זה לא עניין של MultiChain עצמה, מכיוון שהעיכובים בין ניסיונות השליפה של נתח גדלים אוטומטית עם הזמן. אבל זה יכול לגרום לבעיות ברמת היישום, שם כולם יודעים על קיומם של נתונים מסוימים, אך איש אינו מצליח למצוא אותם.
מופע פרסום. על ידי שטיפת נתונים מחוץ לשרשרת לדיסק באופן זה, MultiChain יכול להיגרם עונש ביצועים, מכיוון שהדיסקים הפיזיים הם איטיים. לדוגמה, כונן קשיח באמצע טווח 7200 סל"ד יכול לבצע רק כמאה כתבי נתונים אקראיים בשנייה, ומגביל בתורו את הקצב בו צומת פרטנית יכולה לפרסם פריטים מחוץ לרשת. ישנן שלוש דרכים אפשריות לעקיפת הבעיה. ראשית ופשוטה ביותר, צמתים יכולים להשתמש בכונן התקני מצב מוצק (SSD) במקום בכונן קשיח רגיל, התומך ב -100 פעולות כתיבה אקראיות בשנייה. שנית, ניתן לפרסם מספר פריטים מחוץ לרשת בעסקה יחידה באמצעות ממשק ה- API של "cesserawsendfrom". במקרה זה, MultiChain כותב את כל הנתונים מחוץ לשרשרת אליהם מפנים עסקה בפעולת דיסק יחיד. לבסוף, ניתן לקבוע את התצורה של MultiChain שלא לשטוף נתונים משרשרת מחוץ לדיסק לפני ששידור העסקה המתייחס אליהם. השתמש באפשרות זו בזהירות.
שילוב מטבע הילידים. במקרי שימוש המחייבים זאת, MultiChain תמיד הציעה את האפשרות להשתמש במטבע יליד ב- blockchain כדי למנוע דואר זבל בעסקות ו / או לעודד אימות בלוק ("כורים"). במקרים אלה, על עסקאות להציע לכורים עמלה מינימלית שהיא פרופורציונאלית לגודלם בבתים, על מנת להיות מועברים ואושרים ברשת. מנגנון זה הורחב בכדי לאפשר מניעת דואר זבל מחוץ לרשת על ידי דרישה של תשלום נוסף מינימלי לכל קילובייט של נתונים מחוץ לרשת המוזכרת בעסקה.
צמתים בארכיון. אם צומת מעוניין להירשם לכל זרם, ולכן לאחסן ולאחסן כל פריט מחוץ לרשת שפורסמה, ניתן להגדיר אותו כך באמצעות פרמטר זמן הריצה "הרשמה אוטומטית". כל צומת כזה ישמש כגיבוי עבור הרשת כולה ומבטיח כי פריטים מחוץ לרשת לא יאבדו או לא יהיו זמינים, לא משנה אילו צמתים אחרים ייעלמו. אפשר לדמיין חברות צד ג 'המציעות זאת כשירות מסחרי.