Dyk in i Move - Facebooks Libra blockchain-programmeringsspråk

Därefter kommer vi att i detalj överväga de viktigaste egenskaperna hos Move -språket och vad är dess viktigaste skillnader med ett annat, redan populärt språk för smarta kontrakt - Soliditet (på Ethereum -plattformen). Materialet är baserat på en studie av den tillgängliga online-26-sidiga whitepaper.

Inledning

Move är ett körbart bytekodspråk som används för att utföra användartransaktioner och smarta kontrakt. Observera två punkter:

1. Medan Move är ett bytekodsspråk som kan köras direkt på den virtuella Move-maskinen, är Solidity (Ethereums smarta kontraktspråk) ett språk på högre nivå som först kompileras till bytecode innan det körs på en EVM (Ethereum Virtual Machine).
2. Move kan användas inte bara för att implementera smarta kontrakt, utan också för anpassade transaktioner (mer om detta senare), medan Solidity är ett smart kontrakt som endast är avtalsenligt.

Översättningen utfördes av projektgruppen INDEX Protocol. Vi har redan översatt stort material som beskriver Libra-projektet, nu är det dags att titta på Move-språket lite mer detaljerat. Översättningen utfördes tillsammans med Habrauser coolsiu

En nyckelfunktion i Move är möjligheten att definiera anpassade resurstyper med semantik baserad på linjär logik: en resurs kan aldrig kopieras eller implicit raderas, bara flyttas. Funktionellt liknar detta funktionerna i Rust-språket. Värden i Rust kan endast tilldelas ett namn åt gången. Att tilldela ett värde till ett annat namn gör det otillgängligt under det tidigare namnet.

Till exempel kommer följande kodavsnitt att ge ett fel: Användning av flyttat värde 'x'. Detta beror på att det inte finns någon sophämtning i Rust. När variabler går utanför räckvidden frigörs också minnet de hänvisar till. Enkelt uttryckt kan det bara finnas en "ägare" av data. I det här exemplet x är den ursprungliga ägaren och sedan y blir ny ägare. Läs mer om detta beteende här.

Representation av digitala tillgångar i öppna system

Det finns två egenskaper hos fysiska tillgångar som är svåra att digitalt representera:

• sällsynthet (Brist, ursprungligen knapphet). Antalet tillgångar (utsläpp) i systemet måste kontrolleras. Dubblering av befintliga tillgångar måste vara förbjudet, och att skapa nya är en privilegierad operation.
• Åtkomstkontroll... Systemdeltagaren måste kunna skydda tillgångar med hjälp av åtkomstkontrollpolicyer.

Dessa två egenskaper, som är naturliga för fysiska tillgångar, måste implementeras för digitala objekt om vi vill betrakta dem som tillgångar. Till exempel har en sällsynt metall ett naturligt underskott, och bara du har tillgång till den (till exempel att hålla den i dina händer) och du kan sälja eller spendera den.

För att illustrera hur vi kom fram till dessa två fastigheter, låt oss börja med följande meningar:

Förslag # 1: Den enklaste regeln utan knapphet och åtkomstkontroll

• G [K]: = n betecknar en uppdatering av ett nummer som är tillgängligt med en nyckel К i blockchainens globala tillstånd, med en ny innebörd n.
• transaktion ⟨Alice, 100⟩ betyder att ange Alices kontosaldo till 100.

Ovanstående lösning har flera stora problem:

• Alice kan ta emot ett obegränsat antal mynt genom att bara skicka transaktion ⟨Alice, 100⟩.
• Mynten Alice skickar till Bob är värdelösa, eftersom Bob kunde skicka ett obegränsat antal mynt med samma teknik.

Förslag # 2: Med hänsyn tagen till underskottet

Nu övervakar vi situationen så att antalet mynt Ka var minst lika n före transaktionen. Även om detta löser problemet med brist, finns det ingen information om vem som kan skicka Alices mynt (för närvarande kan vem som helst göra detta, det viktigaste är att inte bryta mot regeln om att begränsa beloppet).

Förslag # 3: Kombinera knapphet och åtkomstkontroll

