Introduktion till smarta kontrakt

I denna artikel går vi igenom vad smarta kontrakt är, vilka typer som finns, vi bekantar oss med olika plattformar för smarta kontrakt, deras egenskaper, samt diskuterar hur de fungerar och vilka fördelar de kan ha. Detta material kommer vara mycket användbart för läsare som inte är tillräckligt bekanta med ämnet smarta kontrakt, men som vill närma sig en förståelse för det.

Vanligt kontrakt vs. smart kontrakt

Innan vi fördjupar oss i detaljerna, låt oss ta ett exempel för att förklara skillnaderna mellan ett vanligt kontrakt, som skrivs på papper, och ett smart kontrakt, som finns i digital form.

Hur fungerade det innan smarta kontrakt? Tänk dig en grupp människor som vill ställa upp vissa regler och villkor för fördelningen av värden samt ha en mekanism som garanterar att fördelningen sker enligt dessa regler och villkor. Då samlades de och skrev ner sina identifierande uppgifter, villkoren, de involverade värdena, satte datum och signerade. Detta kontrakt blev sedan granskat av en betrodd part, exempelvis en notarie. Därefter gick dessa personer skilda vägar med sina papperskopior av kontraktet och började utföra åtgärder som kanske inte överensstämde med själva kontraktet, det vill säga de gjorde en sak, men på papperet var det bekräftat att de skulle göra något helt annat. Och hur löser man denna situation? I praktiken behövde någon av deltagarna i gruppen ta detta papper, ta fram bevis och föra det till domstol för att kräva överensstämmelse mellan kontraktet och de faktiska åtgärderna. Det är ganska ofta svårt att uppnå rättvis fullgörande av detta kontrakt, vilket leder till otrevliga konsekvenser.

Vad kan man säga om smarta kontrakt? De förenar både möjligheten att skriva kontraktsvillkor och mekanismen för strikt efterlevnad av dessa. Om villkoren har ställts upp och en motsvarande transaktion eller begäran har signerats, så är det efter att begäran eller transaktion har accepterats inte längre möjligt att ändra villkoren eller påverka deras utförande.

Det finns en eller flera validators samt en databas som lagrar alla smarta kontrakt som har skickats för att utföras i strikt kronologisk ordning. Det är också viktigt att denna databas ska innehålla alla villkor och triggers för att utföra det smarta kontraktet. Dessutom måste den ta hänsyn till det värde vars fördelning beskrivs i kontraktet. Om detta rör en viss digital valuta, måste denna databas också ha den informationen.

Med andra ord måste validators för smarta kontrakt ha tillgång till all den information som smarta kontrakt hanterar. Till exempel bör en databas användas för att spåra digitala valutor, användarbalanser, användartransaktioner och tidsstämplar samtidigt. Då kan villkoret i det smarta kontraktet vara användarens balans i en specifik valuta, inträffandet av viss tid, eller att en viss transaktion har genomförts, men inte mer.

Definition av smart kontrakt

Själva terminologin myntades av forskaren Nick Szabo och användes för första gången 1994, samt dokumenterades 1997 i en artikel som beskriver själva idén bakom smarta kontrakt.

Smarta kontrakt implicerar att det finns en automatisering av värdespridning, som endast kan bero på de villkor som har förinställts. I sin enklaste form ser det ut som ett kontrakt med strikt fastställda villkor som har signerats av specifika parter.

Smarta kontrakt syftar till att minimera tilliten till tredje parter. Ibland utesluts helt ett beslutsfattande centrum, vilket allt handlar om. Dessutom är det enklare att utföra revisioner för sådana kontrakt. Detta är en följd av vissa designfunktioner av sådana system, men oftast förstår vi med smarta kontrakt en decentraliserad miljö och förekomsten av funktioner som gör att alla intresserade kan analysera databasen och genomföra en fullständig revision av kontraktens genomförande. Detta garanterar skydd mot ändringar av data i efterhand, vilket skulle påverka genomförandet av själva kontraktet. Digitalisering av de flesta processer vid skapandet och lanseringen av ett smart kontrakt förenklar ofta teknologin och kostnaden för deras genomförande.

Ett enkelt exempel — Escrow-tjänst

Låt oss titta på ett mycket enkelt exempel. Det kommer att hjälpa till att förstå de funktionen hos smarta kontrakt bättre och att navigera i vilka situationer de är lämpliga att använda.

