Introduktion till smarta kontrakt

I den här artikeln ska vi titta på vad smarta kontrakt är, vad de är, vi kommer att bekanta oss med olika smarta kontraktsplattformar, deras funktioner, och även diskutera hur de fungerar och vilka fördelar de kan ge. Detta material kommer att vara mycket användbart för läsare som inte är väl bekanta med ämnet smarta kontrakt, men som vill komma närmare att förstå det.

Vanligt kontrakt vs. smart kontrakt

Innan vi fördjupar oss i detaljerna, låt oss ta ett exempel på skillnaderna mellan ett vanligt kontrakt, som är specificerat på papper, och ett smart kontrakt, som representeras digitalt.

Hur fungerade detta innan smarta kontrakt kom? Föreställ dig en grupp människor som vill upprätta vissa regler och villkor för fördelningen av värderingar, samt en viss mekanism för att garantera genomförandet av denna fördelning enligt de givna reglerna och villkoren. Sedan skulle de träffas, upprätta ett papper där de skrev ner sina identifikationsuppgifter, villkoren, de inblandade värdena, datera dem och underteckna dem. Detta kontrakt har också certifierats av en betrodd part, till exempel en notarie. Vidare gick dessa människor åt olika håll med sin papperskopia av ett sådant kontrakt och började utföra några åtgärder som kanske inte motsvarade själva kontraktet, det vill säga de gjorde en sak, men på papper var det intygat att de skulle göra något helt annorlunda. Och hur tar man sig ur denna situation? Faktum är att en av gruppmedlemmarna måste ta detta papper, ta några bevis, ta det till domstol och uppnå överensstämmelse mellan kontraktet och faktiska åtgärder. Ganska ofta är det svårt att uppnå rättvis genomförande av detta kontrakt, vilket leder till obehagliga konsekvenser.

Vad kan man säga om smarta kontrakt? De kombinerar både möjligheten att skriva villkoren i kontraktet och mekanismen för deras strikta genomförande. Om villkoren har ställts och motsvarande transaktion eller begäran har undertecknats, är det inte längre möjligt att ändra villkoren eller påverka implementeringen när den begäran eller transaktionen har accepterats.

Det finns en validator eller ett helt nätverk, samt en databas som lagrar alla smarta kontrakt som lämnats in för utförande i strikt kronologisk ordning. Det är också viktigt att denna databas måste innehålla alla triggervillkor för att utföra det smarta kontraktet. Dessutom måste den ta hänsyn till själva värdet vars fördelning beskrivs i kontraktet. Om detta gäller någon digital valuta, bör denna databas ta hänsyn till det.

Med andra ord måste smarta kontraktsvaliderare ha tillgång till all data som det smarta kontraktet fungerar på. Till exempel bör en enda databas användas för att samtidigt redogöra för digitala valutor, användarsaldon, användartransaktioner och tidsstämplar. Sedan, i ett smart kontrakt, kan villkoret vara användarens saldo i en viss valuta, förekomsten av en viss tid eller det faktum att en viss transaktion har genomförts, men inget mer.

Definition av ett smart kontrakt

I allmänhet myntades själva terminologin av forskaren Nick Szabo och användes först 1994, och dokumenterades 1997 i en artikel som beskriver själva idén med smarta kontrakt.

Smarta kontrakt innebär att viss automatisering av värdefördelning utförs, vilket bara kan bero på de villkor som är förutbestämda i förväg. I sin enklaste form ser det ut som ett kontrakt med strikt definierade villkor, som är undertecknat av vissa parter.

Smarta kontrakt är utformade för att minimera förtroendet för tredje part. Ibland är det beslutscentrum som allt beror på helt uteslutet. Dessutom är sådana kontrakt lättare att granska. Detta är en konsekvens av vissa designfunktioner i ett sådant system, men oftast förstår vi med ett smart kontrakt en decentraliserad miljö och närvaron av funktioner som gör det möjligt för vem som helst att analysera databasen och genomföra en fullständig granskning av utförandet av kontrakt. Detta säkerställer skydd mot retroaktiva dataändringar som skulle medföra förändringar i fullgörandet av själva kontraktet. Digitalisering av de flesta processer när man skapar och lanserar ett smart kontrakt förenklar ofta tekniken och kostnaden för deras implementering.

Ett enkelt exempel - Escrow-tjänst

Låt oss titta på ett mycket enkelt exempel. Det hjälper dig att komma närmare att förstå funktionaliteten hos smarta kontrakt, samt bättre förstå i vilka fall de ska användas.

