U ovom ćemo članku pogledati što su pametni ugovori, što su, upoznat ćemo se s različitim platformama pametnih ugovora, njihovim značajkama, a također ćemo razgovarati o tome kako funkcioniraju i koje prednosti mogu donijeti. Ovaj materijal će biti vrlo koristan za čitatelje koji nisu dobro upoznati s temom pametnih ugovora, ali se žele približiti njenom razumijevanju.
Redovni ugovor vs. pametni ugovor
Prije nego što uđemo u detalje, uzmimo primjer razlika između običnog ugovora, koji je specificiran na papiru, i pametnog ugovora, koji je predstavljen digitalno.
Kako je to funkcioniralo prije pojave pametnih ugovora? Zamislite skupinu ljudi koji žele uspostaviti određena pravila i uvjete za raspodjelu vrijednosti, kao i određeni mehanizam koji jamči provedbu te raspodjele prema zadanim pravilima i uvjetima. Zatim bi se okupili, sastavili papir na kojem su zapisali svoje identifikacijske podatke, uvjete, vrijednosti o kojima je riječ, datirali ih i potpisali. Ovaj ugovor također je ovjerila strana od povjerenja, poput javnog bilježnika. Dalje, ti ljudi su sa svojim papirnatim primjerkom takvog ugovora krenuli na različite strane i počeli izvoditi neke radnje koje možda ne odgovaraju samom ugovoru, odnosno radili su jedno, a na papiru je bilo ovjereno da trebaju nešto učiniti. potpuno drukčije. I kako izaći iz ove situacije? Zapravo, jedan od članova grupe treba uzeti ovaj papir, uzeti neke dokaze, odnijeti ih na sud i postići usklađenost između ugovora i stvarnih radnji. Nerijetko je teško postići pravednu provedbu ovog ugovora, što dovodi do neugodnih posljedica.
Što se može reći o pametnim ugovorima? Oni kombiniraju i mogućnost pisanja uvjeta ugovora i mehanizam za njihovu strogu provedbu. Ako su uvjeti postavljeni i odgovarajuća transakcija ili zahtjev je potpisan, nakon što je zahtjev ili transakcija prihvaćena, više nije moguće promijeniti uvjete niti utjecati na njihovu provedbu.
Postoji jedan validator ili cijela mreža, kao i baza podataka koja pohranjuje sve pametne ugovore koji su predani na izvršenje u strogom kronološkom redoslijedu. Također je važno da ova baza podataka mora sadržavati sve uvjete okidača za izvršenje pametnog ugovora. Osim toga, mora voditi računa o samoj vrijednosti čija je raspodjela opisana u ugovoru. Ako se to odnosi na neku digitalnu valutu, onda bi ova baza podataka to trebala uzeti u obzir.
Drugim riječima, validatori pametnih ugovora moraju imati pristup svim podacima na kojima funkcionira pametni ugovor. Na primjer, jedna baza podataka trebala bi se koristiti za istovremeno obračunavanje digitalnih valuta, stanja korisnika, transakcija korisnika i vremenskih oznaka. Zatim, u pametnom ugovoru, uvjet može biti stanje korisnika u određenoj valuti, dolazak određenog vremena ili činjenica da je određena transakcija izvršena, ali ništa više.
Definicija pametnog ugovora
Općenito, samu terminologiju skovao je istraživač Nick Szabo i prvi put je korišten 1994. godine, a dokumentiran je 1997. godine u članku koji opisuje samu ideju pametnih ugovora.
Pametni ugovori podrazumijevaju da se vrši određena automatizacija raspodjele vrijednosti, koja može ovisiti samo o onim uvjetima koji su unaprijed određeni. U najjednostavnijem obliku izgleda kao ugovor sa strogo definiranim uvjetima, koji potpisuju određene strane.
Pametni ugovori osmišljeni su tako da minimiziraju povjerenje u treće strane. Ponekad je središte odlučivanja o kojem sve ovisi potpuno isključeno. Osim toga, takve je ugovore lakše revidirati. To je posljedica nekih značajki dizajna takvog sustava, ali najčešće pod pametnim ugovorom razumijemo decentralizirano okruženje i prisutnost funkcija koje svakome omogućuju analizu baze podataka i provođenje potpune revizije izvršenja ugovora. Time se osigurava zaštita od retroaktivnih promjena podataka koje bi za posljedicu imale promjene u izvršenju samog ugovora. Digitalizacija većine procesa pri izradi i pokretanju pametnog ugovora često pojednostavljuje tehnologiju i trošak njihove implementacije.
Jednostavan primjer - Escrow usluga
Pogledajmo vrlo jednostavan primjer. Pomoći će vam da se približite razumijevanju funkcionalnosti pametnih ugovora, kao i boljem razumijevanju u kojim slučajevima ih treba koristiti.
Također se može implementirati pomoću Bitcoina, iako se trenutno Bitcoin još uvijek teško može nazvati potpunom platformom za pametne ugovore. Dakle, imamo nekog kupca i imamo online trgovinu. Kupac želi kupiti monitor u ovoj trgovini. U najjednostavnijem slučaju, kupac ispuni i pošalje uplatu, a online trgovina je prihvati, potvrdi i zatim pošalje robu. Međutim, u ovoj situaciji postoji potreba za velikim povjerenjem - kupac mora vjerovati online trgovini za cjelokupnu cijenu monitora. Budući da internetska trgovina može imati nizak ugled u očima kupca, postoji rizik da će iz nekog razloga, nakon prihvaćanja plaćanja, trgovina odbiti uslugu i neće poslati robu kupcu. Stoga kupac postavlja pitanje (i, sukladno tome, internetska trgovina postavlja ovo pitanje) što se može primijeniti u ovom slučaju kako bi se minimizirali takvi rizici i učinile takve transakcije pouzdanijima.
U slučaju Bitcoina, moguće je dopustiti kupcu i prodavatelju da samostalno izaberu posrednika. Mnogo je ljudi koji su uključeni u rješavanje kontroverznih pitanja. A naši sudionici mogu s općeg popisa medijatora izabrati onoga kojem će vjerovati. Zajedno stvaraju 2 od 3 adrese s više potpisa gdje postoje tri ključa i potrebna su dva potpisa s bilo koja dva ključa za trošenje novčića s te adrese. Jedan ključ pripada kupcu, drugi internetskoj trgovini, a treći posredniku. I na takvu multisignature adresu kupac će poslati iznos potreban za plaćanje monitora. Sada, kada prodavač vidi da je novac blokiran neko vrijeme na multisignature adresi koja ovisi o njemu, može sigurno poslati monitor poštom.
Zatim kupac preuzima pošiljku, pregledava robu i donosi odluku o konačnoj kupnji. Može se u potpunosti složiti s pruženom uslugom i potpisati transakciju svojim ključem, pri čemu prebacuje coine s multisignature adrese prodavatelju, ili može biti nečim nezadovoljan. U drugom slučaju, on kontaktira posrednika da sastavi alternativnu transakciju koja će drugačije distribuirati te kovanice.
Recimo monitor je stigao malo izgreban i u kompletu nije bio kabel za spajanje na računalo, iako je na web stranici online trgovine pisalo da taj kabel treba biti u kompletu. Zatim kupac prikuplja dokaze potrebne da dokaže posredniku da je prevaren u ovoj situaciji: snima screenshot stranice, fotografira potvrdu o primitku pošte, fotografira ogrebotine na monitoru i pokazuje da je pečat slomljena i kabel je izvučen. Internetska trgovina pak prikuplja svoje dokaze i prenosi ih posredniku.
Posrednik je zainteresiran istovremeno zadovoljiti i ogorčenost kupca i interese internetske trgovine (kasnije će postati jasno zašto). Predstavlja transakciju u kojoj će se kovanice s multisignature adrese trošiti u određenom omjeru između kupca, online trgovine i posrednika, budući da on uzima dio za sebe kao nagradu za svoj rad. Recimo 90% ukupnog iznosa ide prodavatelju, 5% posredniku i 5% naknade kupcu. Posrednik potpisuje ovu transakciju svojim ključem, ali se još ne može primijeniti, jer su potrebna dva potpisa, ali samo jedan vrijedi. Šalje takvu transakciju i kupcu i prodavatelju. Ako je barem jedan od njih zadovoljan ovom opcijom redistribucije kovanica, tada će transakcija biti unaprijed potpisana i distribuirana mreži. Za njegovu potvrdu dovoljno je da se jedna od strana u transakciji složi s opcijom posrednika.
Važno je u početku odabrati medijatora tako da mu oba sudionika vjeruju. U tom slučaju, on će djelovati neovisno o interesima jednog ili drugog i objektivno procijeniti situaciju. Ako posrednik ne nudi opciju distribucije kovanica koja će zadovoljiti barem jednog sudionika, tada, nakon zajedničkog dogovora, i kupac i internet trgovina mogu slati kovanice na novu višepotpisnu adresu stavljanjem svoja dva potpisa. Nova multisignature adresa bit će sastavljena s drugim posrednikom, koji bi mogao biti kompetentniji u tom pitanju i pružiti bolju opciju.
Primjer sa spavaonicom i hladnjakom
Pogledajmo složeniji primjer koji eksplicitnije prikazuje mogućnosti pametnog ugovora.
Recimo da postoje tri tipa koji su se nedavno uselili u istu sobu u domu. Njih troje zainteresirani su za kupnju hladnjaka za svoju sobu koji bi mogli koristiti zajedno. Jedan od njih volontirao je prikupiti potreban iznos za kupnju hladnjaka i pregovarati s prodavačem. Međutim, tek su se nedavno upoznali i među njima nema dovoljno povjerenja. Očito dvojica od njih riskiraju dajući novac trećem. Osim toga, trebaju postići dogovor u odabiru prodavatelja.
Mogu koristiti escrow uslugu, odnosno odabrati posrednika koji će pratiti provedbu transakcije i rješavati sporna pitanja ako do njih dođe. Zatim, nakon dogovora, sastavljaju pametni ugovor i u njemu propisuju određene uvjete.
Prvi uvjet je da prije određenog vremena, recimo unutar jednog tjedna, odgovarajući račun pametnog ugovora mora primiti tri uplate s određenih adresa za određeni iznos. Ako se to ne dogodi, pametni ugovor prestaje izvršavati i vraća novčiće svim sudionicima. Ako je uvjet ispunjen postavljaju se vrijednosti identifikatora prodavatelja i posrednika te se provjerava uvjet da su svi sudionici suglasni s izborom prodavatelja i posrednika. Kada se ispune svi uvjeti, sredstva će biti doznačena na navedene adrese. Ovaj pristup može zaštititi sudionike od prijevare s bilo koje strane i općenito eliminira potrebu za povjerenjem.
U ovom primjeru vidimo sam princip da ova mogućnost postupnog postavljanja parametara za ispunjavanje svakog uvjeta omogućuje stvaranje sustava bilo koje složenosti i dubine ugniježđenih razina. Osim toga, u pametnom ugovoru prvo možete definirati prvi uvjet, a tek nakon njegovog ispunjenja možete postaviti parametre za sljedeći uvjet. Drugim riječima, uvjet je formalno napisan, a parametri za njega se mogu postaviti već tijekom njegovog rada.
Klasifikacija pametnih ugovora
Za klasifikaciju možete postaviti različite skupine kriterija. Međutim, u trenutku razvoja tehnologije četiri su od njih relevantne.
Pametni ugovori mogu se razlikovati po okruženju izvršenja koje može biti centralizirano ili decentralizirano. U slučaju decentralizacije imamo puno veću neovisnost i toleranciju na greške pri izvršavanju pametnih ugovora.
Razlikuju se i po postupku postavljanja i ispunjavanja uvjeta: mogu biti slobodno programabilni, ograničeni ili predefinirani, tj. strogo tipizirani. Kada na platformi za pametne ugovore postoje samo 4 specifična pametna ugovora, parametri za njih mogu se postaviti na bilo koji način. Sukladno tome, njihovo postavljanje je puno jednostavnije: odabiremo ugovor s popisa i prosljeđujemo parametre.
Prema načinu inicijacije postoje automatizirani pametni ugovori, odnosno kada se pojave određeni uvjeti oni se sami izvršavaju, a postoje ugovori u kojima su uvjeti navedeni, ali platforma ne provjerava automatski njihovo ispunjenje, za to treba pokrenuti odvojeno.
Osim toga, pametni ugovori razlikuju se po razini privatnosti. Mogu biti potpuno otvoreni, djelomično ili potpuno povjerljivi. Potonje znači da promatrači treće strane ne vide uvjete pametnih ugovora. Međutim, tema privatnosti vrlo je široka i bolje ju je razmotriti odvojeno od trenutnog članka.
U nastavku ćemo pobliže pogledati prva tri kriterija kako bismo unijeli više jasnoće u razumijevanje trenutne teme.
Pametni ugovori prema vremenu izvođenja
Na temelju okruženja izvršenja, razlikuju se centralizirane i decentralizirane platforme za pametne ugovore. U slučaju centraliziranih digitalnih ugovora koristi se jedna usluga, gdje postoji samo jedan validator i može postojati usluga sigurnosne kopije i oporavka, kojom se također upravlja centralno. Postoji jedna baza podataka koja pohranjuje sve potrebne informacije za postavljanje uvjeta pametnog ugovora i raspodjelu vrijednosti koja se uzima u obzir upravo u bazi podataka ove usluge. Takav centralizirani servis ima klijenta koji postavlja uvjete s određenim zahtjevima i koristi takve ugovore. Zbog centralizirane prirode platforme, mehanizmi autentifikacije mogu biti manje sigurni nego u kriptovalutama.
Kao primjer možemo uzeti pružatelje mobilnih komunikacija (različiti mobilni operateri). Recimo, određeni operater vodi centraliziranu evidenciju prometa na svojim poslužiteljima, koji se može prenositi u različitim formatima, npr.: u obliku govornih poziva, SMS prijenosa, mobilnog internetskog prometa, te prema različitim standardima, te također vodi evidenciju sredstava na računima korisnika. Sukladno tome, pružatelj mobilnih komunikacija može sklopiti ugovore o obračunu pruženih usluga i njihovom plaćanju s različitim uvjetima. U ovom slučaju lako je postaviti uvjete poput “pošaljite SMS s tim i tim kodom na taj i taj broj i dobit ćete te i te uvjete za raspodjelu prometa.”
Možemo navesti još jedan primjer: tradicionalne banke s proširenom funkcionalnošću Internet bankarstva i vrlo jednostavnim ugovorima kao što su redovita plaćanja, automatska konverzija prispjelih uplata, automatski odbitak kamata na određeni račun itd.
Ako govorimo o pametnim ugovorima s decentraliziranim okruženjem izvršenja, onda imamo grupu validatora. U idealnom slučaju, svatko može postati validator. Zbog protokola sinkronizacije baze podataka i postizanja konsenzusa, imamo neku zajedničku bazu podataka koja će sada pohranjivati sve transakcije uz striktno opisane ugovore, a ne neke uvjetne upite, čiji se formati često mijenjaju, a nema otvorene specifikacije. Ovdje će transakcije sadržavati upute za izvršenje ugovora u skladu sa strogom specifikacijom. Ova je specifikacija otvorena i stoga sami korisnici platforme mogu revidirati i potvrditi pametne ugovore. Ovdje vidimo da su decentralizirane platforme superiornije od centraliziranih u smislu neovisnosti i tolerancije na greške, ali su njihov dizajn i održavanje puno složeniji.
Pametni ugovori po načinu postavljanja i ispunjavanja uvjeta
Pogledajmo sada pobliže kako se pametni ugovori mogu razlikovati u načinu na koji postavljaju i ispunjavaju uvjete. Ovdje usmjeravamo pozornost na pametne ugovore koji su nasumično programabilni i Turing kompletni. Pametni ugovor kompletan po Turingu omogućuje vam da postavite gotovo sve algoritme kao uvjete za izvršenje ugovora: cikluse pisanja, neke funkcije za izračunavanje vjerojatnosti i slično - sve do vlastitih algoritama elektroničkog potpisa. U ovom slučaju mislimo na doista proizvoljno pisanje logike.
Postoje i proizvoljni pametni ugovori, ali ne Turingovi potpuni. To uključuje Bitcoin i Litecoin s vlastitom skriptom. To znači da možete koristiti samo određene operacije bilo kojim redoslijedom, ali više ne možete pisati petlje i vlastite algoritme.
Osim toga, postoje platforme za pametne ugovore koje implementiraju unaprijed definirane pametne ugovore. To uključuje Bitshares i Steemit. Bitshares ima niz pametnih ugovora za trgovanje, upravljanje računima, upravljanje samom platformom i njenim parametrima. Steemit je slična platforma, ali više nije usmjerena na izdavanje tokena i trgovanje, kao Bitshares, već na bloganje, odnosno pohranjuje i obrađuje sadržaj na decentraliziran način.
Proizvoljni Turing-kompletni ugovori uključuju platformu Ethereum i RootStock, koji je još uvijek u razvoju. Stoga ćemo se u nastavku malo detaljnije osvrnuti na platformu pametnih ugovora Ethereum.
Pametni ugovori metodom inicijacije
Na temelju načina pokretanja, pametni ugovori također se mogu podijeliti u najmanje dvije skupine: automatizirani i ručni (neautomatizirani). Za automatizirane je karakteristično da se, s obzirom na sve poznate parametre i uvjete, pametni ugovor u potpunosti izvršava automatski, odnosno ne zahtijeva slanje dodatnih transakcija i trošenje dodatne provizije pri svakom sljedećem izvršenju. Sama platforma ima sve podatke za izračun kako će pametni ugovor završiti. Logika tu nije proizvoljna, nego unaprijed određena i sve je to predvidljivo. To jest, možete unaprijed procijeniti složenost izvršenja pametnog ugovora, koristiti neku vrstu stalne provizije za to, a svi procesi za njegovu implementaciju su učinkovitiji.
Za pametne ugovore koji su slobodno programirani, izvršenje nije automatizirano. Da biste pokrenuli takav pametni ugovor, gotovo u svakom koraku morate kreirati novu transakciju, koja će pozvati sljedeću fazu izvršenja ili metodu sljedećeg pametnog ugovora, platiti odgovarajuću proviziju i čekati da se transakcija potvrdi. Izvršenje može završiti uspješno ili ne, jer je kod pametnog ugovora proizvoljan i mogu se pojaviti neki nepredvidivi trenuci, kao što je vječna petlja, nedostatak nekih parametara i argumenata, neobrađene iznimke itd.
Ethereum računi
Vrste Ethereum računa
Pogledajmo koje vrste računa mogu postojati na platformi Ethereum. Ovdje postoje samo dvije vrste računa i nema drugih opcija. Prva vrsta se zove korisnički račun, druga je ugovorni račun. Hajde da shvatimo kako se razlikuju.
Korisnički račun kontrolira se isključivo osobnim ključem elektroničkog potpisa. Vlasnik računa generira vlastiti par ključeva za elektronički potpis pomoću algoritma ECDSA (Elliptic Curve Digital Signature Algorithm). Samo transakcije potpisane ovim ključem mogu promijeniti stanje ovog računa.
Za račun pametnog ugovora osigurana je zasebna logika. Njime se može upravljati samo unaprijed definiranim softverskim kodom koji u potpunosti određuje ponašanje pametnog ugovora: kako će upravljati svojim kovanicama pod određenim okolnostima, na inicijativu kojeg korisnika i pod kojim dodatnim uvjetima će se ti kovanice distribuirati. Ako programeri nisu predvidjeli neke točke u programskom kodu, mogu se pojaviti problemi. Na primjer, pametni ugovor može dobiti određeno stanje u kojem ne prihvaća pokretanje daljnjeg izvršenja od bilo kojeg korisnika. U ovom slučaju, novčići će zapravo biti zamrznuti, jer pametni ugovor ne predviđa izlazak iz ovog stanja.
Kako se kreiraju računi na Ethereumu
U slučaju korisničkog računa, vlasnik samostalno generira par ključeva koristeći ECDSA. Važno je napomenuti da Ethereum koristi potpuno isti algoritam i potpuno istu eliptičnu krivulju za elektroničke potpise kao i Bitcoin, ali se adresa izračunava na nešto drugačiji način. Ovdje se više ne koristi rezultat dvostrukog raspršivanja, kao u Bitcoinu, već se jednostruko raspršivanje omogućuje Keccak funkcijom u duljini od 256 bita. Najmanje značajni bitovi odsječeni su od dobivene vrijednosti, odnosno najmanje značajnih 160 bitova izlazne hash vrijednosti. Kao rezultat toga, dobivamo adresu u Ethereumu. Zapravo, zauzima 20 bajtova.
Imajte na umu da je identifikator računa u Ethereumu kodiran u hex bez primjene kontrolnog zbroja, za razliku od Bitcoina i mnogih drugih sustava, gdje je adresa kodirana u sustavu brojeva s bazom 58 uz dodatak kontrolnog zbroja. To znači da morate biti oprezni kada radite s identifikatorima računa u Ethereumu: čak i jedna pogreška u identifikatoru sigurno će dovesti do gubitka kovanica.
Postoji jedna bitna karakteristika a to je da se korisnički račun na razini opće baze kreira u trenutku kada prihvati prvu pristiglu uplatu.
Stvaranje računa pametnog ugovora ima potpuno drugačiji pristup. U početku, jedan od korisnika piše izvorni kod pametnog ugovora, nakon čega se kod prolazi kroz kompilator poseban za Ethereum platformu, dobivajući bajt kod za vlastitu Ethereum virtualnu mašinu. Rezultirajući bajt kod se stavlja u posebno polje transakcije. Ovjerava se na račun inicijatora. Zatim se ova transakcija širi kroz mrežu i postavlja kod pametnog ugovora. Provizija za transakciju i, sukladno tome, za izvršenje ugovora povlači se sa salda računa inicijatora.
Svaki pametni ugovor nužno sadrži svoj konstruktor (ovog ugovora). Može biti prazan ili može imati sadržaj. Nakon što se konstruktor izvrši, kreira se identifikator računa pametnog ugovora pomoću kojeg možete slati kovanice, pozivati određene metode pametnog ugovora itd.
Transakcijska struktura Ethereuma
Kako bi bilo jasnije, počet ćemo promatrati strukturu Ethereum transakcije i primjer koda pametnog ugovora.
Ethereum transakcija sastoji se od nekoliko polja. Prvi od njih, nonce, je određeni serijski broj transakcije u odnosu na sam račun koji je distribuira i koji je njezin autor. Ovo je potrebno kako bi se razlikovale dvostruke transakcije, odnosno kako bi se isključio slučaj kada se ista transakcija prihvaća dva puta. Korištenjem identifikatora svaka transakcija ima jedinstvenu hash vrijednost.
Slijedi polje poput cijena plina. To označava cijenu po kojoj se Ethereum osnovna valuta pretvara u plin, koji se koristi za plaćanje izvršenja pametnog ugovora i dodjele resursa virtualnog stroja. Što to znači?
U Bitcoinu, naknade se plaćaju izravno temeljnom valutom - samim Bitcoinom. To je moguće zahvaljujući jednostavnom mehanizmu za njihov izračun: plaćamo strogo prema količini podataka sadržanih u transakciji. U Ethereumu je situacija kompliciranija, jer je vrlo teško osloniti se na količinu transakcijskih podataka. Ovdje transakcija može sadržavati i programski kod koji će se izvršiti na virtualnom stroju, a svaka operacija virtualnog stroja može imati različitu složenost. Postoje i operacije koje dodjeljuju memoriju za varijable. Oni će imati svoju složenost, o kojoj će ovisiti plaćanje za svaku operaciju.
Trošak svake operacije u plinskom ekvivalentu bit će konstantan. Uvodi se posebno kako bi se utvrdio stalni trošak svake operacije. Ovisno o opterećenju mreže mijenjat će se cijena plina, odnosno koeficijent prema kojem će se osnovna valuta preračunavati u ovu pomoćnu jedinicu za plaćanje provizije.
Postoji još jedna značajka transakcije u Ethereumu: bajt kod koji ona sadrži za izvršenje u virtualnom stroju bit će izvršen dok ne završi s nekim rezultatom (uspjeh ili neuspjeh) ili dok ne ponestane određene količine kovanica dodijeljenih za plaćanje provizije. . Da bi se izbjegla situacija da su u slučaju neke greške svi coini s računa pošiljatelja potrošeni na proviziju (npr. neka vrsta vječnog ciklusa pokrenutog u virtualnom stroju), postoji sljedeće polje - start gas (često se naziva ograničenje plina) - određuje maksimalnu količinu kovanica koju je pošiljatelj spreman potrošiti da dovrši određenu transakciju.
Poziva se sljedeće polje adresa odredišta. To uključuje adresu primatelja kovanica ili adresu određenog pametnog ugovora čije će se metode pozivati. Nakon njega dolazi polje vrijednost, gdje se upisuje količina kovanica koje se šalju na odredišnu adresu.
Slijedi zanimljivo polje tzv datum, gdje stane cijela struktura. Ovo nije zasebno polje, već cijela struktura u kojoj je definiran kod za virtualni stroj. Ovdje možete postaviti proizvoljne podatke - za to postoje posebna pravila.
I zadnje polje se zove potpis. Istodobno sadrži i elektronički potpis autora ove transakcije i javni ključ kojim će se taj potpis ovjeravati. Iz javnog ključa možete dobiti identifikator računa pošiljatelja ove transakcije, odnosno jedinstveno identificirati račun pošiljatelja u samom sustavu. Saznali smo glavnu stvar o strukturi transakcije.
Primjer koda pametnog ugovora za Solidity
Pogledajmo sada pobliže najjednostavniji pametni ugovor na primjeru.
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);
}
}Gore je pojednostavljeni izvorni kod koji može zadržati korisničke novčiće i vratiti ih na zahtjev.
Dakle, postoji Bankovni pametni ugovor koji obavlja sljedeće funkcije: akumulira kovanice na svom saldu, odnosno kada se potvrdi transakcija i postavi takav pametni ugovor, kreira se novi račun koji može sadržavati kovanice na svom saldu; pamti korisnike i raspodjelu kovanica među njima; ima nekoliko načina upravljanja saldom, odnosno moguća je dopuna, podizanje i provjera stanja korisnika.
Prođimo kroz svaki redak izvornog koda. Ovaj ugovor ima stalna polja. Jedan od njih, s tipom adresa, zove se vlasnik. Ovdje ugovor pamti adresu korisnika koji je kreirao ovaj pametni ugovor. Nadalje, postoji dinamička struktura koja održava korespondenciju između korisničkih adresa i stanja.
Nakon toga slijedi bankovna metoda - ima isti naziv kao i ugovor. Prema tome, ovo je njegov konstruktor. Ovdje se varijabli vlasnika dodjeljuje adresa osobe koja je postavila ovaj pametni ugovor na mrežu. To je jedina stvar koja se događa u ovom konstruktoru. Odnosno, msg je u ovom slučaju upravo podatak koji je prenesen na virtualni stroj zajedno s transakcijom koja sadrži cijeli kod ovog ugovora. Sukladno tome, msg.sender je autor ove transakcije koja ugošćuje ovaj kod. On će biti vlasnik pametnog ugovora.
Metoda depozita omogućuje prijenos određenog broja kovanica na ugovorni račun transakcijom. U tom slučaju pametni ugovor, primajući te kovanice, ostavlja ih u svojoj bilanci, ali u strukturi stanja bilježi tko je točno bio pošiljatelj tih kovanica kako bi se znalo kome pripadaju.
Sljedeća metoda zove se "povlačenje" i uzima jedan parametar - količinu kovanica koju netko želi podići iz ove banke. Time se provjerava ima li dovoljno kovanica na saldu korisnika koji poziva ovu metodu da ih pošalje. Ako ih ima dovoljno, tada sam pametni ugovor vraća taj broj kovanica pozivatelju.
Slijedi način provjere trenutnog stanja korisnika. Tko god pozove ovu metodu, koristit će se za dohvaćanje ovog stanja u pametnom ugovoru. Vrijedno je napomenuti da je modifikator ove metode pogled. To znači da sama metoda ni na koji način ne mijenja varijable svoje klase i zapravo je samo metoda čitanja. Ne stvara se posebna transakcija za pozivanje ove metode, ne plaća se naknada, a svi se izračuni izvode lokalno, nakon čega korisnik dobiva rezultat.
Metoda kill je potrebna za uništavanje stanja pametnog ugovora. I ovdje postoji dodatna provjera da li je pozivatelj ove metode vlasnik ovog ugovora. Ako je tako, tada se ugovor sam uništava, a funkcija uništavanja uzima jedan parametar - identifikator računa na koji će ugovor poslati sve kovanice preostale na saldu. U tom će slučaju preostali novčići automatski otići na adresu vlasnika ugovora.
Kako funkcionira puni čvor na Ethereum mreži?
Pogledajmo shematski kako se takvi pametni ugovori izvršavaju na platformi Ethereum i kako funkcionira pun mrežni čvor.
Puni čvor na Ethereum mreži mora imati najmanje četiri modula.
Prvi, kao i za svaki decentralizirani protokol, je P2P mrežni modul - modul za mrežno povezivanje i rad s drugim čvorovima, gdje se razmjenjuju blokovi, transakcije i informacije o drugim čvorovima. Ovo je tradicionalna komponenta za sve decentralizirane kriptovalute.
Zatim, imamo modul za pohranjivanje blockchain podataka, obradu, odabir prioritetne grane, dodavanje blokova, odvajanje blokova, provjeru tih blokova itd.
Treći modul se zove EVM (Ethereum virtual machine) - ovo je virtualni stroj koji prima bytecode iz Ethereum transakcija. Ovaj modul uzima trenutno stanje određenog računa i mijenja njegovo stanje na temelju primljenog bajtkoda. Verzija virtualnog stroja na svakom mrežnom čvoru mora biti ista. Izračuni koji se odvijaju na svakom Ethereum čvoru potpuno su isti, ali se odvijaju na asinkroni način: netko ranije provjerava i prihvaća ovu transakciju, odnosno izvršava sav kod koji se u njoj nalazi, a netko kasnije. U skladu s tim, kada se kreira transakcija, ona se distribuira mreži, čvorovi je prihvaćaju, au trenutku verifikacije, na isti način na koji se Bitcoin Script izvršava u Bitcoinu, ovdje se izvršava bajt kod virtualnog stroja.
Transakcija se smatra verificiranom ako je izvršen sav kod sadržan u njoj, generirano novo stanje određenog računa i pohranjeno dok se ne vidi je li ta transakcija primijenjena ili ne. Ako se transakcija primijeni, tada se ovo stanje smatra ne samo završenim, već i trenutnim. Postoji baza podataka koja pohranjuje stanje svakog računa za svaki mrežni čvor. Zbog činjenice da se svi izračuni odvijaju na isti način i da je stanje blockchaina isto, baza podataka koja sadrži stanja svih računa također će biti ista za svaki čvor.
Mitovi i ograničenja pametnih ugovora
Što se tiče ograničenja koja postoje za platforme pametnih ugovora slične Ethereumu, može se navesti sljedeće:
- izvođenje koda;
- dodijeliti memoriju;
- blockchain podaci;
- poslati uplate;
- stvoriti novi ugovor;
- zvati druge ugovore.
Pogledajmo ograničenja koja su nametnuta virtualnom stroju i, u skladu s tim, raspršimo neke mitove o pametnim ugovorima. Na virtualnom stroju, koji može biti ne samo u Ethereumu, već i na sličnim platformama, možete izvoditi doista proizvoljne logičke operacije, odnosno pisati kod i on će se tamo izvršiti, možete dodatno dodijeliti memoriju. Međutim, naknada se plaća zasebno za svaku operaciju i za svaku dodatnu dodijeljenu jedinicu memorije.
Zatim, virtualni stroj može čitati podatke iz blockchain baze podataka kako bi koristio te podatke kao okidač za izvršavanje jedne ili druge logike pametnog ugovora. Virtualni stroj može kreirati i slati transakcije, može kreirati nove ugovore i pozivati metode drugih pametnih ugovora koji su već objavljeni na mreži: postojeći, dostupni itd.
Najčešći mit je da Ethereum pametni ugovori mogu koristiti informacije iz bilo kojeg internetskog izvora u svojim uvjetima. Istina je da virtualni stroj ne može poslati mrežni zahtjev nekom vanjskom informacijskom izvoru na internetu, odnosno nemoguće je napisati pametni ugovor koji će raspodijeliti vrijednost među korisnicima ovisno o tome kakvo je, recimo, vrijeme vani, ili tko je osvojio neko prvenstvo, ili na temelju toga koji se drugi incident dogodio u vanjskom svijetu, jer informacija o tim incidentima jednostavno nema u bazi podataka same platforme. Odnosno, o tome nema ništa na blockchainu. Ako se tamo ne pojavi, virtualni stroj ne može koristiti te podatke kao okidače.
Nedostaci Ethereuma
Nabrojimo glavne. Prvi nedostatak je da postoje neke poteškoće u dizajniranju, razvoju i testiranju pametnih ugovora u Ethereumu (Ethereum koristi jezik Solidity za pisanje pametnih ugovora). Dapače, praksa pokazuje da vrlo veliki postotak svih pogrešaka pripada ljudskom faktoru. Ovo zapravo vrijedi za već napisane Ethereum pametne ugovore koji imaju prosječnu ili višu složenost. Ako je za jednostavne pametne ugovore vjerojatnost pogreške mala, onda kod složenih pametnih ugovora vrlo često dolazi do grešaka koje dovode do krađe sredstava, njihovog zamrzavanja, uništavanja pametnih ugovora na neočekivani način itd. Mnogi takvi slučajevi već su znan.
Drugi nedostatak je taj što sam virtualni stroj nije savršen, budući da ga također pišu ljudi. Može izvršavati proizvoljne naredbe iu tome leži ranjivost: niz naredbi može se konfigurirati na određeni način koji će dovesti do unaprijed nepredviđenih posljedica. Ovo je vrlo složeno područje, ali već postoji nekoliko studija koje pokazuju da te ranjivosti postoje u trenutnoj verziji Ethereum mreže i mogu dovesti do kvara mnogih pametnih ugovora.
Još jedna velika poteškoća, može se smatrati nedostatkom. Ona leži u činjenici da možete praktično ili tehnički doći do zaključka da ako sastavite bytecode ugovora koji će se izvršiti na virtualnom stroju, možete odrediti neki određeni redoslijed operacija. Kada se izvode zajedno, te će operacije uvelike opteretiti virtualni stroj i usporiti ga neproporcionalno naknadi koja je plaćena za izvođenje tih operacija.
U prošlosti je već postojalo razdoblje u razvoju Ethereuma, kada su mnogi ljudi koji su detaljno razumjeli rad virtualnog stroja pronašli takve ranjivosti. Zapravo, transakcije su plaćale vrlo malu naknadu, ali su praktički usporavale cijelu mrežu. Ove probleme je vrlo teško riješiti, jer ih je potrebno, prvo, utvrditi, drugo, prilagoditi cijenu za izvođenje ovih operacija i, treće, izvršiti hard fork, što znači ažuriranje svih mrežnih čvorova na novu verziju softvera, a zatim istovremeno aktiviranje tih promjena.
Što se tiče Ethereuma, provedena su mnoga istraživanja, stečeno je mnoga praktična iskustva: i pozitivna i negativna, ali unatoč tome ostaju poteškoće i ranjivosti s kojima se još uvijek treba nekako nositi.
Dakle, tematski dio članka je završen, prijeđimo na pitanja koja se često pojavljuju.
Šaptač
— Ako sve strane postojećeg pametnog ugovora žele promijeniti uvjete, mogu li otkazati ovaj pametni ugovor koristeći multisig, a zatim stvoriti novi pametni ugovor s ažuriranim uvjetima njegovog izvršenja?
Odgovor će ovdje biti dvojak. Zašto? Zato što je s jedne strane pametni ugovor jednom definiran i više ne podrazumijeva nikakve promjene, as druge strane može imati unaprijed napisanu logiku koja predviđa potpunu ili djelomičnu promjenu nekih uvjeta. Odnosno, ako želite nešto promijeniti u svom pametnom ugovoru, onda morate propisati uvjete pod kojima možete ažurirati te uvjete. Sukladno tome, samo na takav razborit način može se organizirati obnova ugovora. Ali i ovdje možete naići na probleme: napravite neku pogrešku i dobijete odgovarajuću ranjivost. Stoga je takve stvari potrebno vrlo detaljno i pažljivo osmisliti i testirati.
— Što ako posrednik sklopi ugovor s jednom od sudionica: escrow ili pametni ugovor? Je li posrednik potreban u pametnom ugovoru?
Posrednik nije potreban u pametnom ugovoru. Možda ne postoji. Ako, u slučaju escrowa, posrednik uđe u zavjeru s jednom od strana, onda da, ova shema tada naglo gubi svu svoju vrijednost. Stoga se izmiritelji biraju na način da im vjeruju istovremeno sve strane uključene u ovaj proces. Sukladno tome, jednostavno nećete prenositi kovanice na multisignature adresu s posrednikom u kojeg nemate povjerenja.
— Je li moguće jednom Ethereum transakcijom prenijeti mnogo različitih tokena s vaše adrese na različite ciljne adrese, na primjer, adrese razmjene na kojima se trguje tim tokenima?
Ovo je dobro pitanje i odnosi se na transakcijski model Ethereuma i kako se on razlikuje od Bitcoin modela. A razlika je radikalna. Ako u Ethereum transakcijskom modelu jednostavno prenosite kovanice, onda se oni samo prenose s jedne adrese na drugu, bez promjene, samo određeni iznos koji ste naveli. Drugim riječima, ovo nije model nepotrošenih izlaza (UTXO), već model računa i pripadajućih stanja. Teoretski je moguće poslati nekoliko različitih tokena u jednoj transakciji odjednom ako napišete lukavi pametni ugovor, ali svejedno ćete morati napraviti mnogo transakcija, stvoriti ugovor, zatim prenijeti tokene i kovanice na njega, a zatim pozvati odgovarajuću metodu . To zahtijeva trud i vrijeme, pa u praksi to ne funkcionira tako i sva plaćanja u Ethereumu vrše se u zasebnim transakcijama.
— Jedan od mitova o platformi Ethereum je da je nemoguće opisati uvjete koji će ovisiti o podacima vanjskog internetskog izvora, pa što onda učiniti?
Rješenje je u tome što sam pametni ugovor može osigurati jedno ili više tzv. pouzdanih orakula koji prikupljaju podatke o stanju stvari u vanjskom svijetu i posebnim metodama ih prenose pametnim ugovorima. Sam ugovor podatke koje je dobio od povjerljivih strana smatra istinitima. Za veću pouzdanost jednostavno odaberite veliku skupinu proročišta i minimizirajte rizik od njihovog dogovora. Sam ugovor možda neće uzeti u obzir podatke iz proročišta koji su u suprotnosti s većinom.
Jedno od predavanja online tečaja o Blockchainu posvećeno je ovoj temi - “".
Izvor: www.habr.com