Det kan också genomföras med hjälp av Bitcoin, även om Bitcoin för närvarande fortfarande är svårt att kalla en fullfjädrad plattform för smarta kontrakt. Så vi har en köpare och en webbutik. Köparen vill köpa en skärm från denna butik. I det enklaste fallet gör köparen en betalning och skickar den, och webbutiken accepterar den, bekräftar den och skickar sedan varan. Men i denna situation finns det ett stort behov av tillit — köparen måste lita fullt ut på webbutiken för hela beloppet av skärmen. Eftersom webbutiken kan ha ett lågt rykte i köparens ögon, finns det en risk att butiken av någon anledning vägrar att fullfölja beställningen efter att ha mottagit betalningen och inte skickar varan till köparen. Därför undrar köparen (och webbutiken ställer också denna fråga) vad som kan tillämpas för att minimera sådana risker och göra liknande affärer mer tillförlitliga.

I fallet med Bitcoin kan man ge möjligheten för köparen och säljaren att oberoende välja en medlare. Det finns många personer som arbetar med att lösa tvister. Vår deltagare kan välja en medlare från en gemensam lista som de båda kan lita på. Tillsammans skapar de en multisignaturadress 2 av 3, där det finns tre nycklar och två signaturer från vilka som helst av de två nycklarna krävs för att spendera mynten från denna adress. En nyckel kommer att tillhöra köparen, den andra webbutiken och den tredje medlaren. Och på denna multisignaturadress kommer köparen att skicka beloppet som krävs för att betala för skärmen. Nu, när säljaren ser att pengarna är blockerade på multisignaturadressen som är kopplad till honom under en tid, kan han tryggt skicka skärmen med post.

Köparen får sedan paketet, granskar varan och fattar ett beslut om det slutgiltiga köpet. Han kan vara helt nöjd med den tillhandahållna servicen och signera transaktionen med sin nyckel, där han överför mynt från säljarnas multisignaturadress, eller så kan han vara missnöjd. I det andra fallet kontaktar han medlaren för att upprätta en alternativ transaktion som på annat sätt kommer att fördela dessa mynt.

Anta att monitorn har anlänt något repad och att det inte följde med en kabel för att ansluta till datorn, trots att det stod på webbshoppen att en kabel skulle ingå. Då samlar köparen bevis för att visa medlaren att han har blivit lurad i denna situation: han tar skärmdumpar av webbplatsen, fotograferar kvittot från posten, tar ett foto på reporna på monitorn och visar att förseglingen har brutits och kabeln tagits bort. Webbshoppen å sin sida samlar sina bevis och skickar dem till medlaren.

Medlaren är intresserad av att tillfredsställa både köparens missnöje och webbshopens intressen (det blir tydligt varför senare). Han upprättar en transaktion där mynt från multisignaturadressen kommer att fördelas i viss proportion mellan köparen, webbshoppen och medlaren, eftersom han behåller en del som belöning för sitt arbete. Anta att 90% av hela summan går till säljaren, 5% till medlaren och 5% som kompensation till köparen. Denna transaktion signerar medlaren med sin nyckel, men den kan ännu inte tillämpas, eftersom det behövs två signaturer, men det finns bara en. Han skickar denna transaktion till både köparen och säljaren. Om åtminstone en av dem är nöjd med detta förslag för omfördelningen av mynt, så kommer transaktionen att undertecknas och spridas i nätverket. För att validera den räcker det att en av deltagarna i affären samtycker till medlarens förslag.

Det är viktigt att från början välja en medlare som båda parter har förtroende för. I så fall kommer han att agera oberoende av intressen hos någon av parterna och objektivt bedöma situationen. Om medlaren inte erbjuder en fördelning av mynt som tillfredsställer åtminstone en av parterna, kan både köparen och e-handelsbutiken, genom att enas, överföra mynten till en ny multisignaturadress och sätta sina två underskrifter. Den nya multisignaturadressen kommer att bestå av en annan medlare, som kanske är mer kompetent i frågan och kan erbjuda ett bättre alternativ.

Exempel med studenthem och kylskåp

Låt oss titta på ett mer komplext exempel som tydligare illustrerar möjligheterna med smarta kontrakt.

Anta att det finns tre killar som nyligen har flyttat in i samma rum i ett studenthem. De är alla intresserade av att köpa ett kylskåp som de kommer att använda gemensamt i sitt rum. En av dem erbjuder sig att samla ihop det nödvändiga beloppet för att köpa kylskåpet och förhandla med säljaren. Men de har relativt nyligen lärt känna varandra och har inte tillräckligt med förtroende för varandra. Det är uppenbart att två av dem riskerar att ge pengar till den tredje. Dessutom måste de nå en överenskommelse om valet av säljare.

De kan använda en escrow-tjänst, det vill säga välja en medlare som kontrollerar genomförandet av affären och löser eventuella tvister som kan uppstå. Då, genom att enas, skriver de ett smart kontrakt och specificerar vissa villkor.