Det kan även implementeras med Bitcoin, även om Bitcoin just nu knappast kan kallas en fullfjädrad plattform för smarta kontrakt. Så vi har en köpare och vi har en webbutik. En kund vill köpa en bildskärm från denna butik. I det enklaste fallet genomför och skickar köparen en betalning, och webbutiken accepterar den, bekräftar den och skickar sedan varorna. Men i denna situation finns ett behov av stort förtroende - köparen måste lita på nätbutiken för hela kostnaden för monitorn. Eftersom en nätbutik kan ha ett lågt anseende i köparens ögon finns det en risk att butiken av någon anledning efter att ha accepterat betalningen vägrar service och inte skickar varorna till köparen. Därför ställer köparen frågan (och följaktligen ställer onlinebutiken denna fråga) vad som kan användas i det här fallet för att minimera sådana risker och göra sådana transaktioner mer tillförlitliga.

När det gäller Bitcoin är det möjligt att låta köparen och säljaren självständigt välja en medlare. Det finns många människor som är involverade i att lösa kontroversiella frågor. Och våra deltagare kan välja från en allmän lista över medlare den de kommer att lita på. Tillsammans skapar de en 2 av 3 multisignaturadress där det finns tre nycklar och två signaturer med två valfria nycklar krävs för att spendera mynt från den adressen. En nyckel kommer att tillhöra köparen, den andra till nätbutiken och den tredje till medlaren. Och till en sådan multisignaturadress skickar köparen det belopp som krävs för att betala för monitorn. Nu, när säljaren ser att pengar är blockerade under en tid på en multisignaturadress som beror på honom, kan han säkert skicka monitorn med post.

Därefter tar köparen emot paketet, inspekterar varorna och fattar beslut om det slutliga köpet. Han kan helt och hållet gå med på den tillhandahållna tjänsten och underteckna transaktionen med sin nyckel, där han överför mynt från multisignaturadressen till säljaren, eller så kan han vara missnöjd med något. I det andra fallet kontaktar han en medlare för att sätta ihop en alternativ transaktion som kommer att fördela dessa mynt annorlunda.

Låt oss säga att bildskärmen kom lite repad och att satsen inte inkluderade en kabel för anslutning till datorn, även om webbbutikens webbplats sa att kabeln borde ingå i satsen. Sedan samlar köparen in de bevis som krävs för att bevisa för medlaren att han blev lurad i den här situationen: han tar skärmdumpar av webbplatsen, tar ett foto av postkvittot, tar ett foto av reporna på monitorn och visar att förseglingen var trasig och kabeln drogs ut. Nätbutiken samlar i sin tur in sina bevis och överför dem till medlaren.

Medlaren är intresserad av att samtidigt tillfredsställa både köparens indignation och nätbutikens intressen (det kommer att bli klart varför senare). Det utgör en transaktion där mynt från en multisignaturadress kommer att spenderas i någon proportion mellan köparen, nätbutiken och medlaren, eftersom han tar en del för sig själv som belöning för sitt arbete. Låt oss säga att 90 % av det totala beloppet går till säljaren, 5 % till medlaren och 5 % ersättning till köparen. Medlaren undertecknar denna transaktion med sin nyckel, men den kan ännu inte tillämpas, eftersom den kräver två signaturer, men bara en är värd det. Den skickar en sådan transaktion till både köparen och säljaren. Om minst en av dem är nöjd med detta alternativ för omfördelning av mynt, kommer transaktionen att försigneras och distribueras till nätverket. För att validera det räcker det att en av parterna i transaktionen samtycker till medlarens alternativ.

Det är viktigt att först välja en medlare så att båda deltagarna litar på honom. I det här fallet kommer han att agera oberoende av den ena eller den andras intressen och objektivt bedöma situationen. Om förmedlaren inte ger möjlighet att distribuera mynt som tillfredsställer minst en deltagare, kan både köparen och nätbutiken, efter att ha kommit överens, skicka mynten till en ny multisignaturadress genom att sätta sina två signaturer. Den nya multisignaturadressen kommer att sammanställas med en annan medlare, som kan vara mer kompetent i frågan och ge ett bättre alternativ.

Exempel med en sovsal och ett kylskåp

Låt oss titta på ett mer komplext exempel som visar kapaciteten hos ett smart kontrakt mer explicit.

Låt oss säga att det är tre killar som nyligen flyttat in i samma sovsal. De tre är intresserade av att köpa ett kylskåp till sitt rum som de kan använda tillsammans. En av dem anmälde sig frivilligt att samla in den nödvändiga summan för att köpa ett kylskåp och förhandla med säljaren. Men de träffade varandra först nyligen och det finns inte tillräckligt med förtroende mellan dem. Uppenbarligen tar två av dem en risk genom att ge pengar till den tredje. Dessutom måste de komma överens om att välja säljare.

De kan använda depositionstjänsten, det vill säga välja en medlare som kommer att övervaka genomförandet av transaktionen och lösa kontroversiella problem om några uppstår. Sedan, efter att ha kommit överens, upprättar de ett smart kontrakt och föreskriver vissa villkor i det.

Det första villkoret är att innan en viss tidpunkt, säg inom en vecka, måste motsvarande smarta kontraktskonto få tre betalningar från vissa adresser för ett visst belopp. Om detta inte händer slutar det smarta kontraktet att utföras och returnerar mynten till alla deltagare. Om villkoret är uppfyllt ställs värdena för säljarens och medlarens identifierare, och villkoret kontrolleras att alla deltagare är överens om valet av säljare och medlare. När alla villkor är uppfyllda kommer medlen att överföras till de angivna adresserna. Detta tillvägagångssätt kan skydda deltagare från bedrägeri från vilken sida som helst och eliminerar i allmänhet behovet av att lita på.

Vi ser i detta exempel själva principen att denna förmåga att steg-för-steg ställa in parametrar för att uppfylla varje villkor gör att du kan skapa system av vilken komplexitet och djup som helst av kapslade nivåer. Dessutom kan du först definiera det första villkoret i det smarta kontraktet, och först efter att det har uppfyllts kan du ställa in parametrar för nästa villkor. Villkoret är med andra ord formellt skrivet och parametrar för det kan ställas in redan under dess drift.

Klassificering av smarta kontrakt

För klassificering kan du ställa in olika grupper av kriterier. Men i ögonblicket för teknikutvecklingen är fyra av dem relevanta.

Smarta kontrakt kan särskiljas genom sin exekveringsmiljö, som kan vara antingen centraliserad eller decentraliserad. När det gäller decentralisering har vi mycket större oberoende och feltolerans när vi utför smarta kontrakt.

De kan också särskiljas genom processen att ställa in och uppfylla villkor: de kan vara fritt programmerbara, begränsade eller fördefinierade, d.v.s. strikt maskinskrivna. När det bara finns 4 specifika smarta kontrakt på den smarta kontraktsplattformen kan parametrarna för dem ställas in på vilket sätt som helst. Följaktligen är det mycket enklare att ställa in dem: vi väljer ett kontrakt från listan och skickar parametrarna.

Enligt initieringsmetoden finns det automatiserade smarta kontrakt, det vill säga när vissa villkor uppstår är de självutförande, och det finns kontrakt där villkoren är specificerade, men plattformen kontrollerar inte automatiskt att de uppfylls; för detta måste initieras separat.

Dessutom varierar smarta kontrakt i sin integritetsnivå. De kan vara antingen helt öppna, delvis eller helt konfidentiella. Det senare innebär att tredjepartsobservatörer inte ser villkoren för smarta kontrakt. Ämnet om integritet är dock mycket brett och det är bättre att överväga det separat från den aktuella artikeln.

Nedan kommer vi att titta närmare på de tre första kriterierna för att få större klarhet i förståelsen av det aktuella ämnet.

Smarta kontrakt efter körtid

Utifrån exekveringsmiljön skiljer man mellan centraliserade och decentraliserade smarta kontraktsplattformar. Vid centraliserade digitala kontrakt används en enda tjänst, där det bara finns en validator och det kan finnas en backup- och återställningstjänst, som också hanteras centralt. Det finns en databas som lagrar all nödvändig information för att fastställa villkoren för det smarta kontraktet och distribuera värdet som tas med i beräkningen i just denna tjänstedatabas. En sådan centraliserad tjänst har en kund som ställer villkor med vissa förfrågningar och använder sådana kontrakt. På grund av plattformens centraliserade karaktär kan autentiseringsmekanismer vara mindre säkra än i kryptovalutor.

Som exempel kan vi ta mobilkommunikationsleverantörer (olika mobiloperatörer). Låt oss säga att en viss operatör för ett centraliserat register över trafiken på sina servrar, som kan överföras i olika format, till exempel: i form av röstsamtal, SMS-överföring, mobil Internettrafik och enligt olika standarder, och även för register av medel på användarsaldon. Mobilkommunikationsleverantören kan följaktligen upprätta avtal om redovisning av de tillhandahållna tjänsterna och deras betalning med olika villkor. I det här fallet är det lätt att ställa in villkor som "skicka ett SMS med en sådan kod till ett sådant och ett sådant nummer och du kommer att få sådana och sådana villkor för trafikdistribution."

Ytterligare ett exempel kan ges: traditionella banker med utökad funktionalitet av internetbank och mycket enkla kontrakt som regelbundna betalningar, automatisk omvandling av inkommande betalningar, automatisk avdrag av ränta till angivet konto, etc.

