Dernæst vil vi i detaljer overveje de vigtigste egenskaber ved Move -sproget, og hvad er dets vigtigste forskelle med et andet, allerede populært sprog for smarte kontrakter - Solidity (på Ethereum -platformen). Materialet er baseret på en undersøgelse af det tilgængelige online 26-siders hvidbog.
Indledning
Move er et eksekverbart bytekodesprog, der bruges til at udføre brugertransaktioner og smarte kontrakter. Vær opmærksom på to punkter:
- Mens Move er et bytecode-sprog, der kan eksekveres direkte på den virtuelle Move-maskine, er Solidity (Ethereums smarte kontraktsprog) et sprog på højere niveau, der først kompileres til bytecode, før det udføres på en EVM (Ethereum Virtual Machine).
- Move kan bruges ikke kun til at implementere smarte kontrakter, men også til brugerdefinerede transaktioner (mere om dette senere), mens Solidity er et smart kontrakt, der kun er til kontrakt.
Oversættelsen blev lavet af INDEX Protocol-projektteamet. Vi har tidligere oversat , nu er det tid til at se nærmere på Move-sproget. Oversættelsen er lavet sammen med habrauseren
En nøglefunktion ved Move er evnen til at definere brugerdefinerede ressourcetyper med semantik baseret på lineær logik: en ressource kan aldrig kopieres eller implicit slettes, kun flyttes. Funktionelt ligner dette funktionerne i Rust-sproget. Værdier i Rust kan kun tildeles ét navn ad gangen. Hvis du tildeler en værdi til et andet navn, bliver det utilgængeligt under det tidligere navn.
For eksempel udsender følgende kodestykke en fejl: Brug af flyttet værdi 'x'. Det skyldes, at der ikke er nogen affaldssamling i Rust. Når variabler går uden for rækkevidde, frigøres også den hukommelse, de refererer til. Kort sagt kan der kun være én "ejer" af dataene. I dette eksempel x er den oprindelige ejer og derefter y bliver den nye ejer. .
Repræsentation af digitale aktiver i åbne systemer
Der er to egenskaber ved fysiske aktiver, der er svære at repræsentere digitalt:
- sjældenhed (Knaphed, oprindeligt knaphed). Antallet af aktiver (emission) i systemet skal kontrolleres. Kopiering af eksisterende aktiver skal være forbudt, og oprettelse af nye er en privilegeret operation.
- Adgangskontrol... Systemdeltageren skal være i stand til at beskytte aktiver ved hjælp af adgangskontrolpolitikker.
Disse to egenskaber, der er naturlige for fysiske aktiver, skal implementeres for digitale objekter, hvis vi vil betragte dem som aktiver. For eksempel har et sjældent metal en naturlig mangel, og kun du har adgang til det (f.eks. At holde det i dine hænder), og du kan sælge eller bruge det.
For at illustrere, hvordan vi nåede frem til disse to ejendomme, lad os starte med følgende sætninger:
Forslag nr. 1: Den enkleste regel uden knaphed og adgangskontrol
- G [K]: = n betegner en opdatering til et nummer, der er tilgængeligt med en nøgle К i blockchainens globale tilstand, med en ny betydning n.
- transaktion ⟨Alice, 100⟩ betyder at sætte Alices kontosaldo til 100.
Ovenstående løsning har flere store problemer:
- Alice kan modtage et ubegrænset antal mønter ved blot at sende transaktion ⟨Alice, 100⟩.
- De mønter, Alice sender til Bob, er ubrugelige, da Bob kunne sende sig et ubegrænset antal mønter ved hjælp af den samme teknik.
Forslag nr. 2: Under hensyntagen til underskuddet
Nu overvåger vi situationen, så antallet af mønter Ka var mindst lige n før transaktionen. Selvom dette løser problemet med mangel, er der ingen oplysninger om, hvem der kan sende Alices mønter (for nu kan alle gøre dette, det vigtigste er ikke at overtræde reglen om begrænsning af beløbet).
Forslag nr. 3: Kombination af knaphed og adgangskontrol
Vi løser dette problem med en digital signaturmekanisme verificer_sig før du kontrollerer saldoen, hvilket betyder, at Alice bruger sin private nøgle til at underskrive transaktionen og bekræfte, at hun er ejer af hendes mønter.
Blockchain programmeringssprog
De eksisterende blockchain -sprog står over for følgende problemer (alle blev løst i Move (bemærk: desværre appellerer artiklens forfatter kun til Ethereum i sine sammenligninger, så det er værd at tage dem kun i denne sammenhæng. For eksempel løses det meste af det følgende også i EOS.))):
Indirekte repræsentation af aktiver. Et aktiv er kodet ved hjælp af et heltal, men en heltalværdi er ikke det samme som et aktiv. Faktisk er der ingen type eller værdi, der repræsenterer bitcoin / ether / <Enhver mønt>! Dette gør det vanskeligt og udsat for fejl at skrive programmer, der bruger aktiver. Mønstre som at overføre aktiver til/fra procedurer eller lagring af aktiver i strukturer kræver særlig støtte fra sproget.
Underskuddet kan ikke udvides... Sprog repræsenterer kun et knap aktiv. Derudover er midlerne mod knaphed hardwired direkte i semantikken i selve sproget. Udvikleren, hvis han vil oprette et tilpasset aktiv, skal omhyggeligt kontrollere alle aspekter af ressourcen selv. Det er præcis problemerne med Ethereum smarte kontrakter.
Brugere udsteder deres aktiver, ERC-20-tokens, ved hjælp af heltal til at bestemme både værdien og den samlede forsyning. Når der oprettes nye tokens, skal den smarte kontraktkode uafhængigt verificere overholdelsen af emissionsreglerne. Desuden fører den indirekte præsentation af aktiver i nogle tilfælde til alvorlige fejl - dobbeltarbejde, dobbeltforbrug eller endda fuldstændigt tab af aktiver.
Manglende fleksibel adgangskontrol... Den eneste adgangskontrolpolitik, der bruges i dag, er et signaturskema, der bruger asymmetrisk kryptografi. Ligesom mangelbeskyttelse er adgangskontrolpolitikker dybt indlejret i sprogets semantik. Men hvordan man udvider sproget til at give programmører mulighed for at definere deres egne adgangskontrolpolitikker er ofte en meget vanskelig opgave.
Dette gælder også for Ethereum, hvor smarte kontrakter ikke har indbygget understøttelse af kryptografi til adgangskontrol. Udviklere skal manuelt skrive adgangskontrol, for eksempel ved hjælp af onlyOwner-modifikatoren.
Selvom jeg er en stor fan af Ethereum, mener jeg, at aktivegenskaber bør understøttes af sproget af sikkerhedsmæssige årsager. Især at overføre Ether til en smart kontrakt muliggør dynamisk afsendelse, som har introduceret en ny klasse af fejl kendt som genindtrædende sårbarheder. Dynamisk afsendelse betyder her, at kodeudførelseslogikken vil blive bestemt ved kørselstid (dynamisk) og ikke ved kompileringstid (statisk).
I Solidity, når kontrakt A kalder en funktion af kontrakt B, kan kontrakt B således køre kode, som ikke var tiltænkt af bygherren af kontrakt A, hvilket kan føre til (kontrakt A fungerer ved et uheld som kontrakt B om at hæve penge, før saldi faktisk trækkes fra kontoen).
Move Language Design Fundamentals
Førsteordensressourcer
På et højt niveau ligner interaktionen mellem moduler / ressourcer / procedurer i Move -sproget meget forholdet mellem klasser / objekter og metoder på OOP -sprog.
Move -moduler ligner smarte kontrakter i andre blockchains. Modulet erklærer ressourcetyper og procedurer, der definerer reglerne for oprettelse, destruktion og opdatering af deklarerede ressourcer. Men alt dette er bare konventioner (“jargon”) I bevægelse. Vi vil illustrere dette punkt lidt senere.
fleksibilitet
Move tilføjer fleksibilitet til Libra gennem scripting. Hver transaktion i Libra inkluderer et script, som faktisk er den vigtigste procedure for transaktionen. Scriptet kan enten udføre en specificeret handling, for eksempel at foretage betalinger til en specificeret liste over modtagere, eller genbruge andre ressourcer, for eksempel ved at kalde en procedure, der definerer fælles logik. Dette er grunden til, at Move-transaktionsscripts tilbyder en masse fleksibilitet. Et script kan bruge både engangs- og tilbagevendende adfærd, mens Ethereum kun kan udføre tilbagevendende scripts (kalder en enkelt smart kontraktmetode). Grunden til at det kaldes "gentaget" er fordi smarte kontraktfunktioner kan udføres flere gange. (Bemærk: her er øjeblikket meget subtilt. På den ene side er der transaktionsscripts i form af pseudo-bytekode i Bitcoin. På den anden side, som jeg forstår det, udvider Move dette sprog, faktisk til niveauet for et fuldgyldigt smart kontraktsprog).
Безопасность
Det eksekverbare Move-format er bytecode, som på den ene side er et sprog på højere niveau end assembler, men et lavere niveau end kildekode. Bytekoden kontrolleres i run-time (on-chain) for ressourcer, typer og hukommelsessikkerhed ved hjælp af en bytecode-verifikator og udføres derefter af tolken. Denne tilgang gør det muligt for Move at levere kildekodens sikkerhed, men uden kompileringsprocessen og behovet for at tilføje en compiler til systemet. At lave Move til et bytekodesprog er en rigtig god idé. Det behøver ikke at være kompileret fra kilden, da der i tilfælde af Solidity ikke er behov for at bekymre sig om mulige fejl eller angreb på compiler-infrastrukturen.
Verificerbarhed
Vi bestræber os på at gøre kontrollen så nem som muligt, da det hele foregår i kæden (bemærk: online, under udførelsen af hver transaktion, så enhver forsinkelse fører til en afmatning af hele netværket), men i første omgang er sprogdesignet klar til at bruge off-chain statiske verifikationsværktøjer. Selvom dette er mere at foretrække, er udviklingen af verifikationsværktøjer (som et separat værktøjssæt) blevet udskudt for fremtiden, og kun dynamisk verifikation i run-time (on-chain) understøttes i øjeblikket.
Modularitet
Move -moduler giver dataabstraktion og lokaliserer kritiske operationer på ressourcer. Indkapslingen fra modulet kombineret med beskyttelsen fra Move -typesystemet sikrer, at egenskaber, der er angivet på modulets typer, ikke kan krænkes af kode uden for modulet. Dette er et ret gennemtænkt abstraktionsdesign, hvilket betyder, at dataene i kontrakten kun kan ændre sig inden for kontraktens rammer, men ikke udenfor.
Flyt oversigt
Transaktionsskripteksemplet viser, at ondsindede eller skødesløse handlinger fra en programmør uden for et modul ikke kan kompromittere sikkerheden ved et moduls ressourcer. Dernæst ser vi på eksempler på, hvordan moduler, ressourcer og procedurer bruges til at programmere Libra blockchain.
Peer-to-Peer betalinger
Antallet af mønter angivet i beløb vil blive overført fra afsenderens saldo til modtageren.
Der er flere nye punkter her (fremhævet med røde inskriptioner):
- 0x0: adresse på den konto, hvor modulet er gemt
- Valuta: modulnavn
- Coin: ressource type
- Møntværdien, der returneres ved proceduren, er en ressourceværdi af typen 0x0.Currency.Coin
- bevæge sig (): værdi kan ikke bruges igen
- kopi(): værdi kan bruges senere
Parse koden: i det første trin kalder afsenderen en procedure med navnet tilbagetrækning_fra_afsender fra et modul, der er gemt i 0x0.Valuta. I andet trin overfører afsenderen penge til modtageren ved at flytte værdien af møntressourcen ind i modulets indbetalingsprocedure 0x0.Valuta.
Her er tre eksempler på fejl i kode, der vil blive afvist ved kontrol:
Dupliker midler ved at ændre opkaldet flytte (mønt) på kopi (mønt). Ressourcer kan kun flyttes. Forsøg på at duplikere mængden af en ressource (f.eks. ved at ringe kopi (mønt) i eksemplet ovenfor) vil resultere i en fejl under kontrol af bytecode.
Genbrug af midler ved at specificere flytte (mønt) to gange . Tilføjelse af en linje 0x0.Currency.deposit(copy(some_other_payee), move(coin)) eksemplet ovenfor giver afsenderen mulighed for at "bruge" mønterne to gange - første gang med betalingsmodtageren og anden gang med en anden_modtager. Dette er en uønsket adfærd, som ikke er mulig med et fysisk aktiv. Heldigvis vil Move afvise dette program.
Tab af midler på grund af afslag flytte (mønt). Hvis du ikke flytter ressourcen (f.eks. ved at fjerne linjen, der indeholder flytte (mønt)), vil en bytekodebekræftelsesfejl blive rejst. Dette beskytter Move-programmører mod utilsigtet eller ondsindet tab af midler.
Valutamodul
Hver konto kan indeholde 0 eller flere moduler (afbildet som kasser) og en eller flere ressourceværdier (afbildet som cylindre). Eksempelvis en konto på 0x0 indeholder modul 0x0.Valuta og en ressourceværdi af typen 0x0.Currency.Coin. Konto på adresse 0x1 har to ressourcer og et modul; Konto på adresse 0x2 har to moduler og en ressourceværdi.
Nogle øjeblikke:
- Transaktionsscriptet er atomært - enten fuldstændigt udført eller slet ikke.
- Et modul er et stykke kode med lang levetid, der er globalt tilgængeligt.
- Den globale tilstand er struktureret som en hash-tabel, hvor kontoadressen er nøglen
- Konti kan ikke indeholde mere end én ressourceværdi af en given type og ikke mere end ét modul med et givet navn (en konto på 0x0 kan ikke indeholde en ekstra ressource 0x0.Currency.Coin eller et andet navngivet modul Valuta)
- Adressen på det deklarerede modul er en del af typen (0x0.Currency.Coin и 0x1.Currency.Coin er separate typer, der ikke kan bruges i flæng)
- Programmører kan gemme flere forekomster af en given ressourcetype på en konto ved at definere deres brugerdefinerede ressource - (ressource TwoCoins {c1: 0x0.Currency.Coin, c2: 0x0.Currency.Coin})
- Du kan referere til en ressource ved dens navn uden konflikt, for eksempel kan du henvise til to ressourcer ved hjælp af TwoCoins.c1 и TwoCoins.c2.
Mønt ressourceerklæring
Navngivet modul Valuta og en ressourcetype navngivet Coin
Nogle øjeblikke:
- Coin er en struktur med ét typefelt u64 (64-bit heltal uden fortegn)
- Kun modulprocedurer Valuta kan skabe eller ødelægge værdier af typen Coin.
- Andre moduler og scripts kan kun skrive eller henvise til værdifeltet gennem offentlige procedurer leveret af modulet.
Implementering af depositum
Denne procedure accepterer en ressource Coin som input og sammenkæder det med en ressource Coingemt på modtagerens konto:
- Ødelægge inputressourcen Mønt og skrive dens værdi.
- At få et link til en unik møntressource gemt på modtagerens konto.
- Ændring af værdien af antallet af mønter med den værdi, der sendes i parameteren, når proceduren kaldes.
Nogle øjeblikke:
- Pak ud, BorrowGlobal - indbyggede procedurer
- Pakker ud dette er den eneste måde at slette en ressource af type T. Proceduren tager en ressource som input, ødelægger den og returnerer den værdi, der er knyttet til ressourcens felter.
- LånGlobal tager en adresse som input og returnerer en reference til den unikke forekomst af T offentliggjort (ejet) af den adresse
- &mut Mønt dette er et link til en ressource Coin
Implementering af tilbagetrækning_fra_afsender
Denne procedure:
- Får et link til en unik ressource Coin, knyttet til afsenderens konto
- Formindsker værdien af en ressource Coin ved reference for det angivne beløb
- Opretter og returnerer en ny ressource Coin med opdateret saldo.
Nogle øjeblikke:
- Depositum kan kaldes af alle, men tilbagetrækning_fra_afsender har kun adgang til mønterne på den kaldende konto
- GetTxnSenderAddress svarende til besked.afsender i Soliditet
- Afvis Medmindre svarende til kræver i Soliditet. Hvis denne kontrol mislykkes, stopper udførelsen af transaktionen, og alle ændringer rulles tilbage.
- pakke det er også en indbygget procedure, der skaber en ny ressource af type T.
- Såvel som Pakker ud, pakke kan kun kaldes inde i det modul, hvor ressourcen er deklareret T
Konklusion
Vi analyserede hovedegenskaberne ved Move-sproget, sammenlignede det med Ethereum og stiftede også bekendtskab med den grundlæggende syntaks for scripts. Endelig kan jeg varmt anbefale at browse . Den indeholder mange detaljer om designprincipper for programmeringssprog, såvel som mange nyttige links.
Kilde: www.habr.com