Det första villkoret är att innan en viss tidpunkt, säg under en vecka, måste tre betalningar göras till det aktuella smartkontraktets konto från angivna adresser på ett specificerat belopp. Om detta inte sker, avbryts smartkontraktet och mynten returneras till alla deltagare. Om villkoret däremot uppfylls, ställs säljare och medlare identifieringsnummer, och det kontrolleras att alla deltagare är överens om valet av säljare och medlare. När alla villkor har uppfyllts kommer medlen att överföras till de angivna adresserna. Denna metod kan skydda deltagarna från bedrägerier från vilken sida som helst och eliminerar i stort sett behovet av att lita på andra.

Vi ser i detta exempel själva principen att möjligheten att stegvis fastställa parametrar för att uppfylla varje villkor gör att system av alla svårighetsgrader och djup av nivåer kan skapas. Dessutom kan första villkoret först definieras i smartkontraktet, och först efter att det har uppfyllts kan parametrar för nästa villkor fastställas. Med andra ord, formellt skrivs villkoret ut, men parametrarna för det kan sättas under dess verkställande.

Klassificering av smartkontrakt

För klassificering kan olika grupper av kriterier anges. Men för närvarande är fyra av dem relevanta i teknologins utveckling.

Smartkontrakt kan skiljas åt beroende på exekveringsmiljön, som kan vara antingen centraliserad eller decentraliserad. Vid decentralisering har vi mycket större oberoende och motståndskraft vid utförande av smartkontrakt.

De kan också skiljas åt efter processen för att ange och utföra villkor: de kan vara fritt programmerbara, begränsade eller förinställda, det vill säga strikt typade. När det på smartkontraktsplattformen endast finns 4 specifika smartkontrakt, kan parametrarna för dem anges på ett godtyckligt sätt. Därför är det mycket enklare att ställa in dem: vi väljer kontraktet från listan och överför parametrarna.

Det finns automatiserade smarta kontrakt som initieras av vissa villkor, vilket innebär att de körs automatiskt när dessa villkor uppfylls. Det finns också kontrakt där villkoren är definierade, men plattformen kontrollerar inte automatiskt deras uppfyllelse; dessa måste initieras separat.

Dessutom varierar smarta kontrakt beroende på nivå av privatliv. De kan vara helt öppna, delvis öppna eller helt konfidentiella. Det sistnämnda innebär att externa observatörer inte ser villkoren för de smarta kontrakten. Emellertid är ämnet privatliv mycket omfattande och bör behandlas separat från den aktuella artikeln.

Nedan kommer vi att fokusera mer på de tre första kriterierna för att klargöra förståelsen av det aktuella ämnet.

Smarta kontrakt utifrån körningsmiljö

Utifrån körningsmiljö särskiljs centraliserade och decentraliserade plattformar för smarta kontrakt. I fallet med centraliserade digitala kontrakt används en enda tjänst där det finns en enda validerare, och det kan finnas en back-up och återställningstjänst som också hanteras centraliserat. Det finns en databas som lagrar all nödvändig information för att ställa in villkoren för det smarta kontraktet och fördelning av det värde som redovisas i denna databas. Denna centraliserade tjänst har en klient som sätter villkoren med specifika förfrågningar och använder dessa kontrakt. Eftersom plattformen är centraliserad kan autentiseringsmekanismerna vara mindre pålitliga än inom kryptovalutor.

Som ett exempel kan vi ta mobiloperatörer (olika teleoperatörer). Anta att en viss operatör på sina servrar på ett centraliserat sätt hanterar trafik som kan överföras i olika format, till exempel som röstsamtal, SMS-överföringar, mobil Internet-trafik, och enligt olika standarder, samt hanterar kontobalanser hos användare. Följaktligen kan mobiloperatören skapa kontrakt för redovisning av de tjänster som erbjuds och deras betalningar med olika villkor. I sådana fall är det lätt att ange villkor såsom ”skicka ett SMS med en viss kod till ett visst nummer för att få sådana och sådana villkor för trafikfördelning.”

Ett annat exempel kan vara: traditionella banker med utvidgad funktionalitet för internetbanking och väldigt enkla kontrakt, som återkommande betalningar, automatisk konvertering av inkommande betalningar, automatiska avdrag av procent på det angivna kontot och så vidare.

När det handlar om smarta kontrakt med en decentraliserad utförandemiljö har vi då en grupp validerare. Idealt kan vem som helst bli en validerare. Genom databasens synkroniseringsprotokoll och uppnådd konsensus har vi en gemensam databas som nu kommer att lagra alla transaktioner med strikt beskrivna kontrakt, istället för ospecificerade förfrågningar vars format ofta ändras utan någon öppen specifikation. Här innehåller transaktionerna instruktioner för att genomföra kontraktet enligt den strikta specifikationen. Denna specifikation är öppen, vilket innebär att användarna av plattformen själva kan genomföra revision och validera smarta kontrakt. Här ser vi att decentraliserade plattformar överträffar centraliserade i fråga om oberoende och felresistens, men deras design och underhåll är betydligt mer komplicerade.