Om vi ​​pratar om smarta kontrakt med en decentraliserad exekveringsmiljö så har vi en grupp validerare. Helst kan vem som helst bli validerare. På grund av databassynkroniseringsprotokollet och att nå konsensus har vi en gemensam databas som nu kommer att lagra alla transaktioner med strikt beskrivna kontrakt, och inte några villkorliga frågor, vars format ofta ändras, och det finns ingen öppen specifikation. Här kommer transaktioner att innehålla instruktioner för att utföra kontraktet enligt en strikt specifikation. Denna specifikation är öppen och därför kan plattformsanvändare själva granska och validera smarta kontrakt. Här ser vi att decentraliserade plattformar är överlägsna centraliserade när det gäller oberoende och feltolerans, men deras design och underhåll är mycket mer komplext.

Smarta kontrakt genom metoden att sätta och uppfylla villkor

Låt oss nu titta närmare på hur smarta kontrakt kan skilja sig åt i hur de sätter och uppfyller villkoren. Här riktar vi vår uppmärksamhet mot smarta kontrakt som är slumpmässigt programmerbara och Turing kompletta. Ett Turing-komplett smart kontrakt låter dig ställa in nästan vilka algoritmer som helst som villkor för genomförandet av kontraktet: skrivcykler, vissa funktioner för att beräkna sannolikheter och liknande - ända ner till dina egna elektroniska signaturalgoritmer. I det här fallet menar vi verkligen godtycklig skrivning av logik.

Det finns också godtyckliga smarta kontrakt, men inte Turing kompletta. Detta inkluderar Bitcoin och Litecoin med eget skript. Det betyder att du bara kan använda vissa operationer i valfri ordning, men du kan inte längre skriva loopar och dina egna algoritmer.

Dessutom finns det smarta kontraktsplattformar som implementerar fördefinierade smarta kontrakt. Dessa inkluderar Bitshares och Steemit. Bitshares har en rad smarta kontrakt för handel, kontohantering, hantering av själva plattformen och dess parametrar. Steemit är en liknande plattform, men den är inte längre fokuserad på att ge ut tokens och handel, som Bitshares, utan på att blogga, det vill säga den lagrar och bearbetar innehåll på ett decentraliserat sätt.

Godtyckliga Turing-kompletta kontrakt inkluderar Ethereum-plattformen och RootStock, som fortfarande är under utveckling. Därför kommer vi nedan att uppehålla oss lite mer i detalj på Ethereums smarta kontraktsplattform.

Smarta kontrakt med initieringsmetod

Baserat på metoden för initiering kan smarta kontrakt också delas in i minst två grupper: automatiserade och manuella (ej automatiserade). Automatiserade sådana kännetecknas av det faktum att, med alla kända parametrar och villkor, det smarta kontraktet exekveras helt automatiskt, det vill säga det kräver inte att du skickar några ytterligare transaktioner och spenderar en extra provision på varje efterföljande utförande. Plattformen själv har all data för att beräkna hur det smarta kontraktet kommer att slutföras. Logiken där är inte godtycklig, utan förutbestämd och allt detta är förutsägbart. Det vill säga, du kan i förväg uppskatta komplexiteten i att utföra ett smart kontrakt, använda någon form av konstant provision för det, och alla processer för dess implementering är mer effektiva.

För smarta kontrakt som är fritt programmerade är utförande inte automatiserat. För att initiera ett sådant smart kontrakt måste du i praktiskt taget varje steg skapa en ny transaktion, som kommer att anropa nästa exekveringssteg eller nästa smarta kontraktsmetod, betala lämplig provision och vänta på att transaktionen ska bekräftas. Exekveringen kan slutföras framgångsrikt eller inte, eftersom den smarta kontraktskoden är godtycklig och några oförutsägbara ögonblick kan dyka upp, såsom en evig loop, brist på vissa parametrar och argument, obehandlade undantag, etc.

Ethereum-konton

Ethereum-kontotyper

Låt oss titta på vilka typer av konton det kan finnas på Ethereum-plattformen. Det finns bara två typer av konton här och det finns inga andra alternativ. Den första typen kallas ett användarkonto, den andra är ett kontraktskonto. Låt oss ta reda på hur de skiljer sig åt.

Användarkontot styrs endast av den personliga nyckeln till den elektroniska signaturen. Kontoägaren genererar sitt eget nyckelpar för elektronisk signatur med hjälp av algoritmen ECDSA (Elliptic Curve Digital Signature Algorithm). Endast transaktioner som signerats med denna nyckel kan ändra kontots tillstånd.

