מבוא לחוזים חכמים

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

חוזה רגיל לעומת חוזה חכם

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

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

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

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

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

הגדרה של חוזה חכם

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

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

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

דוגמה פשוטה - שירות נאמנות

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

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

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

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

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

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

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

דוגמא עם מעונות ומקרר

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

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

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

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

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

סיווג חוזים חכמים

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

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

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

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

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

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

חוזים חכמים לפי זמן ריצה

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

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

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

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

חוזים חכמים בשיטת קביעת ומילוי תנאים

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

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

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

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

חוזים חכמים לפי שיטת ייזום

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

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

חשבונות Ethereum

סוגי חשבונות Ethereum

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

חשבון המשתמש נשלט רק על ידי המפתח האישי של החתימה האלקטרונית. בעל החשבון מייצר זוג מפתחות משלו לחתימה אלקטרונית באמצעות אלגוריתם ECDSA (Elliptic Curve Digital Signature Algorithm). רק עסקאות שנחתמו עם מפתח זה יכולות לשנות את מצב החשבון הזה.

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

כיצד נוצרים חשבונות ב-Ethereum

במקרה של חשבון משתמש, הבעלים יוצר באופן עצמאי זוג מפתחות באמצעות ECDSA. חשוב לציין כי Ethereum משתמש בדיוק באותו אלגוריתם ובדיוק אותה עקומה אליפטית עבור חתימות אלקטרוניות כמו הביטקוין, אך הכתובת מחושבת בצורה מעט שונה. כאן, התוצאה של גיבוב כפול כבר לא משמשת, כמו בביטקוין, אבל גיבוב יחיד מסופק עם פונקציית Keccak באורך של 256 סיביות. הסיביות הפחות משמעותיות מנותקות מהערך המתקבל, כלומר 160 הסיביות הפחות משמעותיות של ערך ה-hash של הפלט. כתוצאה מכך, אנו מקבלים כתובת ב-Ethereum. למעשה, זה תופס 20 בתים.

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

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

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

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

מבנה עסקת Ethereum

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

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

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

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

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

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

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

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

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

דוגמה לקוד חוזה חכם עבור Solidity

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

contract Bank {
    address owner;
    mapping(address => uint) balances;
    
    function Bank() {
        owner = msg.sender;
    }

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint amount) public {
        if (balances[msg.sender] >= amount) {
            balances[msg.sender] -= amount;
            msg.sender.transfer(amount);
        }
    }

    function getMyBalance() public view returns(uint) {
        return balances[msg.sender];
    }

    function kill() public {
        if (msg.sender == owner)
            selfdestruct(owner);
    }
}

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

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

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

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

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

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

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

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

איך עובד צומת מלא ברשת Ethereum?

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

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

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

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

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

מיתוסים ומגבלות של חוזים חכמים

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

• ביצוע קוד;
• להקצות זיכרון;
• נתוני בלוקצ'יין;
• לשלוח תשלומים;
• ליצור חוזה חדש;
• להתקשר לחוזים אחרים.

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

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

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

החסרונות של Ethereum

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

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

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

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

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

אז, החלק הנושאי של המאמר הושלם, בואו נעבור לשאלות שעולות לעתים קרובות למדי.

שאלות ותשובות

— אם כל הצדדים לחוזה חכם קיים רוצים לשנות את התנאים, האם הם יכולים לבטל את החוזה החכם הזה באמצעות multisig, ולאחר מכן ליצור חוזה חכם חדש עם תנאים מעודכנים של ביצועו?

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

— מה אם המגשר יתקשר בהסכם עם אחד הצדדים המשתתפים: נאמנות או חוזה חכם? האם נדרש מגשר בחוזה חכם?

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

— האם ניתן בעסקת Ethereum אחת להעביר אסימונים רבים ושונים מהכתובת שלך לכתובות יעד שונות, למשל, כתובות חליפין בהן נסחרים באסימונים אלו?

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

— אחד המיתוסים לגבי פלטפורמת Ethereum הוא שאי אפשר לתאר תנאים שיהיו תלויים בנתונים של משאב אינטרנט חיצוני, אז מה לעשות אז?

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

אחת ההרצאות של הקורס המקוון בבלוקצ'יין מוקדשת לנושא זה - "מבוא לחוזים חכמים".

מקור: www.habr.com