Smarta kontrakt baserat på sättet att ange och genomföra villkor

Låt oss nu gå in på hur smarta kontrakt kan skilja sig åt i sättet att ange och genomföra villkor. Här kommer vi att fokusera på smarta kontrakt som programmeras fritt och är Turing-kompletta. Ett Turing-komplett smart kontrakt gör det möjligt att ställa nästan vilka algoritmer som helst som villkor för genomförandet av kontraktet: skriva loopar, funktioner för sannolikhetsberäkning och så vidare — även egna algoritmer för elektronisk signatur. I det här fallet handlar det verkligen om en godtycklig skrivning av logik.

Det finns också godtyckliga smarta kontrakt som inte är Turing-kompletta. Hit hör Bitcoin och Litecoin med sitt skript. Här innebär det att man i godtycklig ordning kan använda endast vissa operationer, men man kan inte skriva loopar eller egna algoritmer.

Dessutom finns det plattformar för smarta kontrakt som implementerar förinställda smarta kontrakt. Dessa inkluderar Bitshares och Steemit. Bitshares har en rad olika smarta kontrakt för handel, kontoadministration och plattformens parameterhantering. Steemit är en liknande plattform, men den är inte inriktad på tokenutgivning och handel som Bitshares, utan på bloggande, det vill säga den lagrar och bearbetar innehåll på ett decentraliserat sätt.

Bland de allmänna Turing-kompletta kontrakten kan vi räkna plattformarna Ethereum och RootStock, som fortfarande är under utveckling. Därför kommer vi längre fram att titta närmare på Ethereum-smarta kontraktsplattformen.

Smarta kontrakt efter initiationsmetod

Efter initiationsmetod kan smarta kontrakt också delas in i minst två grupper: automatiserade och manuella (icke-automatiserade). Automatiserade kontrakt kännetecknas av att de vid kända parametrar och inträffade villkor genomförs helt automatiskt, vilket innebär att det inte krävs några ytterligare transaktioner eller avgifter för varje efterföljande genomförande. Plattformen har all information för att beräkna hur det smarta kontraktet kommer att avslutas. Logiken är inte godtycklig, utan fördefinierad, och allt detta är förutsägbart. Det innebär att man i förväg kan bedöma komplexiteten i att genomföra det smarta kontraktet, använda en konstant avgift för det och alla processer för dess genomförande går mer effektivt.

För smarta kontrakt som programmeras på ett godtyckligt sätt är genomförande inte automatiserat. För att initiera ett sådant smart kontrakt måste man i princip skapa en ny transaktion vid varje steg, vilket kommer att åberopa nästa steg i genomförandet eller nästa metod för det smarta kontraktet, betala den relevanta avgiften och vänta på transaktionsbekräftelse. Genomförandet kan avslutas framgångsrikt eller inte, eftersom koden för det smarta kontraktet är godtycklig och det kan ge upphov till oförutsägbara situationer, såsom oändliga loopar, brist på vissa parametrar och argument, ohanterade undantag och så vidare.

Konton i Ethereum

Typer av Ethereum-konton

Låt oss titta på vilka typer av konton som kan finnas på Ethereum-plattformen. Här finns det endast två typer av konton, och inga fler alternativ än så. Den första typen kallas användarkonto, den andra — kontraktskonto. Låt oss förstå vad som skiljer dem åt.

Användarkontot styrs endast av en privat nyckel för elektronisk signatur. Kontoinnehavaren genererar sitt eget nyckelpar för elektronisk signatur med algoritmen ECDSA (Elliptic Curve Digital Signature Algorithm). Endast transaktioner som är signerade med denna nyckel kan ändra tillståndet för kontot.

För kontraktskontot finns det en separat logik. Det kan endast styras genom fördefinierad programkod, som helt bestämmer beteendet hos kontraktet: hur det kommer att hantera sina mynt under vissa omständigheter, på initiativ av vilken användare och under vilka ytterligare villkor mynten kommer att distribueras. Om vissa aspekter inte täcks av utvecklarna i programkoden kan det uppstå problem. Till exempel kan kontraktet hamna i ett visst tillstånd där det inte accepterar initiativ för fortsatt utförande från någon användare. I så fall kommer mynten i praktiken att vara frysta, eftersom kontraktet inte förutsätter en väg ut ur detta tillstånd.

