🥇Uvod u pametne ugovore

U ovom članku razmotrit ćemo što su pametni ugovori, koje vrste postoje, upoznati se s različitim platformama za pametne ugovore, njihovim značajkama, a također ćemo razgovarati o tome kako funkcioniraju i koje prednosti mogu nositi. Ovaj materijal bit će vrlo koristan za čitatelje koji nisu dovoljno upoznati s temom pametnih ugovora, ali žele bolje razumjeti.

Obični ugovor vs. pametni ugovor

Prije nego što se upustimo u detalje, razjasnimo na primjeru razlike između običnog ugovora, koji se zapisuje na papiru, i pametnog ugovora, koji je predstavljen u digitalnom obliku.

Kako je to funkcioniralo prije pojave pametnih ugovora? Zamislite grupu ljudi koja želi postaviti neka pravila i uvjete raspodjele vrijednosti, kao i odrediti određeni mehanizam za osiguranje provođenja te raspodjele prema zadanim pravilima i uvjetima. Tada su se okupljali, sastavljali papir na kojem su zapisivali svoje identifikacijske podatke, uvjete, uključene vrijednosti, stavljali datum i potpisivali. Ovaj ugovor bi također ovjerila pouzdana strana, poput bilježnika. Nakon toga, ti su ljudi odlazili svatko na svoju stranu sa svojom papirnom kopijom takvog ugovora i počinjali provoditi određene radnje koje nisu nužno odgovarale samom ugovoru, to jest, radili su jedno, a na papiru je bila ovjerena obveza da trebaju raditi sasvim nešto drugo. I kako izaći iz te situacije? U suštini, netko od sudionika grupe trebao bi uzeti taj papir, prikupiti neke dokaze, otići na sud i zatražiti usklađivanje između ugovora i stvarnih radnji. Prilično često je teško postići pravedno izvršenje tog ugovora, što dovodi do neugodnih posljedica.

Što se može reći o pametnim ugovorima? Oni u sebi objedinjuju mogućnost pisanja uvjeta ugovora i mehanizam stroge provedbe. Ako su uvjeti postavljeni i potpisana je odgovarajuća transakcija ili zahtjev, tada nakon prihvaćanja tog zahtjeva ili transakcije više nije moguće promijeniti uvjete ili utjecati na njihovu provedbu.

Postoji jedan validator ili cijela mreža, kao i baza podataka koja pohranjuje sve pametne ugovore koji su primljeni na izvršenje u strogo hronološkom redoslijedu. Također je važno da ta baza podataka sadrži sve uvjete okidače za izvršenje pametnog ugovora. Osim toga, ona mora uzeti u obzir onu vrijednost čija je distribucija opisana u ugovoru. Ako se radi o nekoj digitalnoj valuti, ta baza podataka mora je uzeti u obzir.

Drugim riječima, validatori pametnih ugovora moraju imati pristup svim podacima s kojima upravlja pametni ugovor. Na primjer, jedna baza podataka treba se koristiti za praćenje istovremeno digitalnih valuta, stanja korisnika, transakcija korisnika i vremenskih oznaka. Tada uvjet u pametnom ugovoru može biti stanje korisnika u određenoj valuti, nastup nekog vremena ili činjenje neke transakcije, ali ne više od toga.

Definicija pametnog ugovora

U osnovi, sama terminologija je izumio istraživač Nick Szabo i prvi put primijenjena je 1994. godine, a dokumentirana je 1997. godine u članku koji opisuje samu ideju pametnih ugovora.

Pametni ugovori podrazumijevaju da se provodi neka automatizacija raspodjele vrijednosti koja može ovisiti samo o onim uvjetima koji su unaprijed postavljeni. U najjednostavnijem obliku to izgleda kao ugovor sa strogo definiranim uvjetima, koji potpisuju određene strane.

Pametni ugovori su namijenjeni minimiziranju povjerenja trećim stranama. Ponekad se potpuno isključi središnji organ odlučivanja na kojem sve ovisi. Osim toga, za takve ugovore je lakše provesti reviziju. To je posljedica nekih karakteristika dizajniranja takvog sustava, ali najčešće pod pametnim ugovorom razumijemo decentralizirano okruženje i postojanje funkcija koje omogućuju svakome tko želi analizirati bazu podataka i provesti potpunu reviziju izvršenja ugovora. Na taj način jamči se zaštita od promjena podataka unazad koje će dovesti do promjena u izvršenju samog ugovora. Digitalizacija većine procesa prilikom kreiranja i pokretanja pametnog ugovora često pojednostavljuje tehnologiju i troškove njihove realizacije.

Jednostavan primjer — Escrow usluga

Pogledajmo vrlo jednostavan primjer. On će pomoći da se približite razumijevanju funkcionalnosti pametnih ugovora, kao i da bolje razumijete u kojim se situacijama oni mogu primijeniti.

To se također može realizirati korištenjem Bitcoina, iako se Bitcoin trenutno teško može nazvati punopravnom platformom za pametne ugovore. Dakle, imamo nekog kupca i imamo internetsku trgovinu. Kupac želi kupiti monitor u toj trgovini. U najjednostavnijem slučaju, kupac odabire i šalje uplatu, a internetska trgovina je prima, potvrđuje, nakon čega šalje robu. Međutim, u ovoj situaciji postoji potreba za velikim povjerenjem — kupac mora u potpunosti vjerovati internetskoj trgovini u vezi s cijenom monitora. Budući da internetska trgovina može imati nisku reputaciju u očima kupca, postoji rizik da iz nekog razloga, nakon zaprimanja uplate, trgovina odbije uslugu i ne pošalje robu kupcu. Stoga se kupac postavlja pitanje (a prema tome se i internetska trgovina pita) što se može primijeniti u ovom slučaju kako bi se minimizirali takvi rizici i učinile slične transakcije pouzdanijima.

U slučaju Bitcoina, mogu se pružiti mogućnosti kupcu i prodavaču da neovisno biraju posrednika. Postoji mnogo ljudi koji se bave rješavanjem sporova. I naši sudionici mogu izabrati jednog posrednika iz zajedničkog popisa kojem bi oboje povjeravali. Zajedno stvaraju multisignature adresu 2 od 3, gdje postoje tri ključa i potrebna su dva potpisa bilo koja dva ključa kako bi potrošili novčiće s te adrese. Jedan ključ pripada kupcu, drugi — internetskoj trgovini, a treći — posredniku. Na takvu multisignature adresu kupac će poslati iznos potreban za plaćanje monitora. Sada, kada prodavač vidi da su novci na neko vrijeme blokirani na multisignature adresi koja ovisi o njemu, slobodno može poslati monitor poštom.

Nakon toga, kupac prima paket, pregleda robu i donosi konačnu odluku o kupnji. Može biti potpuno zadovoljan pruženom uslugom i potpisati transakciju svojim ključem, pri čemu prenosi kovanice s multisignature adrese prodavatelju, ili može biti nezadovoljan nečim. U drugom slučaju, kontaktira posrednika kako bi sastavio alternativnu transakciju koja će drugačije raspodijeliti te kovanice.

Recimo da je monitor stigao malo ogreban i da kabel za povezivanje s računalom nije bio uključen u paket, iako je na web stranici internetske trgovine pisalo da bi kabel trebao biti u paketu. Tada kupac prikuplja dokaze potrebne da dokaže posredniku da je prevaren u ovoj situaciji: snima screenshotove web stranice, fotografira račun s pošte, fotografira ogrebotine na monitoru i pokazuje da je pečat bio slomljen i kabel je uklonjen. Internetska trgovina, s druge strane, također prikuplja svoje dokaze i predaje ih posredniku.

Posrednik je zainteresiran zadovoljiti i nezadovoljstvo kupca i interese internetske trgovine (kasnije će biti jasno zašto). Sastavlja transakciju u kojoj će se kovanice s multisignature adrese potrošiti u određenom omjeru između kupca, internetske trgovine i posrednika, budući da zadržava dio kao naknadu za svoj rad. Recimo da će 90% cijelog iznosa ići prodavatelju, 5% posredniku i 5% odštete kupcu. Ovu transakciju posrednik potpisuje svojim ključem, ali još uvijek ne može biti primijenjena jer je potreban još jedan potpis, a postoji samo jedan. Takvu transakciju šalje i kupcu i prodavatelju. Ako barem jedan od njih bude zadovoljan takvom mogućnošću raspodjele kovanica, transakcija će biti dodatno potpisana i distribuirana u mrežu. Za njezinu validaciju dovoljno je da se jedan od sudionika dogovori s predlogom posrednika.

Važno je odabrati posrednika kojem oboje sudionika vjeruje. U tom slučaju, on će djelovati neovisno od interesa jednog ili drugog i objektivno procijeniti situaciju. Ako posrednik ne ponudi raspodjelu novčića koja bi zadovoljila barem jednog sudionika, tada, dogovarajući se, i kupac i internetska trgovina mogu prebaciti novčiće na novu multisig adresu, stavljajući svoja dva potpisa. Nova multisig adresa bit će sastavljena s drugim posrednikom koji će možda biti kompetentniji i ponuditi bolju opciju.

Primjer s hostelom i hladnjakom

Pogledajmo složeniji primjer koji jasnije prikazuje mogućnosti pametnog ugovora.

Pretpostavimo da su trojica momaka nedavno uselili u istu sobu u hostelu. Svi se zajedno žele dogovoriti o kupnji hladnjaka koji će zajednički koristiti. Jedan od njih ponudio je da prikupi potrebnu svotu novca za kupnju hladnjaka i pregovara s prodavačem. Međutim, oni se međusobno poznaju tek kratko i nemaju dovoljno povjerenja. Očigledno je da dvojica od njih riskiraju kada daju novac trećem. Također, moraju postići dogovor o izboru prodavača.