En separat logik tillhandahålls för det smarta kontraktskontot. Det kan endast kontrolleras av fördefinierad mjukvarukod som helt bestämmer beteendet hos det smarta kontraktet: hur det kommer att hantera sina mynt under vissa omständigheter, på initiativ av vilken användare och under vilka ytterligare villkor dessa mynt kommer att distribueras. Om vissa punkter inte tillhandahålls av utvecklarna i programkoden kan problem uppstå. Till exempel kan ett smart kontrakt få ett visst tillstånd där det inte accepterar initiering av ytterligare exekvering från någon av användarna. I det här fallet kommer mynten faktiskt att frysas, eftersom det smarta kontraktet inte ger dig möjlighet att lämna detta tillstånd.

Hur konton skapas på Ethereum

När det gäller ett användarkonto genererar ägaren självständigt ett nyckelpar med hjälp av ECDSA. Det är viktigt att notera att Ethereum använder exakt samma algoritm och exakt samma elliptiska kurva för elektroniska signaturer som Bitcoin, men adressen beräknas på ett lite annorlunda sätt. Här används inte längre resultatet av dubbelhashning, som i Bitcoin, utan enkel hashning förses med Keccak-funktionen i en längd av 256 bitar. De minst signifikanta bitarna skärs av från det resulterande värdet, nämligen de minst signifikanta 160 bitarna av det utgående hashvärdet. Som ett resultat får vi en adress i Ethereum. Faktum är att den tar upp 20 byte.

Observera att kontoidentifieraren i Ethereum är kodad i hex utan att använda en kontrollsumma, till skillnad från Bitcoin och många andra system, där adressen är kodad i ett bas 58-nummersystem med tillägg av en kontrollsumma. Det betyder att du måste vara försiktig när du arbetar med kontoidentifierare i Ethereum: även ett misstag i identifieraren kommer garanterat att leda till förlust av mynt.

Det finns en viktig funktion och det är att ett användarkonto på generell databasnivå skapas i det ögonblick då han accepterar den första inkommande betalningen.

Att skapa ett smart kontraktskonto tar ett helt annat tillvägagångssätt. Inledningsvis skriver en av användarna källkoden för det smarta kontraktet, varefter koden skickas genom en kompilator som är special för Ethereum-plattformen och erhåller bytekod för sin egen virtuella Ethereum-maskin. Den resulterande bytekoden placeras i ett speciellt fält för transaktionen. Det är certifierat på uppdrag av initiativtagarens konto. Därefter sprids denna transaktion i nätverket och placerar den smarta kontraktskoden. Provisionen för transaktionen och följaktligen för genomförandet av kontraktet dras från saldot på initiativtagarens konto.

Varje smart kontrakt innehåller nödvändigtvis sin egen konstruktör (av detta kontrakt). Den kan vara tom eller så kan den ha innehåll. Efter att konstruktören har körts skapas en identifierare för smart kontraktskonto, med hjälp av vilken du kan skicka mynt, anropa vissa smarta kontraktsmetoder, etc.

Ethereums transaktionsstruktur

För att göra det tydligare kommer vi att börja titta på strukturen för en Ethereum-transaktion och ett exempel på en smart kontraktskod.

En Ethereum-transaktion består av flera fält. Den första av dessa, nonce, är ett visst serienummer för transaktionen i förhållande till själva kontot som distribuerar den och är dess författare. Detta är nödvändigt för att särskilja dubbla transaktioner, det vill säga för att utesluta fallet när samma transaktion accepteras två gånger. Genom att använda en identifierare har varje transaktion ett unikt hashvärde.

Därefter kommer ett fält som gaspris. Detta indikerar priset till vilket Ethereums basvaluta omvandlas till gas, som används för att betala för genomförandet av det smarta kontraktet och allokeringen av den virtuella maskinresursen. Vad betyder det?

I Bitcoin betalas avgifter direkt av basvalutan – Bitcoin själv. Detta är möjligt tack vare en enkel mekanism för att beräkna dem: vi betalar strikt för mängden data som ingår i transaktionen. I Ethereum är situationen mer komplicerad, eftersom det är mycket svårt att lita på mängden transaktionsdata. Här kan transaktionen även innehålla programkod som kommer att exekveras på den virtuella maskinen, och varje operation av den virtuella maskinen kan ha olika komplexitet. Det finns också operationer som allokerar minne för variabler. De kommer att ha sin egen komplexitet, på vilken betalningen för varje operation kommer att bero på.

Kostnaden för varje operation i gasekvivalenter kommer att vara konstant. Den introduceras specifikt för att fastställa den konstanta kostnaden för varje operation. Beroende på belastningen på nätet kommer gaspriset att ändras, det vill säga koefficienten enligt vilken basvalutan kommer att omvandlas till denna hjälpenhet för att betala provisionen.