Vi löser detta problem med en digital signaturmekanism verifiera_sig innan du kontrollerar saldot, vilket innebär att Alice använder sin privata nyckel för att underteckna transaktionen och bekräfta att hon äger sina mynt.

Blockchain programmeringsspråk

De befintliga blockchain -språken står inför följande problem (alla löstes i Move (notera: tyvärr tilltalar författaren av artikeln endast Ethereum i sina jämförelser, så det är värt att ta dem endast i detta sammanhang. Till exempel är det mesta av följande också löst i EOS.))):

Indirekt representation av tillgångar. En tillgång kodas med ett heltal, men ett heltal är inte detsamma som en tillgång. Det finns faktiskt ingen typ eller värde som representerar Bitcoin/Ether/<All Coin>! Detta gör det svårt och felbenäget att skriva program som använder tillgångar. Mönster som att överföra tillgångar till/från procedurer eller att lagra tillgångar i strukturer kräver särskilt stöd från språket.

Underskottet kan inte expanderas... Språket representerar bara en knapp tillgång. Dessutom är lösningarna mot knapphet kopplade direkt till semantiken i själva språket. Utvecklaren, om han vill skapa en anpassad tillgång, måste noggrant kontrollera alla aspekter av resursen själv. Detta är exakt problemen med Ethereums smarta kontrakt.

Användare utfärdar sina tillgångar, ERC-20-tokens, med heltal för att bestämma både värdet och det totala utbudet. När nya tokens skapas måste smartkontraktskoden oberoende verifiera efterlevnaden av utsläppsreglerna. Dessutom leder den indirekta presentationen av tillgångar i vissa fall till allvarliga fel - dubbelarbete, dubbla utgifter eller till och med fullständig förlust av tillgångar.

Brist på flexibel åtkomstkontroll... Den enda åtkomstkontrollpolicy som för närvarande används är ett signaturschema med asymmetrisk kryptografi. Precis som knapphetsskydd är åtkomstkontrollpolitiken djupt inbäddade i språkets semantik. Men hur man utökar språket så att programmerare kan definiera sin egen åtkomstkontrollpolitik är ofta en mycket knepig uppgift.

Detta gäller även på Ethereum, där smarta kontrakt inte har inbyggt kryptografistöd för åtkomstkontroll. Utvecklare måste ställa in åtkomstkontroll manuellt, till exempel genom att använda onlyOwner-modifieraren.

Även om jag är ett stort fan av Ethereum, tror jag att tillgångsegenskaper bör stödjas av språket av säkerhetsskäl. I synnerhet innebär överföring av Ether till ett smart kontrakt dynamisk utsändning, vilket har introducerat en ny klass av buggar som kallas återinträdessårbarheter. Dynamisk sändning betyder här att exekveringslogiken för koden kommer att bestämmas vid körning (dynamisk) snarare än vid kompilering (statisk).

Således, i Solidity, när kontrakt A anropar en funktion i kontrakt B, kan kontrakt B köra kod som inte var avsedd av kontrakt A:s utvecklare, vilket kan resultera i sårbarheter för återinträde (kontrakt A fungerar av misstag som kontrakt B för att ta ut pengar innan kontosaldot faktiskt dras).

Move Language Design Fundamentals

Första ordningens resurser

På en hög nivå är interaktionen mellan moduler / resurser / procedurer på Move -språket mycket lik relationen mellan klasser / objekt och metoder på OOP -språk.
Move -moduler liknar smarta kontrakt i andra blockchains. Modulen deklarerar resurstyper och procedurer som definierar reglerna för att skapa, förstöra och uppdatera deklarerade resurser. Men allt detta är bara konventioner ("jargong”) I rörelse. Vi kommer att illustrera denna punkt lite senare.

flexibilitet

Move ger Vågen flexibilitet genom skript. Varje transaktion i Vågen innehåller ett skript, vilket i huvudsak är transaktionens kärna. Skriptet kan utföra antingen en specificerad åtgärd, till exempel betalningar till en specificerad lista med mottagare, eller återanvända andra resurser - till exempel genom att anropa en procedur där den allmänna logiken specificeras. Det är därför som Move-transaktionsskript erbjuder större flexibilitet. Ett skript kan använda både engångs- och upprepande beteenden, medan Ethereum bara kan köra repeterbara skript (anropar en metod på en smart kontraktsmetod). Anledningen till att det kallas "återanvändbar" är för att funktionerna i ett smart kontrakt kan utföras flera gånger. (notera: Poängen här är mycket subtil. Å ena sidan finns transaktionsskript i form av pseudo-bytekod även i Bitcoin. Å andra sidan, som jag förstår det, expanderar Move detta språk, faktiskt, till nivån av ett fullfjädrat smart kontraktsspråk).

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

Det körbara formatet Move är bytecode, som å ena sidan är ett språk på högre nivå än assemblerspråk, men lägre nivå än källkoden. Bytekoden kontrolleras i körtid (on-chain) för resurser, typer och minnessäkerhet med hjälp av en bytecode-verifierare och exekveras sedan av tolken. Detta tillvägagångssätt tillåter Move att tillhandahålla källkodens säkerhet, men utan kompileringsprocessen och behovet av att lägga till en kompilator till systemet. Att göra Move till ett bytekodspråk är en riktigt bra lösning. Det behöver inte kompileras från källan, som är fallet med Solidity, och det finns ingen anledning att oroa sig för eventuella fel eller attacker på kompilatorns infrastruktur.

Verifierbarhet

Vi strävar efter att utföra kontroller så enkelt som möjligt, eftersom allt detta görs i kedjan (obs: online, under genomförandet av varje transaktion, så varje försening leder till en avmattning av hela nätverket), men initialt är språkdesignen redo att använda statiska verifieringsverktyg utanför kedjan. Även om detta är mer att föredra, för närvarande har utvecklingen av verifieringsverktyg (som en separat verktygslåda) skjutits upp för framtiden, och nu stöds endast dynamisk verifiering under körning (on-chain).

Modularitet

Move -moduler ger dataabstraktion och lokaliserar kritiska operationer på resurser. Kapslingen som tillhandahålls av modulen, i kombination med det skydd som tillhandahålls av Move -typsystemet, säkerställer att egenskaper som är inställda på modulens typer inte kan kränkas av kod utanför modulen. Detta är en ganska genomtänkt abstraktionsdesign, vilket innebär att data inom ett kontrakt bara kan förändras inom kontraktets omfattning, men inte externt.

Flytta översikt

Transaktionsskriptsexemplet visar att skadliga eller slarviga handlingar från en programmerare utanför en modul inte kan äventyra säkerheten för en modulresurser. Därefter tittar vi på exempel på hur moduler, resurser och procedurer används för att programmera Libra blockchain.

Peer-to-Peer-betalningar

Antalet mynt som anges i belopp kommer att överföras från avsändarens saldo till mottagaren.
Det finns några nya saker här (markerade i rött):

• 0x0: adressen till kontot där modulen är lagrad
• Valuta: modulnamn
• Coin: resurstyp
• Myntvärdet som returneras av proceduren är ett resursvärde av typen 0x0.Currency.Coin
• flytta (): värde kan inte användas igen
• kopiera(): värde kan användas senare

Analysera koden: i det första steget ringer avsändaren ett förfarande med namnet uttag_från_avsändare från en modul lagrad i 0x0.Valuta. I det andra steget överför avsändaren pengar till mottagaren genom att flytta myntresursvärdet till modulens insättningsprocedur 0x0.Valuta.

Här är tre exempel på fel i kod som kommer att avvisas genom kontroller:
Duplicera pengar genom att ändra samtalet flytta (mynt) på kopia (mynt). Resurser kan bara flyttas. Försöker duplicera en kvantitet av en resurs (till exempel genom att ringa kopia (mynt) i exemplet ovan) kommer att resultera i ett fel vid kontroll av bytekoden.

Återanvändning av medel genom att ange flytta (mynt) två gånger . Lägger till en rad 0x0.Currency.deposit (kopia (some_other_payee), move (mynt)) till exempel kommer ovanstående att tillåta avsändaren att "spendera" mynten två gånger - den första gången med betalningsmottagaren och den andra med någon_annan_betalningsmottagare. Detta är ett oönskat beteende som inte är möjligt med en fysisk tillgång. Lyckligtvis kommer Move att avvisa detta program.

Förlust av medel på grund av vägran flytta (mynt). Om du inte flyttar resursen (till exempel genom att ta bort raden som innehåller flytta (mynt)), kommer ett bytekodverifieringsfel att visas. Detta skyddar Move-programmerare från oavsiktlig eller uppsåtlig förlust av pengar.

Valutamodul

Varje konto kan innehålla 0 eller flera moduler (visas som rektanglar) och ett eller flera resursvärden (visas som cylindrar). Till exempel ett konto hos 0x0 innehåller modul 0x0.Valuta och resurstypens värde 0x0.Currency.Coin. Konto på adress 0x1 har två resurser och en modul; Konto på adress 0x2 har två moduler och ett resursvärde.

Några ögonblick:

• Transaktionsskriptet är atomärt - antingen körs det helt eller inte alls.
• En modul är en långlivad kod som är globalt tillgänglig.
• Det globala tillståndet är strukturerat som en hashtabell, där nyckeln är kontoadressen
• Konton får inte innehålla mer än ett resursvärde av en given typ och inte mer än en modul med ett givet namn (konto på 0x0 kan inte innehålla en extra resurs 0x0.Currency.Coin eller en annan modul som heter Valuta)
• Adressen till den deklarerade modulen är en del av typen (0x0.Currency.Coin и 0x1.Currency.Coin är separata typer som inte kan användas omväxlande)
• Programmerare kan lagra flera instanser av denna typ av resurs i ett konto genom att definiera deras anpassade resurs - (resurs TwoCoins {c1: 0x0.Currency.Coin, c2: 0x0.Currency.Coin})
• Du kan referera till en resurs med dess namn utan konflikter, till exempel kan du referera till två resurser med hjälp av TwoCoins.c1 и TwoCoins.c2.

Meddelande om myntresurser

Modulen heter Valuta och en resurstyp namngiven Coin

Några ögonblick:

• Coin är en struktur med ett typfält u64 (64-bitars osignerat heltal)
• Endast modulprocedurer Valuta kan skapa eller förstöra värden av typ Coin.
• Andra moduler och skript kan endast skriva eller referera till värdefältet genom offentliga procedurer som tillhandahålls av modulen.

Försäljning av pant

Denna procedur accepterar en resurs Coin som input och kombinerar den med resursen Coinlagras på mottagarens konto:

1. Förstör inmatningsresursen Coin och registrera dess värde.
2. Ta emot en länk till en unik myntresurs lagrad på mottagarens konto.
3. Ändra värdet på antalet mynt med värdet som skickas i parametern när proceduren anropas.

Några ögonblick:

• Packa upp, BorrowGlobal - inbyggda rutiner
• Packa upp Detta är det enda sättet att ta bort en resurs av typ T. Proceduren tar en resurs som indata, förstör den och returnerar värdet som är associerat med resursens fält.
• BorrowGlobal tar en adress som indata och returnerar en referens till en unik instans av T publicerad (ägd) av den adressen
• &mut Mynt detta är en länk till resursen Coin

Implementering av draw_from_sender

Denna procedur:

1. Får en länk till en unik resurs Coin, kopplat till avsändarens konto
2. Minskar värdet på en resurs Coin via länken för angivet belopp
3. Skapar och returnerar en ny resurs Coin med uppdaterat saldo.

Några ögonblick:

• Deposition kan orsakas av vem som helst, men uttag_från_avsändare har endast tillgång till mynten på det ringande kontot
• GetTxnSenderAddress Liknande msg.avsändare i Soliditet
• Avvisa Om inte Liknande kräver i Soliditet. Om denna kontroll misslyckas stoppas transaktionen och alla ändringar återställs.
• Packa det är också en inbyggd procedur som skapar en ny resurs av typ T.
• Såväl som Packa upp, Packa kan endast anropas inne i modulen där resursen beskrivs T

Slutsats

Vi undersökte huvudegenskaperna hos Move-språket, jämförde det med Ethereum och blev också bekanta med den grundläggande syntaxen för skript. Slutligen rekommenderar jag starkt att kolla in original vitt papper. Den innehåller mycket detaljer om designprinciper för programmeringsspråk, såväl som många användbara länkar.

Källa: will.com