Hur konton skapas i Ethereum

När det gäller användarkontot genererar ägaren själv ett nyckelpar med ECDSA. Det är viktigt att notera att Ethereum använder exakt samma algoritm och samma elliptiska kurva för elektronisk signatur som Bitcoin, men adressen beräknas på ett något annat sätt. Här används inte resultatet av dubbel hashning, som i Bitcoin, utan enkel hashning med funktionen Keccak på 256 bitars längd. De 160 lägsta bitarna av hash-funktionens utdata tas bort. Resultatet blir en adress i Ethereum. Faktiskt tar den upp 20 byte.

Vi noterar att kontoidentifieraren i Ethereum kodas i hex utan checksumma, till skillnad från Bitcoin och många andra system där adressen kodas i bas 58 med tillägg av checksumma. Detta innebär att man måste vara försiktig när man arbetar med kontoidentifierare i Ethereum: även ett enda fel i identifieraren kommer garanterat att leda till förlust av mynt.

Det finns en viktig egenhet, och den går ut på att användarens konto på nivån av den allmänna databasen skapas i det ögonblick han accepterar den första inkommande betalningen.

När det gäller skapandet av smarta kontrakt tillämpas ett helt annat tillvägagångssätt. Först skriver någon av användarna källkoden för det smarta kontraktet, varefter koden körs genom en kompilerare speciellt för Ethereum-plattformen, vilket ger bytekod för den egna Ethereum-virtuella maskinen. Den resulterande bytekoden placeras i ett speciellt fält i transaktionen. Denna transaktion undertecknas av initiatorens konto. Därefter sprids denna transaktion genom nätverket och publicerar koden för det smarta kontraktet. Avgiften för genomförandet av transaktionen och därmed för utförandet av kontraktet dras från initiatorens konto.

Varje smart kontrakt innehåller alltid sin konstruktör (till detta kontrakt). Den kan vara tom, men den kan också ha innehåll. Efter att konstruktören har körts skapas en kontoidentifierare för det smarta kontraktet, med hjälp av vilken mynt kan skickas, vissa metoder för det smarta kontraktet kan anropas, etc.

Strukturen för Ethereum-transaktionen

För att göra det tydligare börjar vi titta på strukturen av Ethereum-transaktionen och ett exempel på koden för smarta kontrakt.

Ethereum-transaktionen består av flera fält. Det första av dem, nonce, är ett visst sekvensnummer för transaktionen i förhållande till det konto som sprider den och är dess författare. Detta behövs för att särskilja dubletter av transaktioner, det vill säga för att utesluta situationer där samma transaktion tas emot två gånger. Tack vare användningen av identifieraren har varje transaktion ett unikt hash-värde.

Därefter följer ett fält som kallas gas price. Här anges priset, vid vilket basvalutan Ethereum konverteras till gas, som används för att betala för genomförandet av smarta kontrakt och tilldelning av resurser för den virtuella maskinen. Vad betyder detta?

I Bitcoin betalas avgifterna direkt med basvalutan — själva bitcoin. Detta är möjligt tack vare en enkel beräkningsmekanism: vi betalar strikt för mängden data som finns i transaktionen. I Ethereum är situationen mer komplicerad, eftersom det är väldigt svårt att utgå från volymen data i transaktionen. Här kan transaktionen dessutom innehålla programkod som kommer att köras på den virtuella maskinen, och varje operation på den virtuella maskinen kan ha olika svårighetsgrader. Det finns också operationer som allokerar minne för variabler. De kommer att ha sin svårighetsgrad, som kommer att påverka betalningen för varje operation.

Kostnaden för varje operation i gas-ekvivalent kommer att vara konstant. Den införs specifikt för att bestämma den konstanta kostnaden för varje operation. Beroende på belastningen på nätverket kommer gaspriset att förändras, det vill säga koefficienten enligt vilken basvalutan kommer att konverteras till denna hjälp-enhet för att betala avgifter.

Det finns ytterligare en egenskap hos transaktionen i Ethereum: byte-koden som den innehåller för att utföras på den virtuella maskinen, kommer att köras tills den är klar med något resultat (framgång-eller-fel) eller tills det belopp av mynt som avsatts för att betala avgiften är slut. För att undvika en situation där alla mynt på avsändarens konto försvinner på avgiften i händelse av ett fel (till exempel om en oändlig cykel har startats på den virtuella maskinen), finns det följande fält — startgas (det kallas ofta gasgräns) — det definierar den maximala mängden mynt som avsändaren är beredd att spendera för att genomföra en viss transaktion.

Det följande fältet kallas destination address. Hit skrivs mottagarens adress för mynten eller adressen till ett specifikt smart kontrakt vars metoder kommer att anropas. Efter detta följer fältet value, där summan av mynt som skickas till destination address skrivs.

