I denne artikkelen vil vi se på hva smarte kontrakter er, hvilke typer som finnes, bli kjent med de ulike plattformene for smarte kontrakter, deres kjennetegn, samt diskutere hvordan de fungerer og hvilke fordeler de kan ha. Dette materialet vil være svært nyttig for lesere som ikke er godt kjent med temaet smarte kontrakter, men som ønsker å nærme seg forståelsen av det.
Vanlig kontrakt vs. smart kontrakt
Før vi går dypere inn i detaljene, la oss ta et eksempel på forskjellene mellom en vanlig kontrakt som er skrevet på papir, og en smart kontrakt som er presentert i digital form.
Hvordan fungerte det før smarte kontrakter kom? Tenk deg en gruppe mennesker som ønsker å etablere noen regler og betingelser for distribusjon av verdier, samt et spesifikt mekanisme for å garantere gjennomføringen av denne distribusjonen i henhold til de angitte reglene og betingelsene. Tidligere samlet de seg, laget et dokument hvor de skrev ned sine identifikasjonsopplysninger, betingelsene, de involverte verdiene, satte dato og signerte. Denne kontrakten ble også bekreftet av en betrodd part, for eksempel en notarius. Deretter gikk disse menneskene hver sin vei med sin papirversjon av kontrakten og begynte å gjennomføre handlinger som kanskje ikke samsvarte med selve kontrakten, det vil si at de gjorde én ting, men på papiret var de forpliktet til å gjøre noe helt annet. Hvordan skulle de håndtere en slik situasjon? Faktisk måtte noen av deltakerne i gruppen ta med seg dette dokumentet, samle bevis og gå til retten for å få samsvar mellom kontrakten og de faktiske handlingene. Det er ofte vanskelig å oppnå rettferdig gjennomføring av denne kontrakten, noe som kan føre til uheldige konsekvenser.
Hva kan man si om smarte kontrakter? De kombinerer muligheten til å skrive kontraktsbetingelser med en mekanisme for streng overholdelse av dem. Hvis betingelsene er angitt og en tilsvarende transaksjon eller forespørsel er signert, er det ikke mulig å endre betingelsene eller påvirke gjennomføringen deres etter at denne forespørselen eller transaksjonen er akseptert.
Det er en validator eller et helt nettverk, samt en database som lagrer alle smarte kontrakter som har blitt utført i streng kronologisk rekkefølge. Det er også viktig at denne databasen inneholder alle betingelsene som utløser utførelsen av den smarte kontrakten. I tillegg må den ta hensyn til verdien som er beskrevet i kontrakten. Hvis dette gjelder en viss digital valuta, betyr det at databasen må ta hensyn til denne.
Med andre ord må validatorene av smarte kontrakter ha tilgang til alle dataene som kontrakten opererer med. For eksempel må en database brukes til å holde oversikt over digitale valutaer, brukerkontoer, transaksjoner og tidsstempler samtidig. Da kan en betingelse i den smarte kontrakten være saldoen til en bruker i en bestemt valuta, tidspunktet for noe eller et faktum av en viss transaksjon, men ikke mer enn det.
Definisjon av smart kontrakt
Begrepet ble generert av forskeren Nick Szabo og ble første gang brukt i 1994, og ble dokumentert i 1997 i en artikkel som beskriver selve ideen om smarte kontrakter.
Smartere kontrakter innebærer at det utføres en viss automatisering av verdiutdeling, som bare kan avhenge av betingelsene som er forhåndsinnstilt. I sin enkleste form ser dette ut som en kontrakt med strengt definerte vilkår, som er signert av bestemte parter.
Smartere kontrakter er ment å minimere tilliten til tredjeparter. Noen ganger utelukkes helt et beslutningssenter som alt avhenger av. I tillegg er det enklere å revidere slike kontrakter. Dette skyldes noen spesielle designfunksjoner i et slikt system, men oftest forstår vi en smart kontrakt som et desentralisert miljø med funksjoner som lar hvem som helst analysere databasen og gjennomføre en full revisjon av kontraktens utførelse. Dermed sikres beskyttelse mot tilbakevirkende endringer av data som vil føre til endringer i selve kontraktens utførelse. Digitalisering av de fleste prosessene ved opprettelse og lansering av en smart kontrakt forenkler ofte teknologien og kostnadene ved implementeringen.
Enkel eksempel — Escrow-tjeneste
La oss se på et veldig enkelt eksempel. Det vil hjelpe oss med å forstå funksjonaliteten til smarte kontrakter, samt bedre navigere i hvilke situasjoner de bør brukes.
Dette kan også implementeres ved bruk av Bitcoin, selv om Bitcoin fortsatt er vanskelig å anse som en fullverdig plattform for smarte kontrakter. Så, vi har en kjøper og en nettbutikk. Kjøperen ønsker å kjøpe en skjerm fra denne butikken. I det enkleste tilfellet fullfører kjøperen betalingen og sender den, og nettbutikken aksepterer denne, bekrefter, for deretter å sende produktet. Imidlertid er det i denne situasjonen en betydelig tillit involvert — kjøperen må stole på nettbutikken for hele kostnaden av skjermen. Siden nettbutikken kan ha et dårlig rykte i kjøperens øyne, er det en risiko for at butikken, av en eller annen grunn, etter å ha mottatt betalingen, nekter å levere og ikke sender produktet til kjøperen. Derfor stiller kjøperen seg spørsmålet (og dermed stiller nettbutikken seg også dette spørsmålet), hva som kan brukes for å minimere slike risikoer og gjøre slike transaksjoner mer pålitelige.
Når det gjelder Bitcoin, kan man gi muligheten for både kjøper og selger å velge en megler uavhengig av hverandre. Det finnes mange personer som jobber med å løse tvister. Og våre deltakere kan velge fra en felles liste med meglere, en de samtidig har tillit til. Sammen oppretter de en multisignaturadresse 2 av 3, hvor det er tre nøkler og to av nøkler må signere for å bruke myntene fra denne adressen. En nøkkel vil tilhøre kjøperen, den andre nettbutikken, og den tredje megleren. Kjøperen sender nå beløpet som er nødvendig for å betale for skjermen til denne multisignaturadressen. Nå, når selgeren ser at pengene er sperret på multisignaturadressen, som han er avhengig av, kan han trygt sende skjermen med posten.
Kjøperen mottar pakken, inspiserer varen og tar en beslutning om det endelige kjøpet. Han kan være helt enig i den tjenesten som tilbys og signere transaksjonen med sin nøkkel, der han overfører mynter fra multisignaturadressen til selgeren, eller han kan være misfornøyd med noe. I det andre tilfellet kontakter han megleren for å lage en alternativ transaksjon, som vil fordele disse myntene på en annen måte.
Anta at skjermen kom noe riper på, og at kabelen for tilkobling til datamaskinen ikke lå ved, selv om det sto på nettsiden til nettbutikken at kabelen skulle være inkludert. Da samler kjøperen bevisene som er nødvendige for å bevise overfor megleren at han ble lurt i denne situasjonen: han tar skjermbilder av nettsiden, tar et bilde av kvitteringen fra posten, tar et bilde av ripene på skjermen og viser at seglet ble brutt og kabelen ble fjernet. Nettbutikken samler sine bevis og sender dem til megleren.
Megleren er interessert i å tilfredsstille både kjøperens misnøye og interessene til nettbutikken (det vil bli klart hvorfor). Han lager en transaksjon der myntene fra multisignaturadressen vil bli brukt i en viss proporsjon mellom kjøperen, nettbutikken og megleren, ettersom han tar en del som belønning for sitt arbeid. Anta at 90% av det totale beløpet går til selgeren, 5% til megleren og 5% i kompensasjon til kjøperen. Denne transaksjonen signerer megleren med sin nøkkel, men den kan ikke anvendes ennå, fordi det kreves to signaturer, og det er kun én. Han sender denne transaksjonen til både kjøperen og selgeren. Hvis noen av dem er fornøyd med denne måten å omfordele myntene på, vil transaksjonen bli signert på nytt og distribuert til nettverket. For å validere den, er det tilstrekkelig at én av deltakerne i avtalen aksepterer alternativet fra megleren.
Det er viktig å velge en megler som begge deltakerne stoler på fra starten av. I så fall vil megleren handle uavhengig av interessene til den ene eller den andre og objektivt vurdere situasjonen. Hvis megleren ikke tilbyr en slik måte å fordele myntene på som tilfredsstiller minst én av deltakerne, kan både kjøperen og nettbutikken bli enige om å overføre myntene til en ny multisignaturadresse, hvor de setter sine to signaturer. Den nye multisignaturadressen vil bli opprettet med en annen megler, som kanskje er mer kvalifisert i saken og vil tilby et bedre alternativ.
Eksempel med kollektiv og kjøleskap
La oss se på et mer komplisert eksempel som tydeligere viser mulighetene med smartkontrakter.
Anta at det er tre gutter som nylig har flyttet inn i et rom i et kollektiv. De er alle tre interessert i å kjøpe et kjøleskap til rommet sitt, som de skal bruke sammen. En av dem har tilbudt seg å samle inn den nødvendige summen til kjøp av kjøleskapet og forhandle med selgeren. Men de har relativt nylig blitt kjent med hverandre, og det er ikke tilstrekkelig tillit mellom dem. Det er åpenbart at to av dem risikerer å gi penger til den tredje. I tillegg må de bli enige om valget av selger.
De kan benytte en escrow-tjeneste, det vil si velge en megler som overvåker gjennomføringen av avtalen og håndterer eventuelle tvister som måtte oppstå. Da blir de enige om å lage en smartkontrakt og skriver inn spesifikke vilkår.
Det første vilkåret er at tre betalinger må motta fra bestemte adresser til et bestemt beløp på den aktuelle smartkontraktkontoen før en viss tid, for eksempel innen en uke. Hvis dette ikke skjer, stopper smartkontrakten å fungere og returnerer myntene til alle deltakerne. Hvis vilkåret derimot oppfylles, settes verdiene for selger- og megleridentifikatorene, og det blir sjekket om alle deltakerne er enige i valget av selger og megler. Når alle vilkårene er oppfylt, vil midlene bli overført til de angitte adressene. Denne tilnærmingen kan beskytte deltakerne mot svindel fra begge sider og eliminerer generelt behovet for tillit.
Vi ser i dette eksemplet prinsippet om at muligheten for trinnvis å angi parametere for oppfyllelse av hvert vilkår gjør det mulig å lage systemer av enhver kompleksitet og dybde av nivåer. I tillegg kan man først definere det første vilkåret i smartkontrakten, og først etter at dette er oppfylt, angi parametere for det neste vilkåret. Med andre ord, vilkåret skrives formelt, mens parametrene for det kan angi mens det er i drift.
Klassifisering av smartkontrakter
For klassifisering kan forskjellige grupper av kriterier angis. Imidlertid er det for øyeblikket fire av dem som er relevante i teknologienes utvikling.
Smartkontrakter kan skilles ut etter kjøremiljøet, som kan være enten sentralisert eller desentralisert. I tilfelle av desentralisering har vi mye større uavhengighet og feiltoleranse ved utførelsen av smartkontrakter.
De kan også skilles ut etter prosessen med å angi og utføre vilkårene: de kan være vilkårlig programmerbare, begrensede eller forhåndsinnstilte, dvs. strengt typet. Når det på plattformen for smartkontrakter bare finnes 4 bestemte smartkontrakter, kan parametrene til dem angis på en vilkårlig måte. Dermed er det mye enklere å angi dem: vi velger kontrakten fra listen og sender parametrene.
Ved initiere metoden finnes det automatiserte smarte kontrakter, det vil si at de selvutføres når bestemte betingelser oppfylles, og det finnes kontrakter som har angitte betingelser, men plattformen sjekker ikke automatisk om de er oppfylt, og i så fall må de initieres separat.
I tillegg varierer smarte kontrakter etter nivå av personvern. De kan være helt åpne, delvis åpne, eller helt konfidensielle. Det siste betyr at tredjepartsobservatører ikke ser betingelsene for smarte kontrakter. Imidlertid er temaet personvern svært omfattende og det er bedre å se nærmere på det separat fra denne artikkelen.
Nedenfor vil vi utdype de tre første kriteriene for å gi mer klarhet til forståelsen av det aktuelle emnet.
Smarte kontrakter etter utførelsesmiljø
Etter utførelsesmiljø skiller vi mellom sentraliserte og desentraliserte plattformer for smarte kontrakter. I tilfelle av sentraliserte digitale kontrakter brukes en enkelt tjeneste, hvor det er én validatør og det kan være en sikkerhetskopiering og gjenopprettingstjeneste som også er sentralisert. Det finnes en database som lagrer all nødvendig informasjon for å angi betingelsene for den smarte kontrakten og fordeling av verdien som vurderes i denne databasen. En slik sentralisert tjeneste har en klient som setter betingelsene med bestemte forespørsel og bruker slike kontrakter. Siden plattformen er sentralisert, kan autentiseringsmekanismene være mindre pålitelige enn i kryptovalutaer.
Et eksempel kan være mobiloperatører (ulike mobiloperatører). Anta at en bestemt operatør fører sentralisert regnskap for trafikken på sine servere, som kan overføres i ulike formater, for eksempel som talemeldinger, SMS-overføringer, mobil internett-trafikk, og etter ulike standarder, samt regnskap for midler på brukernes saldoer. Følgelig kan mobiloperatøren lage kontrakter for regnskap av de ytelser som leveres og deres betaling med ulike betingelser. I så fall kan betingelser som 'send SMS med en bestemt kode til et bestemt nummer og motta slike betingelser for trafikkfordeling' enkelt angis.
En annen eksempel kan være: tradisjonelle banker med utvidet funksjonalitet for nettbank og enkle kontrakter som faste betalinger, automatisk konvertering av innbetalinger, automatisk overføring av prosentandel til en angitt konto osv.
Når det gjelder smarte kontrakter med desentraliserte kjøremiljøer, har vi en gruppe validatorer. I idealtilfellet kan hvem som helst bli validator. Takket være protokollen for databasen og oppnåelse av konsensus har vi en felles database som nå vil lagre alle transaksjoner med nøye definerte kontrakter, og ikke noen vilkårlige forespørselformat som ofte endres, og ingen åpen spesifikasjon eksisterer. Her vil transaksjoner inneholde instruksjoner om hvordan kontrakten skal gjennomføres i henhold til strenge spesifikasjoner. Denne spesifikasjonen er åpen, og derfor kan brukerne av plattformen selv gjennomføre revisjon og validere smarte kontrakter. Her ser vi at desentraliserte plattformer overgår sentraliserte når det gjelder uavhengighet og feilmotstand, men design og vedlikehold av dem er betydelig mer komplisert.
Smarte kontrakter etter hvordan betingelser settes og utføres
La oss nå se nærmere på hvordan smarte kontrakter kan variere i måte å sette og utføre betingelser på. Her vil vi fokusere på smarte kontrakter som programmeres fritt og er Turing-komplette. En Turing-komplett smart kontrakt lar deg spesifisere nesten hvilke algoritmer som helst som betingelser for kontraktsoppfyllelse: skrive løkker, funksjoner for sannsynlighetsberegning og så videre - helt ned til egne algoritmer for elektronisk signatur. Dette innebærer at man virkelig kan skrive logikk på en vilkårlig måte.
Det skilles også mellom vilkårlige smarte kontrakter som ikke er Turing-komplette. Her kan man inkludere Bitcoin og Litecoin med sitt skript. Det betyr at man kun kan bruke bestemte operasjoner i vilkårlig rekkefølge, men man kan ikke skrive løkker eller egne algoritmer.
I tillegg finnes det plattformer for smarte kontrakter som implementerer forhåndsinstallerte smarte kontrakter. Dette inkluderer Bitshares og Steemit. Bitshares har et bredt spekter av smarte kontrakter for handel, kontoadministrasjon, styring av plattformen og dens parametre. Steemit er en lignende plattform, men den er ikke rettet mot utgivelse av tokens og handel som Bitshares, men mot blogging, det vil si at den lagrer og behandler innhold på en desentralisert måte.
Plattformer som følger Turing-fullstendige kontrakter inkluderer Ethereum og RootStock, som fortsatt er under utvikling. Derfor vil vi se nærmere på Ethereum-plattformen for smarte kontrakter.
Smarte kontrakter etter innstillingsmetode
Smarte kontrakter kan også deles inn i minst to grupper basert på hvordan de initieres: automatiserte og manuelle (ikke-automatiserte). Automatiserte kontrakter kjennetegnes ved at de, ved kjente parametre og oppfylte betingelser, fullføres helt automatisk. Det vil si at de ikke krever sending av ekstra transaksjoner og betaling av tilleggskommisjoner ved hvert etterfølgende utførelse. Plattformen har all nødvendig data for å vurdere hvordan den smarte kontrakten vil avsluttes. Logikken er ikke tilfeldig, men forhåndsbestemt, og alt er forutsigbart. Man kan altså tidlig vurdere kompleksiteten ved utførelsen av den smarte kontrakten, bruke en konstant kommisjon for den, og alle prosessene skjer på en mer effektiv måte.
For smarte kontrakter som programmeres fritt, er utførelsen ikke automatisert. For å initiere en slik smart kontrakt må man faktisk opprette en ny transaksjon på hvert trinn, som vil kalle det neste steget i utførelsen eller den neste metoden i den smarte kontrakten, betale den relevante kommisjonen og vente på bekreftelse av transaksjonen. Utførelsen kan avsluttes med suksess eller ikke, fordi koden for den smarte kontrakten er tilfeldig, og man kan møte uventede situasjoner, som evig sløyfe, mangel på noen parametre og argumenter, ubehandlede unntak osv.
Kontoer i Ethereum
Typer av Ethereum-kontoer
La oss se på hvilke typer kontoer som kan finnes på Ethereum-plattformen. Det finnes bare to typer kontoer, og ingen flere alternativer. Den første typen kalles brukerkonto, den andre - kontraktskonto. La oss gå gjennom hva som skiller dem.
Brukerkontoen styres utelukkende av den private signeringsnøkkelen. Kontoens eier genererer sitt eget nøkkelpar for digital signatur ved hjelp av ECDSA-algoritmen (Elliptic Curve Digital Signature Algorithm). Bare transaksjoner som er signert med denne nøkkelen, kan endre tilstanden til kontoen.
Kontraktskontoen har en egen logikk. Den kan kun styres ved hjelp av forhåndsdefinert programkode, som helt bestemmer oppførselen til smarte kontrakter: hvordan de vil disponere over sine mynter under visse omstendigheter, på initiativ fra hvilken bruker og med hvilke tilleggsbetingelser myntene vil bli distribuert. Hvis enkelte aspekter ikke er inkludert av utviklerne i programkoden, kan det oppstå problemer. For eksempel kan den smarte kontrakten nå en viss tilstand der den ikke aksepterer initiativ til videre utførelse fra noen av brukerne. I så fall vil myntene faktisk være frosset, fordi den smarte kontrakten ikke forutser en utvei fra denne tilstanden.
Hvordan kontoer opprettes i Ethereum
Når det gjelder brukerkontoen, genererer eieren selv et nøkkelpar ved hjelp av ECDSA. Det er viktig å merke seg at Ethereum bruker nøyaktig den samme algoritmen for digital signatur og den samme elliptiske kurven som Bitcoin, men adressen beregnes på en litt annen måte. Her brukes ikke resultatet fra dobbelt hashing, slik som i Bitcoin, men en enkelt hashing ved hjelp av Keccak-funksjonen med en lengde på 256 biter. Fra den resulterende verdien kuttes de laveste bitene, nemlig 160 laveste biter av utdata fra hash-funksjonen. Til slutt får vi en adresse i Ethereum. Denne tar faktisk opp 20 byte.
Vi må merke oss at kontoen i Ethereum er kodat i hex uten bruk av sjekksum, i motsetning til Bitcoin og mange andre systemer, der adressen kodes i et tallsystem med base 58 med tillegg av sjekksum. Dette betyr at man må være forsiktig når man arbeider med kontoidentifikatorer i Ethereum: selv en liten feil i identifikatoren vil garantert føre til tap av mynter.
Det er en viktig egenskap, og den går ut på at brukerkontoen på nivå med den felles databasen opprettes i det øyeblikket han/hun mottar sin første innbetaling.
Når det gjelder opprettelse av en smartkontrakt, benyttes en helt annen tilnærming. Først skriver en av brukerne kildekoden for smartkontrakten, deretter blir koden kjørt gjennom en spesialkompilator for Ethereum-plattformen for å få byte-koden for den spesifikke Ethereum virtuelle maskinen. Den resulterende byte-koden plasseres i et spesialfelt i transaksjonen. Den bekreftes på vegne av initiatorens konto. Deretter distribueres denne transaksjonen i nettverket og plasserer koden for smartkontrakten. Transaksjonsgebyret, og dermed gebyret for utførelsen av kontrakten, trekkes fra initiatorens konto.
Hver smartkontrakt inneholder nødvendigvis sin egen konstruktør. Den kan være tom eller ha innhold. Når konstruktøren kjøres, blir det opprettet en identifikator for smartkontrakten, som kan brukes til å sende mynter, kalle bestemte metoder i smartkontrakten og annet.
Strukturen til en Ethereum-transaksjon
For å gjøre det klarere, skal vi se på strukturen til en Ethereum-transaksjon og et eksempel på kildekoden for en smartkontrakt.
En Ethereum-transaksjon består av flere felt. Det første er nonce — dette er et sekvensnummer for transaksjonen i forhold til kontoens egne transaksjoner, som sprer og er forfatteren av den. Dette er nødvendig for å skille mellom doble transaksjoner, det vil si for å unngå at den samme transaksjonen behandles to ganger. Takket være identifikatoren har hver transaksjon en unik hash-verdi.
Deretter følger et felt som gas priceHer angis prisen som den grunnleggende valutaen Ethereum konverteres til gas, som brukes til å betale for utførelsen av smartkontrakten og tildeling av ressurser til den virtuelle maskinen. Hva betyr dette?
I Bitcoin betales avgiftene direkte med den grunnleggende valutaen – selve Bitcoin. Dette er mulig på grunn av den enkle mekanismen for beregning: vi betaler strengt for volumet av data som er inneholdt i transaksjonen. I Ethereum er situasjonen mer kompleks, fordi det er vanskelig å basere seg kun på data volumet av transaksjonen. Her kan transaksjonen også inneholde programkode som vil kjøre på den virtuelle maskinen, og hver operasjon på den virtuelle maskinen kan ha ulik kompleksitet. Det finnes også operasjoner som allokerer minne for variabler. De vil ha sin egen kompleksitet, som vil påvirke betalingen for hver operasjon.
Kostnaden for hver operasjon i gass ekvivalent vil være konstant. Den er spesifikt innført for å bestemme den konstante kostnaden for hver operasjon. Avhengig av belastningen på nettverket vil gassprisen endres, altså koeffisienten som grunnvalutaen vil konverteres til denne hjelpeenheten for å betale avgiften.
Det er en annen egenskap ved transaksjonen i Ethereum: bytekoden den inneholder for å utføre i den virtuelle maskinen vil bli utført til den er fullført med et eller annet resultat (suksess-feil) eller til det er brukt opp et visst antall mynter tildelt til å betale avgiften. For å unngå situasjonen der senderens konto vil bruke opp alle myntene til avgiften ved en feil (for eksempel at en evig løkke ble startet i den virtuelle maskinen), finnes det følgende felt – start gas (det bli ofte kalt gas limit) – det definerer det maksimale volumet av mynter som sendere er villige til å bruke på å utføre en bestemt transaksjon.
Det neste feltet kalles destination address. Her oppgis adressen til mottakeren av myntene eller adressen til en spesifikk smartkontrakt, hvis metoder vil bli kalt. Etter dette følger feltet value, der summen av myntene som sendes til destination address skrives.
Deretter følger et interessant felt kalt data, der en hel struktur er plassert i. Dette er ikke et eget felt, men en hel struktur der koden for den virtuelle maskinen defineres. Her kan man plassere vilkårlige data - for dette finnes det egne regler.
Det siste feltet kalles signatur. Det inneholder både den elektroniske signaturen til forfatteren av denne transaksjonen og den offentlige nøkkelen som skal brukes til å verifisere denne signaturen. Fra den offentlige nøkkelen kan man få identifikatoren til kontoen som sender denne transaksjonen, altså identifisere kontoen unikt i selve systemet. I strukturen til transaksjonen har vi avdekket det viktigste.
Eksempel på smartkontrakt skrevet i Solidity
La oss nå se nærmere på den enkleste smartkontrakten med 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);
}
}Over er en forenklet kildekode som kan holde brukermyntene og returnere dem på forespørsel.
Så, her er smartkontrakten Bank, som utfører følgende funksjoner: den akkumulere mynter på sin balanse, det vil si at når transaksjonen bekreftes og en slik smartkontrakt settes opp, opprettes en ny konto som kan inneholde mynter på balansen sin; den husker brukerne og fordelingen av mynter mellom dem; har flere metoder for å administrere saldoer, det vil si muligheten til å sette inn, ta ut og sjekke brukerens saldo.
La oss gå gjennom hver linje i kildekoden. Denne kontrakten har konstante felt. Ett av dem, av typen adresse, kalles owner. Her husker kontrakten adressen til brukeren som opprettet denne smartkontrakten. Videre finnes det en dynamisk struktur som lagrer samsvar mellom brukernes adresser og saldoene.
Kanskje man skriver metoden Bank - det heter det samme som kontrakten. Dette er dermed konstruktøren. Her tilordnes variabelen owner adressen til den som har plassert denne smartkontrakten i nettverket. Det er det eneste som skjer i denne konstruktøren. Det vil si at msg i dette tilfellet er de dataene som ble sendt til den virtuelle maskinen sammen med transaksjonen som inneholder hele koden til denne kontrakten. Dermed er msg.sender forfatteren av denne transaksjonen som plasserer denne koden. Han vil være eieren av smartkontrakten.
Deposit-metoden lar deg overføre et bestemt beløp av mynter til kontraktskontoen gjennom en transaksjon. I dette tilfellet, når smartkontrakten mottar disse myntene, beholder den dem i sin balanse, men registrerer i strukturen balances hvem som var avsender av disse myntene for å vite hvem de tilhører.
Den neste metoden kalles withdraw, og den tar ett parameter — beløpet av mynter som noen ønsker å ta ut fra denne banken. Her skjer det en sjekk for å bekrefte om det er tilstrekkelig med mynter på saldoen til brukeren som kaller denne metoden, for å kunne sende dem. Hvis det er nok, returnerer smartkontrakten det ønskede beløpet til den som kaller.
Neste steg er metoden for å sjekke gjeldende saldo for brukeren. Den som kaller denne metoden, blir benyttet for å hente denne balansen i smartkontrakten. Det er verdt å merke seg at modifikatoren for denne metoden er view. Dette betyr at metoden ikke endrer noen variable i klassen sin, og den fungerer faktisk bare som en lesemetode. Ingen separat transaksjon opprettes for å kalle denne metoden, gebyr betales ikke, og alle beregninger utføres lokalt, hvoretter brukeren får resultatet.
Kill-metoden er nødvendig for å ødelegge tilstanden til smartkontrakten. Her er det også en tilleggskontroll for å se om den som kaller metoden er eieren av kontrakten. Hvis de er det, blir kontrakten selvdestruert, og destruksjonsfunksjonen tar ett parameter — kontoidet som kontrakten vil sende alle gjenværende mynter på sin balanse til. I dette tilfellet vil de gjenværende myntene automatisk bli sendt til adressen til kontraktseieren.
Hvordan fungerer en fullverdig Ethereum-node?
La oss se skjematisk på hvordan slike smartkontrakter utføres på Ethereum-plattformen og hvordan en fullverdig node i nettverket fungerer.
En fullverdig Ethereum-node må minst ha fire moduler.
Den første, som for ethvert desentralisert protokoll, er P2P networking module — nettverksmodulen for tilkobling og samarbeid med andre noder, der det skjer utveksling av blokker, transaksjoner og informasjon om andre noder. Dette er en tradisjonell komponent for alle desentraliserte kryptovalutaer.
Vidare har vi en modul för datalagring av blockkedjan, behandling, val av prioriterad gren, blocktilläggning, blockavkoppling, validering av dessa block osv.
Den tredje modulen kallas EVM (Ethereum virtuell maskin) — det är denna en virtuell maskin, som tar emot bytekod från Ethereum-transaktionen. Denna modul tar emot det aktuella tillståndet av ett specifikt konto och utför förändringar i dess tillstånd baserat på den mottagna bytekoden. Versionen av den virtuella maskinen på varje nod i nätverket måste vara densamma. Beräkningarna som sker på varje Ethereum-nod är helt lika, men de sker i asynkront ordning: någon kontrollerar och lägger till denna transaktion tidigare, vilket innebär att hela koden i den exekveras, medan någon gör det senare. Därför, när en transaktion skapas, sprids den i nätverket, noderna accepterar den, och vid verifieringen exekveras den på exakt samma sätt som Bitcoin Script i Bitcoin, här exekveras bytekoden från den virtuella maskinen.
En transaktion anses vara verifierad om all kod som den innehåller har exekverats, ett nytt tillstånd för ett specifikt konto har genererats och sparats tills det är tydligt om denna transaktion har tillämpats eller inte. Om transaktionen har tillämpats, anses då detta tillstånd inte bara vara exekverat utan också aktuellt. Det finns en databas som lagrar tillståndet för varje konto för varje nod i nätverket. Eftersom alla beräkningar görs likadant 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 begränsningar som finns för plattformar med smarta kontrakt som liknar Ethereum kan följande nämnas:
- kodexekvering;
- allokera minne;
- blockkedjedata;
- skicka betalningar;
- skapa nytt kontrakt;
- anropa andra kontrakt.
La oss se nærmere på de begrensningene som pålegges en virtuell maskin, og la oss avlive noen myter om smarte kontrakter. På en virtuell maskin, som kan være ikke bare i Ethereum, men også på lignende plattformer, kan man utføre virkelig vilkårlige logiske operasjoner, det vil si skrive kode som vil bli kjørt der. Man kan også tildele ekstra minne. Imidlertid betales gebyret separat for hver operasjon og for hver ekstra tildelt enhet av minne.
Videre kan den virtuelle maskinen lese data fra blokkjede-databasen for å bruke disse dataene som en utløser for å utføre ulike logiske operasjoner i smarte kontrakter. Den virtuelle maskinen kan opprette og sende transaksjoner, den kan opprette nye kontrakter og appeler metoder fra andre smarte kontrakter som allerede er publisert på nett: de eksisterer, er tilgjengelige osv.
Den mest utbredte myten er at smarte kontrakter i Ethereum kan bruke informasjon fra alle internettressurser i sine betingelser. Sannheten er at den virtuelle maskinen ikke kan sende et nettverksforespørsel til en ekstern informasjonsressurs på internett, det vil si at det er umulig å skrive en slik smart kontrakt som vil fordele verdi mellom brukere basert på for eksempel hvordan været er ute, hvem som vant en konkurranse, eller på grunnlag av hvilke andre hendelser som har skjedd i den ytre verden, fordi informasjonen om disse hendelsene rett og slett ikke finnes i plattformens egen database. Det finnes altså ingen slik informasjon i blokkjeden. Hvis den ikke er der, kan ikke den virtuelle maskinen bruke disse dataene som utløser.
Ulemper med Ethereum
La oss liste opp de viktigste. Den første ulempen er at det er noen utfordringer knyttet til design, utvikling og testing av smarte kontrakter i Ethereum (i Ethereum brukes programmeringsspråket Solidity for å skrive smarte kontrakter). Faktisk viser praksis at en veldig stor prosentandel av alle feil kan tilskrives menneskelig faktor. Dette gjelder faktisk også for allerede skrevne smarte kontrakter i Ethereum, som har middels eller høy kompleksitet. Hvis sannsynligheten for feil er lav for enkle smarte kontrakter, er det svært ofte feil i komplekse smarte kontrakter som fører til tyveri av midler, frysing av midler, ødeleggelse av smarte kontrakter på uventede måter osv. Det er allerede mange kjente slike tilfeller.
Den andre ulempen er at den virtuelle maskinen i seg selv ikke er perfekt, siden den også er skrevet av mennesker. Den kan utføre vilkårlige kommandoer, og her ligger sårbarheten: man kan konfigurere en rekke kommandoer på en viss måte, som vil føre til uventede konsekvenser. Dette er et svært komplisert felt, men det er allerede gjort flere studier som viser at disse sårbarhetene finnes i den nåværende versjonen av Ethereum-nettverket, og de kan føre til at mange smarte kontrakter slutter å fungere.
En annen stor utfordring, som også kan betraktes som en ulempe. Den ligger i at man på en praktisk eller teknisk måte kan komme til at hvis man kompilerer bytekoden til kontrakten som skal kjøres på den virtuelle maskinen, kan man bestemme en spesifikk rekkefølge av operasjoner. Når disse operasjonene utføres samlet, vil de legge en betydelig belastning på den virtuelle maskinen og bremse den uforholdsmessig i forhold til gebyret som ble betalt for å utføre disse operasjonene.
Tidligere har det vært en periode med utvikling av Ethereum, hvor mange som hadde inngående kjennskap til funksjonene til den virtuelle maskinen, oppdaget slike sårbarheter. Faktisk betalte transaksjonene veldig lave avgifter, men de bremset nesten hele nettverket betydelig. Disse problemene er svært vanskelige å løse, fordi først må de bestemmes, for det andre justeres prisen for å utføre disse operasjonene, og for det tredje må det gjennomføres en hardfork, noe som betyr at alle noder i nettverket må oppdateres til en ny versjon av programvaren, etterfulgt av samtidig aktivering av disse endringene.
Når det gjelder Ethereum, har det vært gjennomført en rekke studier, og det er oppnådd mye praktisk erfaring: både positive og negative, men til tross for dette gjenstår det utfordringer og sårbarheter som vi fortsatt må finne måter å håndtere.
Så, den tematiske delen av artikkelen er avsluttet, la oss gå videre til spørsmålene som dukker opp ganske ofte.
Vanlege spørsmål
— Hvis alle parter i den gjeldende smarte kontrakten ønsker å endre betingelsene, kan de da avbryte denne smarte kontrakten med flermedlemssignatur, og deretter opprette en ny smart kontrakt med oppdaterte utførelsesbetingelser?
Her vil svaret være todelt. Hvorfor? Fordi på den ene siden er den smarte kontrakten opprettet en gang for alle og forutsetter ingen endringer, mens på den andre siden kan den ha forhåndsdefinert logikk som tillater fullstendige eller delvise endringer av betingelsene. Det vil si at hvis du ønsker å endre noe i din smarte kontrakt, må du på forhånd spesifisere betingelsene under hvilke du kan oppdatere disse betingelsene. Dermed er det kun på en så forsiktig måte at du kan organisere oppdateringen av kontrakten. Men også her kan det oppstå problemer: å gjøre en feil og dermed få en tilsvarende sårbarhet. Derfor må slike ting prosjekteres og testes svært nøye og grundig.
— Hva skjer hvis megleren inngår en pakt med en av deltakerpartene: escrow eller smart kontrakt? Er megler nødvendig i en smart kontrakt?
En mediator er ikke nødvendig i en smart kontrakt. Den kan mangle. Hvis en mediator i en escrow-situasjon inngår en sammensvergelse med en av partene, så mister ordningen hele sin verdi. Derfor velges mediatorer slik at de blir betrodd av alle parter som er involvert i prosessen. Dermed vil du bare unngå å overføre mynter til mult-signaturadressen med den mediator du ikke stoler på.
— Er det mulig å overføre flere forskjellige tokens fra sin adresse til forskjellige mål-adresser i én Ethereum-transaksjon, for eksempel til børsadresser hvor disse tokens handles?
Det er et godt spørsmål, og det berører Ethereums transaksjonsmodell og dens forskjell fra Bitcoins modell. Og forskjellen er radikal. I Ethereum-modellen overfører du bare mynter fra én adresse til en annen, uten veksel, bare et spesifikt beløp som du angir. Med andre ord, dette er ikke en UTXO-modell, men en modell med kontoer og tilsvarende balanse. Teoretisk kan du i én transaksjon sende flere forskjellige tokens hvis du skriver en smart kontrakt, men du må fortsatt utføre mange transaksjoner, opprette kontrakten, deretter overføre tokens og mynter til den, og deretter kalle den aktuelle metoden. Dette krever innsats og tid, derfor fungerer det ikke på den måten i praksis, og alle betalinger i Ethereum skjer gjennom separate transaksjoner.
— En av mytene om Ethereum-plattformen er at det ikke er mulig å beskrive betingelser som avhenger av data fra eksterne internettressurser, hva skal man gjøre da?
Løsningen er at smart kontrakten kan inkludere én eller flere såkalte pålitelige orakler, som samler inn data om tilstanden i verden utenfor og overfører dem til smart kontrakter via spesielle metoder. Kontrakten anser de dataene som sannhet, som den mottar fra pålitelige parter. For større pålitelighet velges en større gruppe orakler for å minimere risikoen for sammensvergelse. Kontrakten kan ignorere data fra orakler som strider mot flertallet.
Dette emnet er dedikert til en av forelesningene i det online kurset om Blockchain — “”.
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Lithuanian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish