שלושת התפיסות השגויות החכמות הנפוצות ביותר
כמפתחים של פלטפורמת blockchain פופולרית, אנו נשאלים לפעמים האם חוזים חכמים כמו Ethereum קיימים MultiChain מפת דרכים. התשובה שאני תמיד נותנת היא: לא, או לפחות עדיין לא.
אבל בעולם המלא של ההייפ של blockchains, חוזים חכמים הם כל הזעם, אז למה בכלל לא? ובכן, הבעיה היא, שכעת אנו יודעים על שלושה מקרי שימוש חזקים עבור רשימות חסימות בסגנון ביטקוין (מקור, רשומות בין חברות ומימון קל), עדיין לא נמצא את המקבילה לחוזים חכמים בסגנון אתרום.
זה לא שלאנשים חסרים רעיונות מה הם רוצים שחוזים חכמים יעשו. במקום זאת, זה כל כך הרבה מהרעיונות האלה הם פשוט בלתי אפשריים. אתה מבין, כשאנשים חכמים שומעים את המונח "חוזים חכמים", דמיונם נוטה להשתולל. הם מעלים חלומות על תוכנה אינטליגנטית אוטונומית, יוצאים לעולם, לוקחים את הנתונים שלה לנסיעה.
למרבה הצער המציאות של חוזים חכמים היא הרבה יותר ארצית מכל זה:
חוזה חכם הוא פיסת קוד המאוחסנת ב- blockchain, המופעלת על ידי עסקאות blockchain, וקוראת וכותבת נתונים במסד הנתונים של blockchain.
זהו זה. בֶּאֱמֶת. חוזה חכם הוא רק שם מפואר לקוד הפועל על blockchain, ומתקשר עם מצבו של אותו blockchain. ומה is קוד? זה פסקל, זה פייתון, זה PHP. זה Java, זה Fortran, זה C ++. אם מדובר במאגרי מידע, זה פרוצדורות מאוחסנות כתוב בתוסף של SQL. כל השפות הללו שוות ערך במהותן, ופותרות את אותם סוגים של בעיות באותה מיני דרכים. כמובן שלכל אחד יש את נקודות החוזק והחולשה שלו - הייתם משוגעים לבנות אתר ב- C או לדחוס וידאו HD ברובי. אבל לפחות באופן עקרוני, הייתם יכולים אם תרצו. פשוט תשלמו מחיר כבד מבחינת הנוחות, הביצועים, וכנראה שגם השיער שלכם.
הבעיה עם חוזים חכמים אינה רק שהציפיות של האנשים מוגזמות מדי. זה שהציפיות הללו מובילות לרבים לבזבז זמן וכסף על רעיונות שאי אפשר ליישם. נראה שלחברות גדולות יש משאבים מספיקים כדי לעבור מסלול ממושך - מרגע שההנהלה הבכירה נתקלת בטכנולוגיה חדשה, וכלה בה מובנים באמת את היתרונות והמגבלות של אותה טכנולוגיה. אולי החוויה שלנו יכולה לעזור לקצר את הזמן הזה.
במהלך תשעת החודשים האחרונים הוצגנו מקרים רבים של שימוש בחוזה חכמים ומצאנו את עצמנו מגיבים שוב ושוב שהם פשוט לא יכולים להיעשות. כתוצאה מכך, זיהינו את שלושת התפיסות השגויות של החוזה החכם הנפוצות ביותר. רעיונות אלה אינם שגויים מכיוון שהטכנולוגיה אינה בשלה או שהכלים עדיין אינם זמינים. במקום זאת, הם לא מבינים את העניין תכונות יסודיות של קוד שחיה בבסיס נתונים ופועל בצורה מבוזרת.
פנייה לשירותים חיצוניים
לעתים קרובות, מקרה השימוש הראשון שהוצע הוא חוזה חכם שמשנה את התנהגותו בתגובה לאירוע חיצוני כלשהו. לדוגמה, פוליסת ביטוח חקלאית שמשלמת על תנאי בהתבסס על כמות המשקעים בחודש נתון. התהליך המדומיין הולך כדבר הזה: החוזה החכם ממתין עד לשעה שנקבעה מראש, מאחזר את דוח מזג האוויר משירות חיצוני ומתנהג כראוי על סמך הנתונים שהתקבלו.
הכל נשמע די פשוט, אבל זה גם בלתי אפשרי. למה? מכיוון ש- blockchain היא מערכת מבוססת קונצנזוס, כלומר היא עובדת רק אם כל צומת מגיע למצב זהה לאחר עיבוד כל עסקה וחסימה. כל מה שמתרחש על גבי blockchain חייב להיות דטרמיניסטי לחלוטין, ללא דרך אפשרית להתגנב בין ההבדלים. ברגע ששני צמתים כנים חולקים על מצבה של הרשת, המערכת כולה הופכת חסרת ערך.
זכור כעת כי חוזים חכמים מבוצעים באופן עצמאי על ידי כל צומת בשרשרת. לכן, אם חוזה חכם מאחזר מידע מסוים ממקור חיצוני, אחזור זה מבוצע שוב ושוב ונפרד על ידי כל צומת. אך מכיוון שמקור זה נמצא מחוץ לבלוקצ'יין, אין שום ערובה לכך שכל צומת יקבל את אותה התשובה. אולי המקור ישנה את תגובתו בזמן שבין בקשות מצמתים שונים, או אולי הוא יהפוך לזמין באופן זמני. כך או כך, הקונצנזוס נשבר וכל הבלוקצ'יין מת.
אז מה הדרך לעקיפת הבעיה? למעשה, זה די פשוט. במקום חוזה חכם שיוביל לאחזור נתונים חיצוניים, גורם אחד או יותר מהימנים ("אורקלות") יוצר עסקה המטמיעה נתונים אלה בשרשרת. לכל צומת יהיה עותק זהה של נתונים אלה, כך שניתן להשתמש בהם בבטחה בחישוב חוזה חכם. במילים אחרות, אורקל דוחף הנתונים על ה- blockchain ולא על חוזה חכם מושך זה ב.
כשמדובר בחוזים חכמים הגורמים לאירועים בעולם החיצוני, מופיעה בעיה דומה. לדוגמה, רבים אוהבים את הרעיון של חוזה חכם שמתקשר לממשק ה- API של הבנק כדי להעביר כסף. אבל אם כל צומת מבצע באופן עצמאי את הקוד בשרשרת, מי אחראי לקרוא לממשק ה- API הזה? אם התשובה היא רק צומת אחד, מה קורה אם התקלות הספציפית בצומת ההוא, במכוון או לא? ואם התשובה היא כל צומת, האם נוכל לסמוך על כל צומת עם הסיסמה של אותו ממשק API? והאם אנחנו באמת רוצים שממשק ה- API נקרא מאות פעמים? חמור מכך, אם החוזה החכם צריך לדעת אם שיחת ה- API הייתה מוצלחת, אנו חוזרים לבעיה של תלוי בנתונים חיצוניים.
כמו קודם, ניתן לעקיפת הבעיה הפשוטה. במקום שהחוזה החכם יקרא ממשק API חיצוני, אנו משתמשים בשירות מהימן המפקח על מצבו של הבלוקצ'יין ומבצע פעולות מסוימות בתגובה. לדוגמה, בנק יכול לצפות באופן יזום ב- blockchain, ולבצע העברות כספים המשקפות את העסקאות ברשת. זה לא מהווה שום סיכון לקונצנזוס של הבלוקצ'יין מכיוון שהשרשרת ממלאת תפקיד פסיבי לחלוטין.
אם מסתכלים על שני דרכים לעקיפת הבעיה, נוכל לבצע כמה תצפיות. ראשית, שניהם דורשים יישות מהימנה שתנהל את האינטראקציות בין הבלוקצ'יין לעולם החיצון. אמנם זה אפשרי מבחינה טכנית, אך הוא מערער את המטרה של מערכת מבוזרת. שנית, המנגנונים המשמשים לעקיפת הבעיה הם דוגמאות פשוטות ל קריאה וכתיבת בסיס נתונים. אורקל המספק מידע חיצוני הוא פשוט כתיבת מידע זה לשרשרת. ושירות שמשקף את מצבו של הבלוקצ'יין בעולם האמיתי אינו עושה אלא לקרוא מהשרשרת ההיא. במילים אחרות, כל אינטראקציה בין blockchain לעולם החיצוני מוגבלת לפעולות בסיסיות של מסד נתונים. נדבר יותר על עובדה זו בהמשך.
אכיפת תשלומים ברשת
הנה הצעה נוספת שאנחנו נוטים לשמוע הרבה: שימוש בחוזה חכם לאוטומציה של תשלום קופונים עבור מה שנקרא "אג"ח חכם". הרעיון הוא שקוד החוזה החכם יתחיל אוטומטית את התשלומים במועדים המתאימים, ימנע מתהליכים ידניים ויבטיח שהמנפיק לא יכול להחליף.
כמובן שכדי שזה יעבוד, הכספים המשמשים לביצוע התשלומים חייבים לחיות גם בתוך הבלוקצ'יין, אחרת חוזה חכם לא יכול להבטיח את תשלומם. זכרו כי blockchain הוא רק בסיס נתונים, במקרה זה ספר חשבונות פיננסי המכיל את האג"ח שהונפקה וכמה מזומנים. אז כשאנחנו מדברים על תשלומי קופונים, מה שאנחנו מדברים עליהם למעשה הם פעולות בסיס נתונים שמתקיימות אוטומטית בזמן מוסכם.
אמנם אוטומציה זו אפשרית מבחינה טכנית, אך היא סובלת מקושי כלכלי. אם הכספים המשמשים לתשלומי קופון נשלטים על ידי החוזה החכם של האג"ח, ניתן אכן להבטיח אותם תשלומים. אבל זה אומר גם הכספים האלה מנפיק האג"ח לא יכול לשמש שום דבר אחר. ואם הכספים האלה הם לא בשליטת החוזה החכם, אם כן אין דרך להבטיח תשלום.
במילים אחרות, אג"ח חכם הוא חסר טעם עבור המנפיק, או חסר טעם עבור המשקיע. ואם אתה חושב על זה, זו תוצאה ברורה לחלוטין. מנקודת מבט של משקיע, כל נקודת האג"ח היא שיעור התשואה האטרקטיבי שלה, במחיר של סיכון מסוים לברירת מחדל. ולמנפיק, מטרת האג"ח היא לגייס כספים לפעילות יצרנית אך מסוכנת במקצת, כמו הקמת מפעל חדש. מנפיק האג"ח לא יכול לעשות שימוש בכספים שגויסו, ובמקביל להבטיח כי המשקיע יפרע. זה לא אמור להפתיע את זה הקשר בין סיכון לתשואה אינו בעיה שרוכסי חסימות יכולים לפתור.
הסתרת נתונים חסויים
כמו שעשיתי נכתב בעבר, האתגר הגדול ביותר בפריסת רשתות חסימות הוא השקיפות הרדיקלית שהם מספקים. לדוגמה, אם עשר בנקים מקימים יחד blockchain, ושניים מבצעים עסקה דו צדדית, זה יהיה גלוי מייד לשמונה האחרים. אמנם קיימות אסטרטגיות שונות להפחתת בעיה זו, אך אף אחת מהן לא גברה על הפשטות והיעילות של בסיס נתונים ריכוזי, בו מנהל מהימן יש שליטה מלאה על מי שיכול לראות מה.
יש אנשים שחושבים כי חוזים חכמים יכולים לפתור את הבעיה הזו. הם מתחילים בעובדה שכל חוזה חכם מכיל בסיס נתונים מיניאטורי משלו, עליו יש שליטה מלאה. כל פעולות הקריאה והכתיבה במאגר זה מתווכים על ידי קוד החוזה, מה שמאפשר לחוזה אחד לקרוא את הנתונים של אחר באופן ישיר. (הצימוד ההדוק הזה בין נתונים לקוד נקרא אנקפסולציה, והוא הבסיס לפופולרי תכנות מונחה עצמים פרדיגמה.)
אז אם חוזה חכם אחד לא יכול לגשת לנתונים של אחר, האם פתרנו את בעיית הסודיות של blockchain? האם זה הגיוני לדבר על הסתרת מידע בחוזה חכם? למרבה הצער, התשובה היא לא. מכיוון שגם אם חוזה חכם אחד לא יכול לקרוא נתונים של אחר, נתונים אלו עדיין נשמרים בכל צומת בודדים בשרשרת. עבור כל משתתף ב- blockchain, זה בזיכרון או בדיסק של a מערכת אותה משתתף לחלוטין. ואין שום דבר שימנע מהם לקרוא את המידע מהמערכת שלהם, אם ומתי הם בוחרים לעשות זאת.
הסתרת נתונים בחוזה חכם היא בטוחה כמעט כמו הסתרתם בקוד ה- HTML של דף אינטרנט. בטוח שמשתמשי אינטרנט רגילים לא יראו את זה, מכיוון שהוא לא מוצג בחלון הדפדפן שלהם. אך כל מה שנדרש הוא לדפדפן אינטרנט להוסיף פונקציה של 'הצג מקור' (כפי שיש לכולם), והמידע הנסתר הופך לגלוי באופן אוניברסלי. באופן דומה, לגבי נתונים המסתתרים בחוזים חכמים, כל מה שנדרש הוא שמישהו ישנה את תוכנת הבלוקצ'יין שלו כדי להציג את מצבו המלא של החוזה, וכל מראית החשאיות הולכת לאיבוד. מתכנת הגון למחצה יכול לעשות זאת תוך שעה בערך.
בשביל מה חוזים חכמים מיועדים
עם כל כך הרבה דברים שחוזים חכמים לא יכולים לעשות, אפשר לשאול למה הם בעצם נועדו. אבל כדי לענות על שאלה זו, עלינו לחזור ליסודות של מחסומי החסם עצמם. לסיכום מחדש, blockchain מאפשר שיתוף של בסיס נתונים באופן ישיר ובטוח על ידי גורמים שאינם סומכים זה על זה, מבלי לדרוש מנהל מרכזי. שרשראות חסימות מאפשרות התפלגות נתונים, וזה יכול להביא לחיסכון משמעותי במורכבות ובעלות.
כל מסד נתונים משתנה באמצעות "עסקאות", הכוללות מערך שינויים במסד הנתונים שצריך להצליח או להיכשל בכללותו. לדוגמה, בספר כספי, תשלום מאליס לבוב מיוצג על ידי עסקה ש (א) בודקת אם לאליס יש מספיק כספים, (ב) מנכה כמות מחשבונה של אליס ו- (ג) מוסיפה את אותה הכמות לחשבון של בוב. .
במסד נתונים מרכזי רגיל, עסקאות אלה נוצרות על ידי רשות מהימנה אחת. לעומת זאת, במסד נתונים משותף מונע על ידי blockchain, ניתן ליצור עסקאות על ידי כל אחד ממשתמשי ה- blockchain. ומאחר שמשתמשים אלה אינם סומכים זה על זה באופן מלא, על בסיס הנתונים להכיל כללים המגבילים את העסקאות שבוצעו. לדוגמה, בספר פיננסי של עמית לעמית, כל עסקה חייבת לשמור על כמות הכספים הכוללת, אחרת המשתתפים יכלו לתת לעצמם באופן חופשי כמה שהם אוהבים.
אפשר לדמיין דרכים שונות לבטא כללים אלה, אך לעת עתה ישנן שתי פרדיגמות דומיננטיות, בהשראת ביטקוין ו- Ethereum בהתאמה. שיטת הביטקוין, שאנו מכנים אותה "אילוצי עסקאות", מעריכה כל עסקה במונחים של: (א) ערכי בסיס הנתונים שנמחקו על ידי אותה עסקה ו- (ב) הערכים שנוצרו. בספר פיננסי, הכלל קובע כי הסכום הכולל של הכספים בערכים שנמחקו צריך להיות תואם לסך הכל בסכום שנוצר. (אנו רואים שהשינוי של ערך קיים שווה ערך למחיקת הערך וליצירת ערך חדש במקומו.)
הפרדיגמה השנייה, שמגיעה מאתרום, היא חוזים חכמים. זה קובע כי כל השינויים בנתוני החוזה חייבים להתבצע על ידי הקוד שלו. (בהקשר של מסדי נתונים מסורתיים, אנו יכולים לחשוב על זה כאל נאכף הליך מאוחסן.) כדי לשנות את נתוני החוזה, משתמשים על ידי blockchain לשלוח בקשות לקוד שלה, הקובע אם וכיצד למלא את הבקשות האלה. כמו ב דוגמה זו, החוזה החכם עבור ספר חשבונות פיננסי מבצע את אותן שלוש משימות כמו מנהל מסד נתונים ריכוזי: בדיקת מספיק כסף, ניכוי מחשבון אחד והוספת לחשבון אחר.
שתי הפרדיגמות הללו יעילות, ולכל אחת היתרונות והחסרונות שלה, כפי שכבר הייתי נדונו לעומק בעבר. לסיכום, אילוצי עסקאות בסגנון ביטקוין מספקים במקביל ובביצועים מעולים, ואילו חוזים חכמים בסגנון אתרום מציעים גמישות רבה יותר. אז לחזור לשאלה למי מיועדים חוזים חכמים:
חוזים חכמים מיועדים למקרי שימוש ב- blockchain שלא ניתן ליישם עם מגבלות עסקאות.
בהתחשב בקריטריון זה לשימוש בחוזים חכמים, אני עדיין לא רואה מקרה שימוש חזק עבור מחזיקי חסימות מורשים העומדים בתנאי. כל יישומי הבלוקצ'יין המשכנעים שאני מכיר ניתנים ליישום באמצעות עסקאות בסגנון ביטקוין, שיכולות להתמודד עם הרשאות ואחסון נתונים כללי, כמו גם יצירת נכסים, העברה, נאמנות, החלפה והרס. עם זאת, עדיין מופיעים מקרים של שימוש חדש, ואני לא אתפלא אם יש כאלה do דורשים כוח של חוזים חכמים. או, לכל הפחות, הרחבה של פרדיגמת הביטקוין.
תהיה אשר התשובה תהיה אשר תהיה, המפתח לזכור הוא כי חוזים חכמים הם פשוט שיטה אחת להגבלת העסקאות שבוצעו בבסיס נתונים. זה ללא ספק דבר שימושי, וחיוני בכדי להפוך את מסד הנתונים בטוח לשיתוף. אבל חוזים חכמים אינם יכולים לעשות דבר אחר, והם בהחלט לא יכולים להימלט מגבולות בסיס הנתונים בו הם שוכנים.
אנא פרסם הערות בלינקדאין.