Därefter finns det ett intressant fält som kallas data, där en hel struktur fylls i. Det är inte ett separat fält, utan en hel struktur där koden för den virtuella maskinen definieras. Här kan man lägga in godtyckliga data — det finns särskilda regler för detta.

Det sista fältet kallas signatur. Det innehåller både den elektroniska signaturen från författaren av denna transaktion och den offentliga nyckeln som kommer att användas för att verifiera denna signatur. Från den offentliga nyckeln kan man få fram identifieraren för avsändarens konto för denna transaktion, vilket unikt identifierar avsändarkontot inom systemet. Vi har nu klargjort det väsentliga med transaktionsstrukturen.

Exempel på smart kontrakt i Solidity

Låt oss nu titta närmare på det enklaste smarta kontraktet som exempel.

contract Bank {
    address owner;
    mapping(address => uint) balances;
    
    function Bank() {
        owner = msg.sender;
    }

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint amount) public {
        if (balances[msg.sender] >= amount) {
            balances[msg.sender] -= amount;
            msg.sender.transfer(amount);
        }
    }

    function getMyBalance() public view returns(uint) {
        return balances[msg.sender];
    }

    function kill() public {
        if (msg.sender == owner)
            selfdestruct(owner);
    }
}

Ovan finns en förenklad källkod som kan hålla användarnas mynt och återlämna dem på begäran.

Så, det finns ett smart kontrakt Bank som utför följande funktioner: det ackumulerar mynt på sin balans, det vill säga när en transaktion bekräftas och ett sådant smart kontrakt placeras, skapas ett nytt konto som kan ha mynt på sin balans; det kommer ihåg användarna och fördelningen av mynt mellan dem; har flera metoder för att hantera balanser, det vill säga det finns möjligheter för insättning, uttag och kontroll av användarens balans.

Låt oss gå igenom varje rad i källkoden. I detta kontrakt finns det konstanta fält. Ett av dem, av typen address, kallas owner. Här minns kontraktet adressen till användaren som skapade detta smarta kontrakt. Dessutom finns det en dynamisk struktur som lagrar motsvarigheter mellan användares adresser och balanser.

Efter detta följer metoden Bank — den kallas samma som kontraktet. Därmed är detta dess konstruktor. Här tilldelas variabeln owner adressen till den som la upp detta smarta kontrakt på nätet. Det är det enda som sker i denna konstruktor. Således är msg i detta fall just de data som överfördes till den virtuella maskinen tillsammans med transaktionen som innehöll hela koden för detta kontrakt. Därmed är msg.sender avsändaren av denna transaktion som lägger upp denna kod. Denne blir ägaren av det smarta kontraktet.

Metoden deposit tillåter att överföra ett visst antal mynt till kontraktskontot via en transaktion. I detta fall behåller smartkontraktet dessa mynt på sin balans, men registrerar i strukturen balances vem som exakt var avsändaren av dessa mynt för att veta vem de tillhör.

Den följande metoden kallas withdraw och den tar ett parameter — det belopp av mynt som någon vill ta ut från denna bank. Här sker en kontroll för att se om det finns tillräckligt med mynt på användarens balans som anropar denna metod, för att skicka dem. Om det finns tillräckligt, återvänder smartkontraktet det angivna antalet mynt till den som anropar.

Därefter finns en metod för att kontrollera användarens aktuella balans. Den som anropar denna metod kommer att användas för att hämta denna balans i smartkontraktet. Det bör noteras att modifieraren för denna metod är view. Detta innebär att metoden inte ändrar klassens variabler och den är faktiskt endast en läsmetod. Ingen separat transaktion skapas för att anropa denna metod, ingen avgift betalas, och alla beräkningar görs lokalt, varefter användaren får resultatet.

Metoden kill behövs för att förstöra tillståndet av smartkontraktet. Här finns en ytterligare kontroll som ser om den som anropar denna metod är ägaren av kontraktet. Om så är fallet, kommer kontraktet att självförstöra sig och funktionen för förstörelse tar ett parameter — kontots identifierare dit kontraktet kommer att skicka alla mynt som finns kvar på dess balans. I detta fall kommer de kvarvarande mynten automatiskt att gå till ägarens adress.

Hur fungerar ett fullständigt nod i Ethereum-nätverket?

Låt oss schematiskt betrakta hur exekveringen av sådana smartkontrakt på Ethereum-plattformen sker och hur ett fullständigt nod i nätverket fungerar.