Det finns ytterligare en funktion för en transaktion i Ethereum: bytekoden som den innehåller för exekvering i en virtuell maskin kommer att exekveras tills den slutförs med något resultat (framgång eller misslyckande) eller tills en viss mängd mynt som tilldelats tar slut för att betala provisionen . Det är för att undvika en situation där, i händelse av något fel, alla mynt från avsändarens konto spenderades på kommission (till exempel någon form av evig cykel som startade i en virtuell maskin), finns följande fält - starta gas (ofta kallad gasgräns) - den bestämmer den maximala mängden mynt som avsändaren är villig att spendera för att slutföra en viss transaktion.

Nästa fält kallas Destinations adress. Detta inkluderar adressen till mottagaren av mynten eller adressen till ett specifikt smart kontrakt vars metoder kommer att kallas. Efter det kommer fältet värde, där mängden mynt som skickas till destinationsadressen anges.

Nästa är ett intressant fält som heter datum, där hela strukturen passar. Detta är inte ett separat fält, utan en hel struktur där koden för den virtuella maskinen är definierad. Du kan placera godtyckliga data här - det finns separata regler för detta.

Och det sista fältet kallas namnteckning. Den innehåller samtidigt både den elektroniska signaturen från författaren till denna transaktion och den publika nyckeln med vilken denna signatur kommer att verifieras. Från den publika nyckeln kan du få kontoidentifieraren för avsändaren av denna transaktion, det vill säga unikt identifiera avsändarens konto i själva systemet. Vi fick reda på det viktigaste om transaktionens struktur.

Exempel på smart avtalskod för Solidity

Låt oss nu titta närmare på det enklaste smarta kontraktet med hjälp av ett 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 returnera dem på begäran.

Så det finns ett banksmart kontrakt som utför följande funktioner: det ackumulerar mynt på sitt saldo, det vill säga när en transaktion bekräftas och ett sådant smart kontrakt skapas, skapas ett nytt konto som kan innehålla mynt på sitt saldo; den minns användare och fördelningen av mynt mellan dem; har flera metoder för att hantera saldon, det vill säga det är möjligt att fylla på, ta ut och kontrollera användarens saldo.

Låt oss gå igenom varje rad med källkod. Detta kontrakt har konstanta fält. En av dem, med typadress, kallas ägare. Här kommer kontraktet ihåg adressen till användaren som skapade detta smarta kontrakt. Vidare finns det en dynamisk struktur som upprätthåller överensstämmelse mellan användaradresser och balanser.

Detta följs av Bankmetoden - den har samma namn som kontraktet. Följaktligen är detta dess konstruktör. Här tilldelas ägarevariabeln adressen till den person som lade detta smarta kontrakt på nätverket. Detta är det enda som händer i den här konstruktören. Det vill säga, msg i det här fallet är exakt den data som överfördes till den virtuella maskinen tillsammans med transaktionen som innehåller hela koden för detta kontrakt. Följaktligen är msg.sender författaren till denna transaktion som är värd för denna kod. Han kommer att vara ägare till det smarta kontraktet.

Insättningsmetoden låter dig överföra ett visst antal mynt till kontraktskontot per transaktion. I det här fallet lämnar det smarta kontraktet, som tar emot dessa mynt, dem på sin balansräkning, men registrerar i balansstrukturen vem som var avsändaren av dessa mynt för att veta vem de tillhör.

Nästa metod kallas uttag och det krävs en parameter - mängden mynt som någon vill ta ut från denna bank. Detta kontrollerar om det finns tillräckligt med mynt i saldot för användaren som anropar den här metoden för att skicka dem. Om det finns tillräckligt med dem, returnerar det smarta kontraktet självt det antalet mynt till den som ringer.

Därefter kommer metoden för att kontrollera användarens aktuella saldo. Den som anropar denna metod kommer att användas för att hämta detta saldo i det smarta kontraktet. Det är värt att notera att modifieraren av denna metod är syn. Det betyder att metoden i sig inte ändrar variablerna i sin klass på något sätt och det är faktiskt bara en läsmetod. Ingen separat transaktion skapas för att anropa denna metod, ingen avgift betalas, och alla beräkningar utförs lokalt, varefter användaren får resultatet.

Killmetoden behövs för att förstöra det smarta kontraktets tillstånd. Och här finns det en ytterligare kontroll om den som ringer denna metod är ägaren till detta kontrakt. Om så är fallet, förstör kontraktet själv, och förstöringsfunktionen tar en parameter - kontoidentifieraren till vilken kontraktet kommer att skicka alla mynt som finns kvar på saldot. I det här fallet kommer de återstående mynten automatiskt att gå till kontraktsägarens adress.

Hur fungerar en full nod på Ethereum-nätverket?

Låt oss titta schematiskt på hur sådana smarta kontrakt exekveras på Ethereum-plattformen och hur en fullständig nätverksnod fungerar.

En full nod på Ethereum-nätverket måste ha minst fyra moduler.
Den första, som för alla decentraliserade protokoll, är P2P-nätverksmodulen - en modul för nätverksanslutning och arbete med andra noder, där block, transaktioner och information om andra noder utbyts. Detta är en traditionell komponent för alla decentraliserade kryptovalutor.

Därefter har vi en modul för att lagra blockchain-data, bearbeta, välja en prioriterad gren, lägga till block, koppla bort block, validera dessa block, etc.

Den tredje modulen kallas EVM (Ethereum virtual machine) - detta är en virtuell maskin som tar emot bytekod från Ethereum-transaktioner. Denna modul tar det aktuella tillståndet för ett visst konto och gör ändringar i dess tillstånd baserat på den mottagna bytekoden. Den virtuella maskinversionen på varje nätverksnod måste vara densamma. Beräkningarna som sker på varje Ethereum-nod är exakt desamma, men de sker på ett asynkront sätt: någon kontrollerar och accepterar denna transaktion tidigare, det vill säga exekverar all kod som finns i den, och någon senare. Följaktligen, när en transaktion skapas, distribueras den till nätverket, noderna accepterar den, och vid tidpunkten för verifiering, på samma sätt som Bitcoin Script exekveras i Bitcoin, exekveras bytekoden för den virtuella maskinen här.

En transaktion anses verifierad om all kod som finns i den har utförts, ett nytt tillstånd för ett visst konto har genererats och sparats tills det är klart om denna transaktion har tillämpats eller inte. Om transaktionen tillämpas anses detta tillstånd inte bara vara avslutat utan också aktuellt. Det finns en databas som lagrar statusen för varje konto för varje nätverksnod. På grund av det faktum att alla beräkningar sker på samma sätt och blockkedjans tillstånd är detsamma, kommer databasen som innehåller tillstånden för alla konton också att vara densamma för varje nod.

Myter och begränsningar för smarta kontrakt

När det gäller de begränsningar som finns för smarta kontraktsplattformar som liknar Ethereum, kan följande nämnas:

• kodexekvering;
• allokera minne;
• blockkedjedata;
• skicka betalningar;
• skapa nytt kontrakt;
• ringa andra kontrakt.

Låt oss titta på begränsningarna som åläggs en virtuell maskin, och följaktligen skingra några myter om smarta kontrakt. På en virtuell maskin, som inte bara kan vara i Ethereum, utan också i liknande plattformar, kan du utföra verkligt godtyckliga logiska operationer, det vill säga skriva kod och den kommer att köras där, du kan dessutom tilldela minne. Avgiften betalas dock separat för varje operation och för varje extra minnesenhet som tilldelats.

Därefter kan den virtuella maskinen läsa data från blockchain-databasen för att använda dessa data som en trigger för att exekvera en eller annan smart kontraktslogik. Den virtuella maskinen kan skapa och skicka transaktioner, den kan skapa nya kontrakt och anropsmetoder för andra smarta kontrakt som redan är publicerade på nätverket: befintliga, tillgängliga, etc.

Den vanligaste myten är att Ethereums smarta kontrakt kan använda information från vilken internetresurs som helst i sina villkor. Sanningen är att en virtuell maskin inte kan skicka en nätverksbegäran till någon extern informationsresurs på Internet, det vill säga det är omöjligt att skriva ett smart kontrakt som kommer att fördela värdet mellan användare beroende på till exempel hur vädret är utanför, eller vem som vunnit något mästerskap, eller baserat på vilken annan incident som hände i omvärlden, eftersom information om dessa incidenter helt enkelt inte finns i själva plattformens databas. Det vill säga, det finns inget på blockkedjan om detta. Om det inte visas där kan den virtuella maskinen inte använda dessa data som utlösare.

Nackdelar med Ethereum

Låt oss lista de viktigaste. Den första nackdelen är att det finns vissa svårigheter med att designa, utveckla och testa smarta kontrakt i Ethereum (Ethereum använder Solidity-språket för att skriva smarta kontrakt). Praxis visar faktiskt att en mycket stor andel av alla fel tillhör den mänskliga faktorn. Detta är faktiskt sant för redan skrivna smarta Ethereum-kontrakt som har genomsnittlig eller högre komplexitet. Om sannolikheten för ett fel är liten för enkla smarta kontrakt, så finns det i komplexa smarta kontrakt mycket ofta fel som leder till stöld av pengar, frysning av dem, förstörelse av smarta kontrakt på ett oväntat sätt, etc. Många sådana fall finns redan känd.

Den andra nackdelen är att den virtuella maskinen i sig inte är perfekt, eftersom den också är skriven av människor. Den kan utföra godtyckliga kommandon, och däri ligger sårbarheten: ett antal kommandon kan konfigureras på ett visst sätt som kommer att leda till konsekvenser som var oförutsedda på förhand. Detta är ett mycket komplext område, men det finns redan flera studier som visar att dessa sårbarheter finns i den nuvarande versionen av Ethereum-nätverket och de kan leda till att många smarta kontrakt misslyckas.