Mogu koristiti escrow uslugu, odnosno odabrati posrednika koji će nadzirati izvršenje posla i riješiti sporna pitanja ako se tako nešto pojavi. Tada, dogovarajući se, sastavljaju pametni ugovor i u njemu definiraju određene uvjete.

Prvi uvjet je da do određenog trenutka, na primjer, unutar jednog tjedna, na odgovarajući račun pametnog ugovora moraju stići tri uplate s određenih adresa na određeni iznos. Ako se to ne dogodi, pametni ugovor prestaje s izvršenjem i vraća novčiće svim sudionicima. Ako je uvjet ispunjen, tada se postavljaju vrijednosti identifikatora prodavača i posrednika, a također se provjerava uvjet da su svi sudionici saglasni s izborom prodavača i posrednika. Kada su svi uvjeti ispunjeni, sredstva će se dalje prebaciti na navedene adrese. Ovaj pristup može zaštititi sudionike od prevara s bilo koje strane i u potpunosti isključuje potrebu za povjerenjem.

Na ovom primjeru vidimo sam princip da takva mogućnost postavljanja parametara za izvršenje svakog uvjeta omogućava stvaranje sustava bilo koje složenosti i dubine ugnježdenih razina. Štoviše, prvo u pametnom ugovoru može se odrediti prvi uvjet, a tek nakon njegova ispunjenja postavljati parametre za sljedeći uvjet. Drugim riječima, formalno se zapisuje uvjet, a parametre za njega već se mogu postavljati tijekom njegova izvršenja.

Klasifikacija pametnih ugovora

Za klasifikaciju se mogu postavljati različite grupe kriterija. Međutim, u trenutnom razvoju tehnologija aktualne su četiri od njih.

Pametne ugovore možemo razlikovati prema okruženju izvršenja, koje može biti ili centralizirano ili decentralizirano. U slučaju decentralizacije imamo mnogo veću neovisnost i otpornost na kvarove tijekom izvršenja pametnih ugovora.

Također ih možemo razlikovati prema procesu postavljanja i izvršavanja uvjeta: mogu biti proizvoljno programabilni, ograničeni ili unaprijed definirani, tj. strogo tipizirani. Kada na platformi pametnih ugovora postoji samo 4 određena pametna ugovora, parametre im možemo postavljati proizvoljno. Prema tome, njihovo postavljanje je puno lakše: biramo ugovor s popisa i predajemo parametre.

Prema metodi iniciranja postoje automatizirani pametni ugovori, što znači da se sami izvršavaju kad se ispune određeni uvjeti, a postoje i ugovori u kojima su uvjeti zadani, ali platforma ne provjerava automatski njihovo ispunjenje, te ih je potrebno posebno inicirati.

Osim toga, pametni ugovori se razlikuju prema razini privatnosti. Mogu biti potpuno otvoreni, djelomično otvoreni ili potpuno povjerljivi. Posljednje znači da vanjski promatrači ne vide uvjete pametnih ugovora. Međutim, tema privatnosti je vrlo opsežna i bolje ju je razmotriti odvojeno od ovog članka.

U nastavku ćemo detaljnije obraditi prva tri kriterija kako bismo unijeli više jasnoće u razumijevanje ove teme.

Pametni ugovori po sredini izvršavanja

Prema sredini izvršavanja razlikujemo centralizirane i decentralizirane platforme pametnih ugovora. U slučaju centraliziranih digitalnih ugovora koristi se jedna usluga, gdje postoji samo jedan validator i može postojati usluga izrade sigurnosnih kopija i obnavljanja koja se također centralizirano upravlja. Postoji jedna baza podataka koja pohranjuje svu potrebnu informaciju za postavljanje uvjeta pametnog ugovora i raspodjelu te vrijednosti koja se evidentira u toj bazi podataka usluge. Takva centralizirana usluga ima klijenta koji postavlja uvjete određenim zahtjevima i koristi takve ugovore. Budući da je platforma centralizirana, mehanizmi autentikacije mogu biti manje pouzdani nego u kriptovalutama.

Kao primer možemo uzeti pružatelje mobilnih usluga (različite mobilne operatore). Pretpostavimo da određeni operator vodi na svojim poslužiteljima centralizirano praćenje prometa, koji se može prenositi u različitim formatima, na primjer: u obliku glasovnih poziva, slanja SMS poruka, prometa mobilnog interneta i prema različitim standardima, a takođe vodi evidenciju sredstava na računima korisnika. Prema tome, pružatelj mobilnih usluga može sastaviti ugovore za praćenje pruženih usluga i njihovo plaćanje s različitim uvjetima. U takvom slučaju lako se postavljaju uvjeti poput “pošalji SMS s određenim kodom na određeni broj i dobiti ćeš određene uvjete raspodjele prometa.”

Može se navesti još jedan primjer: tradicionalne banke s naprednom funkcionalnošću internetskog bankarstva i vrlo jednostavni ugovori poput redovitog plaćanja, automatske konverzije dolaznih uplate, automatskog knjiženja postotka na određeni račun itd.

