Следно, детално ќе ги разгледаме главните карактеристики на јазикот Move и кои се неговите клучни разлики со друг, веќе популарен јазик за паметни договори - цврстина (на платформата Ethereum). Материјалот е базиран на студија за достапната онлајн бела хартија од 26 страници.
Вовед
Move е јазик за извршна бајтекод што се користи за извршување на кориснички трансакции и паметни договори. Ве молиме имајте предвид две точки:
- Додека Move е бајт-код јазик што може директно да се изврши на виртуелната машина Move, Solidity (паметниот јазик за договор на Ethereum) е јазик од повисоко ниво што прво се составува за бај-код пред да се изврши на EVM (виртуелна машина Ethereum).
- Move може да се користи не само за имплементација на паметни договори, туку и за сопствени трансакции (повеќе за ова подоцна), додека Solidity е паметен јазик само за договор.
Преводот го изведе проектниот тим на протоколот INDEX. Веќе преведовме , сега е време да го разгледаме јазикот Move малку подетално. Преводот е извршен заедно со Хабраузер
Клучна карактеристика на Move е способноста да се дефинираат сопствени типови ресурси со семантика заснована на линеарна логика: ресурсот никогаш не може да се копира или имплицитно да се избрише, само да се премести. Функционално, ова е слично на можностите на јазикот Rust. Вредностите во Rust може да се доделат само на едно име во исто време. Доделувањето вредност на друго име го прави недостапно под претходното име.
На пример, следниов фрагмент од код ќе испушти грешка: Употреба на поместената вредност 'x'. Ова е затоа што нема собирање смет во 'Рѓа. Кога променливите излегуваат од опсегот, меморијата на која тие се однесуваат исто така се ослободува. Едноставно кажано, може да има само еден „сопственик“ на податоците. Во овој пример x е оригиналниот сопственик, а потоа y станува нов сопственик. .
Претставување на дигитални средства во отворени системи
Постојат две својства на физичките средства што е тешко да се претстават дигитално:
- Реткост (Недостаток, првично недостаток). Бројот на средства (емисија) во системот мора да се контролира. Мора да се забрани дуплирање на постојните средства, а создавањето нови е привилигирана операција.
- Контрола на пристап... Учесникот во системот мора да биде способен да ги заштити средствата користејќи политики за контрола на пристапот.
Овие две карактеристики, кои се природни за физичките средства, мора да се имплементираат за дигитални објекти ако сакаме да ги сметаме за средства. На пример, редок метал има природен дефицит, и само вие имате пристап до него (држете го во раце, на пример) и можете да го продадете или потрошите.
За да илустрираме како стигнавме до овие две својства, да почнеме со следните реченици:
Предлог # 1: Наједноставно правило без недостаток и контрола на пристап
- G [K]: = n означува ажурирање на број достапен со копче К во глобалната состојба на блокчејн, со ново значење n.
- трансакција lАлиса, 100⟩ значи поставување на салдото на сметката на Алиса на 100.
Горенаведеното решение има неколку големи проблеми:
- Алиса може да добие неограничен број монети со едноставно испраќање трансакција ⟨Алиса, 100⟩.
- Монетите што Алиса му ги испраќа на Боб се бескорисни, бидејќи Боб може да си испрати неограничен број на монети користејќи ја истата техника.
Предлог # 2: Земајќи го предвид дефицитот
Сега ја следиме ситуацијата така што бројот на монети Ka беше барем еднаков n пред трансфер трансакцијата. Меѓутоа, иако ова го решава проблемот со недостаток, нема информации за тоа кој може да ги испрати монетите на Алиса (засега, секој може да го стори тоа, главната работа е да не се прекрши правилото за ограничување на износот).
Предлог # 3: Комбинирање на недостаток и контрола на пристап
Овој проблем го решаваме со механизам за дигитален потпис verify_sig пред да го провери балансот, што значи дека Алис го користи својот приватен клуч за да ја потпише трансакцијата и да потврди дека е сопственик на нејзините монети.
Блокчејн програмски јазици
Постојните јазици со блокчејн се соочуваат со следниве проблеми (сите се решени во „Премести“ (забелешка: за жал, авторот на статијата апелира само до Ethereum во неговите споредби, па затоа вреди да ги земеме само во овој контекст. На пример, повеќето од следниве се исто така решени во EOS.)):
Индиректно претставување на средствата. Средството се кодира со помош на цел број, но цел број не е ист како средство. Всушност, не постои тип или вредност што го претставува Биткоин/Етер/<Која било паричка>! Ова го прави пишувањето програми што користат средства тешко и склони кон грешки. Моделите како што се пренесување средства на/од процедури или складирање средства во структури бараат посебна поддршка од јазикот.
Дефицитот не може да се прошири... Јазикот претставува само едно ретко средство. Покрај тоа, лековите против недостаток се вградени директно во семантиката на самиот јазик. Развивачот, ако сака да создаде сопствено средство, мора самиот внимателно да ги контролира сите аспекти на ресурсот. Ова се токму проблемите на паметните договори за Ethereum.
Корисниците ги издаваат своите средства, токени ERC-20, користејќи цели броеви за да ја одредат и вредноста и вкупната понуда. Секогаш кога се креираат нови токени, паметниот код на договорот мора независно да ја потврди усогласеноста со правилата за емисија. Покрај тоа, индиректното претставување на средствата води, во некои случаи, до сериозни грешки - дуплирање, двојно трошење или дури и целосно губење на средствата.
Недостаток на флексибилна контрола на пристап... Единствената политика за контрола на пристапот што моментално се користи е шема на потпис користејќи асиметрична криптографија. Како и заштитата од недостаток, политиките за контрола на пристап се длабоко вградени во семантиката на јазикот. Но, како да се прошири јазикот за да им се овозможи на програмерите да дефинираат сопствени политики за контрола на пристапот, честопати е многу незгодна задача.
Ова важи и за Ethereum, каде што паметните договори немаат поддршка за домашна криптографија за контрола на пристап. Програмерите мора рачно да постават контрола на пристап, на пример, користејќи го модификаторот onlyOwner.
Иако сум голем обожавател на Ethereum, верувам дека својствата на средствата треба да бидат природно поддржани од јазикот за безбедносни цели. Конкретно, пренесувањето на Ether на паметен договор вклучува динамично испраќање, кое воведе нова класа на грешки познати како пропусти за повторно влегување. Динамичното испраќање овде значи дека логиката на извршување на кодот ќе се одреди при извршување (динамично) наместо во време на компајлирање (статичко).
Така, во Solidity, кога договорот А повикува функција во договорот Б, договорот Б може да работи код што не бил наменет од развивачот на договорот А, што може да резултира со (договорот А случајно делува како договор Б за повлекување пари пред состојбата на сметката да биде всушност одземена).
Премести јазичен дизајн Основи
Ресурси од прв ред
На високо ниво, интеракцијата помеѓу модулите / ресурсите / процедурите во јазикот Move е многу слична со односот помеѓу класи / објекти и методи во OOP јазиците.
Модулите за поместување се слични на паметните договори во други блокчејн. Модулот декларира типови и процедури на ресурси кои ги дефинираат правилата за креирање, уништување и ажурирање на декларираните ресурси. Но, сето ова се само конвенции („жаргон”) Во движење. Оваа точка ќе ја илустрираме малку подоцна.
Флексибилност
Move додава флексибилност на Libra преку скриптирање. Секоја трансакција во Libra вклучува скрипта, која во суштина е основната процедура на трансакцијата. Скриптата може да изврши или едно одредено дејство, на пример, плаќања до одредена листа на примачи или повторно да користи други ресурси - на пример, со повикување на процедура во која е наведена општата логика. Ова е причината зошто скриптите за трансакции Move нудат поголема флексибилност. Скрипта може да користи и еднократно и повторливо однесување, додека Ethereum може да извршува само повторливи скрипти (повикувајќи еден метод на метод на паметен договор). Причината поради која се нарекува „повторна употреба“ е затоа што функциите на паметниот договор може да се извршат повеќе пати. (Забелешка: Поентата овде е многу суптилна. Од една страна, скриптите за трансакции во форма на псевдо-бајтекод постојат и во Биткоин. Од друга страна, како што јас разбирам, Move го проширува овој јазик, всушност, на ниво на полноправен јазик за паметни договори).
безбедност
Извршниот формат Move е бајтекод, кој е, од една страна, јазик на повисоко ниво од асемблерскиот јазик, но пониско ниво од изворниот код. Бајтекодот се проверува во време на извршување (на синџир) за ресурси, типови и безбедност на меморијата со помош на проверувач на бајтекод, а потоа се извршува од страна на толкувачот. Овој пристап му овозможува на Move да ја обезбеди безбедноста на изворниот код, но без процесот на компилација и потребата да се додаде компајлер во системот. Создавањето на Move јазик бајтекод е навистина добро решение. Не треба да се компајлира од изворот, како што е случајот со Solidity, и нема потреба да се грижите за можни неуспеси или напади на инфраструктурата на компајлерот.
Веродостојност
Наша цел е да извршиме проверки што е можно поедноставно, бидејќи сето тоа се прави на синџир (забелешка: онлајн, за време на извршување на секоја трансакција, така што секое одложување води до забавување на целата мрежа), сепак, првично дизајнот на јазикот е подготвен да користи алатки за статичка проверка надвор од синџирот. Иако ова е попожелно, за сега развојот на алатките за верификација (како посебен комплет алатки) е одложен за во иднина, а сега е поддржана само динамична верификација во време на извршување (on-chain).
Модуларност
Модулите за поместување обезбедуваат апстракција на податоци и локализираат критични операции на ресурсите. Инкапсулацијата обезбедена од модулот, во комбинација со заштитата што ја обезбедува системот за типот Move, гарантира дека својствата поставени на типовите на модулот не можат да бидат прекршени со код надвор од модулот. Ова е прилично добро осмислен дизајн на апстракција, што значи дека податоците во договорот може да се променат само во рамките на договорот, но не и надвор.
Премести преглед
Примерот за трансакциска скрипта покажува дека злонамерните или невнимателните дејствија на програмер надвор од модулот не можат да ја загрозат безбедноста на ресурсите на модулот. Следно, ќе разгледаме примери за тоа како се користат модули, ресурси и процедури за програмирање на блокчејнот Вага.
Плаќања од врсници
Бројот на монети наведени во износ ќе се префрли од салдото на испраќачот до примачот.
Има неколку нови работи овде (означени со црвено):
- 0x0: адреса на сметката каде што е зачуван модулот
- Валута: име на модул
- Монета: тип на ресурси
- Вредноста на монетата вратена со постапката е вредност на ресурсот од типот 0x0.Вела.Кова
- помести (): вредноста не може да се користи повторно
- копирај (): вредноста може да се искористи подоцна
Анализирајте го кодот: во првиот чекор, испраќачот повикува постапка со име повлече_од_праќач од модул зачуван во 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.в1 и TwoCoins.в2.
Објава за ресурси за монети
Именуван модул Валута и именуван тип на ресурс Монета
Некоторични моменти:
- Монета е структура со едно поле на тип u64 (64-битен непотпишан цел број)
- Само процедури за модул Валута може да создаде или уништи вредности од типот Монета.
- Другите модули и скрипти можат само да пишуваат или упатуваат на полето за вредности преку јавни процедури обезбедени од модулот.
Продажба на депозит
Оваа постапка прифаќа ресурс Монета како влез и го комбинира со ресурсот Монетазачувано во сметката на примачот:
- Уништување на влезниот ресурс Coin и снимање на неговата вредност.
- Добивање врска до единствен ресурс за монети зачуван во сметката на примачот.
- Промена на вредноста на бројот на монети за вредноста што е пренесена во параметарот при повикување на постапката.
Некоторични моменти:
- Отпакувајте, BorrowGlobal - вградени процедури
- Отпакувајте Ова е единствениот начин да се избрише ресурс од типот T. Постапката зема ресурс како влез, го уништува и ја враќа вредноста поврзана со полињата на ресурсот.
- БороуГлобал зема адреса како влез и враќа референца на единствена инстанца на Т објавена (во сопственост) на таа адреса
- &mut Монета ова е врска до ресурсот Монета
Имплементација на повлече_од_испраќач
Оваа постапка:
- Добива врска до единствен ресурс Монета, поврзан со сметката на испраќачот
- Ја намалува вредноста на ресурсот Монета преку врската за наведената сума
- Создава и враќа нов ресурс Монета со ажуриран биланс.
Некоторични моменти:
- депозит може да биде предизвикана од било кој, но повлече_од_праќач има пристап само до монетите на сметката за повикување
- GetTxnSenderAddress слично на msg.испраќач во Солидност
- Отфрли освен ако слично на бараат во Солидност. Ако оваа проверка не успее, трансакцијата се прекинува и сите промени се враќаат назад.
- Пакувајте тоа е и вградена процедура која создава нов ресурс од типот Т.
- Како и Отпакувајте, Пакувајте може да се повика само внатре во модулот каде што е опишан ресурсот T
Заклучок
Ги испитавме главните карактеристики на јазикот Move, го споредивме со Ethereum, а исто така се запознавме со основната синтакса на скриптите. Конечно, топло препорачувам да се проверите . Вклучува многу детали во врска со принципите на дизајнирање на програмскиот јазик, како и многу корисни врски.
Извор: www.habr.com