En annan stor svårighet, det kan anses vara en nackdel. Det ligger i det faktum att du praktiskt eller tekniskt kan komma till slutsatsen att om du kompilerar bytekoden för ett kontrakt som kommer att exekveras på en virtuell maskin, kan du bestämma någon specifik operationsordning. När de utförs tillsammans kommer dessa operationer att kraftigt belasta den virtuella maskinen och sakta ner den oproportionerligt mycket i förhållande till den avgift som betalades för att utföra dessa operationer.

Tidigare fanns det redan en period i utvecklingen av Ethereum, när många killar som i detalj förstod driften av en virtuell maskin hittade sådana sårbarheter. Faktum är att transaktioner betalade en mycket liten avgift, men praktiskt taget saktade ner hela nätverket. Dessa problem är mycket svåra att lösa, eftersom det för det första är nödvändigt att fastställa dem, för det andra att justera priset för att utföra dessa operationer och, för det tredje, att utföra en hård gaffel, vilket innebär att uppdatera alla nätverksnoder till en ny version av programvaran och sedan samtidig aktivering av dessa ändringar.

När det gäller Ethereum har mycket forskning utförts, mycket praktisk erfarenhet har vunnits: både positiva och negativa, men ändå finns det svårigheter och sårbarheter som fortfarande måste hanteras på något sätt.

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

Vanliga frågor

— Om alla parter i ett befintligt smart kontrakt vill ändra villkoren, kan de säga upp detta smarta kontrakt med multisig och sedan skapa ett nytt smart kontrakt med uppdaterade villkor för dess utförande?

Svaret här kommer att vara tvådelat. Varför? För å ena sidan definieras ett smart kontrakt en gång och det innebär inte längre några förändringar, och å andra sidan kan det ha förskriven logik som ger en fullständig eller partiell ändring av vissa villkor. Det vill säga om du vill ändra något i ditt smarta kontrakt så måste du föreskriva under vilka villkor du kan uppdatera dessa villkor. Följaktligen kan förnyelsen av avtalet endast organiseras på ett sådant försiktigt sätt. Men även här kan du råka ut för problem: gör något misstag och få en motsvarande sårbarhet. Därför måste sådana saker vara mycket detaljerade och noggrant utformade och testade.

— Vad händer om medlaren ingår ett avtal med en av de deltagande parterna: deposition eller smart kontrakt? Krävs en medlare i ett smart kontrakt?

En medlare krävs inte i ett smart kontrakt. Det kanske inte finns. Om, i fallet med deposition, medlaren inleder en konspiration med en av parterna, ja, detta system förlorar då kraftigt allt sitt värde. Därför väljs medlare ut på ett sådant sätt att de får förtroende av alla parter som är involverade i denna process samtidigt. Följaktligen kommer du helt enkelt inte att överföra mynt till en multisignaturadress med en medlare som du inte litar på.

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

Detta är en bra fråga och det gäller Ethereum-transaktionsmodellen och hur den skiljer sig från Bitcoin-modellen. Och skillnaden är radikal. Om du i Ethereum-transaktionsmodellen helt enkelt överför mynt, så överförs de bara från en adress till en annan, ingen förändring, bara det specifika beloppet du angav. Detta är med andra ord inte en modell av outnyttjade uttag (UTXO), utan en modell av konton och motsvarande saldon. Det är teoretiskt möjligt att skicka flera olika tokens i en transaktion samtidigt om du skriver ett listigt smart kontrakt, men du måste fortfarande göra många transaktioner, skapa ett kontrakt, sedan överföra tokens och mynt till det och sedan anropa lämplig metod . Detta kräver ansträngning och tid, så i praktiken fungerar det inte så och alla betalningar i Ethereum görs i separata transaktioner.

— En av myterna om Ethereum-plattformen är att det är omöjligt att beskriva förhållanden som kommer att bero på data från en extern internetresurs, så vad ska man göra då?

Lösningen är att det smarta kontraktet i sig kan tillhandahålla ett eller flera så kallade betrodda orakel, som samlar in data om sakernas tillstånd i omvärlden och överför det till de smarta kontrakten genom speciella metoder. Själva avtalet anser att uppgifterna som det mottagit från betrodda parter är sanna. För större tillförlitlighet, välj helt enkelt en stor grupp orakel och minimera risken för deras maskopi. Själva kontraktet får inte ta hänsyn till data från orakel som motsäger majoriteten.

En av föreläsningarna i onlinekursen om Blockchain ägnas åt detta ämne - "Introduktion till smarta kontrakt".

Källa: will.com