I denne artikkelen skal vi se på hva smarte kontrakter er, hva de er, vi vil bli kjent med ulike smarte kontraktsplattformer, deres funksjoner, og også diskutere hvordan de fungerer og hvilke fordeler de kan gi. Dette materialet vil være svært nyttig for lesere som ikke er godt kjent med temaet smarte kontrakter, men som ønsker å komme nærmere forståelsen av det.
Vanlig kontrakt vs. smart kontrakt
Før vi fordyper oss i detaljene, la oss ta et eksempel på forskjellene mellom en vanlig kontrakt, som er spesifisert på papir, og en smart kontrakt, som er representert digitalt.
Hvordan fungerte dette før smarte kontrakter kom? Se for deg en gruppe mennesker som ønsker å etablere visse regler og betingelser for distribusjon av verdier, samt en viss mekanisme for å garantere implementeringen av denne fordelingen i henhold til de gitte reglene og betingelsene. Deretter kom de sammen, utarbeidet et papir der de skrev ned identifikasjonsopplysningene sine, vilkårene, verdiene som var involvert, daterte dem og signerte dem. Denne kontrakten ble også sertifisert av en betrodd part, for eksempel en notarius. Videre gikk disse menneskene i forskjellige retninger med sin papirkopi av en slik kontrakt og begynte å utføre noen handlinger som kanskje ikke samsvarte med selve kontrakten, det vil si at de gjorde en ting, men på papiret ble det bekreftet at de skulle gjøre noe helt annerledes. Og hvordan komme seg ut av denne situasjonen? Faktisk må et av gruppemedlemmene ta dette papiret, ta noen bevis, ta det til retten og oppnå samsvar mellom kontrakten og faktiske handlinger. Ganske ofte er det vanskelig å oppnå rettferdig gjennomføring av denne kontrakten, noe som fører til ubehagelige konsekvenser.
Hva kan sies om smarte kontrakter? De kombinerer både muligheten for å skrive vilkårene i kontrakten og mekanismen for deres strenge gjennomføring. Hvis betingelsene er satt og den tilsvarende transaksjonen eller forespørselen er signert, er det ikke lenger mulig å endre vilkårene eller påvirke implementeringen når forespørselen eller transaksjonen er akseptert.
Det er én validator eller et helt nettverk, samt en database som lagrer alle smarte kontrakter som ble sendt inn for utførelse i streng kronologisk rekkefølge. Det er også viktig at denne databasen må inneholde alle utløserbetingelsene for å utføre den smarte kontrakten. I tillegg må den ta hensyn til selve verdien hvis fordeling er beskrevet i kontrakten. Hvis dette gjelder en digital valuta, bør denne databasen ta hensyn til det.
Med andre ord, smarte kontraktsvalidatorer må ha tilgang til alle dataene som smartkontrakten opererer på. For eksempel bør en enkelt database brukes til samtidig å gjøre rede for digitale valutaer, brukersaldo, brukertransaksjoner og tidsstempler. Deretter, i en smart kontrakt, kan betingelsen være brukerens saldo i en bestemt valuta, ankomsten av et bestemt tidspunkt eller det faktum at en bestemt transaksjon er utført, men ikke noe mer.
Definisjon av en smart kontrakt
Generelt ble selve terminologien laget av forskeren Nick Szabo og først brukt i 1994, og ble dokumentert i 1997 i en artikkel som beskriver selve ideen om smarte kontrakter.
Smarte kontrakter innebærer at det utføres en viss automatisering av verdifordeling, som kun kan avhenge av de forholdene som er forhåndsbestemt. I sin enkleste form ser det ut som en kontrakt med strengt definerte vilkår, som er signert av visse parter.
Smarte kontrakter er utformet for å minimere tilliten til tredjeparter. Noen ganger er beslutningssenteret som alt avhenger av, helt utelukket. I tillegg er slike kontrakter lettere å revidere. Dette er en konsekvens av noen designfunksjoner til et slikt system, men oftest forstår vi ved en smart kontrakt et desentralisert miljø og tilstedeværelsen av funksjoner som lar hvem som helst analysere databasen og gjennomføre en fullstendig revisjon av utførelsen av kontrakter. Dette sikrer beskyttelse mot tilbakevirkende dataendringer som vil medføre endringer i utførelsen av selve kontrakten. Digitalisering av de fleste prosesser ved opprettelse og lansering av en smart kontrakt forenkler ofte teknologien og kostnadene ved implementeringen av dem.
Et enkelt eksempel - Escrow-tjeneste
La oss se på et veldig enkelt eksempel. Det vil hjelpe deg å komme nærmere forståelsen av funksjonaliteten til smarte kontrakter, samt bedre forstå i hvilke tilfeller de bør brukes.
Det kan også implementeres ved hjelp av Bitcoin, selv om Bitcoin akkurat nå neppe kan kalles en fullverdig plattform for smarte kontrakter. Så vi har en kjøper og vi har en nettbutikk. En kunde ønsker å kjøpe en skjerm fra denne butikken. I det enkleste tilfellet fullfører og sender kjøperen en betaling, og nettbutikken aksepterer den, bekrefter den og sender deretter varene. Men i denne situasjonen er det behov for stor tillit - kjøperen må stole på nettbutikken for hele kostnaden for skjermen. Siden en nettbutikk kan ha et lavt rykte i kjøperens øyne, er det en risiko for at butikken av en eller annen grunn, etter å ha akseptert betalingen, vil nekte service og ikke sende varene til kjøperen. Derfor stiller kjøperen spørsmålet (og følgelig stiller nettbutikken dette spørsmålet) hva som kan brukes i dette tilfellet for å minimere slike risikoer og gjøre slike transaksjoner mer pålitelige.
Når det gjelder Bitcoin, er det mulig å la kjøper og selger uavhengig velge en formidler. Det er mange mennesker som er involvert i å løse kontroversielle spørsmål. Og våre deltakere kan velge fra en generell liste over meglere den de vil stole på. Sammen lager de en 2 av 3 multisignaturadresse der det er tre nøkler og to signaturer med to nøkler som kreves for å bruke mynter fra den adressen. En nøkkel vil tilhøre kjøperen, den andre til nettbutikken, og den tredje til formidleren. Og til en slik multisignaturadresse vil kjøperen sende beløpet som er nødvendig for å betale for skjermen. Nå, når selgeren ser at penger er blokkert en stund på en multisignatur-adresse som avhenger av ham, kan han trygt sende skjermen med posten.
Deretter mottar kjøperen pakken, inspiserer varene og tar en beslutning om det endelige kjøpet. Han kan være helt enig i tjenesten som tilbys og signere transaksjonen med nøkkelen sin, hvor han overfører mynter fra multisignaturadressen til selgeren, eller han kan være misfornøyd med noe. I det andre tilfellet kontakter han en megler for å sette sammen en alternativ transaksjon som vil fordele disse myntene annerledes.
La oss si at skjermen kom litt oppskrapt og at settet ikke inkluderte en kabel for tilkobling til datamaskinen, selv om nettbutikkens nettsted sa at kabelen skulle være inkludert i settet. Deretter samler kjøperen inn bevisene som er nødvendige for å bevise overfor megleren at han ble lurt i denne situasjonen: han tar skjermbilder av nettstedet, tar et bilde av postkvitteringen, tar et bilde av ripene på skjermen og viser at forseglingen var ødelagt og kabelen ble trukket ut. Nettbutikken samler på sin side bevisene sine og overfører dem til mekleren.
Mekleren er interessert i å tilfredsstille både kjøperens indignasjon og nettbutikkens interesser (det vil bli klart hvorfor senere). Det utgjør en transaksjon der mynter fra en multisignaturadresse vil bli brukt i et visst forhold mellom kjøperen, nettbutikken og formidleren, siden han tar en del for seg selv som belønning for sitt arbeid. La oss si at 90 % av totalbeløpet går til selger, 5 % til megler og 5 % kompensasjon til kjøper. Mekleren signerer denne transaksjonen med nøkkelen sin, men den kan ikke brukes ennå, fordi den krever to signaturer, men bare én er verdt det. Den sender en slik transaksjon til både kjøper og selger. Hvis minst en av dem er fornøyd med dette alternativet for omfordeling av mynter, vil transaksjonen bli forhåndssignert og distribuert til nettverket. For å validere det, er det nok at en av partene i transaksjonen godtar meglerens valg.
Det er viktig i utgangspunktet å velge megler slik at begge deltakerne stoler på ham. I dette tilfellet vil han handle uavhengig av interessene til den ene eller den andre og objektivt vurdere situasjonen. Hvis formidleren ikke gir mulighet for å distribuere mynter som tilfredsstiller minst én deltaker, kan både kjøperen og nettbutikken, etter å ha avtalt sammen, sende myntene til en ny multisignaturadresse ved å sette sine to signaturer. Den nye multisignaturadressen vil bli satt sammen med en annen mekler, som kan være mer kompetent i saken og gi et bedre alternativ.
Eksempel med en hybel og et kjøleskap
La oss se på et mer komplekst eksempel som viser mulighetene til en smart kontrakt mer eksplisitt.
La oss si at det er tre gutter som nylig har flyttet inn i samme hybel. De tre er interessert i å kjøpe et kjøleskap til rommet sitt som de kan bruke sammen. En av dem meldte seg frivillig til å samle inn det nødvendige beløpet for å kjøpe et kjøleskap og forhandle med selgeren. Imidlertid har de bare nylig møtt hverandre, og det er ikke nok tillit mellom dem. Åpenbart tar to av dem en risiko ved å gi penger til den tredje. I tillegg må de komme til enighet om valg av selger.
De kan bruke escrow-tjenesten, det vil si velge en mekler som vil overvåke utførelsen av transaksjonen og løse kontroversielle problemer hvis noen oppstår. Deretter, etter å ha blitt enige, utarbeider de en smart kontrakt og foreskriver visse betingelser i den.
Den første betingelsen er at før et bestemt tidspunkt, for eksempel innen en uke, må den tilsvarende smarte kontraktskontoen motta tre betalinger fra bestemte adresser for et bestemt beløp. Hvis dette ikke skjer, slutter den smarte kontrakten å utføre og returnerer myntene til alle deltakerne. Hvis betingelsen er oppfylt, settes verdiene til selger- og formidleridentifikatorer, og det kontrolleres at alle deltakere er enige i valget av selger og formidler. Når alle vilkår er oppfylt, vil midlene bli overført til de angitte adressene. Denne tilnærmingen kan beskytte deltakere mot svindel fra alle sider og eliminerer generelt behovet for å stole på.
Vi ser i dette eksemplet selve prinsippet om at denne evnen til å sette parametere trinn for trinn for å oppfylle hver betingelse lar deg lage systemer av hvilken som helst kompleksitet og dybde av nestede nivåer. I tillegg kan du først definere den første betingelsen i den smarte kontrakten, og først etter oppfyllelsen kan du angi parametere for den neste betingelsen. Med andre ord er betingelsen formelt skrevet, og parametere for den kan settes allerede under driften.
Klassifisering av smarte kontrakter
For klassifisering kan du angi ulike grupper av kriterier. Men i øyeblikket av teknologiutvikling er fire av dem aktuelle.
Smarte kontrakter kan kjennetegnes ved deres utførelsesmiljø, som enten kan være sentralisert eller desentralisert. Ved desentralisering har vi mye større uavhengighet og feiltoleranse når vi utfører smarte kontrakter.
De kan også skilles ut ved prosessen med å sette og oppfylle vilkår: de kan være fritt programmerbare, begrensede eller forhåndsdefinerte, dvs. strengt skrevet. Når det bare er 4 spesifikke smarte kontrakter på smartkontraktplattformen, kan parametrene for dem settes på hvilken som helst måte. Følgelig er det mye enklere å sette dem: vi velger en kontrakt fra listen og sender parametrene.
I henhold til initieringsmetoden er det automatiserte smarte kontrakter, det vil si at når visse forhold oppstår, er de selvutførende, og det er kontrakter der betingelsene er spesifisert, men plattformen sjekker ikke automatisk oppfyllelsen av dem; for dette må igangsettes separat.
I tillegg varierer smarte kontrakter i personvernnivå. De kan enten være helt åpne, delvis eller helt konfidensielle. Det siste betyr at tredjepartsobservatører ikke ser vilkårene for smarte kontrakter. Emnet personvern er imidlertid veldig bredt, og det er bedre å vurdere det separat fra den nåværende artikkelen.
Nedenfor skal vi se nærmere på de tre første kriteriene for å bringe mer klarhet i forståelsen av det aktuelle temaet.
Smarte kontrakter etter kjøretid
Med utgangspunkt i utførelsesmiljøet skilles det mellom sentraliserte og desentraliserte smarte kontraktsplattformer. Ved sentraliserte digitale kontrakter benyttes en enkelt tjeneste, hvor det kun er én validator og det kan være en backup- og gjenopprettingstjeneste, som også styres sentralt. Det er én database som lagrer all nødvendig informasjon for å sette vilkårene for den smarte kontrakten og distribuere verdien som er tatt i betraktning i nettopp denne tjenestedatabasen. En slik sentralisert tjeneste har en klient som setter betingelser med visse forespørsler og bruker slike kontrakter. På grunn av plattformens sentraliserte natur kan autentiseringsmekanismer være mindre sikre enn i kryptovalutaer.
Som et eksempel kan vi ta mobilkommunikasjonsleverandører (ulike mobiloperatører). La oss si at en viss operatør fører en sentralisert oversikt over trafikken på serverne sine, som kan overføres i forskjellige formater, for eksempel: i form av taleanrop, SMS-overføring, mobil Internett-trafikk og i henhold til forskjellige standarder, og fører også poster av midler på brukersaldo. Tilbyderen av mobilkommunikasjon kan følgelig inngå kontrakter for regnskapsføring av tjenestene som tilbys og deres betaling med ulike betingelser. I dette tilfellet er det enkelt å sette betingelser som "send en SMS med en slik og en kode til et slikt og et nummer, og du vil motta slike og slike betingelser for trafikkdistribusjon."
Et annet eksempel kan nevnes: tradisjonelle banker med utvidet funksjonalitet for nettbank og svært enkle kontrakter som vanlige betalinger, automatisk konvertering av inngående betalinger, automatisk trekk av renter til en spesifisert konto, etc.
Hvis vi snakker om smarte kontrakter med et desentralisert utførelsesmiljø, så har vi en gruppe validatorer. Ideelt sett kan hvem som helst bli validator. På grunn av databasesynkroniseringsprotokollen og oppnå konsensus, har vi en felles database som nå vil lagre alle transaksjoner med strengt beskrevne kontrakter, og ikke noen betingede spørringer, hvis formater ofte endres, og det er ingen åpen spesifikasjon. Her vil transaksjoner inneholde instrukser om å utføre kontrakten i henhold til en streng spesifikasjon. Denne spesifikasjonen er åpen, og derfor kan plattformbrukere selv revidere og validere smarte kontrakter. Her ser vi at desentraliserte plattformer er overlegne sentraliserte når det gjelder uavhengighet og feiltoleranse, men deres design og vedlikehold er mye mer komplekst.
Smarte kontrakter ved å sette og oppfylle betingelser
La oss nå se nærmere på hvordan smarte kontrakter kan variere i måten de setter og oppfyller vilkårene. Her retter vi oppmerksomheten mot smarte kontrakter som er tilfeldig programmerbare og Turing komplette. En Turing-komplett smart kontrakt lar deg sette nesten alle algoritmer som betingelser for utførelse av kontrakten: skrivesykluser, noen funksjoner for beregning av sannsynligheter og lignende – helt ned til dine egne elektroniske signaturalgoritmer. I dette tilfellet mener vi virkelig vilkårlig skriving av logikk.
Det finnes også vilkårlige smarte kontrakter, men ikke komplette Turing-kontrakter. Dette inkluderer Bitcoin og Litecoin med eget skript. Dette betyr at du kun kan bruke visse operasjoner i hvilken som helst rekkefølge, men du kan ikke lenger skrive looper og dine egne algoritmer.
I tillegg finnes det smarte kontraktsplattformer som implementerer forhåndsdefinerte smarte kontrakter. Disse inkluderer Bitshares og Steemit. Bitshares har en rekke smarte kontrakter for handel, kontoadministrasjon, administrasjon av selve plattformen og dens parametere. Steemit er en lignende plattform, men den er ikke lenger fokusert på utstedelse av tokens og handel, som Bitshares, men på blogging, det vil si at den lagrer og behandler innhold på en desentralisert måte.
Vilkårlige Turing-komplette kontrakter inkluderer Ethereum-plattformen og RootStock, som fortsatt er under utvikling. Derfor vil vi nedenfor dvele litt mer detaljert på Ethereums smarte kontraktsplattform.
Smarte kontrakter etter initieringsmetode
Basert på metoden for initiering kan smarte kontrakter også deles inn i minst to grupper: automatiserte og manuelle (ikke automatiserte). Automatiserte er preget av det faktum at, gitt alle kjente parametere og betingelser, utføres den smarte kontrakten fullstendig automatisk, det vil si at den ikke krever å sende noen ekstra transaksjoner og bruke en ekstra provisjon på hver påfølgende utførelse. Plattformen selv har alle dataene for å beregne hvordan den smarte kontrakten vil fullføres. Logikken der er ikke vilkårlig, men forutbestemt og alt dette er forutsigbart. Det vil si at du på forhånd kan estimere kompleksiteten ved å utføre en smart kontrakt, bruke en slags konstant provisjon for den, og alle prosesser for implementeringen er mer effektive.
For smarte kontrakter som er fritt programmert, er ikke utførelse automatisert. For å starte en slik smart kontrakt, må du i praktisk talt hvert trinn opprette en ny transaksjon, som vil kalle neste utførelsesstadium eller neste smarte kontraktsmetode, betale passende provisjon og vente på at transaksjonen skal bekreftes. Utførelse kan fullføres eller ikke, fordi den smarte kontraktskoden er vilkårlig og noen uforutsigbare øyeblikk kan dukke opp, for eksempel en evig sløyfe, mangel på noen parametere og argumenter, ubehandlede unntak, etc.
Ethereum-kontoer
Ethereum-kontotyper
La oss se på hvilke typer kontoer det kan være på Ethereum-plattformen. Det er bare to typer kontoer her, og det er ingen andre alternativer. Den første typen kalles en brukerkonto, den andre er en kontraktskonto. La oss finne ut hvordan de er forskjellige.
Brukerkontoen styres kun av den personlige nøkkelen til den elektroniske signaturen. Kontoeieren genererer sitt eget nøkkelpar for elektronisk signatur ved hjelp av ECDSA (Elliptic Curve Digital Signature Algorithm) algoritmen. Bare transaksjoner signert med denne nøkkelen kan endre tilstanden til denne kontoen.
En egen logikk er gitt for smartkontraktskontoen. Den kan bare kontrolleres av forhåndsdefinert programvarekode som fullstendig bestemmer oppførselen til den smarte kontrakten: hvordan den vil administrere sine mynter under visse omstendigheter, på initiativ fra hvilken bruker og under hvilke tilleggsbetingelser disse myntene vil bli distribuert. Hvis noen punkter ikke er gitt av utviklerne i programkoden, kan det oppstå problemer. For eksempel kan en smart kontrakt motta en viss tilstand der den ikke aksepterer initiering av ytterligere utførelse fra noen av brukerne. I dette tilfellet vil myntene faktisk fryses, fordi den smarte kontrakten ikke sørger for å forlate denne tilstanden.
Hvordan kontoer opprettes på Ethereum
Når det gjelder en brukerkonto, genererer eieren uavhengig et nøkkelpar ved hjelp av ECDSA. Det er viktig å merke seg at Ethereum bruker nøyaktig samme algoritme og nøyaktig samme elliptiske kurve for elektroniske signaturer som Bitcoin, men adressen beregnes på en litt annen måte. Her brukes ikke lenger resultatet av dobbel hashing, som i Bitcoin, men enkel hashing er utstyrt med Keccak-funksjonen i en lengde på 256 biter. De minst signifikante bitene er avskåret fra den resulterende verdien, nemlig de minst signifikante 160 bitene av utgangshash-verdien. Som et resultat får vi en adresse i Ethereum. Faktisk tar den opp 20 byte.
Vær oppmerksom på at kontoidentifikatoren i Ethereum er kodet i hex uten å bruke en sjekksum, i motsetning til Bitcoin og mange andre systemer, hvor adressen er kodet i et base 58 tallsystem med tillegg av en sjekksum. Dette betyr at du må være forsiktig når du arbeider med kontoidentifikatorer i Ethereum: selv én feil i identifikatoren vil garantert føre til tap av mynter.
Det er en viktig funksjon, og det er at en brukerkonto på generell databasenivå opprettes i det øyeblikket han aksepterer den første inngående betalingen.
Å opprette en smart kontraktskonto tar en helt annen tilnærming. Til å begynne med skriver en av brukerne kildekoden til den smarte kontrakten, hvoretter koden sendes gjennom en kompilator spesialisert for Ethereum-plattformen, og henter bytekode for sin egen virtuelle Ethereum-maskin. Den resulterende bytekoden plasseres i et spesialfelt for transaksjonen. Det er sertifisert på vegne av initiativtakers konto. Deretter spres denne transaksjonen gjennom nettverket og plasserer den smarte kontraktskoden. Provisjonen for transaksjonen og følgelig for gjennomføringen av kontrakten trekkes fra saldoen på initiativtakerens konto.
Hver smart kontrakt inneholder nødvendigvis sin egen konstruktør (av denne kontrakten). Det kan være tomt eller det kan ha innhold. Etter at konstruktøren er utført, opprettes en smart kontraktskontoidentifikator, som du kan bruke til å sende mynter, kalle visse smarte kontraktmetoder osv.
Ethereum-transaksjonsstruktur
For å gjøre det klarere, vil vi begynne å se på strukturen til en Ethereum-transaksjon og et eksempel på en smart kontraktskode.
En Ethereum-transaksjon består av flere felt. Den første av disse, ikke en gang, er et visst serienummer på transaksjonen i forhold til selve kontoen som distribuerer den og er dens forfatter. Dette er nødvendig for å skille mellom doble transaksjoner, det vil si å utelukke tilfellet når samme transaksjon er akseptert to ganger. Ved å bruke en identifikator har hver transaksjon en unik hashverdi.
Deretter kommer et felt som bensinpris. Dette indikerer prisen som Ethereum-basisvalutaen konverteres til gass, som brukes til å betale for utførelsen av den smarte kontrakten og tildelingen av den virtuelle maskinressursen. Hva betyr det?
I Bitcoin betales avgifter direkte av basisvalutaen – Bitcoin selv. Dette er mulig takket være en enkel mekanisme for å beregne dem: vi betaler strengt for mengden data som finnes i transaksjonen. I Ethereum er situasjonen mer komplisert, fordi det er veldig vanskelig å stole på volumet av transaksjonsdata. Her kan transaksjonen også inneholde programkode som vil bli utført på den virtuelle maskinen, og hver operasjon av den virtuelle maskinen kan ha en annen kompleksitet. Det er også operasjoner som tildeler minne for variabler. De vil ha sin egen kompleksitet, som betalingen for hver operasjon vil avhenge av.
Kostnaden for hver operasjon i gassekvivalenter vil være konstant. Det er introdusert spesielt for å bestemme den konstante kostnaden for hver operasjon. Avhengig av belastningen på nettverket vil gassprisen endres, det vil si koeffisienten som basisvalutaen vil bli konvertert til denne hjelpeenheten for å betale provisjonen.
Det er en funksjon til ved en transaksjon i Ethereum: bytekoden som den inneholder for utførelse i en virtuell maskin vil bli utført til den fullføres med et eller annet resultat (suksess eller fiasko) eller til en viss mengde mynter som er tildelt går tom for å betale provisjonen . Det er for å unngå en situasjon der alle myntene fra avsenderens konto ble brukt på provisjon i tilfelle feil (for eksempel en slags evig syklus startet i en virtuell maskin), finnes følgende felt - start gass (ofte kalt gassgrense) - det bestemmer det maksimale antallet mynter som avsenderen er villig til å bruke for å fullføre en bestemt transaksjon.
Det neste feltet kalles ankomstadresse. Dette inkluderer adressen til mottakeren av myntene eller adressen til en spesifikk smart kontrakt hvis metoder vil bli kalt. Etter det kommer feltet verdi, hvor mengden mynter som sendes til destinasjonsadressen legges inn.
Neste er et interessant felt kalt dato, hvor hele strukturen passer. Dette er ikke et eget felt, men en hel struktur der koden for den virtuelle maskinen er definert. Du kan plassere vilkårlige data her - det er egne regler for dette.
Og det siste feltet heter signatur. Den inneholder samtidig både den elektroniske signaturen til forfatteren av denne transaksjonen og den offentlige nøkkelen som denne signaturen vil bli verifisert med. Fra den offentlige nøkkelen kan du få kontoidentifikatoren til avsenderen av denne transaksjonen, det vil si unikt identifisere avsenderens konto i selve systemet. Vi fant ut det viktigste om strukturen til transaksjonen.
Eksempel på smart kontraktskode for Solidity
La oss nå se nærmere på den enkleste smarte kontrakten ved å bruke 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 som kan holde brukernes mynter og returnere dem på forespørsel.
Så det er en smart bankkontrakt som utfører følgende funksjoner: den akkumulerer mynter på saldoen, det vil si når en transaksjon er bekreftet og en slik smart kontrakt er plassert, opprettes en ny konto som kan inneholde mynter på saldoen; den husker brukere og fordelingen av mynter mellom dem; har flere metoder for å administrere saldoer, det vil si at det er mulig å fylle på, ta ut og sjekke brukerens saldo.
La oss gå gjennom hver linje med kildekode. Denne kontrakten har konstante felt. En av dem, med typeadresse, kalles eier. Her husker kontrakten adressen til brukeren som opprettet denne smarte kontrakten. Videre er det en dynamisk struktur som opprettholder samsvar mellom brukeradresser og balanser.
Deretter følger Bankmetoden - den har samme navn som kontrakten. Følgelig er dette dens konstruktør. Her blir eiervariabelen tildelt adressen til personen som la denne smarte kontrakten på nettverket. Dette er det eneste som skjer i denne konstruktøren. Det vil si at msg i dette tilfellet er nøyaktig dataene som ble overført til den virtuelle maskinen sammen med transaksjonen som inneholder hele koden til denne kontrakten. Følgelig er msg.sender forfatteren av denne transaksjonen som er vert for denne koden. Han vil være eieren av den smarte kontrakten.
Innskuddsmetoden lar deg overføre et visst antall mynter til kontraktskontoen ved transaksjon. I dette tilfellet etterlater den smarte kontrakten, som mottar disse myntene, dem på balansen, men registrerer i balansestrukturen hvem som var avsenderen av disse myntene for å vite hvem de tilhører.
Den neste metoden kalles uttak og det tar én parameter - mengden mynter som noen ønsker å ta ut fra denne banken. Dette sjekker om det er nok mynter i saldoen til brukeren som kaller denne metoden for å sende dem. Hvis det er nok av dem, returnerer smartkontrakten selv det antallet mynter til den som ringer.
Deretter kommer metoden for å sjekke brukerens gjeldende saldo. Den som kaller denne metoden vil bli brukt til å hente denne saldoen i smartkontrakten. Det er verdt å merke seg at modifiseringen av denne metoden er visning. Dette betyr at selve metoden ikke endrer variablene til klassen sin på noen måte, og det er faktisk bare en lesemetode. Det opprettes ingen egen transaksjon for å kalle denne metoden, ingen avgift betales, og alle beregninger utføres lokalt, hvoretter brukeren mottar resultatet.
Kill-metoden er nødvendig for å ødelegge tilstanden til den smarte kontrakten. Og her er det en ekstra sjekk om den som ringer denne metoden er eieren av denne kontrakten. I så fall destruerer kontrakten seg selv, og destruksjonsfunksjonen tar én parameter - kontoidentifikatoren som kontrakten vil sende alle myntene som er igjen på saldoen. I dette tilfellet vil de gjenværende myntene automatisk gå til adressen til kontraktseieren.
Hvordan fungerer en full node på Ethereum-nettverket?
La oss se skjematisk på hvordan slike smarte kontrakter utføres på Ethereum-plattformen og hvordan en full nettverksnode fungerer.
En full node på Ethereum-nettverket må ha minst fire moduler.
Den første, som for enhver desentralisert protokoll, er P2P-nettverksmodulen - en modul for nettverkstilkobling og arbeid med andre noder, hvor blokker, transaksjoner og informasjon om andre noder utveksles. Dette er en tradisjonell komponent for alle desentraliserte kryptovalutaer.
Deretter har vi en modul for å lagre blokkjededata, behandle, velge en prioritert gren, legge til blokker, koble fra blokker, validere disse blokkene, etc.
Den tredje modulen kalles EVM (Ethereum virtual machine) - dette er en virtuell maskin som mottar bytekode fra Ethereum-transaksjoner. Denne modulen tar den nåværende tilstanden til en bestemt konto og gjør endringer i dens tilstand basert på den mottatte bytekoden. Den virtuelle maskinversjonen på hver nettverksnode må være den samme. Beregningene som finner sted på hver Ethereum-node er nøyaktig de samme, men de skjer på en asynkron måte: noen sjekker og aksepterer denne transaksjonen tidligere, det vil si utfører all koden som finnes i den, og noen senere. Følgelig, når en transaksjon opprettes, distribueres den til nettverket, nodene aksepterer den, og på verifiseringstidspunktet, på samme måte som Bitcoin Script utføres i Bitcoin, utføres bytekoden til den virtuelle maskinen her.
En transaksjon betraktes som verifisert hvis all koden i den har blitt utført, en ny tilstand for en bestemt konto er generert og lagret til det er klart om denne transaksjonen har blitt brukt eller ikke. Hvis transaksjonen brukes, anses denne tilstanden ikke bare som fullført, men også gjeldende. Det er en database som lagrer tilstanden til hver konto for hver nettverksnode. På grunn av det faktum at alle beregninger skjer på samme måte og tilstanden til blokkjeden er den samme, vil databasen som inneholder tilstandene til alle kontoer også være den samme for hver node.
Myter og begrensninger for smarte kontrakter
Når det gjelder restriksjonene som eksisterer for smarte kontraktsplattformer som ligner på Ethereum, kan følgende siteres:
- kodeutførelse;
- tildele minne;
- blokkjededata;
- sende betalinger;
- opprette ny kontrakt;
- ringe andre kontrakter.
La oss se på begrensningene som er pålagt en virtuell maskin, og følgelig fjerne noen myter om smarte kontrakter. På en virtuell maskin, som ikke bare kan være i Ethereum, men også i lignende plattformer, kan du utføre virkelig vilkårlige logiske operasjoner, det vil si skrive kode, og den vil bli utført der, du kan i tillegg tildele minne. Gebyret betales imidlertid separat for hver operasjon og for hver ekstra minneenhet som tildeles.
Deretter kan den virtuelle maskinen lese data fra blokkjededatabasen for å bruke disse dataene som en trigger for å utføre en eller annen smart kontraktslogikk. Den virtuelle maskinen kan opprette og sende transaksjoner, den kan opprette nye kontrakter og ringemetoder for andre smarte kontrakter som allerede er publisert på nettverket: eksisterende, tilgjengelig, etc.
Den vanligste myten er at Ethereums smarte kontrakter kan bruke informasjon fra hvilken som helst Internett-ressurs i deres vilkår. Sannheten er at en virtuell maskin ikke kan sende en nettverksforespørsel til en ekstern informasjonsressurs på Internett, det vil si at det er umulig å skrive en smart kontrakt som vil fordele verdi mellom brukere avhengig av for eksempel hvordan været er utenfor, eller hvem som vant et eller annet mesterskap, eller basert på hvilken annen hendelse som skjedde i omverdenen, fordi informasjon om disse hendelsene rett og slett ikke er i databasen til selve plattformen. Det vil si at det ikke står noe på blokkjeden om dette. Hvis den ikke vises der, kan den virtuelle maskinen ikke bruke disse dataene som utløsere.
Ulemper med Ethereum
La oss liste opp de viktigste. Den første ulempen er at det er noen vanskeligheter med å designe, utvikle og teste smarte kontrakter i Ethereum (Ethereum bruker Solidity-språket til å skrive smarte kontrakter). Faktisk viser praksis at en svært stor prosentandel av alle feil tilhører den menneskelige faktoren. Dette er faktisk sant for allerede skrevne Ethereum smarte kontrakter som har gjennomsnittlig eller høyere kompleksitet. Hvis for enkle smarte kontrakter sannsynligheten for en feil er liten, så er det i komplekse smarte kontrakter veldig ofte feil som fører til tyveri av midler, frysing av dem, ødeleggelse av smarte kontrakter på en uventet måte, etc. Mange slike tilfeller er allerede kjent.
Den andre ulempen er at selve den virtuelle maskinen ikke er perfekt, siden den også er skrevet av mennesker. Den kan utføre vilkårlige kommandoer, og der ligger sårbarheten: en rekke kommandoer kan konfigureres på en bestemt måte som vil føre til konsekvenser som var uforutsette på forhånd. Dette er et veldig komplekst område, men det er allerede flere studier som viser at disse sårbarhetene eksisterer i den nåværende versjonen av Ethereum-nettverket, og de kan føre til feil på mange smarte kontrakter.
En annen stor vanskelighet, det kan betraktes som en ulempe. Det ligger i det faktum at du praktisk eller teknisk kan komme til den konklusjon at hvis du kompilerer bytekoden til en kontrakt som skal utføres på en virtuell maskin, kan du bestemme en bestemt rekkefølge av operasjoner. Når de utføres sammen, vil disse operasjonene belaste den virtuelle maskinen i stor grad og bremse den uforholdsmessig til avgiften som ble betalt for å utføre disse operasjonene.
Tidligere var det allerede en periode i utviklingen av Ethereum, da mange gutter som i detalj forsto driften av en virtuell maskin fant slike sårbarheter. Faktisk betalte transaksjoner en veldig liten avgift, men bremset praktisk talt hele nettverket. Disse problemene er svært vanskelige å løse, siden det for det første er nødvendig å bestemme dem, for det andre å justere prisen for å utføre disse operasjonene og for det tredje å utføre en hard gaffel, noe som betyr å oppdatere alle nettverksnoder til en ny versjon av programvaren, og deretter samtidig aktivering av disse endringene.
Når det gjelder Ethereum, har det blitt utført mye forskning, mye praktisk erfaring er oppnådd: både positive og negative, men likevel gjenstår det vanskeligheter og sårbarheter som fortsatt må håndteres på en eller annen måte.
Så, den tematiske delen av artikkelen er fullført, la oss gå videre til spørsmål som dukker opp ganske ofte.
Ofte stilte spørsmål
— Hvis alle parter i en eksisterende smart kontrakt ønsker å endre vilkårene, kan de kansellere denne smarte kontrakten ved å bruke multisig, og deretter opprette en ny smart kontrakt med oppdaterte vilkår for utførelse?
Svaret her vil være todelt. Hvorfor? For på den ene siden er en smart kontrakt definert én gang og den innebærer ikke lenger noen endringer, og på den andre siden kan den ha forhåndsskrevet logikk som sørger for en fullstendig eller delvis endring av noen forhold. Det vil si at hvis du ønsker å endre noe i smartkontrakten din, så må du foreskrive vilkårene for å oppdatere disse betingelsene. Følgelig kan fornyelsen av kontrakten bare organiseres på en slik forsvarlig måte. Men også her kan du få problemer: gjør en feil og få en tilsvarende sårbarhet. Derfor må slike ting være svært detaljerte og nøye utformet og testet.
— Hva om mekleren inngår en avtale med en av deltakerne: sperret eller smart kontrakt? Er det nødvendig med en mekler i en smart kontrakt?
En mekler er ikke nødvendig i en smart kontrakt. Det finnes kanskje ikke. Hvis mekleren i tilfelle deponering inngår en konspirasjon med en av partene, ja, denne ordningen mister da kraftig all sin verdi. Derfor velges meklere på en slik måte at de får tillit fra alle parter som er involvert i denne prosessen samtidig. Følgelig vil du ganske enkelt ikke overføre mynter til en multisignaturadresse med en formidler som du ikke stoler på.
— Er det mulig med én Ethereum-transaksjon å overføre mange forskjellige tokens fra adressen din til forskjellige måladresser, for eksempel børsadresser der disse tokenene handles?
Dette er et godt spørsmål, og det gjelder Ethereum-transaksjonsmodellen og hvordan den skiller seg fra Bitcoin-modellen. Og forskjellen er radikal. Hvis du i Ethereum-transaksjonsmodellen ganske enkelt overfører mynter, blir de bare overført fra en adresse til en annen, ingen endring, bare det spesifikke beløpet du spesifiserte. Dette er med andre ord ikke en modell av ubrukte utganger (UTXO), men en modell av kontoer og tilsvarende saldoer. Det er teoretisk mulig å sende flere forskjellige tokens i en transaksjon på en gang hvis du skriver en utspekulert smart kontrakt, men du må fortsatt gjøre mange transaksjoner, opprette en kontrakt, overføre tokens og mynter til den, og deretter ringe den aktuelle metoden . Dette krever innsats og tid, så i praksis fungerer det ikke slik og alle betalinger i Ethereum gjøres i separate transaksjoner.
— En av mytene om Ethereum-plattformen er at det er umulig å beskrive forhold som vil avhenge av dataene til en ekstern Internettressurs, så hva skal man gjøre da?
Løsningen er at selve smartkontrakten kan gi ett eller flere såkalte betrodde orakler, som samler inn data om tingenes tilstand i omverdenen og overfører det til de smarte kontraktene gjennom spesielle metoder. Selve kontrakten anser dataene den mottok fra pålitelige parter som sanne. For større pålitelighet, velg ganske enkelt en stor gruppe orakler og minimer risikoen for samhandling. Selve kontrakten kan ikke ta hensyn til data fra orakler som motsier flertallet.
En av forelesningene på nettkurset om Blockchain er viet til dette emnet - "".
Kilde: www.habr.com