צלל לתוך Move - שפת התכנות של פייסבוק בלוקצ'יין מאזניים של פייסבוק

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

מבוא

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

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

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

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

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

ייצוג נכסים דיגיטליים במערכות פתוחות

ישנם שני מאפיינים של נכסים פיזיים שקשה לייצגם דיגיטלי:

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

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

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

הצעה מס '1: הכלל הפשוט ביותר ללא מחסור ובקרת גישה

• G [K]: = n מציין עדכון למספר הנגיש באמצעות מקש К במצב הגלובלי של הבלוקצ'יין, עם משמעות חדשה n.
• עסקה l אליס, 100⟩ פירושו הגדרת יתרת החשבון של אליס ל -100.

לפתרון הנ"ל יש מספר בעיות מרכזיות:

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

הצעה מס '2: התחשבות בגירעון

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

הצעה מס '3: שילוב של מחסור ובקרת גישה

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

שפות תכנות בלוקצ'יין

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

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

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

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

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

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

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

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

Move Language Design Fundamentals

משאבים מסדר ראשון

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

גמישות

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

אבטחה

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

אימות

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

מודולריות

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

העברת סקירה כללית

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

תשלומי עמית לעמית

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

• 0x0: כתובת החשבון שבו מאוחסן המודול
• מַטְבֵּעַ: שם המודול
• מטבע: סוג משאבים
• ערך המטבע המוחזר על ידי ההליך הוא ערך משאבים מסוג 0x0.Currency.Coin
• מהלך \ לזוז \ לעבור (): לא ניתן להשתמש בערך שוב
• עותק(): ניתן להשתמש בערך מאוחר יותר

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

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

שימוש חוזר בכספים על ידי ציון הזז (מטבע) פעמיים . הוספת שורה 0x0.Currency.deposit (העתק (מוטב_אחר), העבר (מטבע)) לדוגמה, האמור לעיל יאפשר לשולח "לבזבז" את המטבעות פעמיים - בפעם הראשונה עם מקבל התשלום, והשנייה עם מקבל_אחר_שהוא. מדובר בהתנהגות לא רצויה שאינה אפשרית עם נכס פיזי. למרבה המזל, Move ידחה את התוכנית הזו.

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

מודול מטבע

כל חשבון יכול להכיל 0 או יותר מודולים (מוצגים כמלבנים) וערך משאב אחד או יותר (מוצג כגלילים). לדוגמה, חשבון ב 0x0 מכיל מודול 0x0. מטבע והערך של סוג המשאב 0x0.Currency.Coin. חשבון בכתובת 0x1 יש שני משאבים ומודול אחד; חשבון בכתובת 0x2 יש שני מודולים וערך משאב אחד.

רגעים נקוטוריים:

• סקריפט העסקה הוא אטומי - או שהוא מבוצע במלואו או שלא.
• מודול הוא פיסת קוד ארוכת חיים הנגישה לכל העולם.
• המצב הגלובלי בנוי כטבלת hash, כאשר המפתח הוא כתובת החשבון
• חשבונות יכולים להכיל לא יותר מערך משאב אחד מסוג נתון ולא יותר ממודול אחד עם שם נתון (חשבון בכתובת 0x0 לא יכול להכיל משאב נוסף 0x0.Currency.Coin או מודול אחר בשם מַטְבֵּעַ)
• הכתובת של המודול המוצהר היא חלק מהסוג (0x0.Currency.Coin и 0x1.Currency.Coin הם סוגים נפרדים שלא ניתן להשתמש בהם לסירוגין)
• מתכנתים יכולים לאחסן מופעים מרובים של משאב מסוג זה בחשבון על ידי הגדרת המשאב המותאם אישית שלהם - (משאב TwoCoins {c1: 0x0.Currency.Coin, c2: 0x0.Currency.Coin})
• אתה יכול להתייחס למשאב לפי שמו ללא התנגשויות, למשל אתה יכול להתייחס לשני משאבים באמצעות TwoCoins.c1 и TwoCoins.c2.

הכרזה על משאבי מטבעות

מודול בשם מַטְבֵּעַ וסוג משאב בשם מטבע

רגעים נקוטוריים:

• מטבע הוא מבנה עם שדה סוג אחד u64 (מספר שלם ללא סימן של 64 סיביות)
• נהלי מודול בלבד מַטְבֵּעַ יכול ליצור או להרוס ערכים מסוג מטבע.
• מודולים ותסריטים אחרים יכולים לכתוב או להפנות את שדה הערך רק באמצעות נהלים ציבוריים שסופקו על ידי המודול.

מכירת פיקדון

הליך זה מקבל משאב מטבע כקלט ומשלב אותו עם המשאב מטבעמאוחסן בחשבון הנמען:

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

רגעים נקוטוריים:

• פרק, BorrowGlobal - נהלים מובנים
• לִפְרוֹק זוהי הדרך היחידה למחוק משאב מסוג T. ההליך לוקח משאב כקלט, הורס אותו ומחזיר את הערך המשויך לשדות המשאב.
• BorrowGlobal לוקח כתובת כקלט ומחזיר הפניה למופע ייחודי של T שפורסם (בבעלות) של אותה כתובת
• &mut מטבע זה קישור למשאב מטבע

יישום משיכה_מהשולח

התהליך הזה:

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

רגעים נקוטוריים:

• פקדון יכול להיגרם על ידי כל אחד, אבל לסגת_משלוח יש לו גישה רק למטבעות של החשבון המתקשר
• GetTxnSenderAddress דומה ל msg.sender בסולידיטי
• דחה אלא אם כן דומה ל לדרוש בסולידיטי. אם בדיקה זו נכשלת, העסקה נעצרת וכל השינויים יבוטלו.
• חבילה זהו גם הליך מובנה שיוצר משאב חדש מסוג T.
• בנוסף ל לִפְרוֹק, חבילה ניתן לקרוא רק בתוך המודול שבו מתואר המשאב T

מסקנה

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

מקור: www.habr.com