Kada govorimo o pametnim ugovorima s decentraliziranim okruženjem izvršavanja, tada imamo grupu validatora. U idealnom slučaju, validator može postati tko god. Uz protokol sinkronizacije baze podataka i postizanje konsenzusa, imamo neku zajedničku bazu podataka koja će sada čuvati sve transakcije s strogo opisanim ugovorima, a ne neke uvjetne zahtjeve čiji se formati često mijenjaju i za koje nema otvorene specifikacije. Ovdje će transakcije sadržavati upute za izvršenje ugovora u skladu sa strogom specifikacijom. Ta specifikacija je otvorena i stoga sami korisnici platforme mogu provoditi reviziju i validirati pametne ugovore. Ovdje vidimo da decentralizirane platforme nadmašuju centralizirane u neovisnosti i otpornosti na kvarove, ali je njihovo projektiranje i održavanje mnogo složenije.

Pametni ugovori prema načinu postavljanja i izvršavanja uvjeta

Sada ćemo detaljnije razraditi kako se pametni ugovori mogu razlikovati prema načinu postavljanja i izvršavanja uvjeta. Ovdje ćemo obratiti pažnju na pametne ugovore koji su programirani proizvoljno i puni su Tjuringske potpunosti. Pametan ugovor pun Tjuringske potpunosti omogućuje postavljanje gotovo bilo kakvih algoritama kao uvjeta izvršenja ugovora: pisanje petlji, funkcija izračuna vjerojatnosti i slično — sve do vlastitih algoritama elektroničkog potpisa. U ovom slučaju, radi se o doista proizvoljnom pisanju logike.

Također se ističu proizvoljni pametni ugovori, ali ne puni Tjuringske potpunosti. Ovdje se mogu svrstati Bitcoin i Litecoin sa svojim skriptom. To znači da se u proizvoljnom redoslijedu mogu koristiti samo određene operacije, ali već nije moguće napisati petlje i vlastite algoritme.

Osim toga, postoje platforme pametnih ugovora koje implementiraju unaprijed postavljene pametne ugovore. To uključuje Bitshares i Steemit. Bitshares ima niz pametnih ugovora za trgovinu, upravljanje računima, upravljanje samom platformom i njezinim parametrima. Steemit je slična platforma, ali je usmjerena ne na izdavanje tokena i trgovinu poput Bitshares-a, već na vođenje blogova, tj. pohranjuje i obrađuje sadržaj na decentraliziran način.

Među proizvoljnim potpuno Turingovim ugovorima možemo nabrojiti platformu Ethereum i RootStock, koja je još uvijek u fazi razvoja. Stoga ćemo se ubuduće malo detaljnije osvrnuti na platformu pametnih ugovora Ethereum.

Pametni ugovori prema načinu iniciranja

Prema načinu iniciranja, pametne ugovore možemo podijeliti u minimalno dvije grupe: automatizirane i ručne (neautomatizirane). Automatizirane se karakteriziraju time da se, uz sve poznate parametre i ostvarene uvjete, pametni ugovor u potpunosti izvršava automatski, odnosno ne zahtijeva slanje dodatnih transakcija i trošenje dodatne naknade prilikom svakog sljedećeg izvršenja. Sama platforma ima sve podatke potrebne za izračun kako će se pametni ugovor završiti. Logika nije proizvoljna, već unaprijed zadana i sve se to može predvidjeti. Dakle, unaprijed se može procijeniti složenost izvršenja pametnog ugovora, koristiti neku konstantnu naknadu za njega i svi procesi njegove realizacije odvijaju se učinkovitije.

Za pametne ugovore koji se programiraju proizvoljno, izvršenje nije automatizirano. Za iniciranje takvog pametnog ugovora zapravo na svakom koraku treba kreirati novu transakciju koja će pozvati sljedeću fazu izvršenja ili sljedeću metodu pametnog ugovora, platiti odgovarajuću naknadu i čekati potvrdu transakcije. Izvršenje može završiti uspješno ili ne, jer je kod pametnog ugovora proizvoljan i mogu se pojaviti nepredvidivi trenuci, kao što su beskonačne petlje, neadekvatnost nekih parametara i argumenata, neobrađene iznimke itd.

Računi u Ethereum-u

Tipovi računa Ethereum

Razmotrit ćemo koje vrste računa mogu postojati na platformi Ethereum. Postoje samo dva tipa računa i nema drugih opcija. Prvi tip naziva se korisnički račun, a drugi — račun ugovora. Proučimo u čemu se razlikuju.

Korisnički račun upravlja se isključivo osobnim ključem elektroničkog potpisa. Vlasnik računa generira svoj par ključeva za elektronički potpis pomoću ECDSA algoritma (Algoritam elektroničkog potpisa s eliptičnom krivuljom). Promjenu stanja ovog računa mogu izvršiti samo transakcije potpisane tim ključem.

