U ovom članku ćemo pogledati šta su pametni ugovori, šta su oni, upoznaćemo se sa različitim platformama pametnih ugovora, njihovim karakteristikama, a takođe ćemo razgovarati o tome kako funkcionišu i koje prednosti mogu doneti. Ovaj materijal će biti veoma koristan za čitaoce koji nisu dobro upoznati sa temom pametnih ugovora, ali žele da je bolje razumeju.
Redovni ugovor vs. pametni ugovor
Prije nego što uđemo u detalje, uzmimo primjer razlika između običnog ugovora koji je naveden na papiru i pametnog ugovora koji je predstavljen digitalno.
Kako je ovo funkcioniralo prije pojave pametnih ugovora? Zamislite grupu ljudi koja želi da uspostavi određena pravila i uslove za distribuciju vrednosti, kao i određeni mehanizam koji garantuje sprovođenje ove distribucije prema datim pravilima i uslovima. Zatim bi se okupili, sastavili papir na koji bi zapisali svoje identifikacione podatke, uslove, vrijednosti koje su uključene, datirali ih i potpisali. Ovaj ugovor je također ovjeren od strane pouzdane strane, kao što je notar. Dalje, ti ljudi su krenuli u različitim smjerovima sa svojim papirnim primjerkom takvog ugovora i počeli da obavljaju neke radnje koje možda ne odgovaraju samom ugovoru, odnosno uradili su jedno, ali je na papiru potvrđeno da nešto treba da urade. potpuno drugačije. I kako izaći iz ove situacije? Zapravo, jedan od članova grupe treba da uzme ovaj papir, uzme neke dokaze, odnese ga na sud i postigne usklađenost između ugovora i stvarnih radnji. Često je teško postići pravičnu implementaciju ovog ugovora, što dovodi do neprijatnih posljedica.
Šta se može reći o pametnim ugovorima? Kombinuju i mogućnost pisanja uslova ugovora i mehanizam za njihovu striktnu implementaciju. Ako su uslovi postavljeni i odgovarajuća transakcija ili zahtjev je potpisan, onda kada je taj zahtjev ili transakcija prihvaćena, više nije moguće mijenjati uslove niti uticati na njihovu implementaciju.
Postoji jedan validator ili cijela mreža, kao i baza podataka koja pohranjuje sve pametne ugovore koji su predati na izvršenje po strogom hronološkom redu. Također je važno da ova baza podataka mora sadržavati sve okidačke uslove za izvršenje pametnog ugovora. Osim toga, mora uzeti u obzir i samu vrijednost čija je raspodjela opisana u ugovoru. Ako se ovo 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 pametni ugovor radi. Na primjer, jedna baza podataka bi se trebala koristiti za istovremeno obračunavanje digitalnih valuta, korisničkih stanja, korisničkih transakcija i vremenskih oznaka. Zatim, u pametnom ugovoru uslov može biti stanje korisnika u određenoj valuti, dolazak određenog vremena ili činjenica da je određena transakcija obavljena, ali ništa više.
Definicija pametnog ugovora
Općenito, samu terminologiju je skovao istraživač Nick Szabo i prvi put je upotrijebio 1994. godine, a dokumentiran je 1997. godine u članku koji opisuje samu ideju pametnih ugovora.
Pametni ugovori podrazumevaju da se vrši neka automatizacija distribucije vrednosti, koja može zavisiti samo od onih uslova koji su unapred određeni. U svom najjednostavnijem obliku, to izgleda kao ugovor sa strogo definisanim uslovima, koji potpisuju određene strane.
Pametni ugovori su dizajnirani da minimiziraju povjerenje u treće strane. Ponekad je potpuno isključen centar za odlučivanje od kojeg sve zavisi. Osim toga, takve ugovore je lakše revidirati. To je posljedica nekih dizajnerskih karakteristika ovakvog sistema, ali najčešće pod pametnim ugovorom podrazumijevamo decentralizirano okruženje i prisustvo funkcija koje omogućavaju svakome da analizira bazu podataka i izvrši potpunu reviziju izvršenja ugovora. Time je osigurana zaštita od retroaktivnih promjena podataka koje bi povlačile promjene u izvršenju samog ugovora. Digitalizacija većine procesa prilikom kreiranja i pokretanja pametnog ugovora često pojednostavljuje tehnologiju i troškove 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.
Može se implementirati i korištenjem Bitcoina, iako se trenutno Bitcoin još uvijek teško može nazvati punopravnom platformom za pametne ugovore. Dakle, imamo nekog kupca i imamo online prodavnicu. Kupac želi kupiti monitor iz ove trgovine. U najjednostavnijem slučaju, kupac dovršava i šalje uplatu, a internet prodavnica je prihvata, potvrđuje i zatim š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 slabu reputaciju u očima kupca, postoji rizik da će iz nekog razloga, nakon prihvatanja plaćanja, trgovina odbiti uslugu i neće poslati robu kupcu. Stoga, kupac postavlja pitanje (i, shodno tome, internetska trgovina postavlja ovo pitanje) šta se može primijeniti u ovom slučaju kako bi se takvi rizici minimizirali i takve transakcije učinile pouzdanijim.
U slučaju Bitcoina, moguće je omogućiti kupcu i prodavcu da samostalno izaberu posrednika. Mnogo je ljudi koji su uključeni u rješavanje kontroverznih pitanja. A naši učesnici mogu sa opće liste medijatora izabrati onog kome će vjerovati. Zajedno kreiraju 2 od 3 adrese s više potpisa gdje postoje tri ključa i dva potpisa sa bilo koja dva ključa su potrebna za trošenje novčića sa te adrese. Jedan ključ će pripadati kupcu, drugi online prodavnici, a treći posredniku. A na takvu adresu sa više potpisa kupac će poslati iznos potreban za plaćanje monitora. Sada, kada prodavac vidi da je novac blokiran neko vreme na adresi sa više potpisa koja zavisi od njega, može bezbedno da pošalje monitor poštom.
Zatim kupac prima paket, pregleda robu i donosi odluku o konačnoj kupovini. Može se u potpunosti složiti sa pruženom uslugom i potpisati transakciju svojim ključem, pri čemu prenosi novčiće sa adrese sa više potpisa prodavcu, ili može biti nečim nezadovoljan. U drugom slučaju, on kontaktira posrednika da sastavi alternativnu transakciju koja će te novčiće distribuirati drugačije.
Recimo da je monitor stigao malo izgreban i da u kompletu nije bio kabl za povezivanje sa računarom, iako je na sajtu internet prodavnice pisalo da kabl treba da bude uključen u komplet. Tada kupac prikuplja dokaze potrebne da dokaže posredniku da je prevaren u ovoj situaciji: snima screenshot stranice, fotografira potvrdu o prijemu pošte, fotografira ogrebotine na monitoru i pokazuje da je pečat bio polomljen i kabl je izvučen. Internet prodavnica, zauzvrat, prikuplja svoje dokaze i prenosi ih posredniku.
Posrednik je zainteresiran da istovremeno zadovolji i ogorčenje kupca i interese online trgovine (kasnije će postati jasno zašto). To predstavlja transakciju u kojoj će se novčići sa adrese sa više potpisa u nekom omjeru potrošiti 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 prodavcu, 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. On šalje takvu transakciju i kupcu i prodavcu. Ako je barem jedan od njih zadovoljan ovom opcijom za redistribuciju kovanica, transakcija će biti unaprijed potpisana i distribuirana mreži. Da bi se to potvrdilo, dovoljno je da se jedna od strana u transakciji složi s opcijom posrednika.
Važno je u početku odabrati posrednika tako da mu oba učesnika vjeruju. U tom slučaju će djelovati nezavisno od interesa jednih ili drugih i objektivno procijeniti situaciju. Ako posrednik ne pruži opciju za distribuciju kovanica koja će zadovoljiti barem jednog učesnika, tada, nakon zajedničkog dogovora, i kupac i internet trgovina mogu poslati kovanice na novu multipotpisnu adresu stavljajući svoja dva potpisa. Nova adresa s više potpisa će biti 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 spavaonicu. Njih troje su zainteresovani da za svoju sobu kupe frižider koji mogu zajedno da koriste. Jedan od njih se dobrovoljno javio da prikupi potrebnu količinu za kupovinu frižidera i pregovara sa prodavcem. Međutim, tek su se nedavno upoznali i među njima nema dovoljno povjerenja. Očigledno, dvojica preuzimaju rizik dajući novac trećem. Osim toga, potrebno je da se dogovore oko izbora prodavca.
Oni mogu koristiti escrow uslugu, odnosno izabrati posrednika koji će pratiti izvršenje transakcije i rješavati kontroverzna pitanja ako do njih dođe. Zatim, nakon dogovora, sastavljaju pametni ugovor i u njemu propisuju određene uslove.
Prvi uslov je da prije određenog vremena, recimo u roku od jedne sedmice, odgovarajući račun pametnog ugovora mora primiti tri uplate sa određenih adresa za određeni iznos. Ako se to ne dogodi, pametni ugovor prestaje da se izvršava i vraća novčiće svim učesnicima. Ako je uvjet ispunjen, tada se postavljaju vrijednosti identifikatora prodavača i posrednika, te se provjerava uvjet da se svi sudionici slažu sa izborom prodavca i posrednika. Kada se ispune svi uslovi, sredstva će biti prebačena na navedene adrese. Ovaj pristup može zaštititi učesnike od prevare sa bilo koje strane i generalno eliminiše potrebu za poverenjem.
U ovom primjeru vidimo sam princip da ova mogućnost korak-po-korak postavljanja parametara za ispunjavanje svakog uslova omogućava kreiranje sistema bilo koje složenosti i dubine ugniježđenih nivoa. Osim toga, prvo možete definirati prvi uvjet u pametnom ugovoru, a tek nakon njegovog ispunjenja možete postaviti parametre za sljedeći uvjet. Drugim riječima, uslov je formalno zapisan, a parametri za njega se mogu podesiti već tokom njegovog rada.
Klasifikacija pametnih ugovora
Za klasifikaciju možete postaviti različite grupe kriterijuma. Međutim, u trenutku razvoja tehnologije, četiri od njih su relevantne.
Pametni ugovori se mogu razlikovati po okruženju izvršenja koje može biti centralizirano ili decentralizirano. U slučaju decentralizacije, imamo mnogo veću nezavisnost i toleranciju na greške pri izvršavanju pametnih ugovora.
Mogu se razlikovati i po procesu postavljanja i ispunjavanja uslova: mogu biti slobodno programabilni, ograničeni ili unapred definisani, odnosno strogo otkucani. Kada na platformi pametnih ugovora postoje samo 4 specifična pametna ugovora, parametri za njih se mogu postaviti na bilo koji način. U skladu s tim, njihovo postavljanje je mnogo jednostavnije: biramo ugovor s liste i prosljeđujemo parametre.
Po metodi inicijacije postoje automatizovani pametni ugovori, odnosno kada se jave određeni uslovi oni se samoizvršavaju, a postoje ugovori u kojima su navedeni uslovi, ali platforma ne proverava automatski njihovo ispunjenje, za to se potrebno je pokrenuti odvojeno.
Osim toga, pametni ugovori se razlikuju po nivou privatnosti. Mogu biti potpuno otvoreni, djelimično ili potpuno povjerljivi. Ovo drugo znači da posmatrači treće strane ne vide uslove pametnih ugovora. Međutim, tema privatnosti je vrlo široka i bolje je razmotriti je odvojeno od trenutnog članka.
U nastavku ćemo detaljnije pogledati prva tri kriterija kako bismo unijeli više jasnoće u razumijevanje trenutne teme.
Pametni ugovori po vremenu izvođenja
Na osnovu okruženja izvršenja, pravi se razlika između centraliziranih i decentraliziranih platformi pametnih ugovora. 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 centralno upravlja. Postoji jedna baza podataka koja pohranjuje sve potrebne informacije za postavljanje uslova pametnog ugovora i distribuciju vrijednosti koja se uzima u obzir upravo u ovoj bazi podataka usluge. Ovakva centralizovana usluga ima klijenta koji postavlja uslove određenim zahtevima 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 da određeni operater vodi centralizovanu evidenciju saobraćaja na svojim serverima, koja se može prenositi u različitim formatima, na primer: u vidu govornih poziva, SMS prenosa, mobilnog internet saobraćaja i po različitim standardima, a takođe vodi evidenciju sredstava na bilansima korisnika. Shodno tome, provajder mobilnih komunikacija može sastaviti ugovore za obračun pruženih usluga i njihovo plaćanje pod različitim uslovima. U ovom slučaju lako je postaviti uslove poput „pošaljite SMS sa tim i takvim kodom na taj i taj broj i dobićete takve i takve uslove za distribuciju saobraćaja“.
Možemo navesti još jedan primjer: tradicionalne banke sa proširenom funkcionalnošću Internet bankarstva i vrlo jednostavnim ugovorima kao što su redovna plaćanja, automatska konverzija pristiglih uplata, automatski odbitak kamate na određeni račun itd.
Ako govorimo o pametnim ugovorima sa decentralizovanim okruženjem za izvršenje, onda imamo grupu validatora. U idealnom slučaju, svako može postati validator. Zbog protokola za sinhronizaciju baze podataka i postizanja konsenzusa, imamo neku zajedničku bazu podataka koja će sada pohranjivati sve transakcije sa strogo opisanim ugovorima, a ne nekim uslovnim upitima, čiji se formati često mijenjaju, a nema otvorene specifikacije. Ovdje će transakcije sadržavati instrukcije za izvršenje ugovora prema strogoj specifikaciji. Ova specifikacija je otvorena i stoga sami korisnici platforme mogu vršiti reviziju i validaciju pametnih ugovora. Ovdje vidimo da su decentralizirane platforme superiornije od centraliziranih u smislu neovisnosti i tolerancije grešaka, ali su njihov dizajn i održavanje mnogo složeniji.
Pametni ugovori po načinu postavljanja i ispunjavanja uslova
Sada pogledajmo bliže kako se pametni ugovori mogu razlikovati u načinu na koji postavljaju i ispunjavaju uslove. Ovdje skrećemo pažnju na pametne ugovore koji se nasumično programiraju i koji su po Turingu potpuni. Pametni ugovor potpun po Turingu omogućava vam da postavite gotovo sve algoritme kao uslove za izvršenje ugovora: cikluse pisanja, neke funkcije za izračunavanje vjerovatnoća i slično - sve do vaših vlastitih algoritama elektronskog potpisa. U ovom slučaju mislimo na istinski proizvoljno pisanje logike.
Postoje i proizvoljni pametni ugovori, ali ne i Turingovi potpuni. Ovo uključuje Bitcoin i Litecoin sa sopstvenom 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 pametnih ugovora 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 fokusiran na izdavanje tokena i trgovanje, kao Bitshares, već na bloganje, odnosno pohranjuje i obrađuje sadržaj na decentraliziran način.
Arbitrarni Turing-kompletni ugovori uključuju Ethereum platformu i RootStock, koji je još uvijek u razvoju. Stoga ćemo se u nastavku malo detaljnije zadržati na platformi pametnih ugovora Ethereum.
Pametni ugovori metodom inicijacije
Na osnovu načina iniciranja, pametni ugovori se također mogu podijeliti u najmanje dvije grupe: automatizirane i ručne (ne automatizirane). Automatizovane karakteriše činjenica da se, s obzirom na sve poznate parametre i uslove, smart ugovor izvršava u potpunosti automatski, odnosno ne zahteva slanje dodatnih transakcija i trošenje dodatne provizije na svako sledeće izvršenje. Sama platforma ima sve podatke za izračunavanje kako će se pametni ugovor završiti. Logika tamo nije proizvoljna, već unaprijed određena i sve je to predvidljivo. Odnosno, možete unaprijed procijeniti složenost izvršavanja pametnog ugovora, koristiti neku vrstu stalne provizije za to, a svi procesi za njegovu implementaciju su efikasniji.
Za pametne ugovore koji su slobodno programirani, izvršenje nije automatizirano. Da biste pokrenuli takav pametni ugovor, na gotovo svakom koraku trebate kreirati novu transakciju, koja će pozvati sljedeću fazu izvršenja ili sljedeći metod pametnog ugovora, platiti odgovarajuću proviziju i čekati da se transakcija potvrdi. Izvršenje se može završiti uspješno ili ne, jer je kod pametnog ugovora proizvoljan i mogu se pojaviti neki nepredvidivi momenti, kao što je vječna petlja, nedostatak nekih parametara i argumenata, neobrađeni izuzeci itd.
Ethereum računi
Vrste Ethereum računa
Pogledajmo koje vrste naloga mogu biti na Ethereum platformi. Ovdje postoje samo dvije vrste računa i nema drugih opcija. Prvi tip se zove korisnički nalog, drugi je ugovorni nalog. Hajde da shvatimo po čemu se razlikuju.
Korisnički nalog kontroliše samo lični ključ elektronskog potpisa. Vlasnik računa generiše svoj vlastiti par ključeva za elektronski potpis koristeći algoritam ECDSA (Elliptic Curve Digital Signature Algoritam). Samo transakcije potpisane ovim ključem mogu promijeniti stanje ovog računa.
Za račun pametnog ugovora predviđena je posebna 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 kovanici distribuirati. Ako programeri nisu predvidjeli neke tačke u programskom kodu, mogu nastati problemi. Na primjer, pametni ugovor može dobiti određeno stanje u kojem ne prihvata pokretanje daljeg 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 naloga, vlasnik samostalno generiše par ključeva koristeći ECDSA. Važno je napomenuti da Ethereum koristi potpuno isti algoritam i potpuno istu eliptičku krivu za elektronske potpise kao Bitcoin, ali se adresa izračunava na malo drugačiji način. Ovdje se više ne koristi rezultat dvostrukog heširanja, kao u Bitcoinu, već je jednostruko heširanje omogućeno funkcijom Keccak na dužini od 256 bita. Najmanji značajni bitovi su odsječeni od rezultirajuće vrijednosti, odnosno najmanje značajnih 160 bitova izlazne heš vrijednosti. Kao rezultat, dobijamo adresu u Ethereumu. U stvari, zauzima 20 bajtova.
Imajte na umu da je identifikator računa u Ethereumu kodiran heksadecimalno bez primjene kontrolne sume, za razliku od Bitcoina i mnogih drugih sistema, gdje je adresa kodirana u sistemu brojeva sa osnovom 58 uz dodatak kontrolne sume. To znači da morate biti oprezni kada radite s identifikatorima računa u Ethereumu: čak i jedna greška u identifikatoru garantirano će dovesti do gubitka kovanica.
Postoji važna karakteristika a to je da se korisnički nalog na nivou opšte baze podataka kreira u trenutku kada prihvati prvu dolaznu uplatu.
Kreiranje računa pametnog ugovora zahtijeva potpuno drugačiji pristup. U početku, jedan od korisnika piše izvorni kod pametnog ugovora, nakon čega se kod prosljeđuje preko kompajlera specijalnog 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 u ime računa inicijatora. Zatim se ova transakcija širi kroz mrežu i postavlja kod pametnog ugovora. Provizija za transakciju, a samim tim i za izvršenje ugovora, povlači se sa stanja 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 novčiće, pozivati određene metode pametnog ugovora itd.
Ethereum transakcijska struktura
Da bismo bili jasniji, počet ćemo gledati strukturu Ethereum transakcije i primjer koda pametnog ugovora.
Ethereum transakcija se sastoji 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 njen autor. Ovo je neophodno kako bi se razlikovale dvostruke transakcije, odnosno da bi se isključio slučaj kada je ista transakcija prihvaćena dva puta. Koristeći identifikator, svaka transakcija ima jedinstvenu heš vrijednost.
Sljedeće dolazi polje poput cijena plina. Ovo označava cijenu po kojoj se osnovna valuta Ethereuma pretvara u plin, koji se koristi za plaćanje izvršenja pametnog ugovora i dodjelu resursa virtuelne mašine. Šta to znači?
U Bitcoin-u, naknade se plaćaju direktno od strane osnovne valute—Bitcoin-a. To je moguće zahvaljujući jednostavnom mehanizmu za njihovo izračunavanje: plaćamo strogo za količinu podataka sadržanih u transakciji. U Ethereumu je situacija složenija, jer se vrlo teško osloniti na količinu podataka o transakcijama. Ovdje transakcija također može sadržavati programski kod koji će se izvršavati na virtuelnoj mašini, a svaka operacija virtuelne mašine može imati različitu složenost. Postoje i operacije koje dodeljuju memoriju za varijable. Oni će imati svoju složenost, o kojoj će ovisiti plaćanje za svaku operaciju.
Cijena svake operacije u plinskom ekvivalentu bit će konstantna. Uvodi se posebno kako bi se odredio stalni trošak svake operacije. Ovisno o opterećenju mreže mijenjat će se i cijena plina, odnosno koeficijent prema kojem će se osnovna valuta pretvoriti u ovu pomoćnu jedinicu za plaćanje provizije.
Postoji još jedna karakteristika transakcije u Ethereumu: bajt kod koji sadrži za izvršenje u virtuelnoj mašini će se izvršavati sve dok se ne završi nekim rezultatom (uspehom ili neuspehom) ili dok ne ponestane određena količina kovanica za plaćanje provizije . Da bi se izbjegla situacija da su u slučaju neke greške svi novčići sa računa pošiljaoca potrošeni na proviziju (na primjer, neka vrsta vječnog ciklusa koji je pokrenut u virtuelnoj mašini), postoji sljedeće polje - start gas (često se naziva ograničenje gasa) - određuje maksimalnu količinu novčića koju je pošiljalac spreman potrošiti da dovrši određenu transakciju.
Poziva se sljedeće polje adresa odredišta. Ovo uključuje adresu primatelja novčića ili adresu određenog pametnog ugovora čije će metode biti pozvane. Nakon toga dolazi teren vrijednost, gdje se upisuje količina novčića koji se šalje na odredišnu adresu.
Sljedeće je zanimljivo polje tzv podaci, gde se uklapa cela konstrukcija. Ovo nije zasebno polje, već cijela struktura u kojoj je definiran kod za virtuelnu mašinu. Ovdje možete postaviti proizvoljne podatke - za to postoje posebna pravila.
I zadnje polje se zove potpis. Istovremeno sadrži i elektronski potpis autora ove transakcije i javni ključ kojim će ovaj potpis biti verifikovan. Iz javnog ključa možete dobiti identifikator naloga pošiljaoca ove transakcije, odnosno jedinstveno identifikovati nalog pošiljaoca u samom sistemu. Saznali smo glavnu stvar o strukturi transakcije.
Primjer koda pametnog ugovora za Solidity
Pogledajmo sada pobliže najjednostavniji pametni ugovor koristeći primjer.
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);
}
}Iznad je pojednostavljeni izvorni kod koji može držati korisničke novčiće i vratiti ih na zahtjev.
Dakle, postoji pametni ugovor Banke koji obavlja sljedeće funkcije: akumulira novčiće na svom saldu, odnosno kada je transakcija potvrđena i takav pametni ugovor sklopljen, kreira se novi račun koji može sadržavati kovanice na svom saldu; pamti korisnike i distribuciju novčića između njih; ima nekoliko metoda za vođenje stanja, odnosno moguće je dopuniti, podići i provjeriti stanje korisnika.
Prođimo kroz svaki red izvornog koda. Ovaj ugovor ima stalna polja. Jedan od njih, sa tipom adrese, 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 metod Banke - ima isti naziv kao i ugovor. Prema tome, ovo je njegov konstruktor. Ovdje je varijabli vlasnika dodijeljena adresa osobe koja je stavila ovaj pametni ugovor na mrežu. Ovo je jedina stvar koja se dešava u ovom konstruktoru. Odnosno, poruka je u ovom slučaju upravo podaci koji su prebačeni na virtuelnu mašinu zajedno sa transakcijom koja sadrži ceo kod ovog ugovora. Prema tome, msg.sender je autor ove transakcije koja hostuje ovaj kod. On će biti vlasnik pametnog ugovora.
Metoda depozita vam omogućava da prenesete određeni broj kovanica na ugovorni račun transakcijom. U ovom slučaju, pametni ugovor, primajući te kovanice, ostavlja ih u svom bilansu, ali u strukturi bilansa bilježi ko je tačno bio pošiljalac ovih kovanica kako bi se znalo kome pripadaju.
Sljedeća metoda se zove povlačenje i uzima jedan parametar - količinu kovanica koju neko želi podići iz ove banke. Ovim se provjerava da li ima dovoljno kovanica na saldu korisnika koji poziva ovu metodu da ih pošalje. Ako ih ima dovoljno, onda sam pametni ugovor vraća taj broj novčića pozivaocu.
Sljedeća je metoda za provjeru trenutnog stanja korisnika. Ko god pozove ovu metodu koristit će se za vraćanje ovog stanja u pametnom ugovoru. Vrijedi napomenuti da je modifikator ove metode view. To znači da sama metoda ni na koji način ne mijenja varijable svoje klase i zapravo je samo metoda čitanja. Ne kreira se posebna transakcija za pozivanje ove metode, ne plaća se naknada, a svi proračuni se vrše lokalno, nakon čega korisnik dobija rezultat.
Metoda ubijanja je potrebna da se uništi stanje pametnog ugovora. I ovdje postoji dodatna provjera da li je pozivalac ove metode vlasnik ovog ugovora. Ako je tako, onda se ugovor samouništava, a funkcija uništavanja uzima jedan parametar - identifikator računa na koji će ugovor poslati sve kovanice preostale na svom saldu. U tom slučaju, preostali novčići će automatski otići na adresu vlasnika ugovora.
Kako funkcionira cijeli čvor na Ethereum mreži?
Pogledajmo šematski kako se takvi pametni ugovori izvršavaju na Ethereum platformi i kako funkcionira pun mrežni čvor.
Pun čvor na Ethereum mreži mora imati najmanje četiri modula.
Prvi, kao i za svaki decentralizovani protokol, je P2P mrežni modul - modul za mrežno povezivanje i rad sa drugim čvorovima, gde se razmenjuju 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 valjanosti ovih blokova itd.
Treći modul se zove EVM (Ethereum virtuelna mašina) - ovo je virtuelna mašina koja prima bajt kod od Ethereum transakcija. Ovaj modul preuzima trenutno stanje određenog računa i mijenja njegovo stanje na osnovu primljenog bajt koda. Verzija virtuelne mašine na svakom mrežnom čvoru mora biti ista. Izračuni koji se odvijaju na svakom Ethereum čvoru su potpuno isti, ali se odvijaju na asinhroni način: neko provjerava i prihvaća ovu transakciju ranije, odnosno izvršava sav kod sadržan u njoj, a neko kasnije. Shodno tome, kada se transakcija kreira, ona se distribuira mreži, čvorovi je prihvataju, a u trenutku verifikacije, na isti način na koji se Bitcoin skripta izvršava u Bitcoin-u, ovde se izvršava bajt kod virtuelne mašine.
Transakcija se smatra verifikovanom ako je izvršena sva šifra sadržana u njoj, generisano novo stanje određenog računa i sačuvano dok se ne utvrdi da li je ova transakcija primenjena ili ne. Ako je transakcija primijenjena, tada se ovo stanje smatra ne samo završenim, već i tekućim. Postoji baza podataka koja pohranjuje stanje svakog naloga za svaki mrežni čvor. Zbog činjenice da se svi prorač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, mogu se navesti sljedeće:
- izvršavanje koda;
- dodijeliti memoriju;
- blockchain podaci;
- slati uplate;
- kreirati novi ugovor;
- pozovite druge ugovore.
Pogledajmo ograničenja koja su nametnuta virtuelnoj mašini i, u skladu s tim, razbiti neke mitove o pametnim ugovorima. Na virtuelnoj mašini, koja može biti ne samo u Ethereumu, već i na sličnim platformama, možete izvoditi zaista 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 posebno za svaku operaciju i za svaku dodatnu dodijeljenu jedinicu memorije.
Zatim, virtualna mašina može čitati podatke iz blockchain baze podataka kako bi te podatke koristila kao okidač za izvršavanje jedne ili druge logike pametnog ugovora. Virtuelna mašina 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 s bilo kojeg internetskog resursa u skladu sa svojim uvjetima. Istina je da virtuelna mašina ne može da pošalje mrežni zahtev nekom eksternom informacionom resursu na internetu, odnosno nemoguće je napisati pametan ugovor koji će raspodeliti vrednost između korisnika u zavisnosti od, recimo, vremena napolju, ili ko je osvojio neko prvenstvo, ili na osnovu nekog drugog incidenta koji se 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 ne pojavi tamo, virtuelna mašina ne može koristiti ove podatke kao okidače.
Nedostaci Ethereuma
Hajde da navedemo glavne. Prvi nedostatak je što postoje određene poteškoće u dizajniranju, razvoju i testiranju pametnih ugovora u Ethereumu (Ethereum koristi jezik Solidity za pisanje pametnih ugovora). Zaista, praksa pokazuje da veoma veliki procenat svih grešaka pripada ljudskom faktoru. Ovo zapravo vrijedi za već napisane Ethereum pametne ugovore koji imaju prosječnu ili veću složenost. Ako je za jednostavne pametne ugovore vjerovatnoća greške mala, onda u složenim pametnim ugovorima vrlo često dolazi do grešaka koje dovode do krađe sredstava, njihovog zamrzavanja, uništavanja pametnih ugovora na neočekivan način itd. Mnogi takvi slučajevi su već poznato.
Drugi nedostatak je što virtuelna mašina sama po sebi nije savršena, jer je takođe pišu ljudi. Može izvršavati proizvoljne komande, a u tome je i ranjivost: određeni broj komandi se može konfigurirati na određeni način što će dovesti do unaprijed nepredviđenih posljedica. Ovo je vrlo složeno područje, ali već postoji nekoliko studija koje pokazuju da ove ranjivosti postoje u trenutnoj verziji Ethereum mreže i mogu dovesti do neuspjeha mnogih pametnih ugovora.
Još jedna velika poteškoća, može se smatrati nedostatkom. Leži u tome da praktično ili tehnički možete doći do zaključka da ako kompajlirate bajt kod ugovora koji će se izvršavati na virtuelnoj mašini, možete odrediti neki specifičan redosled operacija. Kada se izvode zajedno, ove operacije će uvelike opteretiti virtuelnu mašinu i usporiti je neproporcionalno u odnosu na naknadu koja je plaćena za izvođenje ovih operacija.
U prošlosti je već postojao period u razvoju Ethereuma, kada su mnogi momci koji su detaljno razumjeli rad virtualne mašine pronašli takve ranjivosti. U stvari, transakcije su plaćale vrlo malu naknadu, ali su praktično usporavale cijelu mrežu. Ove probleme je vrlo teško riješiti, jer ih je potrebno, prvo, odrediti, 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 ovih promjena.
Što se tiče Ethereuma, provedeno je dosta istraživanja, stečeno je mnogo praktičnog iskustva: i pozitivnog i negativnog, ali ipak ostaju poteškoće i ranjivosti s kojima se još treba nekako nositi.
Dakle, tematski dio članka je završen, prijeđimo na pitanja koja se često javljaju.
Često postavljana pitanja
— Ako sve strane u postojećem pametnom ugovoru žele da promene uslove, da li mogu da ponište ovaj pametni ugovor koristeći multisig, a zatim kreiraju novi pametni ugovor sa ažuriranim uslovima njegovog izvršenja?
Odgovor će ovdje biti dvostruk. Zašto? Jer, s jedne strane, pametni ugovor je jednom definisan i više ne podrazumeva nikakve promene, a sa druge strane može imati unapred napisanu logiku koja predviđa potpunu ili delimičnu promenu nekih uslova. Odnosno, ako želite nešto promijeniti u svom pametnom ugovoru, onda morate propisati uslove pod kojima možete ažurirati ove uslove. Shodno tome, samo na tako oprezan način može se organizovati obnavljanje ugovora. Ali i ovdje možete naići na nevolje: napravite grešku i dobijete odgovarajuću ranjivost. Stoga takve stvari moraju biti vrlo detaljne i pažljivo dizajnirane i testirane.
— Što ako posrednik sklopi sporazum s jednom od sudionica: escrow ili pametni ugovor? Da li je u pametnom ugovoru potreban posrednik?
Posrednik nije potreban u pametnom ugovoru. Možda ne postoji. Ako, u slučaju escrow-a, posrednik uđe u zavjeru s jednom od strana, onda da, ova šema tada naglo gubi svu svoju vrijednost. Stoga se medijatori biraju na način da im istovremeno vjeruju sve strane uključene u ovaj proces. U skladu s tim, jednostavno nećete prenositi kovanice na adresu s više potpisa kod posrednika kojem nemate povjerenja.
— Da li je moguće s jednom Ethereum transakcijom prenijeti mnogo različitih tokena sa vaše adrese na različite ciljne adrese, na primjer, adrese razmjene na kojima se trguje ovim tokenima?
Ovo je dobro pitanje i odnosi se na Ethereum transakcijski model i kako se razlikuje od Bitcoin modela. A razlika je radikalna. Ako u modelu transakcije Ethereum jednostavno prenosite novčiće, onda se oni prenose samo 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 odgovarajućih stanja. Teoretski je moguće poslati nekoliko različitih tokena u jednoj transakciji odjednom ako napišete lukavi pametni ugovor, ali ćete i dalje morati napraviti mnogo transakcija, kreirati ugovor, zatim prebaciti tokene i novčiće 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 se vrše u zasebnim transakcijama.
— Jedan od mitova o Ethereum platformi je da je nemoguće opisati uslove koji će zavisiti od podataka eksternog internet resursa, pa šta onda učiniti?
Rješenje je da sam pametni ugovor može obezbijediti jedno ili više takozvanih proročišta od povjerenja, koja prikupljaju podatke o stanju stvari u vanjskom svijetu i prenose ih na pametne ugovore posebnim metodama. Sam ugovor smatra da su podaci koje je dobio od povjerljivih strana istiniti. Za veću pouzdanost, jednostavno odaberite veliku grupu proročišta i smanjite rizik od njihovog dosluha. Sam ugovor možda neće uzeti u obzir podatke iz proročišta koji su u suprotnosti sa većinom.
Jedno od predavanja online kursa o Blockchainu posvećeno je ovoj temi - “".
izvor: www.habr.com