Dive into Move - Facebook-ի Libra բլոկչեյն ծրագրավորման լեզուն

Հաջորդիվ, մենք մանրամասնորեն կանդրադառնանք Move լեզվի հիմնական բնութագրերին և որոնք են դրա հիմնական տարբերությունները խելացի պայմանագրերի համար արդեն հայտնի լեզվի՝ Solidity-ի հետ (Ethereum հարթակում): Նյութը հիմնված է 26 էջանոց սպիտակ թերթի ուսումնասիրության վրա, որը հասանելի է առցանց:

Ներածություն

Move-ը գործարկվող բայթկոդի լեզու է, որն օգտագործվում է օգտատերերի գործարքները և խելացի պայմանագրերը կատարելու համար: Խնդրում ենք նկատի ունենալ երկու կետ.

1. Թեև Move-ը բայթկոդային լեզու է, որը կարող է ուղղակիորեն գործարկվել Move վիրտուալ մեքենայի վրա, Solidity-ը (խելացի պայմանագրային լեզուն Ethereum-ում) ավելի բարձր մակարդակի լեզու է, որը նախքան EVM-ում (Ethereum վիրտուալ մեքենա) գործարկումն առաջին անգամ կազմվում է բայթկոդի մեջ:
2. Move-ը կարող է օգտագործվել ոչ միայն խելացի պայմանագրերի իրականացման համար, այլև օգտատերերի գործարքների համար (այս մասին ավելի ուշ), մինչդեռ Solidity-ը միայն խելացի պայմանագրերի լեզու է:

Թարգմանությունն իրականացրել է INDEX Protocol նախագծի թիմը: Մենք արդեն թարգմանել ենք մեծ նյութ, որը նկարագրում է Libra նախագիծը, այժմ ժամանակն է մի փոքր ավելի մանրամասն նայել Move լեզվին: Թարգմանությունն իրականացվել է Հաբրաուզերի հետ համատեղ քուլսիու

Move-ի հիմնական առանձնահատկությունը գծային տրամաբանության վրա հիմնված իմաստաբանությամբ ռեսուրսների հատուկ տեսակներ սահմանելու ունակությունն է. ռեսուրսը երբեք չի կարող պատճենվել կամ անուղղակիորեն ջնջվել, այլ միայն տեղափոխվել: Ֆունկցիոնալ առումով սա նման է Rust լեզվի հնարավորություններին: Rust-ի արժեքները կարող են միաժամանակ վերագրվել միայն մեկ անվան: Մեկ այլ անվան համար արժեք վերագրելը այն անհասանելի է դարձնում նախորդ անվան տակ:

Օրինակ, կոդի հետևյալ հատվածը սխալ կառաջացնի. «x» տեղափոխված արժեքի օգտագործումը: Դա պայմանավորված է նրանով, որ Ռաստը չունի աղբահանություն: Երբ փոփոխականները դուրս են գալիս շրջանակից, հիշողությունը, որին նրանք վերաբերում են, նույնպես ազատվում է: Պարզ ասած՝ տվյալների միայն մեկ «տեր» կարող է լինել։ Այս օրինակում x սկզբնական սեփականատերն է և ապա y դառնում է նոր սեփականատեր. Այս վարքագծի մասին ավելին կարդացեք այստեղ.

Թվային ակտիվների ներկայացում բաց համակարգերում

Ֆիզիկական ակտիվների երկու հատկություն կա, որոնք դժվար է թվայնորեն ներկայացնել.

• Հազվադեպություն (Սակավություն, բնագրում՝ սակավություն)։ Համակարգում ակտիվների (արտանետումների) քանակը պետք է վերահսկվի: Գոյություն ունեցող ակտիվների կրկնօրինակումը պետք է արգելվի, իսկ նորերի ստեղծումը արտոնյալ գործողություն է։
• Մուտքի հսկողություն. Համակարգի մասնակիցը պետք է կարողանա պաշտպանել ակտիվները՝ օգտագործելով մուտքի վերահսկման քաղաքականությունը:

Այս երկու բնութագրերը, որոնք բնական են ֆիզիկական ակտիվների համար, պետք է իրականացվեն նաև թվային օբյեկտների համար, եթե մենք ցանկանում ենք դրանք դիտարկել որպես ակտիվներ: Օրինակ, հազվագյուտ մետաղը բնական սակավություն ունի, և միայն դուք ունեք այն հասանելի (օրինակ՝ ձեր ձեռքերում պահելով) և կարող եք վաճառել կամ ծախսել:

Որպեսզի ցույց տանք, թե ինչպես հասանք այս երկու հատկություններին, եկեք սկսենք հետևյալ նախադասություններից.

Առաջարկ թիվ 1. Ամենապարզ կանոնն առանց սակավության և մուտքի վերահսկման

• G[K]:=n նշանակում է թվի թարմացում, որը հասանելի է բանալիով К բլոկչեյնի գլոբալ վիճակում՝ նոր իմաստով n.
• գործարք ⟨Ալիս, 100⟩ նշանակում է Ալիսի հաշվի մնացորդը սահմանել 100:

Վերոնշյալ լուծումն ունի մի քանի լուրջ խնդիրներ.

• Ալիսը կարող է ստանալ անսահմանափակ թվով մետաղադրամներ՝ պարզապես ուղարկելով գործարք ⟨Ալիս, 100⟩.
• Մետաղադրամները, որոնք Ալիսն ուղարկում է Բոբին, արժեք չունեն, քանի որ Բոբը կարող էր իրեն ուղարկել անսահմանափակ թվով մետաղադրամներ՝ օգտագործելով նույն տեխնիկան:

Առաջարկ թիվ 2. Հաշվի առեք դեֆիցիտը

Այժմ մենք վերահսկում ենք իրավիճակը, որպեսզի մետաղադրամների քանակը Ka առնվազն հավասար էր n փոխանցման գործարքից առաջ: Այնուամենայնիվ, թեև սա լուծում է սակավության խնդիրը, տեղեկություններ չկան այն մասին, թե ով կարող է ուղարկել Ալիս մետաղադրամներ (առայժմ յուրաքանչյուրը կարող է դա անել, քանի դեռ դուք չեք խախտում քանակի սահմանաչափի կանոնը):

Առաջարկ թիվ 3. Միավորել սղությունը և մուտքի վերահսկումը

Մենք լուծում ենք այս խնդիրը՝ օգտագործելով թվային ստորագրության մեխանիզմը verify_sig նախքան մնացորդը ստուգելը, ինչը նշանակում է, որ Ալիսն օգտագործում է իր անձնական բանալին գործարքը ստորագրելու և հաստատելու, որ ինքը իր մետաղադրամների տերն է:

Բլոկչեյն ծրագրավորման լեզուներ

Գործող բլոկչեյն լեզուները բախվում են հետևյալ խնդիրների հետ (որոնք բոլորը լուծվել են Move-ում). Ցավոք, հոդվածի հեղինակն իր համեմատություններում անդրադառնում է միայն Ethereum-ին, ուստի դրանք պետք է ընդունել միայն այս համատեքստում։ Օրինակ, հետևյալի մեծ մասը լուծվում է նաև EOS-ում)):

Ակտիվների անուղղակի ներկայացում. Ակտիվը կոդավորված է ամբողջ թվով, բայց ամբողջ թիվը նույնը չէ, ինչ ակտիվը: Փաստորեն, չկա որևէ տեսակ կամ արժեք, որը ներկայացնում է Bitcoin/Ether/<Any Coin>: Սա դժվարացնում է ակտիվներ օգտագործող ծրագրեր գրելը և սխալների հավանականությունը: Օրինակներ, ինչպիսիք են ակտիվների փոխանցումը/ընթացակարգից կամ ակտիվները կառույցներում պահելը, պահանջում են լեզվի հատուկ աջակցություն:

Դեֆիցիտը չի ընդլայնվում. Լեզուն ներկայացնում է միայն մեկ սակավ հատկություն: Բացի այդ, թերություններից պաշտպանվելու միջոցները ուղղակիորեն կապված են լեզվի իմաստաբանության մեջ: Մշակողը, եթե ցանկանում է ստեղծել հատուկ ակտիվ, պետք է ուշադիր վերահսկի ռեսուրսի բոլոր ասպեկտները: Սրանք հենց Ethereum խելացի պայմանագրերի հետ կապված խնդիրներն են:

Օգտագործողները թողարկում են իրենց ակտիվները՝ ERC-20 նշանները՝ օգտագործելով ամբողջ թվեր՝ և՛ արժեքը, և՛ ընդհանուր մատակարարումը որոշելու համար: Ամեն անգամ, երբ ստեղծվում են նոր նշաններ, խելացի պայմանագրի կոդը պետք է ինքնուրույն ստուգի արտանետումների կանոններին համապատասխանությունը: Բացի այդ, ակտիվների անուղղակի ներկայացումը որոշ դեպքերում հանգեցնում է լուրջ սխալների՝ կրկնակի, կրկնակի ծախսերի կամ նույնիսկ ակտիվների ամբողջական կորստի:

Ճկուն մուտքի հսկողության բացակայություն. Մուտքի վերահսկման միակ քաղաքականությունը, որն այժմ կիրառվում է, ստորագրության սխեման է՝ օգտագործելով ասիմետրիկ ծածկագրությունը: Ինչպես սակավությունից պաշտպանվածությունը, մուտքի վերահսկման քաղաքականությունը խորապես ներդրված է լեզվի իմաստաբանության մեջ: Բայց ինչպես ընդլայնել լեզուն, որպեսզի ծրագրավորողները կարողանան սահմանել իրենց սեփական մուտքի վերահսկման քաղաքականությունը, հաճախ շատ դժվար խնդիր է:

Սա ճիշտ է նաև Ethereum-ի դեպքում, որտեղ խելացի պայմանագրերը չունեն մուտքի վերահսկման համար բնիկ կրիպտոգրաֆիայի աջակցություն: Մշակողները պետք է ձեռքով սահմանեն մուտքի կառավարումը, օրինակ՝ օգտագործելով onlyOwner փոփոխիչը:

Թեև ես Ethereum-ի մեծ երկրպագու եմ, կարծում եմ, որ ակտիվների հատկությունները պետք է աջակցվեն լեզվի կողմից՝ անվտանգության նպատակներով: Մասնավորապես, եթերի փոխանցումը խելացի պայմանագրին ենթադրում է դինամիկ առաքում, որը ներկայացրել է սխալների նոր դաս, որը հայտնի է որպես կրկին մուտքի խոցելիություն: Դինամիկ առաքումն այստեղ նշանակում է, որ կոդի կատարման տրամաբանությունը որոշվելու է գործարկման ժամանակ (դինամիկ), այլ ոչ թե կոմպիլյացիայի ժամանակ (ստատիկ):

Այսպիսով, Solidity-ում, երբ A պայմանագիրը կանչում է ֆունկցիա B պայմանագրում, B պայմանագիրը կարող է գործարկել կոդը, որը նախատեսված չէր Ա պայմանագրի մշակողի կողմից, ինչը կարող է հանգեցնել. վերագրանցման խոցելիություններ (Պայմանագիրը A պատահաբար գործում է որպես B պայմանագիր՝ գումար հանելու համար, նախքան հաշվի մնացորդները փաստացի հանվելը):

Տեղափոխել լեզվի ձևավորման հիմունքները

Առաջին կարգի ռեսուրսներ

Եթե ​​խոսենք բարձր մակարդակով, Move լեզվում մոդուլների/ռեսուրսների/ընթացակարգերի միջև փոխազդեցությունը շատ նման է OOP լեզուների դասերի/օբյեկտների և մեթոդների միջև փոխհարաբերություններին:
Move-ի մոդուլները նման են այլ բլոկչեյնների խելացի պայմանագրերին: Մոդուլը հայտարարում է ռեսուրսների տեսակները և ընթացակարգերը, որոնք սահմանում են հայտարարված ռեսուրսների ստեղծման, ոչնչացման և թարմացման կանոններ: Բայց այս ամենը պարզապես պայմանականություններ են («ժարգոն”) Move-ում: Մենք այս կետը կպատկերացնենք մի փոքր ավելի ուշ:

Ճկունություն

Move-ը ճկունություն է հաղորդում Libra-ին սկրիպտավորման միջոցով: Libra-ում յուրաքանչյուր գործարք ներառում է սցենար, որն ըստ էության գործարքի հիմնական ընթացակարգն է: Սցենարը կարող է կատարել կամ մեկ նշված գործողություն, օրինակ՝ վճարումներ հասցեատերերի նշված ցուցակին, կամ վերօգտագործել այլ ռեսուրսներ, օրինակ՝ զանգահարելով ընթացակարգ, որում նշված է ընդհանուր տրամաբանությունը: Ահա թե ինչու Move գործարքների սկրիպտներն առաջարկում են ավելի մեծ ճկունություն: Սցենարը կարող է օգտագործել և՛ մեկանգամյա, և՛ կրկնվող վարքագիծը, մինչդեռ Ethereum-ը կարող է իրականացնել միայն կրկնվող սկրիպտներ (մեկ մեթոդ կանչելով խելացի պայմանագրի մեթոդով): Պատճառն այն է, որ այն կոչվում է «վերօգտագործելի», քանի որ խելացի պայմանագրի գործառույթները կարող են իրականացվել մի քանի անգամ: (Նշում: Բանն այստեղ շատ նուրբ է: Մի կողմից, բիթքոյնում գոյություն ունեն նաև կեղծ բայթկոդի տեսքով գործարքների սկրիպտներ: Մյուս կողմից, ինչպես ես հասկանում եմ, Move-ն ընդլայնում է այս լեզուն, փաստորեն, մինչև լիարժեք խելացի պայմանագրային լեզվի մակարդակ։).