Za račun pametnog ugovora predviđena je posebna logika. On se može upravljati isključivo pomoću unaprijed definirane programske logike, koja potpuno određuje ponašanje pametnog ugovora: kako će raspolagati svojim tokenima u određenim okolnostima, po inicijativi kojeg korisnika i pod kojim dodatnim uvjetima će se ti tokeni distribuirati. Ako neki aspekti nisu predviđeni od strane programera u programskoj logici, mogu nastati problemi. Na primjer, pametni ugovor može doći u određeno stanje u kojem ne prihvaća inicijaciju daljnjeg izvršavanja ni od jednog korisnika. U tom slučaju tokeni će zapravo biti „zaključani”, jer pametni ugovor ne predviđa izlaz iz tog stanja.

Kako se kreiraju računi u Ethereum-u

U slučaju korisničkog računa, vlasnik samostalno generira par ključeva koristeći ECDSA. Važno je napomenuti da Ethereum koristi za elektronički potpis točno isti algoritam i točno istu eliptičnu krivulju kao i Bitcoin, ali se adresa izračunava malo drugačije. Ovdje se ne koristi rezultat dvostrukog heširanja, kao u Bitcoinu, već je predviđeno jedinstveno heširanje funkcijom Keccak na 256-bitnoj dužini. Od dobivenog vrijednosti odsečeni su niži bitovi, a to su konkretno 160 nižih bita izlazne vrijednosti heš-funkcije. Na kraju dobivamo adresu u Ethereum-u. Ona zapravo zauzima 20 bajtova.

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 sistem brojanja sa bazom 58 uz dodatak kontrolne sume. To znači da treba pažljivo raditi s identifikatorima računa u Ethereum: čak i jedna greška u identifikatoru garantovano dovodi do gubitka kovanica.

Postoji važna karakteristika, a to je da se račun korisnika na nivou zajedničke baze podataka stvara u trenutku kada primi prvu dolaznu uplatu.

U vezi s kreiranjem računa pametnog ugovora primenjuje se potpuno drugačiji pristup. U početku jedan od korisnika piše izvorni kod pametnog ugovora, nakon čega se kod propušta kroz specijalni kompilator za platformu Ethereum, dobijajući bajt kod za vlastitu virtuelnu mašinu Ethereum. Dobijeni bajt kod se postavlja u specijalno polje transakcije. Ona se ovjerava u ime računa inicijatora. Nakon toga, ta transakcija se širi mrežom i postavlja kod pametnog ugovora. Naknada za sprovođenje transakcije i, shodno tome, za izvršenje ugovora skida se sa bilansa računa inicijatora.

Svaki pametan ugovor obavezno sadrži svoj konstruktora (tog ugovora). On može biti prazan ili može imati sadržaj. Nakon što se konstruktor izvrši, kreira se identifikator računa pametnog ugovora, koristeći koji se mogu slati kovanice, 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 se sastoji od više polja. Prvo od njih je nonce — to je neki redni broj transakcije u odnosu na sam račun koji je širi i autor je iste. To je potrebno da bi se razlikovali duplikati transakcija, tj. da se isključi slučaj kada se ista transakcija prihvati dva puta. Zahvaljujući primeni identifikatora, svaka transakcija ima jedinstvenu heš vrednost.

Dalje sledi takvo polje kao cena gasaOvdje se navodi cijena po kojoj se osnovna valuta Ethereum konvertira u gas, koji se koristi za plaćanje izvršenja pametnog ugovora i alokaciju resursa virtualne mašine. Što to znači?

U Bitcoinu se naknade plaćaju direktno osnovnom valutom — samim bitcoinom. To je moguće zahvaljujući jednostavnom mehanizmu njihove kalkulacije: plaćamo strogo volumen podataka koji se sadrži u transakciji. U Ethereum situacija je složenija, jer je teško osloniti se na volumen podataka transakcije. Ovdje transakcija može sadržavati i programski kod koji će se izvršavati na virtualnoj mašini, a svaka operacija virtualne mašine može imati različitu složenost. Postoje također operacije koje alociraju memoriju za varijable. One će imati svoju složenost, koja će utjecati na plaćanje za svaku operaciju.

Cijena svake operacije u ekvivalentu gasa bit će konstantna. Ona se uvodi posebno kako bi se odredila konstantna cijena svake operacije. Ovisno o opterećenju na mreži, mijenjat će se i cijena gasa, što je koeficijent prema kojem će se osnovna valuta konvertirati u ovu pomoćnu jedinicu za plaćanje naknade.

Postoji još jedna posebnost transakcije u Ethereum: bajt-kod koji ona sadrži za izvršenje u virtualnoj mašini izvršava se sve dok ne završi s nekim rezultatom (uspjeh-neuspjeh) ili dok ne istekne određena količina novčića dodijeljenih za plaćanje naknade. Upravo kako bi se izbjegla situacija u kojoj sa računa pošiljaoca u slučaju neke greške potroše svi novčići na naknadu (na primjer, pokrenuta je neka beskonačna petlja u virtualnoj mašini), postoji sljedeće polje — start gas (često se naziva gas limit) — ono određuje maksimalnu količinu novčića koje je pošiljaoc spreman potrošiti na izvršenje određene transakcije.

Sljedeće polje naziva se destination address. Ovdje se upisuje adresa primatelja novčića ili adresa konkretnog pametnog ugovora čije će metode biti pozivane. Nakon njega slijedi polje value, u koje se upisuje iznos novčića koji se šalje na destination address.

Zatim se nalazi zanimljivo polje pod nazivom data, gdje se nalazi cijela struktura. To nije odvojeno polje, već cijela struktura u kojoj se definira kod za virtualnu mašinu. Ovdje se mogu smjestiti proizvoljni podaci — za to postoje posebna pravila.

I posljednje polje se zove potpis. Ono u sebi sadrži i elektronički potpis autora ove transakcije, kao i javni ključ kojim će se provjeravati taj potpis. Iz javnog ključa se može dobiti identifikator računa pošiljatelja te transakcije, odnosno jedinstveno identificirati račun pošiljatelja unutar samog sustava. Tako smo utvrdili osnovne podatke o strukturi transakcije.

Primjer koda pametnog ugovora na Solidity

Sada ćemo detaljnije razmotriti 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 prikazan pojednostavljeni izvorni kod koji može zadržavati korisničke novčiće i vraćati ih na zahtjev.

Dakle, postoji pametni ugovor Bank, koji obavlja sljedeće funkcije: akumulira novčiće na svom saldu, dakle, nakon potvrde transakcije i postavljanja takvog pametnog ugovora, stvara se novi račun koji može sadržavati novčiće na svom saldu; pamti korisnike i distribuciju novčića među njima; ima nekoliko metoda za upravljanje saldom, što znači da je moguće dopunjavanje, isplata i provjera salda korisnika.

Prođimo kroz svaku liniju izvorne koda. U ovom ugovoru postoje konstantna polja. Jedno od njih, tipa address, zove se owner. Ovdje ugovor pamti adresu korisnika koji je stvorio ovaj pametni ugovor. Zatim, postoji dinamička struktura koja čuva odgovarajuće veze između adresa korisnika i njihova salda.

Nakon toga slijedi metoda Bank — zove se isto kao i ugovor. To je ujedno i njegov konstruktor. Ovdje se varijabli owner dodjeljuje adresa onoga tko je postavio ovaj pametni ugovor u mreži. To je jedino što se događa u ovom konstruktora. Drugim riječima, msg u ovom slučaju su baš oni podaci koji su bili poslani virtualnoj mašini zajedno s transakcijom koja sadrži cijeli kod ovog ugovora. Prema tome, msg.sender je autor ove transakcije koja postavlja ovaj kod. On će biti vlasnik pametnog ugovora.

Metoda deposit omogućava prijenos određenog broja kovanica na račun ugovora putem transakcije. U ovom slučaju, pametni ugovor drži te kovanice na svom saldu, ali u strukturu balances zapisuje tko je bio pošiljatelj tih kovanica, kako bi znao kome one pripadaju.

Sljedeća metoda se naziva withdraw i prihvaća jedan parametar — iznos kovanica koji netko želi povući iz ove banke. Ovdje se provjerava ima li korisnik koji poziva ovu metodu dovoljno kovanica na svom saldu da ih pošalje. Ako ih ima dovoljno, pametni ugovor vraća ovom korisniku taj iznos kovanica.

Dalje imamo metodu za provjeru trenutnog salda korisnika. Onaj tko poziva ovu metodu koristit će se za dobivanje tog salda u pametnom ugovoru. Važno je napomenuti da je modificator ove metode — view. To znači da sama metoda ne mijenja varijable svoje klase i zapravo je samo metoda čitanja. Ne stvara se posebna transakcija za poziv ove metode, ne plaća se naknada, a sva izračunavanja se obavljaju lokalno, nakon čega korisnik dobiva rezultat.

Metoda kill potrebna je za uništavanje stanja pametnog ugovora. Ovdje je dodana dodatna provjera je li pozivalac ove metode vlasnik ovog ugovora. Ako jeste, tada se ugovor samoupravlja, a funkcija uništenja prihvaća jedan parametar — identifikator računa na koji će ugovor poslati sve preostale kovanice. U ovom slučaju, preostale kovanice automatski će otići na adresu vlasnika ugovora.

Kako funkcioniše puni čvor Ethereum mreže?

Pogledajmo shematski kako se izvršavaju takvi pametni ugovori na platformi Ethereum i kako radi puni čvor mreže.

Puni čvor Ethereum mreže mora imati najmanje četiri modula.
Prvi, kao i za svaki decentralizirani protokol, je P2P networking module — modul za povezivanje i rad s drugim čvorovima, gdje dolazi do razmjene blokova, transakcija i informacija o drugim čvorovima. To je tradicionalna komponenta za sve decentralizirane kriptovalute.

