Transakcija v Tezosovem omreˇzju nosi eno ali veˇc operacij. Operacija je lahko navaden prenos sredstev, objava pametne pogodbe ali interakcija z obstojeˇco pametno pogodbo na omreˇzju [27]. Pametna pogodba je del kode, shranjen v verigi blokov. Vsebuje niz navodil in pravil za njihovo sproˇzitev. Ko je enkrat shranjena na verigi blokov, postane nespremenljiva. Tezosova pametna pogodba se na verigo blokov prenese s pomoˇcjo operacije objavi pogodbo (ang. originate contract). Vsaka operacija zahteva plaˇcilo pristojbin. Zaradi preglednosti in nespremenljivosti na javni verigi blokov omogoˇcajo
zanesljiv sporazum med dvema ali veˇc uporabniki.
Ker smo navodila in pravila vgradili v pametno pogodbo, so tudi ta nespremenljiva.
Pogodba tako vedno ostane tam, kjer je bila shranjena in se ne prenaˇsa na drugo operacijo ali blok. Tezos ne uporablja modela UTXO, temveˇc model stanjskih raˇcunov.
Tako kot pri Ethereumu, tudi v sistemu Tezos uporabljamo dve vrsti raˇcunov:
• klasiˇcni raˇcun s primarnim naslovom za hranjenje tezov;
• raˇcun za pametne pogodbe z naslovom, na katerem se lahko hranita koda pame-tne pogodbe in tez.
Vsak klasiˇcni raˇcun ima lastnika in vsaka pametna pogodba ima upravitelja. Pame-tne pogodbe se pogosto uporabljajo za izdelavo finanˇcnih instrumentov, kot so razliˇcni ˇ
zetoni z razliˇcno uporabnostjo in lastnostmi. Drugi bolj ali manj zapleteni projekti lahko ponujajo posojila, stabilne kovance ali mnoˇziˇcno financiranje. V veˇcini primerov pametne pogodbe odstranijo posrednike in zmanjˇsajo stroˇske v primerjavi s klasiˇcnimi papirnatimi pogodbami in njihovim potrjevanjem. Ker so napisane v programskem jeziku, so bolj deterministiˇcne od pogodb, napisanih v ˇcloveˇskem jeziku.
Koda pametne pogodbe je sestavljena iz ukazov v programskem jeziku Michelson.
Interakcije s pametno pogodbo izvajajo ukaze, rezultat izvajanja ukazov pa je novo stanje v skladiˇsˇcu pametne pogodbe. Ukazi doloˇcajo, kako ustvariti to novo stanje, lahko pa vodijo tudi do drugih operacij, vkljuˇcno z nastankom drugih pametnih pogodb in transakcij. ˇZetoni se prenaˇsajo na naslednji naˇcin:
• uporabnik ali aplikacija pokliˇce pametno pogodbo;
• pametna pogodba preveri, ali lahko uporabnik poˇslje ˇzetone;
• pametna pogodba v skladiˇsˇcu posodobi zapise o sredstvih uporabnikov: zmanjˇsa sredstva poˇsiljatelja za znesek prenosa in ga doda sredstvom prejemnika.
Razvijalci lahko pametne pogodbe piˇsejo z uporabo predlog, ki sledijo Tezosovim standardom. Standardi doloˇcajo osnovne operacije pogodbe, ki so potrebne za uspeˇsno integracijo z razliˇcnimi denarnicami in drugimi aplikacijami na verigi blokov. Poeno-tena imena, funkcionalnost ter parametri operacij omogoˇcajo boljˇso medobratovalnost pametnih pogodb v Tezosovem sistemu. Nekatere pogodbe iz drugih omreˇzij so kom-patibilne s Tezosovimi zavitimi ˇzetoni, vendar vseh pogodb ni enostavno premostiti.
Tezosovi standardi se imenujejo finanˇcne aplikacije, najbolj priljubljena med njimi sta FA1.2 za deljive ˇzetone in FA2 za deljive, nedeljive in hibridne ˇzetone. Pogodba, ki sledi standardu FA2, lahko vsebuje veˇc ˇzetonov hkrati.
Diplomska naloga 19
Glavne operacije FA1.2 standarda so:
• prenesi (ang. transfer) omogoˇca prenos ˇzetonov med uporabniki;
• odobri (ang. approve) pooblasti premik ˇzetonov iz druge denarnice;
• odobreno (ang. getAllowance) poizveduje, koliko ˇzetonov lahko prenesemo iz izbranega raˇcuna;
• sredstva (ang. getBallance) poizveduje vsoto ˇzetonov na doloˇcenem raˇcunu;
• skupna sredstva (ang. getTotalSupply) poizveduje vsoto vseh ˇzetonov v obtoku.
Glavne operacije FA2 standarda so:
• sredstva (ang. balance of) poizveduje vsoto ˇzetonov na doloˇcenem raˇcunu;
• natisni (ang. mint) omogoˇca tiskanje novih ˇzetonov;
• prenesi tez (ang. mutez transfer) omogoˇca prenos tezov iz naslova pogodbe;
• doloˇci upravitelja (ang. set administrator) doloˇci upravitelja pametne pogodbe;
• doloˇci premor (ang. set pause) doloˇci premor pametne pogodbe;
• metapodatki (ang. token metadata) posodobi metapodatke v glavni pogodbi;
• posredni metapodatki (ang. token metadata registry) posodobi naslov posredne pogodbe z metapodatki ˇzetona;
• prenesi (ang. transfer) omogoˇca prenos ˇzetonov med uporabniki;
• doloˇci operatorje(ang. update operators) na raˇcunu doda ali odstrani operaterja za doloˇcen ˇzeton.
Tezosovi standardi doloˇcajo tudi obliko metapodatkov, ki v razliˇcnih implementacijah uporabniˇskih denarnic na poenoten naˇcin prispevajo dodatne informacije o ˇzetonu.
Poenoten zapis vsebuje ˇstevilo decimalk, navodila za posamezne operacije, pripise parametrov, razlago napak, sliko ˇzetona in druge podatke, ki se hranijo v datoteki izven verige blokov, saj na ta naˇcin s krajˇso pogodbo na verigi blokov prihranimo dragocen prostor. Tezosovi standardi niso statiˇcni, temveˇc se skozi ˇcas spreminjajo in nadgrajujejo. Predlogi za nove standarde so opisani v oˇstevilˇcenih dokumentih TZIP.
Delovanje Tezosovih transakcij smo raziskali v fazi analize 6.1 pred objavo pame-tnih pogodb. Operacije glavnih standardov FA1.2 in FA2 so naˇstete za celosten pregled
testiranih operacij. Za laˇzjo primerjavo uporabe in stroˇskov smo izbrali podobne ope-racije obeh standardov.
Poglavje 4
Orodja in tehnologije
Programska oprema v Tezosovem vozliˇsˇcu, ki je razvita v jeziku OCaml [10], je odpr-tokodna. Ocaml je funkcijski programski jezik, ki se uporablja v kritiˇcnih panogah, ki zahtevajo formalne dokaze lastnosti programov. Programske komponente v vozliˇsˇcu so sestavljene iz OPAM [11] modulov. OPAM je upravitelj paketov za programski jezik Ocaml. Module lahko delimo na tri naˇcine:
• moduli lupine in moduli ekonomskega protokola;
• od Unixa odvisni moduli in moduli, zdruˇzljivi z JavaScriptom;
• ter moduli knjiˇznice in moduli z vmesnikom ukazne vrstice.
4.1 Arhitektura vozliˇ sˇ ca
Lupina v Tezosovem vozliˇsˇcu deluje kot streˇznik, ki odgovarja na poizvedbe in zahteve odjemalcev [21]. Takˇsne poizvedbe in zahteve se izvajajo s klici RPC. Odjemalec lahko poizveduje po stanju verige blokov ter v vozliˇsˇce vnaˇsa nove bloke in operacije.
Primer posebnega odjemalca je pek, ki je povezan s privatnimi kljuˇci delegata in lahko podpisuje bloke in operacije.
Glavni razlog za uporabo arhitekture odjemalec-streˇznik je varnost. Cilj je izoli-rati komponento, ki ima dostop do odjemalˇcevih kljuˇcev, od komponente, ki potrebuje internet. Vozliˇsˇce in pek sta poslediˇcno lahko na razliˇcnih napravah, tako da pek ni izpostavljen internetu. Vozliˇsˇce torej upravlja vso komunikacijo in ˇsˇciti peka pred omreˇznimi napadi, pek pa hrani skrivnosti in dodaja podpisane bloke v verigo blokov.
Podobno razmerje lahko za poveˇcano varnost vzpostavimo tudi z drugimi odjemalci, ki opravljajo s privatnimi kljuˇci ali pa delujejo na loˇceni napravi zaradi viˇsjih perfor-manˇcnih zahtev.
21
Druga prednost te arhitekture je moˇznost razliˇcnih implementacij pekov, kar omo-goˇca, da lahko posamezni peki izvajajo razliˇcne strategije za izbiranje transakcij.
Slika 4.1: Diagram arhitekture programske opreme vozliˇsˇca.
Na sliki 4.1 vidimo, kako lupina simboliˇcno objema ekonomski protokol skupaj z validatorjem in porazdeljeno podatkovno bazo (ang. distributed database ali DDB).
Ekonomski protokol vedno vidi le eno verigo blokov, torej linearno zaporedje blokov od nastanka. Ne zaveda se, da deluje v odprtem omreˇzju, kjer lahko druga vozliˇsˇca predlagajo alternativne veje verige blokov.
Za veˇc vej ve samo lupina, ki je odgovorna za izbiro in prenos alternativnih verig, katere posreduje ekonomskemu protokolu, ta pa je odgovoren, da jih preveri za napake in jim dodeli absolutno oceno. Lupina nato preprosto izbere veljavno glavo z najviˇsjo absolutno oceno. Ta del lupine se imenuje validator.
Preostali del lupine vkljuˇcuje plast za medsebojno povezovanje, shranjevanje blo-kov na disku, operacije, ki vozliˇsˇcu omogoˇcajo prenos podatkov o verigi novim vo-zliˇsˇcem, in stanje glavne knjige (ang. ledger). Validator je pomoˇzni prikriti proces, ki ga zaˇzene vozliˇsˇce, da bi validiralo operacije vzporedno s svojim glavnim procesom (razen, ˇce je podana moˇznost --singleprocess). Poleg tega vstavlja veljavne operacije v blok in raˇcuna posodobljeno stanje. Uporabnik ga ne more uporabiti neposredno.
Med validatorjem in P2P modulom se nahaja programska komponenta, imenovana po-razdeljena podatkovna baza, ki za validatorja abstrahira pridobivanje in posredovanje novih podatkov na verigi.
Ko je ˇcas za nov ekonomski protokol, se ta zgradi z uporabo specializiranega pre-vajalnika OCaml (zeleni del na levi strani slike 4.1). Prva vloga prepre-vajalnika je, da
Diplomska naloga 23 preveri, ali ima glavni modul protokola pravi tip. Ker se protokoli menjajo, lahko nanj gledamo kot na vtiˇcnik, v tem primeru pa to pomeni, da mora spoˇstovati skupni vmesnik vtiˇcnikov. To je oblika statiˇcno uveljavljenega peskovnika. Druga vloga pre-vajalnika je, da omeji okolje protokola, tako da ta lahko dostopa le do pooblaˇsˇcenih modulov in funkcij iz standardne knjiˇznice.
V Tezosovem repozitoriju imamo veˇc vrst ekonomskih protokolov. Izvirni protokol, imenovan tezos-protocol-genesis, je protokol izvirnega bloka. Sprejme en sam blok, ki ga podpiˇse aktivator, katerega javni kljuˇc je trdno zakodiran in katerega edino dejanje je preklop na nov protokol, ki ga izbere aktivator. Glavna veja repozitorija vsebuje dodatne razliˇcice izvirnega protokola, po eno za vsako od obstojeˇcih testnih omreˇzij.
Aktivni protokol je bodisi trenutni protokol v glavnem omreˇzju bodisi protokol, ki je bil v nekem trenutku aktiven v glavnem omreˇzju. Nosijo posebno shemo poimenovanja tezos-protocol-nnn-hhhhhhhh, kjer je nnn ˇstevec, ki se zaˇcne pri 0, in hhhhhhhhh je predpona rezultata zgoˇsˇcevalne funkcije protokola (ang. protocol hash). Tudi tezos-protocol-alpha, ki je implementacija izvirnega protokola, opisanega v poglavju 3.2, je kljub zapadlosti ˇse vedno v glavni veji repozitorija. Vse protokole, ki so bili kadar koli aktivni v glavnem omreˇzju, moramo obdrˇzati v vozliˇsˇcu, da lahko preverimo veljavnost verige blokov vse od izvirnega bloka do najnovejˇsega bloka v omreˇzju.
Demonstracijski protokol, imenovan tezos-protocol-demo-noops, nima operativne vloge, vendar ima pravo obliko, ker sluˇzi kot primer pravilno zasnovanega protokola.
tezos-protocol-demo-counter je ˇse en demonstracijski protokol, v katerem lahko bloki vsebujejo preproste operacije, vendar ni namenjen za uporabo v glavnem omreˇzju.
Pomemben del vozliˇsˇca je tudi sloj RPC, saj omogoˇca, da lahko odjemalci, prikriti procesi in aplikacije tretjih oseb komunicirajo z vozliˇsˇcem in pregledujejo njegovo stanje (rumeni del na desni strani slike 4.1). Ta komponenta uporablja sploˇsno razˇsirjeno obliko JSON in protokol HTTP. Prikriti proces peka potrebuje dodaten direkten dostop do podatkov v vozliˇsˇcu zaradi performanˇcnih razlogov. ˇCe bi proces uporabljal le RPC klice, ne bi deloval dovolj hitro. Naloge peka, potrjevalca in obtoˇzevalca so opisane v poglavju 3.3.1.
Glavni odjemalec se uporablja za interakcijo z vozliˇsˇcem in za upravljanje z lokal-nimi denarnicami. Preko ukazne vrstice lahko poizvedujemo po stanju verige blokov ali zahtevamo nekatera dejanja. Omogoˇca kreiranje privatnega kljuˇca iz katerega so izpeljani javni kljuˇci in naslovi denarnice. Uporabljamo ga lahko tudi za poˇsiljanje, simuliranje in validacijo transakcij. Po vsaki opravljeni ali simulirani operaciji se v ter-minalu izpiˇse raˇcun, ki opisuje podroben izraˇcun vseh vkljuˇcenih stroˇskov operacije.
Razvijalci Tezosovih denarnic z grafiˇcnim uporabniˇskim vmesnikom lahko to
program-sko komponento uporabijo v zaledju aplikacije za laˇzjo implementacijo z vozliˇsˇcem.
Odjemalec upravitelja se uporablja za administracijske poizvedbe na vozliˇsˇcu. Med drugim omogoˇca interakcijo s plastjo P2P, zato lahko preveri trenutno stanje povezanih vrstnikov, prisili povezave z znanimi vrstniki in prepove povezave z zlonamernimi.
Uporaben ukaz za odpravljanje napak v vozliˇsˇcu, ki ima teˇzave s sinhronizacijo, je tezos-admin-client p2p stat, saj prikaˇze stanje vseh obstojeˇcih P2P povezav.
Skupna prednost izbrane arhitekture je modularnost, formalizacija, poenoten pro-gramski jezik in visoka prilagodljivost posameznih propro-gramskih komponent v vozliˇsˇcu.
Podroben pregled arhitekture vozliˇsˇca omogoˇca boljˇso predstavo uporabljene program-ske opreme in njenih komponent v petem poglavju, kjer opisujemo postavitev vozliˇsˇca.