Безопасность

Move գործարկվող ձևաչափը բայթկոդ է, որը, մի կողմից, ավելի բարձր մակարդակի լեզու է, քան անսամբլի լեզուն, բայց ավելի ցածր մակարդակ, քան սկզբնական կոդը։ Բայթկոդը ստուգվում է գործարկման ժամանակում (շղթայի վրա) ռեսուրսների, տեսակների և հիշողության անվտանգության համար՝ օգտագործելով բայթկոդի ստուգիչ, և այնուհետև գործարկվում է թարգմանչի կողմից: Այս մոտեցումը թույլ է տալիս Move-ին ապահովել սկզբնական կոդի անվտանգությունը, բայց առանց կոմպիլյացիայի գործընթացի և համակարգում կոմպիլյատոր ավելացնելու անհրաժեշտության։ Move-ը բայթկոդի լեզու դարձնելն իսկապես լավ լուծում է: Այն պետք չէ կազմվել աղբյուրից, ինչպես դա Solidity-ի դեպքում է, և կարիք չկա անհանգստանալու կոմպիլյատորի ենթակառուցվածքի վրա հնարավոր ձախողումների կամ հարձակումների մասին։

Ստուգելիություն

Մենք նպատակ ունենք հնարավորինս հեշտ ստուգումներ իրականացնել, քանի որ այս ամենը կատարվում է շղթայական (նշում. առցանց, յուրաքանչյուր գործարքի կատարման ընթացքում, ուստի ցանկացած ուշացում հանգեցնում է ամբողջ ցանցի դանդաղեցմանը), այնուամենայնիվ, սկզբնական շրջանում լեզվի դիզայնը պատրաստ է օգտագործել շղթայից դուրս ստատիկ ստուգման գործիքներ: Թեև սա ավելի նախընտրելի է, առայժմ ստուգման գործիքների մշակումը (որպես առանձին գործիքակազմ) հետաձգվել է ապագայի համար, և այժմ աջակցվում է միայն դինամիկ ստուգումը գործարկման ժամանակում (շղթայի վրա):

Մոդուլյարություն

Move մոդուլները ապահովում են տվյալների աբստրակցիա և տեղայնացնում են կարևոր ռեսուրսների գործողությունները: Մոդուլի կողմից տրամադրված ինկապսուլյացիան՝ զուգակցված Move type համակարգի կողմից տրամադրված պաշտպանության հետ, ապահովում է, որ մոդուլի տեսակների վրա սահմանված հատկությունները չեն կարող խախտվել մոդուլից դուրս ծածկագրով: Սա աբստրակցիայի բավականին խելացի ձևավորում է, ինչը նշանակում է, որ պայմանագրի ներսում տվյալները կարող են փոփոխվել միայն պայմանագրի շրջանակներում, և ոչ դրսից:

Տեղափոխել կարծիքը

Գործարքի սցենարի օրինակը ցույց է տալիս, որ մոդուլից դուրս ծրագրավորողի չարամիտ կամ անզգույշ գործողությունները չեն կարող վտանգել մոդուլի ռեսուրսների անվտանգությունը: Հաջորդը, մենք կդիտարկենք օրինակներ, թե ինչպես են մոդուլները, ռեսուրսները և ընթացակարգերը օգտագործվում Libra բլոկչեյնը ծրագրավորելու համար:

Peer-to-Peer վճարումներ

Գումարով նշված մետաղադրամների քանակը ուղարկողի հաշվեկշռից կփոխանցվի ստացողին:
Այստեղ կան մի քանի նոր բաներ (կարմիրով ընդգծված).