Nadalje, imamo modul za pohranu podataka blockchaina, obradu, odabir prioritetne grane, dodavanje blokova, odvijanje blokova, provjeru tih blokova itd.

Treći modul se zove EVM (Ethereum virtualna mašina) — to je virtualna mašina, koji prihvaća bytecode iz Ethereum transakcije. Ovaj modul prihvaća trenutno stanje određenog računa i provodi promjene njegovog stanja na temelju primljenog bytecode-a. Verzija virtualne mašine na svakom čvoru mreže mora biti identična. Izračuni se na svakom čvoru Ethereuma odvijaju potpuno isto, ali se događaju asinkrono: neki brže provjeravaju i prihvaćaju ovu transakciju, tj. izvršavaju cijeli kod koji se u njoj nalazi, dok drugi kasnije. Stoga, kad se stvori transakcija, ona se širi u mrežu, čvorovi je prihvaćaju, a u trenutku provjere se na isti način kao u Bitcoinu izvršava Bitcoin Script, ovdje se izvršava bytecode virtualne mašine.

Transakcija se smatra provjerenom ako je sav kod koji se u njoj nalazi bio izvršen, generirano je novo stanje određenog računa i sačuvano sve dok ne bude jasno je li ta transakcija primijenjena ili ne. Ako je transakcija primijenjena, tada se to stanje smatra ne samo izvršenim, već već i aktualnim. Postoji baza podataka koja pohranjuje stanje svakog računa za svaki čvor mreže. Budući da se svi izračuni odvijaju na isti način i stanje blockchaina je identično, tada će i baza podataka koja sadrži stanja svih računa biti ista za svaki čvor.

Mitovi i ograničenja pametnih ugovora

Što se tiče ograničenja koja postoje za slične platforme pametnih ugovora poput Ethereuma, može se navesti sljedeće:

izvršenje koda;
alokacija memorije;
podaci blockchaina;
slanje uplata;
kreiranje novog ugovora;
pozivanje drugih ugovora.

Pogledajmo ograničenja koja se nameću na virtualnu mašinu i, prema tome, raspršimo neke mitove o pametnim ugovorima. Na virtualnoj mašini, koja može biti ne samo na Ethereum-u, već i na sličnim platformama, mogu se izvesti zaista proizvoljne logičke operacije, što znači da možeš napisati kod koji će se izvršavati, a možeš dodatno dodijeliti memoriju. Međutim, naknade se plaćaju posebno za svaku operaciju i za svaku dodatno dodijeljenu jedinicu volumena memorije.

Nadalje, virtualna mašine može čitati podatke iz blockchain baze podataka kako bi koristila te podatke kao okidač za izvođenje određene logike pametnih ugovora. Virtualna mašine može stvarati i slati transakcije, može stvarati nove ugovore i pozivati metode drugih pametnih ugovora koji su već objavljeni na mreži: postoje, dostupni itd.

Najčešći mit je taj da pametni ugovori Ethereum-a mogu koristiti informacije iz bilo kojih internetskih izvora u svojim uvjetima. Istina je da virtualna mašine ne može poslati mrežni zahtjev nekom vanjskom informacijskom resursu na internetu, to jest, ne možeš napisati takav pametni ugovor koji bi raspodijelio vrijednost među korisnicima ovisno o tome, recimo, kakvo je vrijeme napolju, tko je pobijedio na nekom prvenstvu, ili na temelju nekog drugog događaja koji se dogodio u vanjskom svijetu, jer informacije o tim događajima jednostavno nema u bazi podataka same platforme. Dakle, u blockchainu ništa po tom pitanju ne postoji. Ako to ne bude prisutno, tada virtualna mašine ne može koristiti te podatke kao okidače.

Nedostaci Ethereum-a

Navodimo neke od osnovnih nedostataka. Prvi nedostatak je u tome što postoje određene poteškoće prilikom projektiranja, razvoja i testiranja pametnih ugovora u Ethereum mreži (za pisanje pametnih ugovora u Ethereum koristi se jezik Solidity). Praksa pokazuje da jako veliki postotak svih grešaka pripada ljudskom faktoru. Ovo se zapravo odnosi i na već napisane pametne ugovore Ethereum koji imaju prosječnu ili višu složenost. Ako je za jednostavne pametne ugovore vjerojatnost greške mala, u složenim pametnim ugovorima često se javljaju greške koje dovode do krađe sredstava, njihove zamrzavanja, uništenja pametnih ugovora na nepredviđen način itd. Poznato je mnogo takvih slučajeva.

Drugi nedostatak je u tome što sama virtualna mašina nije savršena, jer ju je također napisao čovjek. Ona može izvoditi proizvoljne naredbe i u tom leži ranjivost: određeni niz komandi može se konfigurirati tako da dovede do nepredviđenih posljedica. Ovo je veoma složeno područje, ali već postoje neka istraživanja koja pokazuju da te ranjivosti postoje u trenutnoj verziji Ethereum mreže i da one mogu dovesti do kvara mnogih pametnih ugovora.

