V tem članku bomo raziskali, kaj so pametne pogodbe, katere vrste obstajajo, spoznali različne platforme pametnih pogodb in njihove značilnosti, ter razpravljali o tem, kako delujejo in kakšne prednosti lahko prinašajo. Ta material bo zelo uporaben za bralce, ki niso dovolj dobro seznanjeni s temo pametnih pogodb, vendar si želijo približati njihovo razumevanje.
Običajna pogodba vs. pametna pogodba
Preden se podrobneje poglobimo v temo, razjasnimo na primeru razlike med običajno pogodbo, ki je zapisana na papirju, in pametno pogodbo, ki je predstavljena v digitalni obliki.
Kako je to delovalo pred pojavom pametnih pogodb? Predstavljajte si skupino ljudi, ki želijo določiti nekatera pravila in pogoje za razporeditev vrednosti ter z določenim mehanizmom zagotoviti izpolnjevanje teh pravil in pogojev. V preteklosti so se ti ljudje zbrali, sestavili dokument, v katerem so zapisali svoje identifikacijske podatke, pogoje in vključene vrednosti, nato so dodali datum in se podpisali. To pogodbo je potrdila zaupanja vredna stran, na primer notar. Nato so se ljudje razšli s svojimi papirnimi kopijami te pogodbe in začeli izvajati določene aktivnosti, ki morda niso bile v skladu s samo pogodbo, kar pomeni, da so delali eno, na papirju pa je bilo potrjeno, da bi morali delati povsem drugo stvar. Kako se iz te situacije rešiti? Dejstvo je, da je moral nekdo iz skupine vzeti to papirno pogodbo, zbrati dokaze, iti na sodišče in zahtevati skladnost med pogodbo in dejanskimi dejanji. Dokaj pogosto je težko doseči pravično izpolnitev te pogodbe, kar vodi do neprijetnih posledic.
Kaj lahko rečemo o pametnih pogodbah? Združujejo možnost pisanja pogojev pogodbe in mehanizem strogega izvrševanja. Če so bili pogoji določeni in je bila podpisana ustrezna transakcija ali zahteva, potem po sprejemu te zahteve ali transakcije ni več mogoče spremeniti pogojev ali vplivati na njihovo izvrševanje.
Obstaja en sam validator ali celotna mreža, pa tudi podatkovna baza, ki hrani vse pametne pogodbe, ki so bile poslane v izvrševanje v strogo časovni zaporedju. Prav tako je pomembno, da ta podatkovna baza vsebuje vse pogoje-trigerje za izvrševanje pametne pogodbe. Poleg tega mora upoštevati tisto vrednost, katere porazdelitev je opisano v pogodbi. Če gre za določeno digitalno valuto, mora ta podatkovna baza to vrednost upoštevati.
Drugimi besedami, validatorji pametnih pogodb morajo imeti dostop do vseh podatkov, s katerimi upravlja pametna pogodba. Na primer, ena podatkovna baza bi morala biti uporabljena za sočasno beleženje digitalnih valut, ravnotežij uporabnikov, transakcij uporabnikov in časovnih žigov. Takrat lahko v pametni pogodbi pogoj predstavlja ravnotežje uporabnika v določeni valuti, dogoditev določenega časa ali dejstvo izvedbe določene transakcije, vendar ne več kot to.
Opredelitev pametne pogodbe
Sama terminologija je bila prvič predstavljena raziskovalcu Nicku Szabu leta 1994, dokumentirana pa je bila leta 1997 v članku, ki opisuje samo idejo pametnih pogodb.
Pametne pogodbe predpostavljajo avtomatizacijo porazdelitve vrednosti, ki je lahko odvisna samo od tistih pogojev, ki so vnaprej določeni. V najenostavnejši različici to izgleda kot pogodba z natančno določenimi pogoji, ki jo podpišejo določene stranke.
Pametne pogodbe so namenjene minimiziranju zaupanja tretjim osebam. Včasih se popolnoma izključi center za odločanje, od katerega je vse odvisno. Poleg tega je za take pogodbe preprosteje izvajati revizije. To izhaja iz nekaterih značilnosti zasnove takšne sisteme, vendar največkrat pod pametno pogodbo razumemo decentralizirano okolje in prisotnost funkcij, ki omogočajo vsakomur, da analizira podatkovno bazo in izvede popolno revizijo izvrševanja pogodb. Na tak način se zagotavlja zaščita pred spremembami podatkov retroaktivno, kar bi povzročilo spremembe v izvrševanju same pogodbe. Digitalizacija večine procesov pri ustvarjanju in zagonu pametne pogodbe pogosto poenostavi tehnologijo in stroške njihove realizacije.
Enostaven primer - Escrow storitev
Poglejmo zelo enostaven primer. Pomagal bo bolje razumeti funkcionalne možnosti pametnih pogodb ter se lažje orientirati, kdaj jih je smiselno uporabiti.
Implementirati ga je mogoče tudi z uporabo Bitcoina, čeprav težko rečemo, da je Bitcoin danes polna platforma za pametne pogodbe. Torej imamo kupca in spletno trgovino. Kupec želi kupiti monitor v tej trgovini. V najpreprostejšem primeru kupec odda in pošlje plačilo, trgovina ga sprejme, potrdi, nato pa pošlje blago. Vendar je v tej situaciji potrebno veliko zaupanje — kupec mora zaupati trgovini za celotno vrednost monitorja. Ker ima spletna trgovina morda nizko reputacijo v očeh kupca, obstaja tveganje, da trgovina po prejetju plačila zavrne storitev in ne pošlje blaga kupcu. Zato se kupec vpraša (in trgovina se prav tako vpraša), kaj lahko v takem primeru uporabimo, da bi zmanjšali takšna tveganja in naredili tovrstne transakcije bolj varne.
V primeru Bitcoina je mogoče omogočiti kupcu in prodajalcu, da si neodvisno izbereta mediatorja. Obstaja veliko ljudi, ki se ukvarjajo z reševanjem spornih vprašanj. Naši udeleženci lahko iz skupnega seznama mediatorjev izberejo tistega, kateremu bosta hkrati zaupala. Skupaj ustvarijo multisignature naslov 2 od 3, pri čemer so trije ključi in potrebni sta dva podpisa z dvema katerima koli ključema za porabo kovancev z tega naslova. Eden ključ pripada kupcu, drugi trgovini, tretji pa mediatorju. Na tak multisignature naslov bo kupec poslal znesek, potreben za plačilo monitorja. Sedaj, ko prodajalec vidi, da je denar nekaj časa zaklenjen na multisignature naslovu, ki je odvisen od njega, se lahko brez skrbi odloči, da pošlje monitor po pošti.
Nato, kupec prejme paket, pregleda izdelek in se odloči o končni nakupi. Popolnoma se lahko strinja s ponujeno storitvijo in transakcijo podpiše s svojim ključem, kjer prenese kovance z multisig naslova prodajalcu, lahko pa je tudi nezadovoljen. V drugem primeru stopi v stik z posrednikom za pripravo alternativne transakcije, ki bo drugače razdelila te kovance.
Recimo, da je monitor prispel rahlo opraskan in v kompletu ni bilo kabla za povezavo s računalnikom, čeprav je na spletni strani internetne trgovine pisalo, da bi moral kabel biti v kompletu. Takrat kupec zbere dokaze, potrebne za to, da dokaže posredniku, da je bil v tej situaciji prevaren: naredi posnetke zaslona spletne strani, posname račun s pošte, fotografira praske na monitorju in pokaže, da je bila pečat pretrgana in kabel odstranjen. Internetna trgovina pa zbere svoje dokaze in jih posreduje posredniku.
Posrednik si prizadeva zadovoljiti tako nezadovoljstvo kupca kot tudi interese internetne trgovine (kasneje bo jasno, zakaj). Pripravi transakcijo, v kateri bodo kovanci z multisig naslova porabljeni v določenem razmerju med kupcem, internetno trgovino in posrednikom, saj si deli svojo provizijo za svoje delo. Recimo, da bo 90% celotne zneska šlo prodajalcu, 5% posredniku in 5% odškodnini kupcu. To transakcijo posrednik podpiše s svojim ključem, vendar še ni mogoča, ker potrebujemo dva podpisa, trenutno pa imamo samo enega. To transakcijo pošlje tako kupcu kot prodajalcu. Če bo vsaj en izmed njiju zadovoljen s to možnostjo prerazporeditve kovancev, bo transakcija dopodpisana in razširjena v omrežje. Za njeno validacijo je dovolj, da se en izmed udeležencev strinja s predlogom posrednika.
Pomembno je izbrati posrednika, ki mu zaupata oba udeleženca. V tem primeru bo deloval neodvisno od interesov enega ali drugega in objektivno ocenil situacijo. Če posrednik ne ponudi takšnega načina razdelitve sredstev, ki bi zadovoljil vsaj enega od udeležencev, lahko kupec in spletna trgovina, po dogovoru, preneseta sredstva na nov multisignature naslov, pri čemer imata oba svoj pečat. Nov multisignature naslov bo oblikovan z drugim posrednikom, ki bo morda bolj usposobljen za to vprašanje in bo ponudil boljšo rešitev.
Primer s študentskim domom in hladilnikom
Oglejmo si bolj kompleksen primer, ki bolj jasno prikazuje možnosti pametnega pogodbenega sistema.
Recimo, da so trije fantje, ki so se nedavno vselili v eno sobo v študentskem domu. Vsi trije so zainteresirani za nakup hladilnika, ki ga bodo skupaj uporabljali. Eden izmed njih se je ponudil, da zbere potrebno količino za nakup hladilnika in vodi pogajanja s prodajalcem. Vendar so se relativno nedavno spoznali in med njimi ni dovolj zaupanja. Očitno je, da bi se dva izmed njih izpostavila tveganju, če bi denar zaupali tretjemu. Poleg tega morajo doseči soglasje glede izbire prodajalca.
Lahko izkoristijo escrow storitev, torej izberejo posrednika, ki bo nadzoroval izvedbo posla in uredil sporna vprašanja, če se ta pojavijo. Potem, po dogovoru, pripravijo pametno pogodbo in v njej določijo določene pogoje.
Prvo pravilo je da do određenog trenutka, na primer, u roku od jedne nedelje, na odgovarajući račun pametnog ugovora moraju stići tri uplate sa određenih adresa u određenom iznosu. Ako se to ne dogodi, pametni ugovor prestaje sa radom i vraća novčiće svim učesnicima. Ako se uslov ispuni, tada se postavljaju vrednosti identifikatora prodavca i posrednika, a takođe se proverava da su svi učesnici saglasni sa izborom prodavca i posrednika. Kada se svi uslovi ispune, sredstva se dalje prebacuju na navedene adrese. Ovakav pristup može zaštititi učesnike od prevare sa svih strana i potpuno eliminiertati potrebu za poverenjem.
Na ovom primeru vidimo samu suštinu, da ova mogućnost korak po korak postavljanja parametara za izvršenje svakog uslova omogućava kreiranje sistema bilo kakve složenosti i nivoa ugnježdenosti. Pored toga, prvo se u pametnom ugovoru može definisati prvi uslov, a tek nakon njegovog ispunjenja postaviti parametre za sledeći uslov. Drugim rečima, formalno se uslov definiše, a parametri za njega mogu se postaviti tokom njegovog izvršavanja.
Klasifikacija pametnih ugovora
Za klasifikaciju se mogu postaviti različite grupe kriterijuma. Ipak, u ovom trenutku razvoja tehnologija aktuelne su četiri od njih.
Pametni ugovori se mogu razlikovati po okruženju izvršenja, koje može biti ili centralizovano ili decentralizovano. U slučaju decentralizacije, imamo mnogo veću nezavisnost i otpornost na greške prilikom izvršenja pametnih ugovora.
Oni se takođe mogu razlikovati po procesu postavljanja i izvršenja uslova: mogu biti proizvoljno programabilni, ograničeni ili unapred postavljeni, tj. strogo tipizovani. Kada na platformi pametnih ugovora postoji samo 4 određena pametna ugovora, parametre za njih možemo postaviti proizvoljno. Samim tim, njihovo postavljanje je mnogo jednostavnije: biramo ugovor sa liste i prenosimo parametre.
Obstajajo avtomatizirani pametni pogodbi, torej se ob izpolnitvi določenih pogojev samoizpolnijo, in takšni pogodbi, kjer so pogoji določeni, a platforma ne preverja avtomatsko njihovega izpolnjevanja, temveč jih je treba posebej iniciirati.
Poleg tega se pametni pogodbi razlikujejo po nivoju zasebnosti. Lahko so popolnoma odprte, delno ali popolnoma zaupne. Zadnje pomeni, da tretje osebe ne vidijo pogojev pametnih pogodb. Vendar je tema zasebnosti zelo obsežna in jo je bolje obravnavati ločeno od trenutnega članka.
Spodaj se bomo podrobneje osredotočili na prvih treh kriterijih, da bi bolje razjasnili razumevanje trenutne teme.
Pametni pogodbi glede na okolje izvajanja
Glede na okolje izvajanja ločimo centralizirane in decentralizirane platforme pametnih pogodb. V primeru centraliziranih digitalnih pogodb se uporablja ena storitev, kjer obstaja le en validator, lahko pa obstaja tudi storitev za varnostno kopiranje in obnovitev, ki je prav tako centralizirano upravljana. Obstoja ena baza podatkov, ki hrani vse potrebne informacije za določitev pogojev pametne pogodbe in distribucijo vrednosti, ki je zabeležena v tej bazi podatkov storitve. Tak centraliziran servis ima stranko, ki s določenimi zahtevami določa pogoje in uporablja take pogodbe. Zaradi centralizirane platforme so lahko mehanizmi overjanja manj zanesljivi kot pri kriptovalutah.
Kot primer lahko vzamemo ponudnike mobilnih storitev (različne mobilne operaterje). Recimo, da določen operater vodi na svojih strežnikih centralizirano evidenco prometa, ki se lahko prenaša v različnih formatih, kot so: v obliki glasovnih klicev, prenosa SMS-ov, mobilnega internetnega prometa in po različnih standardih, ter vodi evidenco sredstev na računih uporabnikov. Zato lahko ponudnik mobilnih storitev sestavi pogodbe o evidenci ponujenih storitev in njihovi plačilu s različnimi pogoji. V tem primeru je enostavno določiti pogoje, kot so 'pošlji SMS s takim kodom na takšen številko in prejmi takšne pogoje distribucije prometa'.
Lahko navedemo še en primer: tradicionalne banke z napredno funkcionalnostjo spletnega bančništva in zelo preprostimi pogodbenimi dogovori, kot so redna plačila, samodejna pretvorba prejetih plačil, samodejno obrestovanje na določen račun itd.
Če govorimo o pametnih pogodbah v decentraliziranem izvajanju, imamo skupino validatorjev. V idealnem primeru je validator lahko kdorkoli. Zaslugom protokola sinhronizacije podatkovne baze in doseganja konsenza imamo skupno podatkovno bazo, ki bo sedaj shranjevala vse transakcije z natančno opisnimi pogodbenimi dogovori, namesto nekaterih pogojnih zahtev, katerih formati se pogosto spreminjajo, brez odprte specifikacije. Tu bodo transakcije vsebovale navodila za izvedbo pogodbe v skladu s strogo specifikacijo. Ta specifikacija je odprta in zato lahko uporabniki platforme izvajajo revizijo in validacijo pametnih pogodb. Vidimo, da decentralizirane platforme presegajo centralizirane glede neodvisnosti in odpornosti na napake, vendar je njihovo oblikovanje in vzdrževanje precej bolj zapleteno.
Pametne pogodbe glede na način določanja in izvajanja pogojev
Sedaj podrobneje razpravljajmo o tem, kako se lahko pametne pogodbe razlikujejo glede na način določanja in izvajanja pogojev. Tukaj se bomo osredotočili na pametne pogodbe, ki so programirane prosto in so Turingove popolne. Turingovo polna pametna pogodba omogoča določanje skoraj vseh algoritmov kot pogojev za izvršitev pogodbe: pisanje ciklov, določene funkcije izračuna verjetnosti in podobno — vse do lastnih algoritmov digitalnega podpisa. V tem primeru gre za resnično prosto pisanje logike.
Prav tako razlikujemo proste pametne pogodbe, ki pa niso Turingove popolne. Sem lahko uvrstimo Bitcoin in Litecoin s svojim skriptom. To pomeni, da lahko v poljubnem zaporedju uporabljamo le določene operacije, vendar ne moremo pisati ciklov in lastnih algoritmov.
Poleg tega obstajajo platforme za pametne pogodbe, ki izvajajo vnaprej določene pametne pogodbe. Sem sodita Bitshares in Steemit. Bitshares ponuja vrsto pametnih pogodb za trgovanje, upravljanje računov ter upravljanje same platforme in njenih parametrov. Steemit je podobna platforma, vendar je osredotočena ne na izdajanje žetonov in trgovanje, kot Bitshares, temveč na bloganje, tj. shranjuje in obdeluje vsebino na decentraliziran način.
Med poljubne polne Turingove pogodbe spadata platforma Ethereum in RootStock, ki je še vedno v razvoju. Zato se bomo v nadaljevanju nekoliko bolj podrobno osredotočili na platformo pametnih pogodb Ethereum.
Pametne pogodbe po načinu iniciacije
Po načinu iniciacije lahko pametne pogodbe razdelimo na vsaj dve skupini: avtomatizirane in ročne (neavtomatizirane). Avtomatizirane pogodbe so značilne po tem, da se ob vseh znanih parametrih in izpolnjenih pogojih pametna pogodba v celoti izvrši samodejno, torej ne potrebuje pošiljanja dodatnih transakcij in porabe dodatne provizije pri vsakem naslednjem izvršenju. Sama platforma ima vse podatke, da izračuna, kako se bo pametna pogodba zaključila. Logika ni poljubna, temveč vnaprej določena in vse to je predvidljivo. Tako je mogoče vnaprej oceniti kompleksnost izvršitve pametne pogodbe, uporabiti neko konstantno provizijo zanjo in vsi procesi njenega izvrševanja potekajo bolj učinkovito.
Za pametne pogodbe, ki se programirajo poljubno, pa izvedba ni avtomatizirana. Za iniciacijo takšne pametne pogodbe je v bistvu na vsakem koraku potrebno ustvariti novo transakcijo, ki bo poklicala naslednjo fazo izvršitve ali naslednjo metodo pametne pogodbe, plačati ustrezno provizijo in počakati na potrditev transakcije. Izvršitev se lahko zaključi uspešno ali ne, saj je koda pametne pogodbe poljubna in se lahko pojavijo nepremostljive težave, kot so neskončne zanke, pomanjkanje nekaterih parametrov in argumentov, neobdelani izjeme in podobno.
Računi v Ethereum
Vrste računov Ethereum
Poglejmo, kakšni računi so lahko na platformi Ethereum. Obstajata le dva tipa računov in nobena druga možnost ni na voljo. Prvi tip se imenuje uporabniški račun, drugi pa račun pogodbe. Poglejmo, kakšne so razlike med njima.
Uporabniški račun upravlja izključno osebni ključ digitalnega podpisa. Lastnik računa generira svoj par ključev za digitalni podpis po algoritmu ECDSA (Algorithm za digitalni podpis z eliptično krivuljo). Spremembe stanja tega računa lahko izvedejo le transakcije, ki so podpisane s tem ključem.
Za račun pametne pogodbe je predvidena ločena logika. Upravlja se lahko le z vnaprej določenim programskim kodo, ki popolnoma opredeljuje obnašanje pametne pogodbe: kako bo razpolagala s svojimi kovanci pod določenimi pogoji, po pobudi katerega uporabnika in pod kakšnimi dodatnimi pogoji bodo ti kovanci distribuirani. Če nekateri vidiki niso predvideni s strani razvijalcev v programski kodi, lahko pride do težav. Na primer, pametna pogodba lahko doseže določeno stanje, v katerem ne sprejema pobude za nadaljnje izvajanje od katerega koli uporabnika. V tem primeru bodo kovanci dejansko zamrznjeni, ker pametna pogodba ne predvideva izhod iz tega stanja.
Kako se ustvarjajo računi na Ethereumu
V primeru uporabniškega računa lastnik samostojno generira par ključev po ECDSA. Pomembno je omeniti, da Ethereum uporablja enak algoritem za digitalni podpis in enako eliptično krivuljo kot Bitcoin, vendar se naslov izračuna nekoliko drugače. Tukaj se ne uporablja rezultat dvojnega hasiranja, kot v Bitcoinu, temveč je predvideno enkratno hasiranje z funkcijo Keccak dolžine 256 bitov. Iz pridobljene vrednosti se odseka 160 najmanjših bitov izlazne vrednosti hash-funkcije. Na koncu dobimo naslov v Ethereumu. Dejansko zajema 20 bajtov.
Dajmo da obratimo pažnju na to da se identifikator računa u Ethereum kodira u hex bez primene kontrolne sume, za razliku od Bitcoina i mnogih drugih sistema, gde se adresa kodira u sistemu sa osnovom 58 uz dodatak kontrolne sume. To znači da je potrebno pažljivo raditi sa identifikatorima računa u Ethereum-u: čak i jedna greška u identifikatoru će garantovano dovesti do gubitka novčića.
Postoji važna osobina koja se sastoji u tome da se račun korisnika na nivou zajedničke baze podataka stvara u trenutku kada primi prvu dolaznu uplatu.
U vezi sa kreiranjem računa pametnog ugovora, primenjuje se potpuno drugačiji pristup. Prvo, jedan od korisnika napiše izvorni kod pametnog ugovora, nakon čega se kod propušta kroz poseban kompajler za Ethereum platformu, dobijajući bajt kod za svoju virtuelnu mašinu Ethereum. Dobijeni bajt kod se smešta u posebno polje transakcije. Ona se ovlašćuje u ime računa inicijatora. Zatim, ova transakcija se širi mrežom i postavlja kod pametnog ugovora. Naknada za obavljanje transakcije i, shodno tome, za izvršenje ugovora se skida sa bilansa računa inicijatora.
Svaki pametni ugovor obavezno sadrži svoj konstruktor (tog ugovora). On može biti prazan, a može imati i sadržaj. Nakon što se konstruktor izvrši, kreira se identifikator računa pametnog ugovora, koristeći koji je moguće slati novčiće, pozivati određene metode pametnog ugovora itd.
Struktura Ethereum transakcije
Da bi bilo jasnije, pristupićemo razmatranju strukture Ethereum transakcije i primera koda pametnog ugovora.
Ethereum transakcija sastoji se od nekoliko polja. Prvo od njih nonce — to je neki redni broj transakcije u odnosu na sam račun koji je širi i koji je njen autor. Ovo je potrebno kako bi se razlikovali duplirani transakcije, tj. da se isključi slučaj kada se ista transakcija prihvata više puta. Zbog primene identifikatora, svaka transakcija ima jedinstvenu hash vrednost.
Zatim sledi takođe polje kao što je cena gasaTu se navaja cena, po kateri se osnovna valuta Ethereum pretvori v gas, ki se uporablja za plačilo izvajanja pametnih pogodb in dodelitev virov virtualnega stroja. Kaj to pomeni?
Pri Bitcoinu se provizije plačujejo neposredno z osnovno valuto – samim bitcoinom. To je mogoče zaradi preprostega mehanizma njihovih izračunov: plačamo strogo glede na količino podatkov, ki jih vsebuje transakcija. V Ethereum situacija ni tako preprosta, ker se je zelo težko opreti na količino podatkov transakcije. Tukaj transakcija lahko vsebuje tudi programsko kodo, ki se bo izvajala na virtualnem stroju, vsak postopek virtualnega stroja pa lahko ima različne težavnosti. Obstajajo tudi postopki, ki dodelijo pomnilnik za spremenljivke. Ti bodo imeli svojo težavnost, od katere bo odvisno plačilo za vsak postopek.
Strošek vsake operacije v ekvivalentu gasa bo konstanten. Ta se uvaja posebej zato, da se določi konstantna cena za vsak postopek. Glede na obremenitev omrežja se bo spremenila cena gasa, torej koeficient, po katerem se bo osnovna valuta pretvorila v to pomočjo enote za plačilo provizij.
Obstaja še ena posebnost transakcije v Ethereumu: bajtna koda, ki jo vsebuje za izvajanje v virtualnem stroju, se bo izvajala, dokler se ne konča z nekim rezultatom (uspeh-neuspeh) ali dokler ne zmanjka določenega števila kovancev dodeljenih za plačilo provizije. Da bi se izognili situaciji, ko se iz računa pošiljatelja v primeru napake porabi vseh kovancev za provizije (na primer, ker je v virtualnem stroju zagnan neskončen cikel), obstaja naslednje polje — start gas (pogosto ga imenujejo tudi gas limit) — določa največjo količino kovancev, ki jo je pošiljatelj pripravljen porabiti za izvedbo določene transakcije.
Naslednje polje se imenuje destination address. Sem vpišemo naslov prejemnika kovancev ali naslov konkretnega pametnega pogodb, katere metode bodo klicane. Za njim sledi polje value, kamor se vnese znesek kovancev, ki se pošlje na destination address.
Naslednje zanimivo polje se imenuje data, kamor se vključi vsa struktura. To ni ločeno polje, temveč celotna struktura, v kateri je določen koda za virtualni stroj. Sem lahko vstavite poljubne podatke — za to obstajajo posebna pravila.
In zadnje polje se imenuje potpis. V sebi vsebuje tako elektronski podpis avtorja te transakcije kot tudi javni ključ, s katerim bo ta podpis preverjen. Iz javnega ključa lahko pridobite identifikator računa pošiljatelja te transakcije, torej za edinstveno identifikacijo računa pošiljatelja v sami sistemu. Po strukturi transakcije smo ugotovili glavne informacije.
Primer kode pametne pogodbe v Solidity
Poglejmo zdaj podrobneje najpreprostejšo pametno pogodbo na primeru.
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);
}
}Zgornji je poenostavljena izvorna koda, ki lahko hrani kovance uporabnikov in jih vrača na zahtevo.
Torej, obstaja pametna pogodba Bank, ki izvaja naslednje funkcije: nabira kovance na svojem saldu, torej ob potrditvi transakcije in postavitvi te pametne pogodbe se ustvari nov račun, ki lahko vsebuje kovance na svojem saldu; beleži uporabnike in razdelitev kovancev med njimi; ima več metod za upravljanje saldo, torej obstaja možnost dopolnjenja, umika in preverjanja saldo uporabnika.
Poglejmo vsako vrstico izvorne kode. V tej pogodbi so konstantna polja. Eno izmed njih, tipa address, se imenuje owner. Tukaj pogodba zapomni naslov uporabnika, ki je ustvaril to pametno pogodbo. Nadalje, obstaja dinamična struktura, ki ohranja ustreznosti med naslovi uporabnikov in saldom.
Nato sledi metoda Bank — imenuje se tako kot pogodba. Tako je njen konstrukt. Tukaj se spremenljivki owner dodeli naslov tistega, ki je postavil to pametno pogodbo v omrežju. To je edina stvar, ki se zgodi v tem konstruktorju. Torej, msg v tem primeru so tisti podatki, ki so bili poslani virtualnemu stroju skupaj s transakcijo, ki vsebuje vso kodo te pogodbe. Tako je msg.sender avtor te transakcije, ki postavlja to kodo. On bo lastnik pametne pogodbe.
Metoda deposit omogoča prenos določenega števila kovancev na račun pogodbe preko transakcije. V tem primeru pametna pogodba, ob prejemu teh kovancev, ohrani le-te na svojem saldo računu, a v strukturo balances zapiše, kdo je bil pošiljatelj teh kovancev, da ve, komu pripadajo.
Naslednja metoda se imenuje withdraw in sprejema en parameter — znesek kovancev, ki ga želi nekdo dvigniti iz te banke. Tukaj se preveri, ali ima uporabnik, ki kliče to metodo, dovolj kovancev na svojem računu, da jih pošlje. Če jih ima dovolj, pametna pogodba vrne klicatelju zahtevani znesek kovancev.
Nato sledi metoda za preverjanje trenutnega stanja uporabnika. Tisti, ki kliče to metodo, bo uporabljen za pridobitev tega stanja v pametni pogodbi. Omeniti je treba, da je modifikator te metode — view, kar pomeni, da metoda ne spreminja spremenljivk svoje klase in je dejansko le metoda za branje. Za klic te metode se ne ustvari ločena transakcija, provizija se ne plača, vsa izračunavanja pa se izvedejo lokalno, po čemer uporabnik prejme rezultat.
Metoda kill je namenjena uničenju stanja pametne pogodbe. Tu je dodana še dodatna preverba, ali je klicatelj te metode lastnik pogodbe. Če je, se pogodba samouničijo, funkcija uničenja pa sprejema en parameter — identifikator računa, na katerega bo pogodba poslala vse kovance, ki so ostali na njenem stanju. V tem primeru bodo preostali kovanci samodejno poslani na naslov lastnika pogodbe.
Kako deluje popoln vozlišče omrežja Ethereum?
Shematsko si oglejmo, kako poteka izvajanje takšnih pametnih pogodb na platformi Ethereum in kako deluje popoln vozlišče omrežja.
Popolno vozlišče omrežja Ethereum mora imeti vsaj štiri module.
Prvi, kot pri vsakem decentraliziranem protokolu, je P2P networking module — modul za omrežno povezavo in delo z drugimi vozlišči, kjer poteka izmenjava blokov, transakcij, informacij o drugih vozliščih. To je tradicionalna komponenta za vse decentralizirane kriptovalute.
Nato imamo modul za shranjevanje blockchain podatkov, obdelavo, izbiro prednostne veje, dodajanje blokov, odklapljanje blokov, preverjanje teh blokov itd.
Tretji modul se imenuje EVM (Ethereum virtual machine) — to je tisto, virtualni stroj, ki sprejema bajtkodo iz Ethereum transakcij. Ta modul sprejme trenutno stanje določenega računa in izvede spremembe njegovega stanja na podlagi prejetega bajtkoda. Različica virtualnega stroja na vsakem vozlišču omrežja mora biti enaka. Izračuni potekajo na vsakem vozlišču Ethereum povsem enako, vendar se izvajajo asinkrono: nekdo prej preveri in sprejme to transakcijo, torej izvede vsebino v njej, nekdo kasneje. Tako, ko je transakcija ustvarjena, se širijo po omrežju, vozlišča jo sprejmejo in med verifikacijo se prav tako, kot pri Bitcoinu, izvaja Bitcoin Script, tu pa se izvršuje bajtkoda virtualnega stroja.
Transakcija se šteje za preverjeno, če je bila celotna vsebina v njej izvedena, je bilo ustvarjeno novo stanje določenega računa in to stanje je shranjeno, dokler ni jasno, ali je bila ta transakcija uporabljena ali ne. Če je bila transakcija uporabljena, se to stanje šteje ne samo za izvedeno, temveč že tudi za aktualno. Obstaja baza podatkov, ki hrani stanje vsakega računa za vsako vozlišče omrežja. Ker se vsi izračuni izvajajo enako in je stanje blockchaina enako, bo tudi baza podatkov, ki vsebuje stanja vseh računov, enaka za vsako vozlišče.
Mit in omejitve pametnih pogodb
Kar zadeva omejitve, ki obstajajo za platforme pametnih pogodb, podobne Ethereum, lahko navedemo naslednje:
- izvajanje kode;
- dodelitev pomnilnika;
- podatki blockchain;
- pošiljanje plačil;
- ustvarjanje nove pogodbe;
- klic drugih pogodb.
Poglejmo omejitve, ki jih nalaga virtualni stroj, in razblinimo nekaj mitov o pametnih pogodbah. Na virtualnem stroju, ki ni le v Ethereum, ampak tudi v podobnih platformah, je mogoče izvajati resnično poljubne logične operacije, torej napisati kodo, ki bo tam izvajana, in dodatno dodeljevati pomnilnik. Vendar je provizija plačana ločeno za vsako operacijo in za vsako dodatno dodeljeno enoto pomnilnika.
Nadalje, virtualni stroj lahko bere podatke iz blokchain baze podatkov, da bi te podatke uporabil kot sprožilec za izvajanje določene logike pametnih pogodb. Virtualni stroj lahko ustvarja in pošilja transakcije, lahko ustvarja nove pogodbe in kliče metode drugih pametnih pogodb, ki so že objavljene v mreži: obstajajo, dostopne itd.
Najbolj razširjen mit je, da pametne pogodbe Ethereum lahko uporabljajo informacije iz kakršnih koli internetnih virov v svojih pogojih. Resnica je, da virtualni stroj ne more poslati omrežnega zahtevka kateremu koli zunanjemu informacijskemu viru na internetu. To pomeni, da ni mogoče napisati takšne pametne pogodbe, ki bi razdeljevala vrednost med uporabniki glede na to, kakšno vreme je zunaj, kdo je zmagal na nekem prvenstvu, ali na podlagi drugih dogodkov v zunanjih svetovih, ker informacij o teh dogodkih preprosto ni v bazi podatkov same platforme. To pomeni, da v blockchainu ni nič glede tega. Če ti podatki tam ne pridejo, potem virtualni stroj ne more uporabiti teh podatkov kot sprožilcev.
Slabosti Ethereuma
Poglejmo si glavne pomanjkljivosti. Prva pomanjkljivost je, da pri načrtovanju, razvoju in testiranju pametnih pogodb v Ethereum obstajajo določene težave (v Ethereumu za pisanje pametnih pogodb uporabljajo jezik Solidity). V praksi se izkaže, da zelo velik odstotek vseh napak izhaja iz človeškega faktorja. To velja tudi za že napisane pametne pogodbe v Ethereumu, ki imajo povprečno ali višjo zapletenost. Medtem ko je pri preprostih pametnih pogodbah verjetnost napake nizka, se pri zapletenih pametnih pogodbah zelo pogosto pojavijo napake, ki lahko privedejo do kraje sredstev, zamrznitve sredstev, uničenja pametnih pogodb na nepričakovan način itd. Znano je že veliko takih primerov.
Druga pomanjkljivost je, da sama virtualna naprava ni idealna, saj jo tudi ljudje pišejo. Izvaja lahko poljubne ukaze, kar pomeni, da obstajajo ranljivosti: določene ukaze je mogoče konfigurirati na način, ki bo privedel do nepričakovanih posledic. To je zelo zapleteno področje, vendar že obstaja več raziskav, ki kažejo, da te ranljivosti obstajajo v trenutni različici omrežja Ethereum in lahko privedejo do napak v delovanju številnih pametnih pogodb.
Še ena velika težava, ki jo lahko štejemo za pomanjkljivost. Ta se nanaša na to, da je mogoče na praktičen ali tehnični način priti do ugotovitve, da če se zakompilira bajtna koda pogodbe, ki se bo izvajala na virtualni napravi, lahko določimo nek specifičen zaporedje operacij. Ko se te operacije izvajajo skupaj, močno obremenijo virtualno napravo in jo upočasnijo neproporcionalno tistemu proviziji, ki je bila plačana za izvajanje teh operacij.
V preteklosti je bil že tak čas razvoja Ethereuma, ko so mnogi fantje, ki so se podrobno ukvarjali z delovanjem virtualnega stroja, odkrili takšne ranljivosti. Dejansko so transakcije plačevale zelo nizko provizijo, a so precej upočasnile delovanje celotne mreže. Te težave se zelo težko rešujejo, saj jih je treba, prvič, determinirati, drugič, prilagoditi ceno za izvedbo teh operacij in, tretjič, izvesti hard fork, kar pomeni posodobitev vseh vozlišč mreže na novo različico programske opreme, nato pa hkratno aktiviranje teh sprememb.
Kar zadeva Ethereum, je bilo opravljenih veliko študij, pridobljenih je bilo zelo veliko praktičnih izkušenj: tako pozitivnih kot negativnih, vendar kljub temu ostajajo zapleti in ranljivosti, s katerimi se bo še treba boriti.
Torej, tematski del članka je zaključen, preidimo na vprašanja, ki se pogosto pojavljajo.
Pogosto zastavljena vprašanja
— Če vse strani veljavnega pametnega pogodbe želijo spremeniti pogoje, ali lahko prek večpodpisne pogodbe prekličejo to pametno pogodbo in nato ustvarijo novo pametno pogodbo z posodobljenimi pogoji njene izvedbe?
Tu bo odgovor dvojen. Zakaj? Ker iz ene strani je pametna pogodba enkrat določena in ne predvideva sprememb, iz druge strani pa lahko ima vnaprej zapisano logiko, ki predvideva popolno ali delno spremembo določenih pogojev. To pomeni, da če želite kaj spremeniti v svoji pametni pogodbi, morate vnaprej določiti pogoje, pod katerimi lahko posodobite te pogoje. Samo tako previdno lahko organizirate posodobitev pogodbe. Ampak tudi tu se lahko zgodi kakšna napaka in dobite ustrezno ranljivost. Zato je take stvari treba zelo podrobno in temeljito načrtovati in testirati.
— Kaj pa, če posrednik sklene dogovor z eno od udeleženk: escrow ali pametno pogodbo? Ali je posrednik obvezen v pametni pogodbi?
Mediátor nije obavezan u pametnom ugovoru. Može biti odsutan. Ako u slučaju escrow mediátor uđe u dogovor s jednom od strana, tada ta shema drastično gubi svu svoju vrednost. Stoga se mediatori biraju na način da im veruju sve strane uključene u ovaj proces. Shodno tome, jednostavno nećete prenositi novčiće na multisignature adresu onom mediadoru kojem ne verujete.
— Da li je moguće jednim Ethereum transakcijom preneti mnogo različitih tokena sa svoje adrese na različite ciljne adrese, na primer, adrese berzi gde se trguje tim tokenima?
To je dobro pitanje koje se tiče modela transakcija Ethereum i njegove razlike od modela Bitcoin. I razlika je radikalna. Ako u modelu transakcije Ethereum jednostavno prenosite novčiće, oni se prenose samo s jedne adrese na drugu, bez povraćaja, već konkretna suma koju ste naveli. Drugim rečima, to nije model neiskorišćenih izlaza (UTXO), već model računa i odgovarajućih saldoa. Teoretski je moguće poslati jednom transakcijom nekoliko različitih tokena, ako napišete pametan pametan ugovor, ali ćete i dalje morati uraditi mnogo transakcija, stvoriti ugovor, zatim preneti njemu tokene i novčiće, a zatim pozvati odgovarajuću metodu. To zahteva trud i vreme, shodno tome, u praksi to tako ne funkcioniše i sve isplate u Ethereum-u se vrše odvojenim transakcijama.
— Jedan od mitova o platformi Ethereum je da je nemoguće opisati takve uslove koji zavise od podataka spoljnog internet resursa, šta da radimo onda?
Rešenje je u tome da sam pametan ugovor može predvideti jednog ili više takozvanih pouzdanih oracle-a, koji prikupljaju podatke o stanju stvari u spoljnjem svetu i prenose ih u pametne ugovore putem posebnih metoda. Sam ugovor smatra istinitim one podatke koje primi od pouzdanih strana. Za veću pouzdanost jednostavno se bira veća grupa oracle-a i minimizira rizik od njihovog dogovora. Sam ugovor može ignorisati podatke od oracle-a koji su u suprotnosti sa većinom.
Ovoj temi posvećena je jedna od predavanja online kursa o Blockchain-u — “”.
Izvor: habr.com
