האם יש ערך בבלוקצ'יין ללא cryptocurrency?
הוויכוח נמשך זמן מה, אך בחודש האחרון חלה uptick רציני. השאלה שנשאלת היא:
האם יש ערך בבלוקצ'יין ללא מטבע קריפטוגרפי? והאם בכלל ניתן לקרוא ל"חשבונות ספרים משותפים חסרי אסימון "אלה חסימות?
אז קראתי המאמר של ביילי, התבוננו הסרטון של טים, לקרוא פוסט זה של נאסד"ק, הלך בעקבות ריצ'רד כל מילהואפילו היה לי את שלי דיון טוב רוח (ראו הערות) עם כריס דרוז של קרן הצדדים. כל כך הרבה אוויר חם.
דבר אחד שכריס עושה היטב זה להרתיח את השאלה: האם הבלוקצ'יין הוא חידוש כלכלי או מדעי המחשב? המשמעות היא שאם מחסומי חסימות הם חידוש כלכלי גרידא, אין טעם לחסימת חסימות ללא cryptocururrency. אז הרשו לי להצביע על עמדתי בהתחלה:
הבלוקצ'יין של ביטקוין היה שניהם כלכליים ו חידוש במדעי המחשב.
אני מאפשר לכלול "חדשנות" כאן שילוב חדש של טכניקות קיימות, ולא משהו שאין לו תקדים כלשהו. הגדרה זו מאפשרת להחשיב את הרשת העולמית כחידוש, למרות שהיא עשתה מעט יותר משילוב היפר טקסט עם טוויסט בכמה פרוטוקולי אינטרנט קיימים. אם ברצונך לאמץ הגדרה מחמירה יותר של חדשנות, תהיה אורח שלי, אך תתפלא מכמה מעט "חידושים" אמיתיים שנותרו. לפרפרזה המורה, יש מעט חדש תחת השמש.
אם לדייק, אני טוען את זה מחסומי חסימות ללא אסימון אכן משרתים מטרה, אבל זה א מטרה שונה בהשוואה לבלוקצ'יין המקורי של הביטקוין. ראשי קריפטו צוחקים על חסימות אסימונים מכיוון שהם לא יכולים לספק התנגדות לצנזורה וביטחון מבוזר באמצעות הוכחת עבודה. ראשי פינטק צוחקים על רשתות ציבוריות מכיוון שהן איטיות, יקרות ולא מתאימות למימון מסורתי. ובכן, המשיכו לצחוק את כולם, כי אני מאמין ששניכם צודקים.
אני מתכוון לטעון כי חסימות אסימונים ללא שימוש באסימונים מועילות לשמירת מסדי נתונים מבוזרים מסונכרנים, אפילו בארגון יחיד בו יש אמון מושלם. ואז נראה אילו תכונות אחרות מציעות רשתות חסימות, ההופכות אותם למתאימים ליצירת קונצנזוס סוגים ספציפיים של עסקאות בין ארגונים, שבהם יש רק אמון מוגבל ובלתי מושלם.
למרבה הצער, כדי לעקוב אחר הוויכוח, תצטרך לחקור איתי את המודל של עסקאות הביטקוין, בקרת מספר רב של מסדי נתונים במקביל (MVCC), ובעיית פתרון הקונפליקטים בשכפול מסדי נתונים מרובי-מאסטר. אני אעשה כמיטב יכולתי לדבוק באנגלית, אך בכל זאת מדובר בדברים טכניים, ואין מנוס מכך.
מודל העסקה של ביטקוין
מודל העסקה של הביטקוין הוא פשוט אך חזק. לכל עסקת ביטקוין יש מערך תשומות ומכל תפוקות. כל קלט "מוציא" פלט אחד מעסקה קודמת. כל הביטקוין בתשומות של עסקה זורם לעסקה זו ומופץ על פני התפוקות שלו על פי הכמויות שנכתבו בתוכה. באופן זה, עסקאות יוצרות שרשרת מחוברת רב כיוונית המסתיימת בעסקאות "מטבע הבסיס" בהן נוצרים ביטקוין חדש.
לביטקוין יש כמה כללים נוספים אשר נאכפים על ידי כל צומת ברשת:
- כל קלט בעסקה חייב להוכיח שיש לו את הזכות להוציא את התפוקה הקודמת אליה היא מחוברת. זכות זו מוגבלת על ידי תנאים המקודדים בתפוקה הקודמת.
- בעסקה חייבים להיות מספיק סה"כ ביטקוין בכניסותיה כדי לכסות את סך הכתוב בתפוקותיה. החריגים היחידים הם עסקאות בסיס מטבעות היוצרים יחידות חדשות של המטבע.
- ניתן להוציא כל פלט פעם אחת בלבד, במילים אחרות, ניתן לחבר אותו רק לקלט אחד בעסקה אחת שלאחר מכן.
בגלל הכלל האחרון הזה, הרשת דורשת מנגנון להשגת הסכמה לגבי אילו עסקאות תקפות, וזה מה שעושה הבלוקצ'יין. במיוחד:
אם שתי עסקאות מנסות להוציא את אותה התפוקה, בסופו של דבר רק אחת מאותן עסקאות תתקבל. בלוקצ'יין משמש כמנגנון אחיד לאיתור ולמניעת התנגשויות אלה ברחבי הרשת.
הבלוקצ'יין בנוי כסדרה של בלוקים מקושרים, בהם כל בלוק מכיל קבוצת עסקאות שאינן מתנגשות זו עם זו או עם חסימות קודמות, החל מהבלוק הראשון שנוצר בשנת 2009. בתיאוריה, הרשת יכולה להכיל סדרה של עסקאות אינדיבידואליות, אך על ידי קיבוץ עסקאות לבלוקים אנו משיגים מספר יעילות שהופכות את התוכנית לפרקטית יותר.
אז מה מטרתו של cryptocurrency בכל זה? זה בא לשאלה מי מחליט על הבלוקים המהווים את השרשרת. ביטקוין מבוזר ואין לו שום סמכות שיכולה לקבל החלטה זו, ולכן היא צריכה למצוא דרך אחרת להגיע להסכמה.
אנו עשויים לרצות להשתמש בגישה דמוקרטית, בה הצמתים ברשת מצביעים על בלוקים, והרוב מנצח. למרבה הצער, כפי שכל סקר אינטרנטי יכול להוכיח, דמוקרטיה מייצגת אינה אפשרית ברשת, בגלל בעיית ההתחזות (הידועה גם כ התקפת סיביל). אדם אחד יכול להשתלט על מיליון מחשבים ולהחליט כיצד הם מצביעים, וכך לתפוס את השליטה בקונצנזוס הרשת. אף אחד אחר אפילו לא יידע שזה קרה.
כדי לפתור את זה, הביטקוין מקשה בכוונה להוסיף חסימה לרשת, באמצעות תהליך שנקרא "כרייה". כדי ליצור בלוק עליכם לפתור בעיה מתמטית קשה אך חסרת טעם, הדורשת חישוב רב (ולכן חשמל וכסף). אתה גם צריך קצת מזל, מכיוון שאתה בתחרות עם כורי בלוק רבים אחרים ברחבי העולם. אינך יכול להתקדם זמן רב על ידי רכישת מחשב כרייה חזק יותר, מכיוון שהרשת מתאימה באופן קבוע את קושי הבעיה לשמור על קצב גלובלי יציב של בלוק אחד ל -10 דקות.
אם כל כך קשה ויקר ליצור בלוק, למה שמישהו יטרח? התשובה היא בתגמול הגוש. הכורה המצליח של בלוק שולט בעסקת מטבע הבסיס שמעניקה להם 25 ביטקוין (סכום זה מחצית כל ארבע שנים). הם יכולים למכור את הביטקוינים האלה בשוק הפתוח תמורת 7,000 דולר (בקצב של היום), לשלם את חשבון החשמל שלהם ולקוות לכיס קצת רווח. כורים גובים גם תוספת קטנה מדמי שמצורפים לעסקאות, אם כי לעת עתה אלה משחקים תפקיד משני.
אז ביטקוין מייצר הסכמה באמצעות הוכחת עבודה ועיקר הוויכוח של ראשי הביטקוין הוא זה: ללא cryptocurrency אין דרך לתמרץ כריית בלוקים מבוזרת. לכן אין דרך להבטיח בלוקצ'יין פתוח מפני התקפות התחזות. לכן כל אחד יכול למונופול את הקונצנזוס ברשת ולהפוך את כל העניין לחסר תועלת. אני לא אתווכח עם כל זה.
שליטה מקבילית multiversion
בינתיים אני רוצה לדבר על משהו שאולי נראה שאינו קשור לחלוטין.
מסד נתונים הוא מאגר של מידע מובנה, המקובץ לגופים דמויי גיליונות אלקטרוניים הנקראים טבלאות. דוגמה פשוטה לטבלה כזו היא רשימה של חשבונות בנק, שבה כל שורה מכילה מספר חשבון יחד עם היתרה של אותו חשבון. נניח שהחשבון שלך מתחיל את היום ביתרה של 900 דולר. כיום מתוכנן תשלום משכנתא אוטומטי בסך 750 דולר וצריך למשוך 400 דולר מכספומט. לרוע המזל אין לך מתקן משיכת יתר ולכן אחת מהפעולות הללו מוגדרת להיכשל.
התהליכים לתשלומי משכנתא ולמשיכת כספומטים פועלים במערכות נפרדות, שניהם ניגשים למאגר חשבונות יחיד זה. בואו נגיד שכל תהליך עובד על ידי קריאת היתרה בחשבונכם, בדיקה שהיא מספיקה לצורך הפעולה, התחלת פעולה זו, אימות השלמת הפעולה, חישוב היתרה החדשה ואז לבסוף כתיבת המסד.
כל עוד תשלום המשכנתא ומשיכת הכספומט שלך אינם חופפים, ההיגיון הזה יעבוד בסדר. הפעולה הראשונה תבוצע בהצלחה, והשנייה תבוטל מכיוון שאין מספיק חשבונות בחשבונך. בהתאם להזמנה, תקבל שיחת טלפון זועמת מהבנק או הודעה גסה במסך הכספומט.
אך מה קורה אם שני התהליכים מתחילים במקביל? במקרה זה, כל אחד יקרא את יתרת חשבונך ויראה את זה מספיק כדי להמשיך. לאחר השלמת תשלום המשכנתא, היתרה החדשה שלך תחושב כ -150 דולר ותכתב למסד הנתונים. לאחר השלמת משיכת הכספומט, היתרה החדשה שלך בסך 500 $ תיכתב באופן דומה. אחת מפעולות הכתיבה הללו תעקוף את השנייה ובהתאם למזלכם תקבלו בונוס של 750 דולר או 400 דולר. אין ספק שתלמד בקרוב לתזמן את ביקורי כספומט ליום המשכנתא.
כמובן, זה לא קורה במציאות בגלל טכנולוגיית מסד נתונים שנקראת בקרת מקביליות. בקרת מקבילות שומרת על הנתונים שלנו (במיוחד פיננסיים) שפויה ובטוחה, והיא מגיעה בצורות רבות. אך כולם חולקים את העיקרון שפעולות בסיס הנתונים מקובצות ל"עסקאות ", המטופלות באטומיקה, כלומר הן מצליחות או נכשלות בכללותן. המקביליות שומרת על עקביות על ידי נעילה או הקפאה של חלקים ממסד נתונים בזמן שהם נמצאים בשימוש על ידי עסקה אחת, כדי למנוע מעסקאות אחרות לפעול על אותו מידע בצורה סותרת.
אם לא היינו צריכים להפעיל עסקאות במקביל, נוכל לנעול את מסד הנתונים כולו למשך כל תקופת העסקה. עם זאת זה לא מעשי ברוב היישומים בעולם האמיתי. תכנית בקרת מקבילות טובה מאפשרת פעולות מקבילות על ידי נעילת כמה שפחות נתונים לזמן קצר ככל האפשר. בדוגמה שלמעלה, רק שורת מסד הנתונים המתאימה לחשבונך תינעל, ורק לשבריר השנייה בה נערך בדיקה וסכום אחרון. עסקה סותרת הפועלת במקביל תצטרך פשוט להמתין עד לשחרור נעילה זו.
נקראת טכניקת בקרת מקביליות אחת פופולרית שליטה במקביל לרבויות, או בקיצור MVCC. ב- MVCC, כל עסקה רואה תמונת מצב עקבית של הנתונים בנקודת זמן מסוימת, גם אם חלק מאותם נתונים נמצא בתהליך עדכון על ידי עסקה בו זמנית שניה. זֶה בידוד תמונה המאפיין מבטיח, למשל, כי הצהרה המציגה את היתרה הכוללת שלנו במספר חשבונות תהיה תמיד נכונה, גם אם כמה כספים נמצאים בתהליך מעבר מחשבון אחד למשנהו. עסקה אחת תשפיע על הנתונים שרואים בעסקה שנייה רק אם השנייה תתחיל לאחר שהשינויים הראשונים יושמו בהצלחה.
מאחורי הקלעים, MVCC עובד בכך שהוא מאפשר לשמור על מספר גרסאות של שורה בו זמנית, לצד חותמת זמן המייצגת את תאריך השינוי האחרון של כל גרסה. שינוי שורה של מסד נתונים ב- MVCC מסמן את הגרסה הנוכחית של אותה שורה למחיקה, תוך החלת השינוי על עותק של השורה ההיא עם חותמת זמן מעודכנת. מנקודת המבט של שכבת האחסון של מסד הנתונים, אין דבר כזה לשנות שורה במקום. כל עסקה יודעת בדיוק מתי התחילה, ורואה רק גרסאות של שורות שחותמת הזמן שלהן קודמת לאותה תקופה. גרסאות ישנות של שורות ניתנות להסרה מהאחסון ברגע שאין עסקאות שוטפות שעשויות להזדקק לגישה אליהן.
חשוב מאוד לענייננו כאן, MVCC מונע עימותים בין פעולות הכתיבה. במיוחד:
אם שתי עסקאות מנסות למחוק את אותה גרסת שורה, בסופו של דבר רק אחת מעסקאות אלה תתקבל. בקרת מקבילות רב-צדדית משמשת כמנגנון אחיד לאיתור ומניעת התנגשויות אלה בתוך מסד נתונים.
לצלצל לפעמונים? יש עוד פיסת רקע אחת שאנחנו צריכים לדון בה.
שכפול מסדי נתונים רב-מאסטר
עכשיו בואו נדבר על שכפול מסד נתונים, בו קיים מסד נתונים במספר עותקים. ישנן מספר סיבות טובות לשכפל מסד נתונים, כגון:
- כדי להגדיל את האמינות, כך שאם עותק אחד של מסד הנתונים יאבד (למשל בגלל כשל בדיסק), נוכל לעבור מייד לעותק שני.
- כדי להגדיל את התפוקה, אם נפח הפעולות עולה על הקיבולת של שרת מסד נתונים יחיד.
- כדי להפחית את החביון, כך שתהליכים הפועלים במשרד בסינגפור אינם צריכים לחכות לתגובות ממסד הנתונים היושב בטורונטו.
כשמדובר קריאה נתונים ממאגרי נתונים, שכפול הוא טכניקה אידיאלית, מכיוון שכל העותקונים מכילים אותו מידע. עם זאת הדברים נעשים מדביקים יותר כשמדובר בפעולות כתיבה, מכיוון שאנו צריכים להחליט היכן מבוצעות פעולות הכתיבה הללו וכיצד הם מועברים לעותקים אחרים של מסד הנתונים.
התשובה הנפוצה ביותר היא שימוש בשכפול מאסטר-עבדים, שבו מסד נתונים יחיד ("המאסטר") נחשב סמכותי. כל שינוי בנתונים מתבצע באופן בלעדי על המאסטר ואז זולג לכל מאגרי ה"עבדים "האחרים באמצעות יומן עסקאות. זה שומר על כל עותקי מסד הנתונים (פחות או יותר) מסונכרנים באופן מיידי.
למרבה הצער, אם פעולות כתיבה הן תכופות, שכפול מאסטר-עבד מחזיר אותנו ישר לבעיה שהשכפול נועד לפתור. מסד הנתונים הראשי הופך לצוואר בקבוק מבחינת אמינות, תפוקה וחביון, שכן כל פעולת כתיבה מתבצעת בו בלבד.
אסטרטגיה מורכבת יותר נקראת שכפול רב-מאסטר, בה ניתן לבצע כתיבה בכל אחד מעותקי מסד הנתונים, ולא על מאסטר יחיד. במקרה זה, העותקים חולקים עדכונים זה עם זה באופן עמית לעמית על מנת להישאר מסונכרנים.
זה נשמע פשוט בתיאוריה, אך שכפול רב-מאסטר מציג בעיה חדשה מכיוון שיכולים להתעורר קונפליקטים. מה אם שני עותקים של מסד נתונים מעדכנים את אותה השורה בו זמנית, ואז מנסים להחליף עדכונים אלה זה עם זה? שני מאגרי המידע יבחינו כי התרחש עדכון מנוגד, והם חייבים להחיל איזו אסטרטגיה מוסכמת לפתרון סכסוכים אלה. וכאן הדברים מקבלים די מורכב - ראה מסמכים עבור MySQL, שרת SQL or אורקל עבור כמה דוגמאות לאסטרטגיות ליישוב סכסוכים. (אני מתעלם משכפול רב-מאסטר סינכרוני או כביכול "להוט", שבו כל העתקים חייבים להתחייב לפעולת כתיבה לפני שהיא יכולה להתרחש, כי זה הופך כל העתק של מסד הנתונים לצוואר בקבוק.)
אז לכאן מוביל כל הרקע הזה:
האם זה לא יהיה נחמד אם היינו יכולים להפיץ בקרת רב-גוניות במקביל, כדי למנוע התנגשויות בשכפול רב-מאסטר?
ובכן, כן, אני מתאר לעצמי שזה יהיה מאוד נחמד. ואני מאמין שזה בדיוק מה שעושים רשתות חסימות.
מחזיקי חסימות כמפיצים MVCC
בואו להעתיק כמה משפטים שכתבתי מודגשים לעיל:
אם שתי עסקאות מנסות לבצע לבלות אותו דבר תפוקה, אז רק אחת מאותן עסקאות תתקבל בסופו של דבר. בלוקצ'יין פועל כמנגנון אחיד לגילוי ומניעה של סכסוכים אלה ברחבי הרשת.
אם שתי עסקאות מנסות לבצע להסיר אותו דבר גרסת שורה, בסופו של דבר רק אחת מהעסקאות האלה תתקבל. שליטה מקבילית multiversion פועל כמנגנון אחיד לגילוי ומניעה של סכסוכים אלה בתוך מסד נתונים.
משפטים אלה זהים למעט המונחים המודגשים. אז הנה מה שאני מתכוון לטעון:
בלוקצ'יין מספק MVCC מבוזר (עם כמה פעמונים ושריקות נוספות).
בואו נברג את ההשוואה עוד קצת. מנקודת מבט של צומת בלוקצ'יין, הסט הנוכחי של תפוקות עסקאות ביטקוין שלא הוצאו מהווה בסיס נתונים, שבו כל שורה היא פלט יחיד שלא הוצא. זה דומה למאגר חשבונות הבנק שתיארנו קודם, עם ההבדל הקטן שניתן לחלק את היתרה של כל חשבון על פני מספר שורות, שכל אחת מהן מסומנת באותו מספר חשבון.
עסקת ביטקוין מוציאה אחת או יותר מהתפוקות הללו ויוצרת כתוצאה אחת או יותר תפוקה חדשה. זה בדיוק כמו עסקת מסד נתונים שמוחקת גרסת שורה אחת או יותר, ויוצרת שורה אחת או יותר כתוצאה מכך (זכרו שב- MVCC אין דבר כזה לשנות שורה במקום). הבלוקצ'יין של הביטקוין מבטיח שלא ניתן להוציא פלט יחיד ביותר מעסקה אחת. זה שווה ערך להבטחה שלא ניתן למחוק גרסת שורה אחת על ידי יותר מעסקת מסד נתונים אחת.
לפני שאנחנו נסחפים, אני לא טוען שבלוק-שורשים הם טכנולוגיה נהדרת למטרות כלליות לסינכרון מסדי נתונים מבוזר בסביבה אמינה לחלוטין. יש הרבה טכנולוגיות אחרות כגון Paxos, רפסודה ו התחייבות דו-שלבית שמבצעים את העבודה יפה מאוד. אבל אני כן מאמין שלבלוקצ'ינים יש נקודה מתוקה, שניתן לאפיין כיישומים שבהם:
- אנו יכולים לקבל עיכוב קצר בין סביר להניח שעסקה מתקבלת למצב שהיא בהחלט מתקבלת. (עיכוב זה יכול להיות עניין של שניות ולא של 10 דקות כמו בביטקוין).
- עסקאות סותרות לעולם לא צריכות להתרחש אם כולם היו כנים והמערכות שלהם מתפקדות כראוי.
- כל עסקה משנה מספר שורות בו זמנית (אחרת לעסקאות הבלוקצ'יין שלנו יש מספר קלט לא מבוטל).
- הגודל של כל שורת מסדי נתונים הוא קטן למדי (שוב, כדי למנוע מביצוע פעולות הבלוקצ'יין שלנו).
כל הקריטריונים הללו מתקיימים על ידי בקשות פיננסיות. העולם הפיננסי כבר רגיל לעיכובים (של עד 3 ימים!) בין ביצוע עסקה להסדרתה הסופית. מבחינת מניעת סכסוכים, יש בו חוזים ותקנות לאיתור הונאה, וההשלכות עלולות להיות קשות. וכמות הנתונים המעורבים בכל עסקה די קטנה - חשוב על הדוגמה של חשבון הבנק לעיל.
עד כה, כל מה שהוכחתי הוא שבלוק-צ'יינס הם עוד מנגנון סנכרון למאגרי מידע מבוזרים. וואו גדול. הדברים רק מעניינים כאשר אנו רואים בתכונות הנוספות שמציעות רשתות חסימות.
מחסומי חסימות מעבר ל- MVCC
עסקת ביטקוין עושה הרבה יותר מסתם להצביע על כמה תפוקות עסקאות קודמות וליצור כמה חדשות במקומן. אפילו עסקת הביטקוין הפשוטה ביותר משרתת שתי מטרות נוספות.
ראשית, הכללים בדבר עסקאות תקפות מכילים חלק מהלוגיקה היישומית של מאגר חשבונותינו. נזכיר כי הכמות הכוללת של הביטקוין בתשומות העסקה חייבת לכסות את הכמות הכוללת בתפוקות. מתורגם לוגיקה של יישומי מסד נתונים, זהו כלל הקובע כי עסקאות בסיסי נתונים (למעט בסיסי מטבעות) אינן מורשות להגדיל את כמות הביטקוין הכוללת במסד הנתונים. סוג זה של אילוץ חורג ממסד הנתונים הרגיל פרוצדורות מאוחסנות מכיוון שלא ניתן לעקוף אותו בשום פנים ואופן.
שנית, זכרו שכל פלט של עסקת ביטקוין מקודד את התנאים שבהם ניתן להוציא אותו. עבור תפוקות ביטקוין רגילות, מצב זה מבוסס על הצפנת מפתח ציבורי. כתובת ציבורית משובצת בתוך "סקריפט" הפלט כך שניתן לבזבז אותה רק באמצעות המפתח הפרטי המתאים לאותה כתובת ציבורית. אם אנו רואים בפלט זה שורה של מסדי נתונים, מה שיש לנו הוא מסד נתונים עם הרשאות לכל שורה המבוססות על הצפנת מפתח ציבורי. יתר על כן, כל עסקה מציגה הוכחה הניתנת לביקורת ציבורית כי היוצרים שלה היו רשאים למחוק / לשנות את השורות הקודמות שלה. זהו (אני מאמין) חידוש אמיתי בטכנולוגיית מסדי נתונים.
ושוב, כל כך קורה ששתי התכונות הללו שימושיות להפליא ליישומים פיננסיים. אנו אוהבים את העובדה שמאגר המידע שלנו מבטיח, ברמה הנמוכה ביותר האפשרית, שלא ניתן ליצור כסף יש מאין. ואנחנו אוהבים שיש מסלול ביקורת בלתי ניתן למניעה המדגים שכל עסקה אושרה על ידי בעל הכספים שהועברה. כפי ש נדון כאן בפירוטאנו עשויים למצוא חן בעינינו גם לבצע עסקאות חילופי עמיתים בין עמיתים בטוחים (מסירה מול תשלום בשיחת כספים) מבלי שנדע אפילו מה זהות הצד שכנגד שלנו.
אז איפה האסימון?
כמובן, כל זה אינו צירוף מקרים, מכיוון שהביטקוין עצמו הוא יישום פיננסי של עמית לעמית יפה. ובכל זאת, אף אחד מהמאפיינים הנ"ל של בלוקצ'יין אינו תלוי באסימון כלל. אם נשנה את סכימת "מסד הנתונים" שלנו כך שכל שורה תוכל לייצג מספר נכסים במקום את המטבע המקורי של הבלוקצ'יין, נוכל להיפטר מהמטבע הזה לחלוטין. זה משאיר אותנו עם בלוקצ'יין כדרך להשיג קונצנזוס וביטחון ביישום כספי של עמית לעמית כל סוג של נכס.
אבל רק שאלה אחת קטנה: מי עושה את הכרייה כדי ליצור הסכמה זו? בביטקוין כורים אנונימיים חייבים לבצע חישובים חסרי תועלת יקרים, והם מתמריצים לעשות זאת על ידי תגמולי החסימה (ודמי העסקה) הנקובים במטבע המקורי או באסימון של הבלוקצ'יין. האם יש לנו אפשרויות אחרות?
מתברר שאנחנו כן. אנו יכולים לקבל רשימה סגורה של כורים מורשים, המזהים את עצמם על ידי חתימה על הבלוקים שהם יוצרים. כללים לגבי קונצנזוס מבוזר (או "מגוון כרייה" כפי שאנו מכנים אותו MultiChain) מספקים דרך אחרת למניעת שליטת מיעוטים בבלוקצ'יין, כל עוד תוכלו לקבל שכורים אושרו מראש. כמובן שבביטקוין זה לא מקובל, כי חלק מהעניין הוא לאפשר כרייה אנונימית, כך שאין שום דרך לצנזר עסקאות באופן מרכזי. אבל אם, נניח, הייתה לנו מערכת פיננסית מוסדרת מאוד, שבה המודל של הביטקוין לא היה תקף, אולי בכל זאת נוכל לקבל רשימה של כורים שאושרה מראש? אם היה לנו מספיק מהם, ונפיץ אותם מספיק טוב בין המוסדות, והיה לנו חוזים משפטיים עם כולם, האם הם באמת עשויים להתקבץ ולערער את הרשת בה הם תלויים, כאשר פעולה זו תביא אותם לכלא?
אֶפִּילוֹג
אני מקווה שהוכחתי שלחסימות ללא אסימונים יש כמה יישומים שימושיים, גם אם אלה שונים מאוד מבלוקצ'יין הביטקוין. בכל זאת נותרה שאלה אחת:
האם מדובר במערכות ספרים משותפות מורשות ונטולות אסימונים באמת ראויות לשם "בלוקצ'יין"?
התשובה הקצרה היא: למי אכפת? לעתים רחוקות כדאי להתווכח על משמעות המילים, כי יש אין תשובה נכונה.
אבל כדי להעמיק קצת יותר, נניח שאני מקבל את ההנחה שהבלוקצ'יין של הביטקוין הוא הבלוקצ'יין הארכיטיפי. במקרה זה, מה שאנחנו באמת צריכים לשאול הוא:
האם ספרים ספרים משותפים אלה דומים מספיק לביטקוין כדי לזכות בשם "בלוקצ'יין"?
ההשקפה האישית שלי כאן היא כן. מכיוון שהם חולקים מספר עצום של קווי דמיון טכניים, גם אם הם שונים במודל ההרשאות והתמריצים הכלכליים. והכי חשוב, משום ששניהם מייצרים קונצנזוס במאגר מידע מבוזר באמצעות א שרשרת בלוקים.
תודה שקראת.
אתה יכול עקוב אחרי בטוויטר כאן. ראה גם: משלוח מול תשלום באמצעות blockchain.
להלן מספר יצירות נוספות שכדאי לקרוא בנושא זה מאת פיוטר פיאסקי ו דאג קמפבל.
