Vervolgens kyk ons in detail na die belangrikste kenmerke van die Move -taal en wat is die belangrikste verskille met 'n ander, reeds gewilde taal vir slim kontrakte - Solidity (op die Ethereum -platform). Die materiaal is gebaseer op 'n studie van die beskikbare aanlynblad van 26 bladsye.
Inleiding
Move is 'n uitvoerbare greepkode-taal wat gebruik word om gebruikerstransaksies en slim kontrakte uit te voer. Gee aandag aan twee punte:
- Alhoewel Move 'n bytecode-taal is wat direk op die Move-virtuele masjien uitgevoer kan word, is Solidity (Ethereum se slim kontraktaal) 'n taal op hoër vlak wat eers saamgestel word in bytecode voordat dit op 'n EVM (Ethereum Virtual Machine) uitgevoer word.
- Move kan nie net gebruik word om slim kontrakte te implementeer nie, maar ook vir pasgemaakte transaksies (meer hieroor later), terwyl Solidity slegs 'n slim taal is.
Die vertaling is gemaak deur die INDEX Protocol-projekspan. Ons het voorheen vertaal , nou is dit tyd om die Move-taal van nader te bekyk. Die vertaling is saam met die habrauser gemaak
'n Sleutelkenmerk van Move is die vermoë om pasgemaakte hulpbrontipes te definieer met semantiek gebaseer op lineêre logika: 'n hulpbron kan nooit gekopieer of implisiet uitgevee word nie, net geskuif word. Funksioneel is dit soortgelyk aan die kenmerke van die Rust-taal. Waardes in Rust kan slegs aan een naam op 'n slag toegeken word. Om 'n waarde aan 'n ander naam toe te ken, maak dit ontoeganklik onder die vorige naam.
Byvoorbeeld, die volgende kodefragment sal 'n fout veroorsaak: Gebruik van verplaasde waarde 'x'. Dit is omdat daar geen vullisversameling in Rust is nie. As veranderlikes buite omvang gaan, word die geheue waarna hulle verwys ook vrygemaak. Eenvoudig gestel, daar kan slegs een 'eienaar' van die data wees. In hierdie voorbeeld x is die oorspronklike eienaar en dan y word die nuwe eienaar. .
Voorstelling van digitale bates in oop stelsels
Daar is twee eienskappe van fisiese bates wat moeilik is om digitaal voor te stel:
- rariteit (Skaarsheid, oorspronklik skaarsheid). Die aantal bates (emissie) in die stelsel moet beheer word. Duplisering van bestaande bates moet verbied word, en om nuwe te skep is 'n bevoorregte operasie.
- Toegangsbeheer... Die deelnemer van die stelsel moet bates kan beskerm deur toegangsbeheerbeleid te gebruik.
Hierdie twee eienskappe, wat natuurlik is vir fisiese bates, moet geïmplementeer word vir digitale voorwerpe as ons dit as bates wil beskou. Byvoorbeeld, 'n seldsame metaal het 'n natuurlike tekort, en slegs u het toegang daartoe (byvoorbeeld in u hande) en u kan dit verkoop of bestee.
Om te illustreer hoe ons by hierdie twee eiendomme gekom het, laat ons met die volgende sinne begin:
Voorstel # 1: Die eenvoudigste reël sonder skaarsheid en toegangsbeheer
- G [K]: = n dui 'n opdatering aan van 'n nommer wat toeganklik is met 'n sleutel К in die globale toestand van die blockchain, met 'n nuwe betekenis n.
- transaksie ⟨Alice, 100⟩ beteken om Alice se rekeningsaldo op 100 te stel.
Bogenoemde oplossing het verskeie groot probleme:
- Alice kan 'n onbeperkte aantal muntstukke ontvang deur eenvoudig te stuur transaksie ⟨Alice, 100⟩.
- Die munte wat Alice vir Bob stuur, is nutteloos, aangesien Bob vir hom 'n onbeperkte aantal munte kan stuur met dieselfde tegniek.
Voorstel # 2: Met inagneming van die tekort
Nou monitor ons die situasie sodat die aantal munte Ka was ten minste gelyk n voor die oordragtransaksie. Alhoewel dit die probleem van skaarsheid oplos, is daar geen inligting oor wie Alice se muntstukke kan stuur nie (voorlopig kan almal dit doen, die belangrikste is om nie die reël om die hoeveelheid te beperk nie) te oortree.
Voorstel # 3: kombinasie van skaarste en toegangsbeheer
Ons los hierdie probleem op met 'n digitale handtekeningsmeganisme verifieer_sig voordat u die saldo nagaan, wat beteken dat Alice haar privaat sleutel gebruik om die transaksie te onderteken en te bevestig dat sy die eienaar van haar muntstukke is.
Blockchain programmeertale
Die bestaande blockchain -tale ondervind die volgende probleme (almal is opgelos in beweging) (let op: Ongelukkig doen die skrywer van die artikel slegs 'n beroep op Ethereum in sy vergelykings, dus is dit die moeite werd om dit slegs in hierdie konteks te neem. Die meeste van die volgende word byvoorbeeld ook opgelos in EOS.)):
Indirekte voorstelling van bates. 'n Bate word geënkodeer deur 'n heelgetal te gebruik, maar 'n heelgetalwaarde is nie dieselfde as 'n bate nie. Trouens, daar is geen tipe of waarde wat bitcoin / eter / <Enige Munt> verteenwoordig nie! Dit maak dit moeilik en vatbaar vir foute om programme te skryf wat bates gebruik. Patrone soos die oordrag van bates na/van prosedures of die berging van bates in strukture vereis spesiale ondersteuning van die taal.
Die tekort kan nie uitgebrei word nie... Taal verteenwoordig slegs een skaars bate. Boonop word die middels teen skaarsheid direk in die semantiek van die taal gekoppel. Die ontwikkelaar, as hy 'n aangepaste bate wil skep, moet alle aspekte van die hulpbron self sorgvuldig beheer. Dit is presies die probleme van Ethereum -slimkontrakte.
Gebruikers reik hul bates, ERC-20-tokens, uit met heelgetalle om beide die waarde en die totale aanbod te bepaal. Elke keer as nuwe tokens geskep word, moet die slim kontrakkode onafhanklik nagaan of die emissiereëls nagekom word. Boonop lei die indirekte aanbieding van bates in sommige gevalle tot ernstige foute - duplisering, dubbele besteding of selfs volledige verlies van bates.
Gebrek aan buigsame toegangsbeheer... Die enigste toegangsbeheerbeleid wat tans gebruik word, is 'n handtekeningskema met asimmetriese kriptografie. Net soos beskerming teen skaarsheid, is toegangsbeheerbeleid diep ingebed in die semantiek van die taal. Maar hoe om die taal uit te brei sodat programmeerders hul eie toegangsbeheerbeleid kan definieer, is dikwels 'n baie moeilike taak.
Dit geld ook vir Ethereum, waar slim kontrakte nie inheemse ondersteuning vir kriptografie vir toegangsbeheer het nie. Ontwikkelaars moet toegangsbeheer met die hand skryf, byvoorbeeld deur die enigste Eienaar-wysiger te gebruik.
Alhoewel ek 'n groot aanhanger van Ethereum is, glo ek dat bate-eiendomme vir sekuriteitsdoeleindes inheems deur die taal ondersteun moet word. Veral, deur Ether in 'n slim kontrak deur te gee, maak dit dinamiese versending moontlik, wat 'n nuwe klas foute bekendgestel het, bekend as hertoetredingskwesbaarhede. Dinamiese versending beteken hier dat die kode-uitvoeringslogika tydens looptyd (dinamies) bepaal sal word en nie op samestellingstyd (staties).
Dus, in Solidity, wanneer kontrak A 'n funksie van kontrak B oproep, kan kontrak B kode uitvoer wat nie deur die ontwikkelaar van kontrak A bedoel is nie, wat kan lei tot (kontrak A tree per ongeluk op as kontrak B om geld te onttrek voordat die saldo's werklik van die rekening afgetrek word).
Move Language Design Fundamentals
Eerste-orde hulpbronne
Op 'n hoë vlak is die interaksie tussen modules / hulpbronne / prosedures in die Move -taal baie soortgelyk aan die verhouding tussen klasse / voorwerpe en metodes in OOP -tale.
Skuifmodules is soortgelyk aan slim kontrakte in ander blokke. Die module verklaar hulpbrontipes en -prosedures wat die reëls definieer vir die skep, vernietiging en opdatering van verklaarde hulpbronne. Maar dit is alles net konvensies ("jargon”) In beweging. Ons sal hierdie punt 'n bietjie later toelig.
Buigsaamheid
Beweeg voeg buigsaamheid by Weegskaal deur middel van skrif. Elke transaksie in Weegskaal bevat 'n skrif, wat eintlik die hoofprosedure van die transaksie is. Die skrip kan óf een gespesifiseerde aksie uitvoer, byvoorbeeld, betalings aan 'n gespesifiseerde lys van ontvangers maak, óf ander hulpbronne hergebruik, byvoorbeeld deur 'n prosedure aan te roep wat algemene logika definieer. Dit is hoekom Move-transaksieskrifte baie buigsaamheid bied. 'n Skrip kan beide eenmalige en herhalende gedrag gebruik, terwyl Ethereum slegs herhalende skrifte kan uitvoer (wat 'n enkele slimkontrakmetode noem). Die rede waarom dit "herhaal" genoem word, is omdat slimkontrakfunksies verskeie kere uitgevoer kan word. (let wel: hier is die oomblik baie subtiel. Aan die een kant is daar transaksieskrifte in die vorm van pseudo-greepkode in Bitcoin. Aan die ander kant, soos ek dit verstaan, brei Move hierdie taal eintlik uit tot die vlak van 'n volwaardige slimkontraktaal).
sekuriteit
Die Move-uitvoerbare formaat is bytecode, wat aan die een kant 'n hoërvlaktaal as samesteller is, maar laervlak as bronkode. Die greepkode word in looptyd (op-ketting) nagegaan vir hulpbronne, tipes en geheueveiligheid met behulp van 'n greepkode-verifieerder en dan deur die tolk uitgevoer. Hierdie benadering laat Move toe om die sekuriteit van bronkode te verskaf, maar sonder die samestellingsproses en die behoefte om 'n samesteller by die stelsel te voeg. Om 'n greepkode-taal van Beweeg te maak, is 'n baie goeie idee. Dit hoef nie van bron af saamgestel te word nie, want in die geval van Solidity hoef u nie bekommerd te wees oor moontlike mislukkings of aanvalle op die samesteller-infrastruktuur nie.
verifieerbaarheid
Ons poog om die tjeks so maklik as moontlik te maak, want dit gaan alles aan die ketting (let wel: aanlyn, tydens die uitvoering van elke transaksie, sodat enige vertraging tot 'n vertraging van die hele netwerk lei), maar aanvanklik is die taalontwerp gereed om buite-ketting statiese verifikasie-instrumente te gebruik. Alhoewel dit meer verkieslik is, is die ontwikkeling van verifikasiehulpmiddels (as 'n aparte gereedskapstel) vir die toekoms uitgestel, en slegs dinamiese verifikasie in looptyd (aan-ketting) word tans ondersteun.
Modulariteit
Move -modules bied data -onttrekking en lokaliseer kritieke bewerkings op hulpbronne. Die omhulsel wat deur die module verskaf word, gekombineer met die beskerming van die Move -tipe stelsel, verseker dat die eienskappe wat op die tipes modules gestel is, nie deur die kode buite die module geskend kan word nie. Dit is 'n redelik deurdagte abstraksie-ontwerp, wat beteken dat die data binne die kontrak slegs binne die raamwerk van die kontrak kan verander, maar nie buite nie.
Skuif oorsig
Die voorbeeld van die transaksieskrip toon aan dat kwaadwillige of nalatige optrede deur 'n programmeerder buite 'n module nie die veiligheid van 'n module se hulpbronne kan benadeel nie. Vervolgens kyk ons na voorbeelde van hoe modules, hulpbronne en prosedures gebruik word om die Weegskaal -ketting te programmeer.
Peer-to-Peer betalings
Die aantal munte wat in bedrag gespesifiseer word, sal van die sender se balans na die ontvanger oorgedra word.
Daar is verskeie nuwe punte hier (met rooi inskripsies uitgelig):
- 0x0: adres van die rekening waar die module gestoor word
- Geld: module naam
- Muntstuk: hulpbrontipe
- Die muntwaarde wat deur die prosedure terugbesorg word, is 'n bronwaarde van die tipe 0x0.Currency.Coin
- beweeg (): waarde kan nie weer gebruik word nie
- kopie (): waarde kan later gebruik word
Ontleed die kode: in die eerste stap noem die sender 'n prosedure met die naam onttrek_van_sender vanaf 'n module gestoor in 0x0.Geldeenheid. In die tweede stap dra die sender fondse na die ontvanger oor deur die waarde van die munthulpbron na die module se depositoprosedure te skuif 0x0.Geldeenheid.
Hier is drie voorbeelde van foute in kode wat deur tjeks verwerp sal word:
Dupliseer geld deur die oproep te verander beweeg (munt) op kopie (muntstuk). Hulpbronne kan slegs geskuif word. Poging om die hoeveelheid van 'n hulpbron te dupliseer (byvoorbeeld deur te bel kopie (muntstuk) in die voorbeeld hierbo) sal 'n fout tot gevolg hê wanneer die bytecode nagegaan word.
Hergebruik van fondse deur te spesifiseer beweeg (munt) twee keer . Voeg 'n reël by 0x0.Currency.deposit(copy(some_other_payee), move(coin)) voorbeeld hierbo sal die sender toelaat om die munte twee keer te "bestee" - die eerste keer met die begunstigde, en die tweede keer met een_ander_betaler. Dit is 'n ongewenste gedrag wat nie moontlik is met 'n fisiese bate nie. Gelukkig sal Move hierdie program verwerp.
Verlies aan fondse as gevolg van ontkenning beweeg (munt). As jy nie die hulpbron skuif nie (byvoorbeeld deur die reël te verwyder wat beweeg (munt)), sal 'n greepkode-verifikasiefout opgewek word. Dit beskerm Move-programmeerders teen toevallige of kwaadwillige verlies van fondse.
Geldeenheid module
Elke rekening kan 0 of meer modules bevat (uitgebeeld as bokse) en een of meer hulpbronwaardes (uitgebeeld as silinders). Byvoorbeeld, 'n rekening by 0x0 module bevat 0x0.Geldeenheid en 'n hulpbronwaarde van tipe 0x0.Currency.Coin. Rekening by adres 0x1 het twee hulpbronne en een module; Rekening by adres 0x2 het twee modules en een hulpbronwaarde.
Nekotory oomblikke:
- Die transaksieskrif is atoom - of heeltemal uitgevoer, of glad nie.
- 'n Module is 'n langlewende stuk kode wat wêreldwyd beskikbaar is.
- Die globale toestand is gestruktureer as 'n hash-tabel, waar die rekeningadres die sleutel is
- Rekeninge kan nie meer as een hulpbronwaarde van 'n gegewe tipe bevat nie en nie meer as een module met 'n gegewe naam nie ('n rekening by 0x0 kan nie 'n bykomende hulpbron bevat nie 0x0.Currency.Coin of 'n ander module genoem Geld)
- Die adres van die verklaarde module is deel van die tipe (0x0.Currency.Coin и 0x1.Currency.Coin is afsonderlike tipes wat nie uitruilbaar gebruik kan word nie)
- Programmeerders kan veelvuldige gevalle van 'n gegewe hulpbrontipe in 'n rekening stoor deur hul persoonlike hulpbron te definieer - (hulpbron TwoCoins {c1: 0x0.Currency.Coin, c2: 0x0.Currency.Coin})
- Jy kan sonder konflik na 'n hulpbron met sy naam verwys, byvoorbeeld jy kan verwys na twee hulpbronne wat gebruik word Twee Muntstukke.c1 и Twee Muntstukke.c2.
Munthulpbronverklaring
Benoemde module Geld en 'n hulpbrontipe genoem Muntstuk
Nekotory oomblikke:
- Muntstuk is 'n struktuur met een veld van tipe u64 (64-bis ongetekende heelgetal)
- Slegs moduleprosedures Geld kan soorte waardes skep of vernietig Muntstuk.
- Ander modules en skrifte kan slegs die waardeveld skryf of verwys deur middel van openbare prosedures wat deur die module verskaf word.
Implementering van die deposito
Hierdie prosedure aanvaar 'n hulpbron Muntstuk as inset en verbind dit met 'n hulpbron Muntstukgestoor op die begunstigde se rekening:
- Vernietig die insethulpbron Muntstuk en skryf die waarde daarvan.
- Die verkryging van 'n skakel na 'n unieke muntbron wat op die ontvanger se rekening gestoor is.
- Verander die waarde van die aantal munte deur die waarde wat in die parameter geslaag is wanneer die prosedure gebel word.
Nekotory oomblikke:
- Pak uit, BorrowGlobal - ingeboude prosedures
- Pak uit dit is die enigste manier om 'n hulpbron van tipe T uit te vee. Die prosedure neem 'n hulpbron as toevoer, vernietig dit en gee die waarde terug wat met die velde van die hulpbron geassosieer word.
- BorrowGlobal neem 'n adres as invoer en gee 'n verwysing terug na die unieke instansie van T wat deur daardie adres gepubliseer (besit) is
- &mut Muntstuk dit is 'n skakel na 'n hulpbron Muntstuk
Implementering van onttrek_van_sender
Hierdie prosedure:
- Kry 'n skakel na 'n unieke hulpbron Muntstuk, gekoppel aan die sender se rekening
- Verlaag die waarde van 'n hulpbron Muntstuk deur verwysing vir die gespesifiseerde bedrag
- Skep en gee 'n nuwe hulpbron terug Muntstuk met opgedateerde balans.
Nekotory oomblikke:
- deposito kan deur enigiemand gebel word, maar onttrek_van_sender het slegs toegang tot die munte van die oproeprekening
- GetTxnSenderAddress soortgelyk aan boodskap.sender in Soliditeit
- Verwerp Tensy soortgelyk aan vereis in Soliditeit. As hierdie kontrole misluk, stop die uitvoering van die transaksie en alle veranderinge word teruggerol.
- pak dit is ook 'n ingeboude prosedure wat 'n nuwe hulpbron van tipe T skep.
- Sowel as Pak uit, pak kan slegs opgeroep word binne die module waar die hulpbron verklaar is T
Gevolgtrekking
Ons het die hoofkenmerke van die Move-taal ontleed, dit met Ethereum vergelyk, en ook kennis gemaak met die basiese sintaksis van skrifte. Ten slotte beveel ek sterk aan om te blaai . Dit bevat baie besonderhede oor programmeertaalontwerpbeginsels, sowel as baie nuttige skakels.
Bron: will.com