Još jedna velika poteškoća, koja se može smatrati nedostatkom, leži u tome da se praktičnim ili tehničkim načinom može doći do zaključka da, ako se kompajlira bajt-kod ugovora koji će se izvoditi na virtualnoj mašini, može se odrediti određeni specifičan redoslijed operacija. Kada se te operacije obave zajedno, one opterećuju virtualnu mašinu u velikoj mjeri i usporavaju je nesrazmjerno naknadi koja je plaćena za izvršenje tih operacija.

U prošlosti je bilo razdoblja razvoja Ethereuma kada su mnogi pojedinci, koji su detaljno razumjeli rad virtualne mašine, pronalazili takve ranjivosti. U suštini, transakcije su plaćale vrlo malu naknadu, ali su u velikoj mjeri usporavale rad cijele mreže. Ovi problemi se vrlo teško rješavaju, jer ih je potrebno, prvo, determinirati, drugo, prilagoditi cijenu za izvršenje tih operacija i, treće, provesti hard fork, što podrazumijeva ažuriranje svih čvorova mreže na novu verziju softvera, a zatim istovremeno aktivirati te promjene.

Što se tiče Ethereuma, provedeno je mnogo istraživanja, stečeno je vrlo veliko praktično iskustvo: kako pozitivno, tako i negativno, ali i dalje ostaju složenosti i ranjivosti s kojima se još uvijek mora boriti.

Dakle, tematski dio članka je završen, pređimo na pitanja koja se često postavljaju.

Često postavljana pitanja

— Ako sve strane aktivnog pametnog ugovora žele promijeniti uvjete, mogu li otkazati taj pametni ugovor pomoću višestrukog potpisa, a zatim stvoriti novi pametni ugovor s ažuriranim uvjetima izvršenja?

Ovdje će odgovor biti dvojak. Zašto? Zato što s jedne strane pametni ugovor jednom postavljen ne podrazumijeva nikakve promjene, dok s druge strane može imati unaprijed definiranu logiku koja predviđa potpune ili djelomične promjene nekih uvjeta. To jest, ako želite nešto promijeniti u svom pametnom ugovoru, unaprijed morate definirati uvjete pod kojima možete ažurirati te uvjete. Tako se može organizirati ažuriranje ugovora samo na tako predostrožan način. Međutim, i ovdje se može naići na neugodnosti: napraviti neku grešku i dobiti odgovarajuću ranjivost. Stoga se takve stvari moraju vrlo detaljno i pažljivo projektirati i testirati.

— A što ako se posrednik dogovori s jednom od strana - sudionika: escrow ili pametnog ugovora? Je li posrednik obavezan u pametnom ugovoru?

Posrednik nije obavezan u pametnom ugovoru. Može ga biti ili ne. Ako bi se posrednik u slučaju escrow-a dogovorio s jednom od strana, tada ta shema gubi svu svoju vrijednost. Stoga se posrednici biraju na način da im vjeruju sve strane uključene u ovaj proces. Prema tome, jednostavno nećete prenositi novčiće na multisignature adresu posredniku kojem ne vjerujete.

— Može li se jednom transakcijom Ethereum prenijeti mnogo različitih tokena sa svoje adrese na različite ciljne adrese, na primjer burzovne adrese gdje se ti tokeni trguju?

To je dobro pitanje i tiče se modela transakcija Ethereum-a i njegovih razlika od modela Bitcoin-a. A ta razlika je drastična. Ako u modelu transakcije Ethereum jednostavno prenosite novčiće, oni se prenose samo s jedne adrese na drugu, bez povrata, samo određeni iznos koji ste naveli. Drugim riječima, to nije model nepotrošenih izlaza (UTXO), nego model računa i pripadajućih saldoa. Jednom transakcijom teoretski je moguće poslati više različitih tokena, ako napišete pametan ugovor, ali ćete i dalje morati napraviti mnogo transakcija, stvoriti ugovor, zatim mu prenijeti tokene i novčiće, a potom pozvati odgovarajuću metodu. To zahtijeva trud i vrijeme, stoga u praksi to ne funkcioniše i sve uplate u Ethereum-u se vrše odvojenim transakcijama.

— Jedan od mitova o platformi Ethereum je da nije moguće opisati takve uvjete koji će ovisiti o podacima vanjskog internetskog resursa, što onda učiniti?

Rješenje leži u tome da sam pametan ugovor može predvidjeti jednog ili više takozvanih pouzdanih oracle-a, koji prikupljaju podatke o stanju stvari u vanjskom svijetu i prenose ih u pametne ugovore putem posebnih metoda. Sam ugovor smatra istinitim one podatke koje je dobio od pouzdanih strana. Radi veće pouzdanosti, jednostavno se bira veća grupa oracle-a i minimiziraju rizik od njihovog dogovora. Sam ugovor može zanemariti podatke od oracle-a koji su u suprotnosti s većinom.

Ovoj temi posvećena je jedna od predavanja online tečaja o Blockchain-u — “Uvod u pametne ugovore”.

Izvor: habr.com