I denne artikel vil vi se på, hvad smarte kontrakter er, hvad de er, vi vil stifte bekendtskab med forskellige smarte kontraktplatforme, deres funktioner og også diskutere, hvordan de fungerer, og hvilke fordele de kan give. Dette materiale vil være meget nyttigt for læsere, der ikke er godt bekendt med emnet smarte kontrakter, men ønsker at komme tættere på at forstå det.
Almindelig kontrakt vs. smart kontrakt
Før vi dykker ned i detaljerne, lad os tage et eksempel på forskellene mellem en almindelig kontrakt, som er specificeret på papir, og en smart kontrakt, som er repræsenteret digitalt.
Hvordan fungerede dette før fremkomsten af smarte kontrakter? Forestil dig en gruppe mennesker, der ønsker at etablere bestemte regler og betingelser for fordeling af værdier, samt en bestemt mekanisme til at garantere implementeringen af denne fordeling i henhold til de givne regler og betingelser. Derefter ville de mødes, lave et papir, hvorpå de skrev deres identifikationsoplysninger, vilkårene, de involverede værdier ned, daterede dem og underskrev dem. Denne kontrakt blev også certificeret af en betroet part, såsom en notar. Yderligere gik disse mennesker i forskellige retninger med deres papirkopi af en sådan kontrakt og begyndte at udføre nogle handlinger, der måske ikke svarede til selve kontrakten, det vil sige, de gjorde én ting, men på papiret blev det bekræftet, at de skulle gøre noget helt anderledes. Og hvordan kommer man ud af denne situation? Faktisk skal et af gruppemedlemmerne tage dette papir, tage nogle beviser, tage det for retten og opnå overensstemmelse mellem kontrakten og faktiske handlinger. Ganske ofte er det svært at opnå retfærdig gennemførelse af denne kontrakt, hvilket fører til ubehagelige konsekvenser.
Hvad kan man sige om smarte kontrakter? De kombinerer både muligheden for at skrive vilkårene i kontrakten og mekanismen for deres strenge gennemførelse. Hvis betingelserne er fastsat, og den tilsvarende transaktion eller anmodning er blevet underskrevet, så er det ikke længere muligt at ændre betingelserne eller påvirke deres gennemførelse, når den pågældende anmodning eller transaktion er blevet accepteret.
Der er én validator eller et helt netværk, samt en database, der gemmer alle smarte kontrakter, der blev indsendt til udførelse i streng kronologisk rækkefølge. Det er også vigtigt, at denne database skal indeholde alle udløsende betingelser for at udføre den smarte kontrakt. Derudover skal der tages hensyn til selve værdien, hvis fordeling er beskrevet i kontrakten. Hvis dette gælder for en eller anden digital valuta, bør denne database tage højde for det.
Med andre ord skal smarte kontraktvalidatorer have adgang til alle de data, som den smarte kontrakt opererer på. For eksempel bør en enkelt database bruges til samtidig at redegøre for digitale valutaer, brugersaldi, brugertransaktioner og tidsstempler. Så kan betingelsen i en smart kontrakt være brugerens saldo i en bestemt valuta, ankomsten af et bestemt tidspunkt eller det faktum, at en bestemt transaktion er blevet gennemført, men ikke mere.
Definition af en smart kontrakt
Generelt blev selve terminologien opfundet af forskeren Nick Szabo og brugt første gang i 1994 og blev dokumenteret i 1997 i en artikel, der beskriver selve ideen om smarte kontrakter.
Smarte kontrakter indebærer, at der udføres en vis automatisering af værdifordelingen, som kun kan afhænge af de forudbestemte forhold. I sin enkleste form ligner det en kontrakt med strengt definerede vilkår, som er underskrevet af visse parter.
Smarte kontrakter er designet til at minimere tilliden til tredjeparter. Nogle gange er det beslutningscenter, som alt afhænger af, fuldstændig udelukket. Desuden er sådanne kontrakter lettere at revidere. Dette er en konsekvens af nogle designfunktioner i et sådant system, men oftest forstår vi ved en smart kontrakt et decentraliseret miljø og tilstedeværelsen af funktioner, der giver enhver mulighed for at analysere databasen og udføre en fuld revision af udførelsen af kontrakter. Dette sikrer beskyttelse mod tilbagevirkende dataændringer, der ville medføre ændringer i udførelsen af selve kontrakten. Digitalisering af de fleste processer ved oprettelse og lancering af en smart kontrakt forenkler ofte teknologien og omkostningerne ved deres implementering.
Et simpelt eksempel - Escrow service
Lad os se på et meget simpelt eksempel. Det vil hjælpe dig med at komme tættere på at forstå funktionaliteten af smarte kontrakter, samt bedre forstå, i hvilke tilfælde de skal bruges.
Det kan også implementeres ved hjælp af Bitcoin, selvom Bitcoin lige nu stadig næppe kan kaldes en fuldgyldig platform for smarte kontrakter. Så vi har en køber, og vi har en online butik. En kunde ønsker at købe en skærm fra denne butik. I det enkleste tilfælde gennemfører og sender køber en betaling, og netbutikken accepterer den, bekræfter den og sender derefter varerne. Men i denne situation er der behov for stor tillid – køberen skal stole på netbutikken for hele prisen på skærmen. Da en netbutik kan have et lavt omdømme i købers øjne, er der risiko for, at butikken af en eller anden grund, efter at have accepteret betalingen, nægter service og ikke sender varerne til køberen. Derfor stiller køberen spørgsmålet (og følgelig stiller onlinebutikken dette spørgsmål), hvad der kan anvendes i dette tilfælde for at minimere sådanne risici og gøre sådanne transaktioner mere pålidelige.
I Bitcoins tilfælde er det muligt at give køber og sælger mulighed for uafhængigt at vælge en mægler. Der er mange mennesker, der er involveret i at løse kontroversielle spørgsmål. Og vores deltagere kan fra en generel liste over mediatorer vælge den, de vil stole på. Sammen skaber de en 2 af 3 multisignaturadresse, hvor der er tre nøgler, og der kræves to signaturer med to vilkårlige nøgler for at bruge mønter fra den adresse. Den ene nøgle tilhører køberen, den anden til netbutikken og den tredje til mægleren. Og til en sådan multisignatur-adresse sender køberen det nødvendige beløb for at betale for skærmen. Nu, når sælgeren ser, at penge er spærret i nogen tid på en multisignatur-adresse, der afhænger af ham, kan han trygt sende skærmen med posten.
Dernæst modtager køber pakken, inspicerer varerne og træffer beslutning om det endelige køb. Han kan være helt enig i den leverede service og underskrive transaktionen med sin nøgle, hvor han overfører mønter fra multisignaturadressen til sælgeren, eller han kan være utilfreds med noget. I det andet tilfælde kontakter han en mægler for at sammensætte en alternativ transaktion, der vil fordele disse mønter anderledes.
Lad os sige, at skærmen ankom lidt ridset, og at sættet ikke indeholdt et kabel til tilslutning til computeren, selvom netbutikkens hjemmeside sagde, at kablet skulle være inkluderet i sættet. Så indsamler køberen de nødvendige beviser for at bevise over for mægleren, at han blev bedraget i denne situation: han tager skærmbilleder af webstedet, tager et billede af postkvitteringen, tager et billede af ridserne på skærmen og viser, at forseglingen var knækket og kablet blev trukket ud. Netbutikken indsamler til gengæld sine beviser og overfører dem til mægleren.
Mægleren er interesseret i samtidig at tilfredsstille både køberens indignation og netbutikkens interesser (det vil blive klart hvorfor senere). Det er en transaktion, hvor mønter fra en multisignatur-adresse vil blive brugt i et vist forhold mellem køberen, netbutikken og mægleren, da han tager en del til sig selv som belønning for sit arbejde. Lad os sige, at 90 % af det samlede beløb går til sælger, 5 % til mægler og 5 % kompensation til køber. Mægleren underskriver denne transaktion med sin nøgle, men den kan endnu ikke anvendes, fordi den kræver to underskrifter, men kun én er det værd. Det sender en sådan transaktion til både køber og sælger. Hvis mindst en af dem er tilfreds med denne mulighed for omfordeling af mønter, vil transaktionen blive underskrevet på forhånd og distribueret til netværket. For at validere det er det nok, at en af parterne i transaktionen er enig i mæglerens mulighed.
Det er vigtigt i første omgang at vælge en mediator, så begge deltagere har tillid til ham. I dette tilfælde vil han handle uafhængigt af den ene eller den andens interesser og objektivt vurdere situationen. Hvis mægleren ikke giver mulighed for at distribuere mønter, der vil tilfredsstille mindst én deltager, kan både køberen og netbutikken, efter at have aftalt dem, sende mønterne til en ny multisignatur-adresse ved at sætte deres to underskrifter. Den nye multisignaturadresse vil blive udarbejdet med en anden mediator, som kan være mere kompetent i sagen og give en bedre mulighed.
Eksempel med en sovesal og et køleskab
Lad os se på et mere komplekst eksempel, der viser mulighederne for en smart kontrakt mere eksplicit.
Lad os sige, at der er tre fyre, der for nylig er flyttet ind i det samme kollegieværelse. De er tre interesserede i at købe et køleskab til deres værelse, som de kan bruge sammen. En af dem meldte sig frivilligt til at indsamle det nødvendige beløb til at købe et køleskab og forhandle med sælgeren. De har dog først mødt hinanden for nylig, og der er ikke nok tillid mellem dem. Det er klart, at to af dem tager en risiko ved at give penge til den tredje. Derudover skal de nå til enighed om valget af sælger.
De kan bruge escrow-tjenesten, det vil sige vælge en mægler, der vil overvåge udførelsen af transaktionen og løse kontroversielle problemer, hvis nogen opstår. Derefter, efter at være blevet enige, udarbejder de en smart kontrakt og foreskriver visse betingelser i den.
Den første betingelse er, at inden et bestemt tidspunkt, f.eks. inden for en uge, skal den tilsvarende smarte kontraktkonto modtage tre betalinger fra bestemte adresser for et bestemt beløb. Hvis dette ikke sker, stopper den smarte kontrakt med at udføre og returnerer mønterne til alle deltagere. Hvis betingelsen er opfyldt, sættes værdierne af sælger- og mediator-id'erne, og det kontrolleres, at alle deltagere er enige i valget af sælger og mediator. Når alle betingelser er opfyldt, vil midlerne blive overført til de angivne adresser. Denne tilgang kan beskytte deltagere mod svindel fra enhver side og eliminerer generelt behovet for at have tillid.
Vi ser i dette eksempel selve princippet om, at denne evne til trin-for-trin at indstille parametre for at opfylde hver betingelse giver dig mulighed for at skabe systemer af enhver kompleksitet og dybde af indlejrede niveauer. Derudover kan du først definere den første betingelse i den smarte kontrakt, og først efter dens opfyldelse kan du indstille parametre for den næste betingelse. Med andre ord er betingelsen formelt skrevet, og parametre for den kan indstilles allerede under driften.
Klassificering af smarte kontrakter
Til klassificering kan du indstille forskellige grupper af kriterier. Men i øjeblikket af teknologiudvikling er fire af dem relevante.
Smarte kontrakter kan kendetegnes ved deres eksekveringsmiljø, som enten kan være centraliseret eller decentraliseret. I tilfælde af decentralisering har vi meget større uafhængighed og fejltolerance, når vi udfører smarte kontrakter.
De kan også skelnes ved processen med at indstille og opfylde betingelser: de kan være frit programmerbare, begrænsede eller foruddefinerede, dvs. strengt skrevet. Når der kun er 4 specifikke smarte kontrakter på smart contract platformen, kan parametrene for dem indstilles på enhver måde. Derfor er det meget enklere at indstille dem: vi vælger en kontrakt fra listen og videregiver parametrene.
Ifølge initieringsmetoden er der automatiserede smarte kontrakter, det vil sige, når visse forhold opstår, er de selvudførende, og der er kontrakter, hvor betingelserne er specificeret, men platformen kontrollerer ikke automatisk deres opfyldelse; for dette skal igangsættes særskilt.
Derudover varierer smarte kontrakter i deres niveau af privatliv. De kan enten være helt åbne, delvist eller helt fortrolige. Sidstnævnte betyder, at tredjepartsobservatører ikke kan se vilkårene for smarte kontrakter. Emnet privatliv er dog meget bredt, og det er bedre at overveje det separat fra den aktuelle artikel.
Nedenfor vil vi se nærmere på de første tre kriterier for at skabe større klarhed over forståelsen af det aktuelle emne.
Smarte kontrakter efter kørselstid
Med udgangspunkt i udførelsesmiljøet skelnes der mellem centraliserede og decentraliserede smarte kontraktplatforme. Ved centraliserede digitale kontrakter anvendes en enkelt tjeneste, hvor der kun er én validator og der kan være en backup- og gendannelsestjeneste, som også styres centralt. Der er én database, der gemmer al den nødvendige information til at sætte vilkårene for den smarte kontrakt og distribuere den værdi, der tages i betragtning i netop denne servicedatabase. En sådan centraliseret tjeneste har en klient, der stiller betingelser med visse anmodninger og bruger sådanne kontrakter. På grund af platformens centraliserede karakter kan autentificeringsmekanismer være mindre sikre end i kryptovalutaer.
Som et eksempel kan vi tage mobilkommunikationsudbydere (forskellige mobiloperatører). Lad os sige, at en bestemt operatør fører en centraliseret registrering af trafikken på sine servere, som kan transmitteres i forskellige formater, for eksempel: i form af taleopkald, SMS-transmission, mobil internettrafik og i henhold til forskellige standarder, og fører også optegnelser af midler på brugersaldi. I overensstemmelse hermed kan udbyderen af mobilkommunikation indgå kontrakter om regnskabsføring af de leverede tjenester og deres betaling med forskellige betingelser. I dette tilfælde er det nemt at sætte betingelser som "send en SMS med sådan og sådan en kode til sådan og sådan et nummer, og du vil modtage sådanne og sådanne betingelser for trafikdistribution."
Endnu et eksempel kan nævnes: traditionelle banker med udvidet funktionalitet af internetbank og meget simple kontrakter såsom almindelige betalinger, automatisk konvertering af indgående betalinger, automatisk fradrag af renter til en specificeret konto mv.
Hvis vi taler om smarte kontrakter med et decentraliseret eksekveringsmiljø, så har vi en gruppe validatorer. Ideelt set kan enhver blive validator. På grund af databasesynkroniseringsprotokollen og opnåelse af konsensus har vi en fælles database, der nu vil gemme alle transaktioner med strengt beskrevne kontrakter, og ikke nogle betingede forespørgsler, hvis formater ofte ændres, og der er ingen åben specifikation. Her vil transaktioner indeholde instruktioner om at udføre kontrakten i henhold til en streng specifikation. Denne specifikation er åben, og derfor kan platformbrugere selv revidere og validere smarte kontrakter. Her ser vi, at decentraliserede platforme er overlegne i forhold til centraliserede med hensyn til uafhængighed og fejltolerance, men deres design og vedligeholdelse er meget mere kompleks.
Smarte kontrakter ved at sætte og opfylde betingelser
Lad os nu se nærmere på, hvordan smarte kontrakter kan adskille sig i den måde, de sætter og opfylder betingelser. Her retter vi vores opmærksomhed mod smarte kontrakter, der er tilfældigt programmerbare og Turing komplette. En Turing-komplet smart kontrakt giver dig mulighed for at sætte næsten alle algoritmer som betingelser for udførelse af kontrakten: skrivecyklusser, nogle funktioner til beregning af sandsynligheder og lignende - helt ned til dine egne elektroniske signaturalgoritmer. I dette tilfælde mener vi virkelig vilkårlig logikskrivning.
Der er også vilkårlige smarte kontrakter, men ikke Turing komplette. Dette inkluderer Bitcoin og Litecoin med deres eget script. Det betyder, at du kun kan bruge bestemte operationer i vilkårlig rækkefølge, men du kan ikke længere skrive loops og dine egne algoritmer.
Derudover er der smarte kontraktplatforme, der implementerer foruddefinerede smarte kontrakter. Disse inkluderer Bitshares og Steemit. Bitshares har en række smarte kontrakter til handel, kontostyring, administration af selve platformen og dens parametre. Steemit er en lignende platform, men den er ikke længere fokuseret på udstedelse af tokens og handel, som Bitshares, men på blogging, dvs. den gemmer og behandler indhold på en decentral måde.
Vilkårlige Turing-komplette kontrakter inkluderer Ethereum-platformen og RootStock, som stadig er under udvikling. Derfor vil vi nedenfor dvæle lidt mere detaljeret ved Ethereums smarte kontraktplatform.
Smarte kontrakter efter initieringsmetode
Baseret på initieringsmetoden kan smarte kontrakter også opdeles i mindst to grupper: automatiserede og manuelle (ikke automatiserede). Automatiserede er kendetegnet ved, at i betragtning af alle kendte parametre og betingelser udføres den smarte kontrakt fuldstændig automatisk, det vil sige, at den ikke kræver at sende yderligere transaktioner og bruge en ekstra kommission på hver efterfølgende udførelse. Platformen selv har alle data til at beregne, hvordan den smarte kontrakt vil fuldføre. Logikken dér er ikke vilkårlig, men forudbestemt, og alt dette er forudsigeligt. Det vil sige, at du på forhånd kan estimere kompleksiteten af at udføre en smart kontrakt, bruge en form for konstant kommission for det, og alle processer til dens implementering er mere effektive.
For smarte kontrakter, der er frit programmerede, er eksekveringen ikke automatiseret. For at påbegynde en sådan smart kontrakt skal du ved stort set hvert trin oprette en ny transaktion, som kalder det næste udførelsestrin eller den næste smarte kontraktmetode, betaler den passende kommission og venter på, at transaktionen bliver bekræftet. Udførelsen kan gennemføres med succes eller ej, fordi den smarte kontraktkode er vilkårlig, og nogle uforudsigelige øjeblikke kan dukke op, såsom en evig løkke, mangel på nogle parametre og argumenter, ubehandlede undtagelser osv.
Ethereum-konti
Ethereum-kontotyper
Lad os se på, hvilke typer konti der kan være på Ethereum-platformen. Der er kun to typer konti her, og der er ingen andre muligheder. Den første type kaldes en brugerkonto, den anden er en kontraktkonto. Lad os finde ud af, hvordan de adskiller sig.
Brugerkontoen styres kun af den personlige nøgle til den elektroniske signatur. Kontoejeren genererer sit eget nøglepar til elektronisk signatur ved hjælp af ECDSA (Elliptic Curve Digital Signature Algorithm) algoritmen. Kun transaktioner, der er signeret med denne nøgle, kan ændre denne kontos tilstand.
En separat logik er tilvejebragt for den smarte kontraktkonto. Det kan kun styres af foruddefineret softwarekode, der fuldstændigt bestemmer adfærden af den smarte kontrakt: hvordan den vil administrere sine mønter under visse omstændigheder, på initiativ af hvilken bruger og under hvilke yderligere betingelser disse mønter vil blive distribueret. Hvis nogle punkter ikke er fastsat af udviklerne i programkoden, kan der opstå problemer. For eksempel kan en smart kontrakt modtage en bestemt tilstand, hvor den ikke accepterer initiering af yderligere eksekvering fra nogen af brugerne. I dette tilfælde vil mønterne faktisk blive frosset, fordi den smarte kontrakt ikke giver mulighed for at forlade denne tilstand.
Sådan oprettes konti på Ethereum
I tilfælde af en brugerkonto genererer ejeren selvstændigt et nøglepar ved hjælp af ECDSA. Det er vigtigt at bemærke, at Ethereum bruger nøjagtig den samme algoritme og nøjagtig den samme elliptiske kurve til elektroniske signaturer som Bitcoin, men adressen er beregnet på en lidt anden måde. Her bruges resultatet af dobbelt hashing ikke længere, som i Bitcoin, men enkelt hashing er forsynet med Keccak-funktionen i en længde på 256 bit. De mindst signifikante bit afskæres fra den resulterende værdi, nemlig de mindst signifikante 160 bit af output-hashværdien. Som et resultat får vi en adresse i Ethereum. Faktisk fylder det 20 bytes.
Bemærk venligst, at konto-id'et i Ethereum er kodet i hex uden at anvende en kontrolsum, i modsætning til Bitcoin og mange andre systemer, hvor adressen er kodet i et base 58-talsystem med tilføjelse af en kontrolsum. Dette betyder, at du skal være forsigtig, når du arbejder med kontoidentifikatorer i Ethereum: selv en fejl i identifikatoren vil garanteret føre til tab af mønter.
Der er en vigtig funktion, og det er, at en brugerkonto på det generelle databaseniveau oprettes i det øjeblik, han accepterer den første indgående betaling.
Oprettelse af en smart kontraktkonto tager en helt anden tilgang. I første omgang skriver en af brugerne kildekoden til den smarte kontrakt, hvorefter koden sendes gennem en specialkompiler til Ethereum-platformen, hvorved der opnås bytekode til sin egen virtuelle Ethereum-maskine. Den resulterende bytekode placeres i et særligt felt af transaktionen. Det er certificeret på vegne af initiativtagerens konto. Dernæst spredes denne transaktion gennem netværket og placerer den smarte kontraktkode. Provisionen for transaktionen og følgelig for udførelsen af kontrakten trækkes fra saldoen på initiativtagerens konto.
Hver smart kontrakt indeholder nødvendigvis sin egen konstruktør (af denne kontrakt). Det kan være tomt, eller det kan have indhold. Efter at konstruktøren er udført, oprettes en smart kontraktkontoidentifikator, ved hjælp af hvilken du kan sende mønter, kalde visse smarte kontraktmetoder osv.
Ethereum-transaktionsstruktur
For at gøre det klarere, vil vi begynde at se på strukturen af en Ethereum-transaktion og et eksempel på en smart kontraktkode.
En Ethereum-transaktion består af flere felter. Den første af disse, nonce, er et bestemt serienummer på transaktionen i forhold til selve kontoen, der distribuerer den og er dens forfatter. Dette er nødvendigt for at skelne mellem dobbelttransaktioner, det vil sige for at udelukke tilfældet, hvor den samme transaktion accepteres to gange. Ved at bruge en identifikator har hver transaktion en unik hashværdi.
Dernæst kommer et felt som gaspris. Dette angiver den pris, hvortil Ethereum-basisvalutaen konverteres til gas, som bruges til at betale for udførelsen af den smarte kontrakt og tildelingen af den virtuelle maskinressource. Hvad betyder det?
I Bitcoin betales gebyrer direkte af basisvalutaen - Bitcoin selv. Dette er muligt takket være en simpel mekanisme til at beregne dem: vi betaler strengt for mængden af data, der er indeholdt i transaktionen. I Ethereum er situationen mere kompliceret, fordi det er meget vanskeligt at stole på mængden af transaktionsdata. Her kan transaktionen også indeholde programkode, der vil blive udført på den virtuelle maskine, og hver operation af den virtuelle maskine kan have forskellig kompleksitet. Der er også operationer, der allokerer hukommelse til variabler. De vil have deres egen kompleksitet, som betalingen for hver operation vil afhænge af.
Omkostningerne ved hver operation i gasækvivalent vil være konstante. Det er indført specifikt for at bestemme de konstante omkostninger ved hver operation. Afhængigt af belastningen på netværket vil gasprisen ændre sig, det vil sige koefficienten, ifølge hvilken basisvalutaen vil blive konverteret til denne hjælpeenhed for at betale provisionen.
Der er endnu et træk ved en transaktion i Ethereum: bytekoden, som den indeholder til udførelse i en virtuel maskine, vil blive udført, indtil den afsluttes med et eller andet resultat (succes eller fiasko), eller indtil en vis mængde af tildelte mønter løber tør for at betale kommissionen . Det er for at undgå en situation, hvor alle mønter fra afsenderens konto i tilfælde af en fejl blev brugt på kommission (for eksempel en form for evig cyklus startet i en virtuel maskine), findes følgende felt - start gas (ofte kaldet gasgrænse) - det bestemmer det maksimale antal mønter, som afsenderen er villig til at bruge for at gennemføre en bestemt transaktion.
Det næste felt kaldes destinationsadresse. Dette inkluderer adressen på modtageren af mønterne eller adressen på en specifik smart kontrakt, hvis metoder vil blive kaldt. Efter det kommer feltet værdi, hvor mængden af mønter, der sendes til destinationsadressen, indtastes.
Næste er et interessant felt kaldet data, hvor hele strukturen passer ind. Dette er ikke et separat felt, men en hel struktur, hvor koden til den virtuelle maskine er defineret. Du kan placere vilkårlige data her - der er separate regler for dette.
Og det sidste felt hedder signatur. Den indeholder samtidig både den elektroniske signatur fra forfatteren af denne transaktion og den offentlige nøgle, som denne signatur vil blive verificeret med. Fra den offentlige nøgle kan du få konto-id'et for afsenderen af denne transaktion, det vil sige entydigt identificere afsenderens konto i selve systemet. Vi fandt ud af det vigtigste om strukturen af transaktionen.
Eksempel på smart kontraktkode for Solidity
Lad os nu se nærmere på den enkleste smarte kontrakt ved hjælp af et 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 en forenklet kildekode, der kan indeholde brugernes mønter og returnere dem efter behov.
Så der er en banksmart kontrakt, der udfører følgende funktioner: den akkumulerer mønter på sin saldo, det vil sige, når en transaktion bekræftes, og en sådan smart kontrakt er placeret, oprettes en ny konto, der kan indeholde mønter på sin saldo; det husker brugere og fordelingen af mønter mellem dem; har flere metoder til at administrere saldi, det vil sige, at det er muligt at genopfylde, hæve og kontrollere brugerens saldo.
Lad os gennemgå hver linje med kildekode. Denne kontrakt har konstante felter. En af dem, med typeadresse, hedder ejer. Her husker kontrakten adressen på den bruger, der har oprettet denne smarte kontrakt. Yderligere er der en dynamisk struktur, der opretholder overensstemmelse mellem brugeradresser og balancer.
Herefter følger Bankmetoden - den har samme navn som kontrakten. Derfor er dette dens konstruktør. Her tildeles ejervariablen adressen på den person, der placerede denne smarte kontrakt på netværket. Dette er det eneste, der sker i denne konstruktør. Det vil sige, msg i dette tilfælde er præcis de data, der blev overført til den virtuelle maskine sammen med transaktionen, der indeholder hele koden for denne kontrakt. Følgelig er msg.sender forfatteren af denne transaktion, der er vært for denne kode. Han bliver ejeren af den smarte kontrakt.
Indbetalingsmetoden giver dig mulighed for at overføre et vist antal mønter til kontraktkontoen ved transaktion. I dette tilfælde efterlader den smarte kontrakt, der modtager disse mønter, dem på sin balance, men registrerer i balancestrukturen, hvem der nøjagtigt var afsenderen af disse mønter for at vide, hvem de tilhører.
Den næste metode kaldes hæve, og det kræver én parameter - mængden af mønter, som nogen ønsker at hæve fra denne bank. Dette kontrollerer, om der er nok mønter i saldoen på den bruger, der kalder denne metode til at sende dem. Hvis der er nok af dem, så returnerer den smarte kontrakt selv det antal mønter til den, der ringer.
Dernæst kommer metoden til at kontrollere brugerens aktuelle saldo. Den, der kalder denne metode, vil blive brugt til at hente denne saldo i den smarte kontrakt. Det er værd at bemærke, at modifikationen af denne metode er udsigt. Det betyder, at selve metoden ikke ændrer variablerne i sin klasse på nogen måde, og det er faktisk kun en læsemetode. Der oprettes ingen særskilt transaktion for at kalde denne metode, der betales intet gebyr, og alle beregninger udføres lokalt, hvorefter brugeren modtager resultatet.
Kill-metoden er nødvendig for at ødelægge tilstanden af den smarte kontrakt. Og her er der en ekstra kontrol, om den, der ringer til denne metode, er ejeren af denne kontrakt. Hvis det er tilfældet, destruerer kontrakten sig selv, og destruktionsfunktionen tager én parameter - konto-id'en, som kontrakten sender alle de resterende mønter på saldoen til. I dette tilfælde vil de resterende mønter automatisk gå til adressen på kontraktejeren.
Hvordan fungerer en fuld node på Ethereum-netværket?
Lad os se skematisk på, hvordan sådanne smarte kontrakter udføres på Ethereum-platformen, og hvordan en fuld netværksknude fungerer.
En fuld node på Ethereum-netværket skal have mindst fire moduler.
Den første, som for enhver decentral protokol, er P2P-netværksmodulet - et modul til netværksforbindelse og arbejde med andre noder, hvor blokke, transaktioner og information om andre noder udveksles. Dette er en traditionel komponent for alle decentraliserede kryptovalutaer.
Dernæst har vi et modul til lagring af blockchain-data, behandling, valg af prioritetsgren, tilføjelse af blokke, frakobling af blokke, validering af disse blokke osv.
Det tredje modul kaldes EVM (Ethereum virtual machine) - dette er en virtuel maskine, der modtager bytekode fra Ethereum-transaktioner. Dette modul tager den aktuelle tilstand for en bestemt konto og foretager ændringer i dens tilstand baseret på den modtagne bytekode. Den virtuelle maskinversion på hver netværksknude skal være den samme. Beregningerne, der finder sted på hver Ethereum-knude, er nøjagtig de samme, men de forekommer på en asynkron måde: nogen kontrollerer og accepterer denne transaktion tidligere, det vil sige udfører al den kode, der er indeholdt i den, og nogen senere. Følgelig, når en transaktion oprettes, distribueres den til netværket, noderne accepterer den, og på tidspunktet for verifikation, på samme måde som Bitcoin Script udføres i Bitcoin, udføres bytekoden for den virtuelle maskine her.
En transaktion anses for at være verificeret, hvis al koden indeholdt i den er blevet udført, en ny tilstand for en bestemt konto er blevet genereret og gemt, indtil det er klart, om denne transaktion er blevet anvendt eller ej. Hvis transaktionen anvendes, betragtes denne tilstand ikke kun som afsluttet, men også aktuel. Der er en database, der gemmer tilstanden for hver konto for hver netværksknude. På grund af det faktum, at alle beregninger foregår på samme måde, og tilstanden af blockchain er den samme, vil databasen, der indeholder tilstandene for alle konti, også være den samme for hver node.
Myter og begrænsninger af smarte kontrakter
Hvad angår de begrænsninger, der findes for smarte kontraktplatforme, der ligner Ethereum, kan følgende citeres:
- kodeudførelse;
- allokere hukommelse;
- blockchain data;
- sende betalinger;
- oprette ny kontrakt;
- ringe til andre kontrakter.
Lad os se på de begrænsninger, der er pålagt en virtuel maskine, og følgelig aflive nogle myter om smarte kontrakter. På en virtuel maskine, som ikke kun kan være i Ethereum, men også i lignende platforme, kan du udføre virkelig vilkårlige logiske operationer, det vil sige skrive kode, og det vil blive udført der, du kan desuden allokere hukommelse. Gebyret betales dog særskilt for hver operation og for hver ekstra tildelt hukommelsesenhed.
Dernæst kan den virtuelle maskine læse data fra blockchain-databasen for at bruge disse data som en trigger til at udføre en eller anden smart kontraktlogik. Den virtuelle maskine kan oprette og sende transaktioner, den kan oprette nye kontrakter og opkaldsmetoder for andre smarte kontrakter, der allerede er offentliggjort på netværket: eksisterende, tilgængelige osv.
Den mest almindelige myte er, at Ethereums smarte kontrakter kan bruge information fra enhver internetressource i deres vilkår. Sandheden er, at en virtuel maskine ikke kan sende en netværksanmodning til en ekstern informationsressource på internettet, det vil sige, at det er umuligt at skrive en smart kontrakt, der vil fordele værdi mellem brugere afhængigt af, for eksempel, hvordan vejret er udenfor, eller hvem der vandt et eller andet mesterskab, eller baseret på hvilken anden hændelse der skete i omverdenen, fordi information om disse hændelser simpelthen ikke findes i selve platformens database. Det vil sige, at der ikke er noget på blockchain om dette. Hvis det ikke vises der, kan den virtuelle maskine ikke bruge disse data som triggere.
Ulemper ved Ethereum
Lad os liste de vigtigste. Den første ulempe er, at der er nogle vanskeligheder med at designe, udvikle og teste smarte kontrakter i Ethereum (Ethereum bruger Solidity-sproget til at skrive smarte kontrakter). Praksis viser faktisk, at en meget stor procentdel af alle fejl tilhører den menneskelige faktor. Dette gælder faktisk for allerede skrevne Ethereum smarte kontrakter, der har gennemsnitlig eller højere kompleksitet. Hvis sandsynligheden for en fejl er lille for simple smarte kontrakter, så er der i komplekse smarte kontrakter meget ofte fejl, der fører til tyveri af midler, deres indefrysning, ødelæggelse af smarte kontrakter på en uventet måde osv. Mange sådanne tilfælde er allerede kendt.
Den anden ulempe er, at selve den virtuelle maskine ikke er perfekt, da den også er skrevet af mennesker. Den kan udføre vilkårlige kommandoer, og deri ligger sårbarheden: en række kommandoer kan konfigureres på en bestemt måde, der vil føre til konsekvenser, der var uforudsete på forhånd. Dette er et meget komplekst område, men der er allerede flere undersøgelser, der viser, at disse sårbarheder eksisterer i den nuværende version af Ethereum-netværket, og de kan føre til fejl i mange smarte kontrakter.
En anden stor vanskelighed, det kan betragtes som en ulempe. Det ligger i det faktum, at du praktisk eller teknisk kan komme til den konklusion, at hvis du kompilerer bytekoden til en kontrakt, der vil blive udført på en virtuel maskine, kan du bestemme en bestemt rækkefølge af operationer. Når de udføres sammen, vil disse operationer i høj grad belaste den virtuelle maskine og bremse den uforholdsmæssigt i forhold til det gebyr, der blev betalt for at udføre disse operationer.
Tidligere var der allerede en periode i udviklingen af Ethereum, hvor mange fyre, der i detaljer forstod driften af en virtuel maskine, fandt sådanne sårbarheder. Faktisk betalte transaktioner et meget lille gebyr, men praktisk talt bremsede hele netværket. Disse problemer er meget vanskelige at løse, da det for det første er nødvendigt at bestemme dem, for det andet at justere prisen for at udføre disse operationer og for det tredje at udføre en hård gaffel, hvilket betyder at opdatere alle netværksknuder til en ny version af softwaren og derefter samtidig aktivering af disse ændringer.
Med hensyn til Ethereum, er der blevet udført en masse forskning, en masse praktisk erfaring er opnået: både positive og negative, men ikke desto mindre er der stadig vanskeligheder og sårbarheder, som stadig skal håndteres på en eller anden måde.
Så den tematiske del af artiklen er afsluttet, lad os gå videre til spørgsmål, der opstår ret ofte.
Ofte stillede spørgsmål
— Hvis alle parter i en eksisterende smart kontrakt ønsker at ændre vilkårene, kan de så annullere denne smarte kontrakt ved hjælp af multisig og derefter oprette en ny smart kontrakt med opdaterede vilkår for dens udførelse?
Svaret her vil være todelt. Hvorfor? For på den ene side er en smart kontrakt defineret én gang, og den indebærer ikke længere ændringer, og på den anden side kan den have forudskrevet logik, der sørger for en hel eller delvis ændring af nogle betingelser. Det vil sige, at hvis du vil ændre noget i din smarte kontrakt, så skal du foreskrive, under hvilke betingelser du kan opdatere disse betingelser. Følgelig kan fornyelsen af kontrakten kun tilrettelægges på en så forsigtig måde. Men også her kan du løbe ind i problemer: lav en fejl og få en tilsvarende sårbarhed. Derfor skal sådanne ting være meget detaljerede og omhyggeligt designet og testet.
— Hvad hvis mægleren indgår en aftale med en af de deltagende parter: escrow eller smart kontrakt? Er en mediator påkrævet i en smart kontrakt?
En mediator er ikke påkrævet i en smart kontrakt. Det findes måske ikke. Hvis mægleren i tilfælde af spærring indgår i en sammensværgelse med en af parterne, så ja, denne ordning mister da kraftigt al sin værdi. Derfor udvælges mæglere på en sådan måde, at de har tillid fra alle parter, der er involveret i denne proces på samme tid. Derfor vil du simpelthen ikke overføre mønter til en multisignatur-adresse med en mediator, som du ikke har tillid til.
— Er det muligt med én Ethereum-transaktion at overføre mange forskellige tokens fra din adresse til forskellige måladresser, for eksempel børsadresser, hvor disse tokens handles?
Dette er et godt spørgsmål, og det vedrører Ethereum-transaktionsmodellen, og hvordan den adskiller sig fra Bitcoin-modellen. Og forskellen er radikal. Hvis du i Ethereum-transaktionsmodellen blot overfører mønter, så overføres de kun fra en adresse til en anden, ingen ændring, kun det specifikke beløb, du har angivet. Dette er med andre ord ikke en model for ubrugte output (UTXO), men en model for konti og tilsvarende saldi. Det er teoretisk muligt at sende flere forskellige tokens i en transaktion på én gang, hvis du skriver en udspekuleret smart kontrakt, men du skal stadig lave mange transaktioner, oprette en kontrakt, derefter overføre poletter og mønter til den, og så kalde den passende metode . Dette kræver indsats og tid, så i praksis fungerer det ikke sådan, og alle betalinger i Ethereum foretages i separate transaktioner.
— En af myterne om Ethereum-platformen er, at det er umuligt at beskrive forhold, der vil afhænge af data fra en ekstern internetressource, så hvad skal man så gøre?
Løsningen er, at den smarte kontrakt i sig selv kan give et eller flere såkaldte betroede orakler, som indsamler data om tingenes tilstand i omverdenen og overfører det til de smarte kontrakter gennem særlige metoder. Selve kontrakten anser de data, den modtog fra betroede parter, for at være sande. For større pålidelighed skal du blot vælge en stor gruppe af orakler og minimere risikoen for deres hemmelige samarbejde. Selve kontrakten må ikke tage højde for data fra orakler, der modsiger flertallet.
Et af foredragene på onlinekurset om Blockchain er viet til dette emne - "".
Kilde: www.habr.com