Ett fullständigt nod i Ethereum-nätverket måste minst ha fyra moduler.
Den första, som för alla decentraliserade protokoll, är P2P networking module — nätverksmodulen för att ansluta till och arbeta med andra noder, där utbyte av block, transaktioner och information om andra noder sker. Detta är en traditionell komponent för alla decentraliserade kryptovalutor.

Vidare har vi en modul för lagring av blockchain-data, processering, val av prioriterad kedja, tillägg av block, avskiljning av block, verifiering av dessa block etc.

Den tredje modulen kallas EVM (Ethereum Virtual Machine) — det är virtuell maskin, som tar emot bytekod från Ethereum-transaktioner. Denna modul tar emot det aktuella tillståndet för ett visst konto och utför förändringar av dess tillstånd baserat på den mottagna bytekoden. Versionen av den virtuella maskinen på varje nätverksnod måste vara densamma. Beräkningarna på varje Ethereum-nod är exakt lika, men de sker i asynkron ordning: någon bekräftar och accepterar denna transaktion tidigare, det vill säga kör hela koden i den, medan någon gör det senare. Därför, när en transaktion skapas, sprids den i nätverket, noderna accepterar den och vid verifieringssteget, precis som i Bitcoin, utförs Bitcoin Script, här körs bytekoden av den virtuella maskinen.

En transaktion anses vara verifierad om all kod som finns i den har körts, ett nytt tillstånd för det angivna kontot har genererats och detta tillstånd sparas tills det är klart om transaktionen har tillämpats eller ej. Om transaktionen har tillämpats, då anses detta tillstånd inte bara vara utfört, utan också aktuellt. Det finns en databas som lagrar tillståndet för varje konto för varje nod i nätverket. Eftersom alla beräkningar sker likadant och blockchainens tillstånd är densamma, så kommer även databasen som innehåller tillstånden för alla konton att vara densamma för varje nod.

Myter och begränsningar för smarta kontrakt

När det gäller begränsningar som existerar för smarta kontrakt på plattformar liknande Ethereum kan följande nämnas:

• kodexekvering;
• allokera minne;
• blockchain-data;
• skicka betalningar;
• skapa nya kontrakt;
• anropa andra kontrakt.

Låt oss titta på de begränsningar som åläggs den virtuella maskinen och därför avliva vissa myter om smarta kontrakt. På den virtuella maskinen, som kan finnas inte bara i Ethereum utan även i liknande plattformar, kan man utföra verkligen godtyckliga logiska operationer, det vill säga skriva kod som kommer att köras där, och dessutom är det möjligt att allokera minne. Dock betalas avgiften separat för varje operation och för varje ytterligare allokerad enhet av minneskapacitet.

Vidare kan den virtuella maskinen läsa data från blockkedjans databas, för att använda dessa data som en trigger för att utföra olika logiker i smarta kontrakt. Den virtuella maskinen kan skapa och skicka transaktioner, den kan skapa nya kontrakt och kalla metoder från andra smarta kontrakt som redan har publicerats på nätverket: de finns, är tillgängliga och så vidare.

Den mest utbredda myten är att Ethereum-smartkontrakt kan använda information från vilken internetresurs som helst i sina villkor. Sanningen är att den virtuella maskinen inte kan skicka ett nätverksanrop till någon extern informationsresurs på internet, det vill säga man kan inte skriva ett sådant smart kontrakt som skulle fördela värde mellan användare utifrån vilket väder som råder, eller vem som har vunnit i en tävling, eller baserat på någon annan händelse i den yttre världen, eftersom information om dessa händelser helt enkelt inte finns i plattformens databas. Det vill säga, på blockkedjan finns inget om detta. Om det inte kommer dit kan den virtuella maskinen inte använda dessa data som triggers.

Nackdelar med Ethereum

Låt oss lista de viktigaste av dem. Den första nackdelen är att det finns vissa svårigheter vid design, utveckling och testning av smarta kontrakt i Ethereum (i Ethereum används programmeringsspråket Solidity för att skriva smarta kontrakt). Faktiskt visar erfarenheten att en stor andel av alla fel beror på mänskliga faktorer. Detta gäller faktiskt också för redan skrivna Ethereum-smarta kontrakt som har medelhög eller hög komplexitet. Om risken för fel är låg för enkla smarta kontrakt, så förekommer det ofta fel i komplexa smarta kontrakt som leder till stöld av medel, frysing av medel, oavsiktlig destruktion av smarta kontrakt osv. Många sådana fall är redan kända.

Den andra nackdelen är att den virtuella maskinen inte är perfekt, eftersom den också är skriven av människor. Den kan utföra godtyckliga kommandon, vilket utgör en sårbarhet: det går att konfigurera en rad kommandon på ett visst sätt som leder till oönskade konsekvenser. Detta är ett mycket komplext område, men det finns redan flera studier som visar att dessa sårbarheter finns i den aktuella versionen av Ethereum-nätverket och att de kan leda till att många smarta kontrakt slutar fungera.