• 0x0: հաշվի հասցեն, որտեղ պահվում է մոդուլը
• Արտարժույթ: մոդուլի անվանումը
• Փող: ռեսուրսի տեսակը
• Ընթացակարգով վերադարձված մետաղադրամի արժեքը ռեսուրսի արժեք է, որի տեսակն է 0x0.Currency.Coin
• շարժվել ()արժեքը չի կարող կրկին օգտագործվել
• պատճենել ()արժեքը կարող է օգտագործվել ավելի ուշ

Դիտարկենք ծածկագիրը. առաջին քայլում ուղարկողը կանչում է անունով պրոցեդուրան հանել_ուղարկողից մեջ պահված մոդուլից 0x0.Արժույթ. Երկրորդ քայլում ուղարկողը միջոցներ է փոխանցում ստացողին՝ մետաղադրամի ռեսուրսի արժեքը տեղափոխելով մոդուլի ավանդի ընթացակարգ։ 0x0.Արժույթ.

Ահա կոդի սխալների երեք օրինակ, որոնք կմերժվեն ստուգումների միջոցով.
Կրկնօրինակեք գումարը՝ փոխելով զանգը տեղափոխել (մետաղադրամ) մասին պատճեն (մետաղադրամ). Ռեսուրսները կարող են տեղափոխվել միայն: Փորձելով կրկնօրինակել ռեսուրսի քանակությունը (օրինակ՝ զանգահարելով պատճեն (մետաղադրամ) վերը նշված օրինակում) կհանգեցնի սխալի բայթկոդի ստուգման ժամանակ:

Ֆոնդերի վերաօգտագործում` նշելով տեղափոխել (մետաղադրամ) երկու անգամ . Գծի ավելացում 0x0.Արժույթ.ավանդ (պատճեն (մյուս_վճարվող), տեղափոխել (մետաղադրամ)) օրինակ՝ վերը նշվածը թույլ կտա ուղարկողին երկու անգամ «ծախսել» մետաղադրամները՝ առաջին անգամ վճարողի հետ, իսկ երկրորդը՝ որոշ_մյուս_վճարվող. Սա անցանկալի վարքագիծ է, որը հնարավոր չէ ֆիզիկական ակտիվի դեպքում: Բարեբախտաբար, Move-ը կմերժի այս ծրագիրը:

Մերժման պատճառով միջոցների կորուստ տեղափոխել (մետաղադրամ). Եթե ​​դուք չեք տեղափոխում ռեսուրսը (օրինակ՝ ջնջելով պարունակող տողը տեղափոխել (մետաղադրամ)), բայթկոդի ստուգման սխալ կուղարկվի: Սա պաշտպանում է Move-ի ծրագրավորողներին միջոցների պատահական կամ վնասակար կորստից:

Արժույթի մոդուլ

Յուրաքանչյուր հաշիվ կարող է պարունակել 0 կամ ավելի մոդուլներ (ցուցադրված են որպես ուղղանկյուններ) և մեկ կամ ավելի ռեսուրսների արժեքներ (ցուցադրված են որպես բալոններ): Օրինակ, հաշիվը ժամը 0x0 պարունակում է մոդուլ 0x0.Արժույթ և ռեսուրսի տեսակի արժեքը 0x0.Արժույթ.Մետաղադրամ. Հաշիվ հասցեով 0x1 ունի երկու ռեսուրս և մեկ մոդուլ; Հաշիվ հասցեով 0x2 ունի երկու մոդուլ և մեկ ռեսուրսային արժեք:

Որոշ պահեր.

• Գործարքի սկրիպտը ատոմային է՝ կա՛մ ամբողջությամբ կատարվում է, կա՛մ ընդհանրապես չի կատարվում:
• Մոդուլը երկարակյաց կոդ է, որը հասանելի է ամբողջ աշխարհում:
• Գլոբալ վիճակը կառուցված է որպես հեշ աղյուսակ, որտեղ բանալին հաշվի հասցեն է
• Հաշիվները կարող են պարունակել ոչ ավելի, քան մեկ տվյալ տեսակի ռեսուրսային արժեք և ոչ ավելի, քան մեկ մոդուլ տվյալ անունով (հաշիվ՝ 0x0 չի կարող պարունակել լրացուցիչ ռեսուրս 0x0.Արժույթ.Մետաղադրամ կամ մեկ այլ մոդուլ անունով Արտարժույթ)
• Հայտարարված մոդուլի հասցեն տիպի մի մասն է (0x0.Արժույթ.Մետաղադրամ и 0x1.Արժույթ.Մետաղադրամ առանձին տեսակներ են, որոնք չեն կարող օգտագործվել միմյանց հետ)
• Ծրագրավորողները կարող են հաշվում պահել այս տեսակի ռեսուրսի բազմաթիվ օրինակներ՝ սահմանելով իրենց հատուկ ռեսուրսը - (ռեսուրս TwoCoins {c1: 0x0.Currency.Coin, c2: 0x0.Currency.Coin})
• Դուք կարող եք առանց հակասությունների հղում կատարել ռեսուրսին իր անունով, օրինակ՝ օգտագործելով երկու ռեսուրս TwoCoins.c1 и TwoCoins.c2.

Մետաղադրամների ռեսուրսի հայտարարություն

Մոդուլի անվանումը Արտարժույթ և անվանված ռեսուրսի տեսակը Փող

Որոշ պահեր.

• Փող տիպի մեկ դաշտով կառույց է u64 (64-բիթանոց անստորագիր ամբողջ թիվ)
• Միայն մոդուլի ընթացակարգերը Արտարժույթ կարող է ստեղծել կամ ոչնչացնել տեսակի արժեքներ Փող.
• Այլ մոդուլներ և սցենարներ կարող են գրել կամ հղում կատարել արժեքի դաշտին միայն մոդուլի կողմից տրամադրված հանրային ընթացակարգերի միջոցով:

Ավանդի վաճառք

Այս ընթացակարգը ընդունում է ռեսուրս Փող որպես մուտքագրում և այն համատեղում է ռեսուրսի հետ ՓողՍտացողի հաշվում պահված՝

1. Մետաղադրամի մուտքային ռեսուրսի ոչնչացում և դրա արժեքի գրանցում:
2. Ստացողի հաշվում պահվող մետաղադրամների եզակի ռեսուրսի հղումի ստացում:
3. Ընթացակարգը կանչելիս Մետաղադրամների քանակի արժեքը փոխելով պարամետրում փոխանցված արժեքով:

Որոշ պահեր.

• Բացեք փաթեթավորումը, BorrowGlobal - ներկառուցված ընթացակարգեր
• Բացեք փաթեթավորումը Սա միակ միջոցն է T տիպի ռեսուրսը ջնջելու համար: Ընթացակարգը որպես մուտք է վերցնում ռեսուրսը, ոչնչացնում է այն և վերադարձնում ռեսուրսի դաշտերի հետ կապված արժեքը:
• BorrowGlobal ընդունում է հասցեն որպես մուտքագրում և վերադարձնում հղում դեպի այդ հասցեի կողմից հրապարակված (պատկանող) T-ի եզակի օրինակին
• &mut Մետաղադրամ սա հղում է ռեսուրսին Փող

Հեռացում_ուղարկողի իրականացում

Այս ընթացակարգը.

1. Ստանում է հղում դեպի եզակի ռեսուրս Փող, կապված ուղարկողի հաշվի հետ
2. Նվազեցնում է ռեսուրսի արժեքը Փող նշված գումարի համար հղման միջոցով
3. Ստեղծում և վերադարձնում է նոր ռեսուրս Փող թարմացված մնացորդով:

Որոշ պահեր.

• Ավանդ կարող է առաջանալ որևէ մեկի կողմից, բայց հանել_ուղարկողից մուտք ունի միայն զանգահարող հաշվի մետաղադրամները
• GetTxnSenderAddress նման msg.sender Solidity-ում
• Մերժել Եթե նման պահանջել Solidity-ում։ Եթե ​​այս ստուգումը ձախողվի, գործարքը դադարեցվում է, և բոլոր փոփոխությունները հետ են վերադարձվում:
• Փաթեթ դա նաև ներկառուցված ընթացակարգ է, որը ստեղծում է T տիպի նոր ռեսուրս:
• Ինչպես նաեւ Բացեք փաթեթավորումը, Փաթեթ կարելի է կանչել միայն այն մոդուլի ներսում, որտեղ նկարագրված է ռեսուրսը T

Ամփոփում

Մենք ուսումնասիրեցինք Move լեզվի հիմնական բնութագրերը, համեմատեցինք այն Ethereum-ի հետ, ինչպես նաև ծանոթացանք սկրիպտների հիմնական շարահյուսությանը: Ի վերջո, ես բարձր խորհուրդ եմ տալիս ստուգել օրիգինալ սպիտակ թուղթ. Այն ներառում է ծրագրավորման լեզվի նախագծման սկզբունքների վերաբերյալ շատ մանրամասներ, ինչպես նաև շատ օգտակար հղումներ:

Source: www.habr.com