I denne artikel vil vi se på, hvad smarte kontrakter er, hvilke typer der findes, vi vil blive bekendt med forskellige platforme for smarte kontrakter, deres særlige egenskaber, samt diskutere, hvordan de fungerer, og hvilke fordele de kan have. Dette materiale vil være meget nyttigt for læsere, der ikke er så godt bekendt med emnet smarte kontrakter, men ønsker at forstå det bedre.
Traditionel kontrakt vs. smart kontrakt
Før vi dykker ned i detaljerne, lad os tage et eksempel på forskellene mellem en traditionel kontrakt, som er skrevet på papir, og en smart kontrakt, som præsenteres i digital form.
Hvordan fungerede det før smarte kontrakter? Forestil dig en gruppe mennesker, der ønsker at fastsætte nogle regler og vilkår for distribution af værdier, samt at have en bestemt mekanisme til at sikre, at denne distribution udføres i henhold til de fastsatte regler og vilkår. De ville mødes, skrive en papircontract, der indeholdt deres identifikationsoplysninger, vilkår, involverede værdier, skrive datoen og underskrive den. Denne kontrakt ville også blive bekræftet af en betroet part, såsom en notar. Derefter ville disse mennesker sprede sig i forskellige retninger med deres papirbaserede kopi af kontrakten og begynde at udføre handlinger, der ikke nødvendigvis stemte overens med kontrakten, altså de gjorde én ting, men på papiret stod der, at de skulle gøre noget helt andet. Og hvordan komme ud af denne situation? Faktisk skulle en af deltagerne tage denne papir, samle beviser, bære dem ind i retten og sikre overensstemmelse mellem kontrakten og de faktiske handlinger. Det kan ofte være svært at sikre retfærdig opfyldelse af en sådan kontrakt, hvilket kan føre til ubehagelige konsekvenser.
Hvad kan man så sige om smarte kontrakter? De kombinerer muligheden for at udforme kontraktvilkår og mekanismen for streng opfyldelse af disse. Hvis vilkårene er fastsat, og den relevante transaktion eller anmodning er underskrevet, så kan vilkårene eller udførelsen ikke ændres, når denne anmodning eller transaktion er accepteret.
Der er enten en validator eller et helt netværk samt en database, der gemmer alle smarte kontrakter, som blev udført i en streng kronologisk rækkefølge. Det er også vigtigt, at denne database indeholder alle betingelser og udløsere for udførelsen af den smarte kontrakt. Endvidere skal den tage højde for den værdi, hvis fordeling er beskrevet i kontrakten. Hvis det drejer sig om en form for digital valuta, skal databasen tage hensyn til den.
Med andre ord skal validatorer af smarte kontrakter have adgang til alle de data, som den smarte kontrakt opererer med. For eksempel skal én database anvendes til at holde styr på digitale valutaer, brugeres saldi, brugeres transaktioner og tidsstempler på samme tid. Så kan en betingelse i den smarte kontrakt være brugerens saldo i en given valuta, at et bestemt tidspunkt indtræffer, eller at en bestemt transaktion finder sted, men ikke mere end det.
Definition af smarte kontrakter
Selve terminologien blev opfundet af forskeren Nick Szabo og anvendt første gang i 1994, og blev dokumenteret i 1997 i en artikel, der beskriver selve idéen om smarte kontrakter.
Smartere kontrakter indebærer, at der udføres en form for automatisering af værdifordeling, der kun kan afhænge af de betingelser, der er forudbestemt. I sin simpleste form ser det ud som en kontrakt med strengt definerede betingelser, der er underskrevet af bestemte parter.
Smartere kontrakter har til formål at minimere tillid til tredjeparter. Nogle gange udelukkes centrum for beslutningstagning helt, som alt afhænger af. Derudover er det lettere at udføre revisioner af sådanne kontrakter. Dette er en følge af nogle designtræk ved et sådant system, men oftest forstår vi smarte kontrakter som en decentraliseret miljø med funktioner, der gør det muligt for enhver, der ønsker det, at analysere databasen og udføre en fuld revision af kontraktens udførelse. Dermed sikres beskyttelse mod ændringer af data med tilbagevirkende kraft, som vil medføre ændringer i selve kontraktens udførelse. Digitaliseringen af de fleste processer ved oprettelsen og implementeringen af smarte kontrakter forenkler ofte teknologien og omkostningerne ved deres gennemførelse.
Et simpelt eksempel — Escrow-tjeneste
Lad os overveje et meget enkelt eksempel. Det vil hjælpe os med at forstå funktionaliteterne ved smarte kontrakter bedre samt give en bedre idé om, i hvilke situationer de bør anvendes.
Det kan også implementeres med Bitcoin, selvom Bitcoin i øjeblikket stadig er vanskeligt at kalde en fuldgyldig platform for smarte kontrakter. Så vi har en kunde og en internetbutik. Kunden ønsker at købe en skærm i denne butik. I det simpleste tilfælde foretager kunden en betaling og sender den, mens internetbutikken modtager den, bekræfter den og derefter sender varen. Men i denne situation er der behov for stor tillid – kunden skal stole på internetbutikken for hele skærmens værdi. Da internetbutikken muligvis har et lavt omdømme i kundens øjne, er der risiko for, at butikken nægter at udføre sin del af aftalen og ikke sender varen til kunden efter modtagelse af betalingen. Derfor stiller kunden sig selv spørgsmålet (og internetbutikken stiller sig selv spørgsmålet), hvad der kan anvendes i denne situation for at minimere sådanne risici og gøre sådanne transaktioner mere pålidelige.
I tilfælde af Bitcoin kan man give mulighed for, at både køberen og sælgeren uafhængigt vælger en mægler. Der er mange mennesker, der beskæftiger sig med at løse tvister. Vores deltagere kan vælge en mægler fra en fælles liste, som de begge vil have tillid til. Sammen opretter de en multisignature-adresse 2 af 3, hvor der er tre nøgler, og to underskrifter fra hvilke som helst to nøgler er nødvendige for at bruge mynterne fra denne adresse. En nøgle vil tilhøre kunden, den anden – internetbutikken, og den tredje – mæglere. Og på denne multisignature-adresse vil kunden sende det beløb, der er nødvendigt for at betale for skærmen. Nu, når sælgeren ser, at pengene er midlertidigt blokeret på en multisignature-adresse, som han er afhængig af, kan han trygt sende skærmen med posten.
Hereafter, the buyer receives the package, inspects the product, and decides on the final purchase. They may fully agree with the provided service and sign the transaction with their key, transferring coins from the multisignature address to the seller. Alternatively, they may be dissatisfied. In this case, they contact the mediator to create an alternative transaction that will distribute these coins differently.
Suppose the monitor arrived slightly scratched and the cable to connect to the computer was missing, even though the online store stated that the cable should be included. The buyer then gathers evidence needed to demonstrate to the mediator that they were deceived in this situation: they take screenshots of the website, photograph the receipt from the post office, capture images of the scratches on the monitor, and show that the seal has been broken and the cable was removed. The online store, in turn, gathers its evidence and submits it to the mediator.
The mediator is interested in satisfying both the buyer's grievances and the interests of the online store (it will become clear later why). They create a transaction in which coins from the multisignature address will be distributed in some proportion among the buyer, the online store, and the mediator, as they take a portion as a reward for their work. For example, 90% of the total amount would go to the seller, 5% to the mediator, and 5% as compensation to the buyer. The mediator signs this transaction with their key, but it cannot be applied yet, as two signatures are required, and only one is present. They send this transaction to both the buyer and the seller. If either of them agrees with this redistribution of coins, the transaction will be co-signed and propagated in the network. To validate it, it is sufficient for one participant in the deal to agree with the mediator's proposal.
Det er vigtigt at vælge en mediator, som begge parter har tillid til fra starten. På den måde vil han handle uafhængigt af den ene eller den anden parts interesser og objektivt vurdere situationen. Hvis mediator ikke tilbyder en fordelingsmulighed for mønterne, der tilfredsstiller mindst én af parterne, kan både køberen og webshoppen, efter en fælles aftale, overføre mønterne til en ny multisignaturadresse ved at sætte deres to underskrifter. Den nye multisignaturadresse vil blive oprettet med en anden mediator, som muligvis er mere kompetent i sagen og kan tilbyde en bedre løsning.
Eksempel med et kollegium og et køleskab
Lad os se på et mere komplekst eksempel, som tydeligere viser mulighederne for smart contracts.
Antag, at der er tre fyre, der for nylig er flyttet ind i det samme værelse på et kollegium. De er alle interesseret i at købe et køleskab til deres værelse, som de vil bruge sammen. En af dem har meldt sig til at samle den nødvendige sum til købet af køleskabet og føre forhandlinger med sælgeren. De har dog kun lige mødt hinanden, og der er ikke den tillid imellem dem. Åbenlyst risikerer to af dem at overgive penge til den tredje. Derudover skal de nå til enighed om valget af sælger.
De kan benytte en escrow-tjeneste, dvs. vælge en mediator, der vil overvåge gennemførelsen af handlen og afgøre eventuelle tvister, der måtte opstå. Derefter laver de i fællesskab en smart contract og angiver bestemte betingelser i den.
Den første betingelse er, at der inden for et bestemt tidsrum, lad os sige en uge, skal der modtages tre betalinger til den relevante smarte kontrakt fra bestemte adresser i et bestemt beløb. Hvis dette ikke sker, stopper den smarte kontrakt sin udførelse og returnerer mønterne til alle deltagere. Hvis betingelsen derimod opfyldes, angives værdierne for sælgerens og mediatorens ID, og det kontrolleres, at alle deltagere er enige i valget af sælger og mediator. Når alle betingelserne er opfyldt, vil midlerne blive overført til de angivne adresser. Denne tilgang kan beskytte deltagerne mod svindel fra enhver side og fjerner generelt behovet for tillid.
Vi ser i dette eksempel selve princippet om, at muligheden for trinvis at angive parametre for udførelsen af hver betingelse gør det muligt at skabe systemer af enhver kompleksitet og dybde af indlejrede niveauer. Derudover kan det første betingelse i den smarte kontrakt defineres først, og først efter dens opfyldelse kan parametrene for den næste betingelse angives. Med andre ord, formelt er betingelsen skrevet, men parametrene for den kan angives under arbejdet.
Klassificering af smarte kontrakter
Der kan angives forskellige grupper af kriterier til klassificering. Men i øjeblikket er fire af dem relevante i forhold til teknologiens udvikling.
Smarte kontrakter kan adskilles efter udførelsesmiljøet, som kan være enten centraliseret eller decentraliseret. I tilfælde af decentralisering har vi meget større uafhængighed og fejltolerance ved udførelsen af smarte kontrakter.
De kan også adskilles efter processen for angivelse og opfyldelse af betingelser: de kan være vilkårligt programmerbare, begrænsede eller forudindstillede, dvs. strengt typede. Når der kun findes 4 bestemte smarte kontrakter på platformen for smarte kontrakter, kan parametrene til dem angives vilkårlig måde. Dette gør det meget lettere at angive dem: vi vælger kontrakten fra en liste og overfører parametrene.
Der findes automatiserede smarte kontrakter, der aktiveres under bestemte betingelser, og der findes kontrakter, hvor betingelserne er angivet, men platformen tjekker ikke automatisk deres opfyldelse; de skal aktiveres separat.
Desuden varierer smarte kontrakter i niveauet af privatliv. De kan være helt åbne, delvist åbne eller helt fortrolige. Det sidste betyder, at tredjepartsobservatører ikke kan se betingelserne for de smarte kontrakter. Emnet omkring privatliv er dog meget omfattende og bør behandles særskilt fra denne artikel.
Nedenfor vil vi uddybe de første tre kriterier for at bringe mere klarhed over det aktuelle emne.
Smarte kontrakter efter udførelsesmiljø
Der skelnes mellem centraliserede og decentraliserede platforme for smarte kontrakter. I tilfælde af centraliserede digitale kontrakter anvendes én service, hvor der kun er én validator, og der kan være en backup- og gendannelsesservice, der også styres centraliseret. Der er én database, der gemmer alle nødvendige oplysninger til fastsættelse af betingelserne for den smarte kontrakt og fordelingen af den værdi, der registreres i denne database. En sådan centraliseret service har en klient, der angiver betingelserne med specifikke forespørgsler og bruger disse kontrakter. Da platformen er centraliseret, kan autentificeringsmekanismerne være mindre pålidelige end i kryptovalutaer.
Som et eksempel kan man tage mobiloperatører. Antag, at en bestemt operatør centraliseret registrerer trafikken på sine servere, som kan overføres i forskellige formater, f.eks.: som stemmeopkald, SMS-overførsler, mobilinternettrafik og via forskellige standarder, samt fører regnskab over midlerne på brugernes konti. Derfor kan mobiloperatøren oprette kontrakter for registrering af de leverede tjenester og deres betaling med forskellige betingelser. I så fald kan betingelserne let angives som “send en SMS med en bestemt kode til dette nummer og få disse betingelser for trafikfordeling.”
Man kan også give et andet eksempel: traditionelle banker med udvidet funktionalitet af onlinebanking og meget enkle kontrakter som regelmæssige betalinger, automatisk konvertering af indgående betalinger, automatisk overførsel af rente til den angivne konto osv.
Når det kommer til smarte kontrakter med et decentraliseret udførelsesmiljø, har vi en gruppe validatorer. Ideelt set kan hvem som helst blive validator. Gennem protokollen for synkronisering af databasen og opnåelse af konsensus har vi en fælles database, der nu gemmer alle transaktioner med strengt definerede kontrakter, snarere end nogle betingede forespørgsler, hvis formater ofte ændres, og hvor der ikke findes nogen åben specifikation. Her vil transaktioner indeholde instruktioner til udførelse af kontrakten i overensstemmelse med den strenge specifikation. Denne specifikation er åben, og derfor kan brugerne af platformen udføre revision og validere smarte kontrakter. Her ser vi, at decentraliserede platforme overgår centraliserede på uafhængighed og fejltolerance, men deres design og vedligeholdelse er meget mere komplekst.
Smarte kontrakter efter måden at angive og udføre betingelserne på
Lad os nu se nærmere på, hvordan smarte kontrakter kan variere i måden at angive og udføre betingelserne på. Her fokuserer vi på smarte kontrakter, der er programmerbare på en vilkårlig og Turing-komplet måde. En Turing-komplet smart kontrakt giver mulighed for at angive næsten enhver algoritme som betingelse for kontraktens udførelse: at skrive loops, nogle funktioner til beregning af sandsynligheder og lignende - op til egne algoritmer for digital signatur. I dette tilfælde henvises der faktisk til en helt vilkårlig skrivning af logikken.
Man skelner også mellem vilkårlige smarte kontrakter, men ikke Turing-komplette. Herunder kan Bitcoin og Litecoin med deres script regnes. Det betyder, at man kan bruge visse operationer i vilkårlig rækkefølge, men det er ikke muligt at skrive loops og egne algoritmer.
Derudover er der sådanne smart kontrakt platforme, der implementerer forudindstillede smart kontrakter. Blandt dem kan nævnes Bitshares og Steemit. Bitshares har en række smart kontrakter til handel, kontoadministration, samt administration af selve platformen og dens parametre. Steemit er en lignende platform, men den er ikke fokuseret på udgivelse af tokens og handel som Bitshares, men på blogging, dvs. den opbevarer og behandler indhold på en decentraliseret måde.
Til vilkårlige Turing-komplette kontrakter kan platformene Ethereum og RootStock henregnes, som stadig er under udvikling. Derfor vil vi i det følgende se lidt nærmere på Ethereum smart kontrakt platformen.
Smart kontrakter efter initieringsmetode
Efter initieringsmetode kan smart kontrakter også opdeles i mindst to grupper: automatiserede og manuelle (ikke-automatiserede). For automatiserede kontrakter karakteriseres det ved, at når alle kendte betingelser opfyldes, udbydes smart kontrakten helt automatisk, hvilket betyder, at der ikke kræves nogen yderligere transaktioner eller ekstra gebyrer ved hver følgende udførelse. Selve platformen har alle de data, der er nødvendige for at beregne, hvordan smart kontrakten vil blive afsluttet. Logikken er ikke vilkårlig, men forudbestemt, og alt dette er forudsigeligt. Det vil sige, at man i forvejen kan vurdere kompleksiteten af at udføre smart kontrakten, bruge et konstant gebyr til den, og alle processer ved dens udførelse forløber mere effektivt.
For smart kontrakter, der programmeres på vilkårlig måde, er udførelsen ikke automatiseret. For at initiere en sådan smart kontrakt er det nødvendigt at oprette en ny transaktion på hvert trin, som vil kalde det næste udførelsestrin eller den næste metode i smart kontrakten, betale det tilsvarende gebyr og vente på transaktionsbekræftelse. Udførelsen kan enten afsluttes med succes eller ej, fordi koden til smart kontrakten er vilkårlig, og der kan opstå uforudsigelige situationer såsom uendelige løkker, mangel på bestemte parametre og argumenter, ubehandlede undtagelsesmomenter osv.
Kontoer i Ethereum
Typer af Ethereum-konti
Lad os se på, hvilke kontotyper der findes på Ethereum-platformen. Der er kun to typer konti, og der er ingen andre muligheder. Den første type kaldes en brugerkonto, den anden - en kontraktkonto. Lad os undersøge, hvordan de adskiller sig.
Brugerkontoen styres kun af den private nøgle til den elektroniske signatur. Kontoejeren genererer sit eget nøglepar til den elektroniske signatur ved hjælp af ECDSA-algoritmen (Elliptic Curve Digital Signature Algorithm). Kun transaktioner, der er signeret med denne nøgle, kan ændre tilstanden af denne konto.
For smarte kontraktkonti er der en særskilt logik. Den kan kun styres via forudbestemt programkode, som fuldstændigt definerer adfærden af den smarte kontrakt: hvordan den vil forvalte sine mønter under bestemte omstændigheder, efter initiativ fra hvilken bruger og under hvilke yderligere betingelser disse mønter vil blive distribueret. Hvis visse aspekter ikke er forudset af udviklerne i programkoden, kan der opstå problemer. For eksempel kan den smarte kontrakt opnå en bestemt tilstand, hvor den ikke accepterer initiativ til videre udførelse fra nogen af brugerne. I så fald vil mønterne faktisk være låst, fordi den smarte kontrakt ikke forudser en måde at komme ud af denne tilstand på.
Hvordan oprettes konti i Ethereum
For brugerkontoen genererer ejeren selvstændigt et nøglepar ved hjælp af ECDSA. Det er vigtigt at bemærke, at Ethereum anvender præcis den samme algoritme og den samme elliptiske kurve til den elektroniske signatur som Bitcoin, men adressen beregnes på en lidt anden måde. Her anvendes der ikke det dobbelte hashresultat, som i Bitcoin, men der udføres en enkelt hashing med Keccak-funktionen på 256 bit. De laveste bits af den opnåede værdi skæres fra, nemlig de 160 laveste bits af hash-funktionens output. Resultatet er en Ethereum-adresse. Faktisk fylder den 20 byte.
Vi bemærker, at kontoidentifikatoren i Ethereum er kodet i hex uden brug af kontrolsum, i modsætning til Bitcoin og mange andre systemer, hvor adressen kodes i et talsystem med base 58 med en kontrolsum. Det betyder, at man skal være forsigtig, når man arbejder med kontoenheder i Ethereum: selv en enkelt fejl i identifikatoren vil garanteret føre til tab af mønter.
Der er en vigtig funktion, som indebærer, at brugerens konto på niveauet for den fælles database oprettes i det øjeblik, han eller hun modtager den første indgående betaling.
Med hensyn til oprettelse af en smart kontrakt anvendes en helt anden tilgang. Først skriver en bruger kildekoden til smart kontrakten, hvorefter koden køres gennem en specifik kompilator for Ethereum-platformen og genererer bytekode til den egen virtuelle maskine i Ethereum. Den genererede bytekode placeres i et særligt felt i transaktionen. Denne underskrives af kontoen, der initierer den. Derefter distribueres transaktionen gennem netværket og placerer koden for smart kontrakten. Gebyret for at gennemføre transaktionen og dermed for at udføre kontrakten trækkes fra saldoen på initiatorens konto.
Hver smart kontrakt indeholder nødvendigvis sin egen konstruktør (til denne kontrakt). Den kan være tom eller have indhold. Når konstruktøren udføres, oprettes der en kontoidentifikator for smart kontrakten, som kan bruges til at sende mønter, kalde bestemte metoder i smart kontrakten osv.
Strukturen af Ethereum-transaktionen
For at gøre det klarere vil vi se nærmere på strukturen af Ethereum-transaktionen og et eksempel på koden til smart kontrakten.
En Ethereum-transaktion består af flere felter. Det første af disse er nonce — et bestemt sekventielt nummer for transaktionen i forhold til den konto, der distribuerer og ejer den. Dette er nødvendigt for at skelne mellem dublerede transaktioner, så man undgår, at den samme transaktion modtages to gange. Takket være brugen af identifikatoren har hver transaktion en unik hashværdi.
Dernæst følger et felt som gas priceHer angives prisen, hvormed basisvalutaen Ethereum konverteres til gas, som bruges til betaling for udførelsen af smart contracts og tildeling af ressourcer til den virtuelle maskine. Hvad betyder dette?
I Bitcoin betales gebyrer direkte med basisvalutaen — selve bitcoin. Dette er muligt takket være en enkel beregningsmekanisme: Vi betaler præcist for den mængde data, der er indeholdt i transaktionen. I Ethereum er situationen mere kompleks, fordi det er meget svært at basere sig på mængden af data i transaktionen. Her kan transaktionen desuden indeholde programmeringskode, der vil blive udført på den virtuelle maskine, og hver operation i den virtuelle maskine kan have forskellig kompleksitet. Der findes også operationer, der allokerer hukommelse til variabler. Disse vil have deres egen kompleksitet, som vil påvirke betalingen for hver operation.
Omkostningerne ved hver operation i gas-ækvivalent vil være konstante. Dette indføres specielt for at bestemme den konstante omkostning ved hver operation. Afhængigt af belastningen på netværket vil gasprisen ændre sig, det vil sige den faktor, hvormed basisvalutaen konverteres til denne hjælpeenhed til betaling af gebyrer.
Der er endnu en særegenhed ved transaktionen i Ethereum: byte-koden, som den indeholder til udførelse i den virtuelle maskine, vil blive udført, indtil den afsluttes med et eller andet resultat (succes-eller-fejl) eller indtil der løber et bestemt antal mønter ud, der er afsat til at betale gebyrer. For at undgå situationen, hvor alle mønter fra senderens konto bruges til gebyrer i tilfælde af en fejl (for eksempel hvis en uendelig løkke kører i den virtuelle maskine), findes der følgende felt — start gas (det kaldes ofte gas grænse) — det definerer det maksimale antal mønter, som afsenderen er villig til at bruge til udførelsen af en bestemt transaktion.
Det næste felt hedder destination address. Her skrives adressen på modtageren af mønterne, eller adressen på en specifik smart contract, hvis metoder vil blive kaldt. Efter dette følger feltet value, hvor summen af mønterne, der sendes til destination address, skrives.
Dernæst er der et interessant felt kaldet data, hvor hele strukturen er indlejret. Dette er ikke et separat felt, men en samlet struktur, hvor koden til den virtuelle maskine defineres. Her kan man indsætte vilkårlige data — der findes specielle regler til dette.
Det sidste felt hedder signatur. Det indeholder både forfatterens elektroniske underskrift på denne transaktion og den offentlige nøgle, hvormed denne underskrift vil blive verificeret. Fra den offentlige nøgle kan man få identifikatoren for afsenderens konto af denne transaktion, hvilket unikt identificerer afsenderens konto i systemet. Med hensyn til transaktionsstrukturen har vi afdækket det grundlæggende.
Eksempel på smart kontrakts kode i Solidity
Lad os nu se nærmere på den simpleste smart kontrakt som eksempel.
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);
}
}Ovenfor er den forenklede kildekode, som kan holde brugernes mønter og returnere dem på forespørgsel.
Så der er en smart kontrakt Bank, som udfører følgende funktioner: den opsparer mønter på sin balance, hvilket vil sige, at der ved bekræftelse af transaktionen og implementeringen af en sådan smart kontrakt oprettes en ny konto, som kan indeholde mønter på sin balance; den husker brugerne og fordelingen af mønter mellem dem; den indeholder flere metoder til at administrere saldi, hvilket vil sige, at det er muligt at indbetale, hæve og kontrollere brugerens balance.
Lad os gennemgå hver linje i kildekoden. I denne kontrakt er der konstante felter. Et af dem, af typen address, kaldes owner. Her husker kontrakten adressen på brugeren, der har oprettet denne smart kontrakt. Derudover er der en dynamisk struktur, som gemmer korrespondancer mellem brugernes adresser og saldi.
Efter dette følger metoden Bank — den hedder det samme som kontrakten. Derfor er dette dens konstruktør. Her sker der en tildeling af variablen owner til adressen på den, der har placeret denne smart kontrakt i netværket. Det er det eneste, der sker i denne konstruktør. Altså er msg i dette tilfælde netop de data, der er blevet sendt til den virtuelle maskine sammen med transaktionen, der indeholder al koden til denne kontrakt. Derfor er msg.sender forfatteren af den pågældende transaktion, som placerer denne kode. Han vil være ejer af smart kontrakten.
Metoden deposit giver mulighed for at overføre et bestemt antal mønter til kontraktens konto via en transaktion. I dette tilfælde, når smartkontrakten modtager disse mønter, beholder den dem i sin saldo, men i strukturen balances registrerer den, hvem der præcist var afsenderen af disse mønter, for at vide, hvem de tilhører.
Den næste metode kaldes withdraw, og den tager et parameter - det beløb af mønter, som nogen ønsker at trække fra denne bank. Her sker der en kontrol for at se, om der er tilstrækkeligt med mønter på brugerens saldo, som kalder denne metode, til at sende dem. Hvis der er nok, returnerer smartkontrakten selv dette beløb af mønter til den, der kalder.
Derefter følger metoden til at tjekke den aktuelle saldo for brugeren. Den, der kalder denne metode, vil blive brugt til at hente denne saldo i smartkontrakten. Det er værd at bemærke, at denne metode har en modifier - view. Dette betyder, at metoden på ingen måde ændrer variablerne i sin klasse, og faktisk er den kun en læsemetode. Ingen separat transaktion oprettes til at kalde denne metode, gebyret betales ikke, og alle beregninger udføres lokalt, hvorefter brugeren modtager resultatet.
Metoden kill er nødvendig for at ødelægge tilstanden af smartkontrakten. Her er der en ekstra kontrol for at se, om den, der kalder denne metode, er ejer af kontrakten. Hvis ja, selvødelægger kontrakten sig selv, og ødelæggelsesfunktionen tager et parameter - kontoudidentifikatoren, som kontrakten vil sende alle mønter, der er tilbage på dens saldo, til. I dette tilfælde vil de resterende mønter automatisk blive sendt til ejerens adresse.
Hvordan fungerer en fuld node i Ethereum-netværket?
Lad os se skematisk, hvordan sådanne smartkontrakter udføres på Ethereum-platformen, og hvordan en fuld node i netværket fungerer.
En fuld node i Ethereum-netværket skal mindst have fire moduler.
Den første, ligesom for enhver decentraliseret protokol, er P2P networking module - netværksforbindelsesmodulet og arbejdet med andre noder, hvor der sker udveksling af blokke, transaktioner og information om andre noder. Dette er en traditionel komponent for alle decentraliserede kryptovalutaer.
Derudover har vi en blockchain-datastorage-modul, behandling, valg af prioritetsgren, blokudvidelse, blokafkobling, kontrol af disse blokke osv.
Den tredje modul kaldes EVM (Ethereum Virtual Machine) – det er virtual machine, der modtager bytecode fra Ethereum-transaktionen. Dette modul modtager den nuværende tilstand af en bestemt konto og foretager ændringer i dens tilstand baseret på den modtagne bytecode. Versionen af den virtuelle maskine på hver af netværkets noder skal være den samme. Beregningerne sker på hver af Ethereum-noderne fuldstændig ens, men de sker asynkront: nogle verificerer og accepterer denne transaktion før andre, dvs. de udfører hele den indeholdte kode, mens andre gør det senere. Derfor, når en transaktion oprettes, bliver den spredt i netværket, noderne modtager den og i verificeringsøjeblikket, ligesom Bitcoin Script udføres i Bitcoin, udføres her bytekoden fra den virtuelle maskine.
En transaktion betragtes som verificeret, hvis al den indeholdte kode er blevet udført, et nyt status for en bestemt konto er genereret og gemt indtil det er klart, om denne transaktion er blevet anvendt eller ej. Hvis transaktionen er blevet anvendt, så betragtes denne tilstand ikke kun som udført, men også som aktuel. Der er en database, der gemmer tilstanden af hver konto for hver node i netværket. Da alle beregninger sker ensartet, og blockchain-tilstanden er den samme, vil databasen, der indeholder tilstandene for alle konti, også være ens for hver node.
Myter og begrænsninger af smart contracts
Hvad angår de begrænsninger, der findes for Ethereum-lignende platforme for smart contracts, kan følgende nævnes:
- kodeudførelse;
- allokere hukommelse;
- blockchain-data;
- send betalinger;
- oprette nye kontrakter;
- kalde andre kontrakter.
Lad os se på de begrænsninger, der pålægges den virtuelle maskine, og samtidig aflive nogle myter om smart contracts. På en virtuel maskine, som kan findes ikke kun i Ethereum, men også i lignende platforme, kan der udføres reelt vilkårlige logiske operationer, hvilket betyder, at man kan skrive kode, og den vil blive udført der, desuden kan der tildeles ekstra hukommelse. Men gebyret betales særskilt for hver operation og for hver tillagt enhed af hukommelse.
Derudover kan den virtuelle maskine læse data fra blockchain-databasen for at bruge disse data som udløser for at udføre forskellig logik af smart contracts. Den virtuelle maskine kan oprette og sende transaktioner, den kan oprette nye kontrakter og kalde metoder fra andre smart contracts, der allerede er offentliggjort i netværket: de eksisterer, er tilgængelige osv.
Den mest udbredte myte er, at Ethereum smart contracts kan bruge oplysninger fra enhver internetressource i deres betingelser. Sandheden er, at den virtuelle maskine ikke kan sende en netværksforespørgsel til en ekstern informationsressource på internettet, det vil sige, man kan ikke skrive en sådan smart contract, der vil distribuere værdi mellem brugerne afhængigt af, for eksempel, hvad vejret er udenfor, eller hvem der vandt en bestemt turnering, eller baseret på hvilke andre hændelser der skete i den omgivende verden, fordi informationen om disse hændelser simpelthen ikke findes i databasen på selve platformen. Med andre ord er der ikke noget i blockchain i den henseende. Hvis det ikke vises der, så kan den virtuelle maskine ikke bruge disse data som udløsere.
Ulemper ved Ethereum
Lad os gennemgå de vigtigste ulemper. Den første ulempe er, at der er visse udfordringer ved design, udvikling og test af smart contracts i Ethereum (i Ethereum benyttes programmeringssproget Solidity til at skrive smart contracts). Faktisk viser praksis, at en meget stor procentdel af alle fejl kan tilskrives menneskelige faktorer. Dette er faktisk også relevant for allerede skrevne smart contracts i Ethereum, som har en gennemsnitlig eller høj kompleksitet. For enkle smart contracts er sandsynligheden for fejl lav, men i komplekse smart contracts opstår der ofte fejl, der fører til tyveri af midler, frysing af midler og utilsigtet destruktion af smart contracts m.m. Der er allerede mange kendte tilfælde af sådanne hændelser.
Den anden ulempe er, at selve den virtuelle maskine ikke er perfekt, da den også er skrevet af mennesker. Den kan udføre arbitrære kommandoer, og her ligger der en sårbarhed: man kan konfigurere et antal kommandoer på en bestemt måde, som vil føre til uforudsete konsekvenser. Dette er et meget komplekst område, men der eksisterer allerede flere undersøgelser, som viser, at disse sårbarheder findes i den nuværende version af Ethereum-netværket, og de kan føre til, at mange smart contracts ikke fungerer.
Endnu en stor udfordring, som kan betragtes som en ulempe, er, at man på praktisk eller teknisk vis kan komme frem til, at hvis man kompilere bytekoden af kontrakten, der vil blive udført på den virtuelle maskine, kan man bestemme en specifik rækkefølge af operationer. Når disse operationer udføres samlet, vil de lægge en betydelig belastning på den virtuelle maskine og dramatisk forsinke den i forhold til det gebyr, der blev betalt for udførelsen af disse operationer.
Tidligere har der været en udviklingsperiode for Ethereum, hvor mange mennesker, som havde en dyb forståelse af virtuel maskines funktion, fandt sådanne sårbarheder. Faktisk betalte transaktioner meget lave gebyrer, men de bremsede praktisk talt netværkets samlede funktion. Disse problemer er svære at løse, da det først kræver, at de bliver bestemt, for det andet kræver det at justere prisen for udførelsen af disse operationer, og for det tredje at udføre en hard fork, hvilket indebærer opdatering af alle netværksnoder til den nye version af softwaren, og derefter en samtidig aktivering af disse ændringer.
Når det kommer til Ethereum, er der blevet udført mange undersøgelser og opnået en betydelig praktisk erfaring: både positiv og negativ, men der er stadig kompleksiteter og sårbarheder, som vi skal finde en løsning på.
Så, den tematiske del af artiklen er afsluttet; lad os gå videre til de spørgsmål, der ofte dukker op.
Ofte stillede spørgsmål
— Hvis alle parter i den aktive smart-kontrakt ønsker at ændre betingelserne, kan de så opsige denne smart-kontrakt ved hjælp af multiparty signatur og derefter oprette en ny smart-kontrakt med de opdaterede betingelser for dens udførelse?
Her vil svaret være todelt. Hvorfor? Fordi smart-kontrakten engang er oprettet, og den ikke forudser nogen ændringer, men på den anden side kan den have en forudbestemt logik, der tillader totale eller delvise ændringer af nogle betingelser. Så hvis du ønsker at ændre noget i din smart-kontrakt, skal du på forhånd definere de betingelser, under hvilke du kan opdatere disse betingelser. Derfor er det kun på denne forsigtige måde, at man kan organisere opdateringen af kontrakten. Men her kan man også støde på problemer: lave nogle fejl og derved skabe en relateret sårbarhed. Derfor skal sådanne ting designes og testes meget detaljeret og omhyggeligt.
— Hvad nu hvis mediator går i sammensværgelse med en af de deltagende parter: escrow eller smart-kontrakten? Er en mediator obligatorisk i en smart-kontrakt?
En mægler er ikke nødvendig i en smart kontrakt. Den kan være fraværende. Hvis mægleren i tilfælde af escrow indgår en aftale med en af parterne, ja, så mister denne ordning hurtigt sin værdi. Derfor vælges mæglere på en sådan måde, at de har tillid fra alle involverede parter. Derfor vil du simpelthen ikke overføre mønter til en multisignaturadresse med den mægler, du ikke har tillid til.
— Er det muligt at overføre mange forskellige tokens fra sin adresse til forskellige mål adresser, for eksempel børsadresser, hvor disse tokens handles, med én Ethereum-transaktion?
Det er et godt spørgsmål, og det handler om Ethereum-transaktionsmodellen og dens forskelle fra Bitcoin-modellen. Og forskellen er markant. I Ethereum-transaktionsmodellen overfører du simpelthen mønter; de overføres kun fra én adresse til en anden, uden veksling, bare det specifikke beløb, du angiver. Med andre ord er det ikke en model for ikke-brugte udgange (UTXO), men en model af netop konti og de tilsvarende saldi. Teoretisk set kan man sende flere forskellige tokens med én transaktion, hvis man skriver en smart kontrakt, men det vil stadig kræve mange transaktioner, oprette kontrakten, derefter overføre tokens og mønter til den og derefter kalde den relevante metode. Dette kræver kræfter og tid, derfor fungerer det ikke i praksis, og alle betalinger i Ethereum udføres med separate transaktioner.
— En af myterne om Ethereum-platformen er, at det ikke er muligt at beskrive sådanne betingelser, der ville afhænge af data fra en ekstern internetressource, hvad skal man så gøre?
Løsningen er, at selve smart kontrakten kan forudse én eller flere såkaldte betroede orakler, der indsamler data om tilstanden i verden uden for og overfører dem til smart kontrakterne gennem særlige metoder. Selve kontrakten anser de data for at være sande, som den har modtaget fra betroede parter. For større pålidelighed vælger man simpelthen en større gruppe orakler og minimerer risikoen for deres sammensværgelse. Selve kontrakten kan ignorere data fra orakler, der modsiger flertallet.
Dette emne er dedikeret til et af foredragene i det online kursus om Blockchain — “”.
Kilde: habr.com