En annan stor svårighet, som kan betraktas som en nackdel, är att man på praktiskt eller tekniskt sätt kan komma fram till att om man komprimerar bytekod för ett kontrakt som ska köras på den virtuella maskinen, kan man bestämma en specifik ordning av operationer. När dessa operationer utförs tillsammans kommer de att belasta den virtuella maskinen betydligt och fördröja den oproportionerligt i förhållande till den avgift som betalats för att utföra dessa operationer.

Tidigare har det funnits perioder i Ethereums utveckling där många som kände till den virtuella maskinens funktioner upptäckte sådana sårbarheter. Faktiskt betalades mycket låga avgifter för transaktionerna, men de saktade nästan ner hela nätverkets funktion kraftigt. Dessa problem är svåra att lösa, eftersom de först måste identifieras, sedan justera kostnaden för att utföra dessa operationer och till sist genomföra en hard fork, vilket innebär en uppdatering av alla nätverksnoder till den nya programvaruversionen, följt av en samtidig aktivering av dessa förändringar.

När det gäller Ethereum har det genomförts många studier och en stor mängd praktisk erfarenhet har samlats: både positiv och negativ, men det kvarstår ändå svårigheter och sårbarheter som måste hanteras på något sätt.

Så, den tematiska delen av artikeln är avslutad, låt oss gå vidare till frågor som dyker upp ganska ofta.

Vanliga frågor

— Om alla parter i ett gällande smart kontrakt vill ändra villkoren, kan de då avsluta detta smarta kontrakt med hjälp av multipartsunderskrift och sedan skapa ett nytt smart kontrakt med uppdaterade villkor för dess genomförande?

Svaret här kommer att vara dubbelt. Varför? För att å ena sidan sätts det smarta kontraktet en gång för alla och implicerar inga förändringar, men å andra sidan kan det ha en förutbestämd logik som möjliggör fullt eller delvis ändring av vissa villkor. Det vill säga, om du vill ändra något i ditt smarta kontrakt måste du på förhand ange de villkor under vilka du kan uppdatera dessa villkor. Därmed kan uppdateringen av kontraktet endast organiseras på ett så förutseende sätt. Men även här kan man stöta på problem: göra något misstag och få en motsvarande sårbarhet. Därför måste sådana saker planeras och testas mycket noggrant.

— Och om medlaren går i samförstånd med en av deltagarna: escrow eller smart kontrakt? Är medlaren obligatorisk i ett smart kontrakt?

En medlare är inte nödvändig i smarterna. Den kan vara frånvarande. Om medlaren i en escrow-överenskommelse skulle samarbeta med en av parterna, så förlorar den modellen snabbt sitt värde. Därför väljs medlare på ett sådant sätt att alla involverade parter litar på dem samtidigt. Därmed kommer du helt enkelt inte att överföra mynt till en multisignaturadress med den medlare du inte litar på.

— Går det att med en transaktion av Ethereum överföra många olika token från din adress till olika måladresser, till exempel börsadresser där dessa token handlas?

Det är en bra fråga och den rör modellen för Ethereum-transaktioner och dess skillnader från Bitcoin-modellen. Skillnaden är radikal. I Ethereum-modellen överför du helt enkelt mynt, och de överförs endast från en adress till en annan, utan växel, bara det specifika beloppet som du angav. Med andra ord, det är inte en modell för obrukade utgångar (UTXO), utan en modell för konton och motsvarande saldon. En transaktion kan teoretiskt sett genomföra flera olika token om man skriver ett smart kontrakt, men man måste ändå göra många transaktioner, skapa kontraktet, överföra token och mynt till det, och sedan anropa motsvarande metod. Detta kräver ansträngning och tid, så i praktiken fungerar det inte så och alla betalningar i Ethereum genomförs som separata transaktioner.

— En av myterna om Ethereum-plattformen är att det är omöjligt att beskriva sådana villkor som beror av data från externa internetresurser, hur ska man göra då?

Lösningen är att själva smartkontraktet kan förutsätta en eller flera så kallade pålitliga orakler, som samlar in data om tillståndet i den externa världen och överför dem till smartkontrakten via speciella metoder. Själva kontraktet anser att de data är sanna som det fått från pålitliga källor. För större tillförlitlighet väljs helt enkelt en större grupp orakler för att minimera risken för samverkan. Själva kontraktet kan ignorera data från orakler som motsäger majoriteten.

Ämnet ägnas åt en av föreläsningarna i onlinekursen om Blockchain — “Introduktion till smarta kontrakt”.

Källa: habr.com