Univerza v Ljubljani
Fakulteta za raˇ cunalniˇ stvo in informatiko
Avguˇstin Kastelic
Postavitev vozliˇ sˇ ca in analiza verige blokov Tezos
DIPLOMSKO DELO
VISOKOˇSOLSKI STROKOVNI ˇSTUDIJSKI PROGRAM PRVE STOPNJE
RA ˇCUNALNIˇSTVO IN INFORMATIKA
Mentor : prof. dr. Vlado Stankovski
Ljubljana, 2022
tov diplomske naloge je potrebno pisno privoljenje avtorja, Fakultete za raˇcunalniˇstvo in informatiko ter mentorja.
Fakulteta za raˇcunalniˇstvo in informatiko izdaja naslednjo nalogo:
Tematika naloge:
V diplomski nalogi je predstavljen postopek postavitev vozliˇsˇca in analiza verige blokov Tezos. Opisana je arhitektura z razlago vlog posameznih akterjev v sistemu. Obravna- vana je tema raˇcunalniˇske varnosti, potrjevanje transakcij, obdelava pametnih pogodb ter upravljanje z decentralizirano organizacijo. Predstavljeni so primeri uporabe.
Kazalo
Povzetek Abstract
1 Uvod 1
1.1 Predstavitev domene . . . 1
1.2 Cilji diplome . . . 1
1.3 Pregled sorodnih del . . . 2
1.4 Struktura diplome . . . 2
2 Pregled stanja 5 3 Tezos 7 3.1 Samonadgrajujoˇca veriga blokov . . . 7
3.1.1 Omreˇzni protokol in omreˇzna lupina . . . 8
3.1.2 Transakcijski protokol . . . 9
3.1.3 Protokol soglasja . . . 9
3.2 Izviren protokol . . . 10
3.3 Likviden dokaz o deleˇzu . . . 10
3.3.1 Ustvarjanje blokov . . . 11
3.3.2 Inflacijski model . . . 14
3.3.3 Stroˇski operacij na verigi blokov . . . 14
3.3.4 Validacija operacij . . . 15
3.4 Potek glasovanja . . . 16
3.4.1 Faze glasovanja . . . 16
3.5 Prenos sredstev in pametne pogodbe . . . 17
4 Orodja in tehnologije 21 4.1 Arhitektura vozliˇsˇca . . . 21
4.2 Tehnologije pametnih pogodb . . . 24
5.2 Naˇcrtovanje . . . 28
5.3 Nameˇsˇcanje strojne in programske opreme . . . 29
5.3.1 Nameˇsˇcanje strojne opreme . . . 29
5.3.2 Nameˇsˇcanje in nastavljanje operacijskega sistema . . . 29
5.3.3 Nameˇsˇcanje Tezosove programske opreme . . . 30
5.3.4 Registracija vozliˇsˇca . . . 31
5.3.5 Nastavitve vozliˇsˇca . . . 31
5.4 Registracija delegata in delegacije . . . 32
5.5 Vzdrˇzevanje vozliˇsˇca . . . 34
5.6 Testiranje delovanja vozliˇsˇca . . . 35
6 Izvajanje pametnih pogodb 39 6.1 Analiza . . . 39
6.2 Naˇcrtovanje . . . 40
6.3 Testiranje in cena operacij . . . 41
6.3.1 Ustvarjanje denarnic na glavnem omreˇzju . . . 41
6.3.2 Testiranje pametne pogodbe s standardom FA1.2 . . . 41
6.3.3 Testiranje pametne pogodbe s standardom FA2 . . . 45
6.3.4 Pregled stroˇskov vseh izvedenih operacij . . . 46
7 Zakljuˇcek 49
Literatura 51
Seznam uporabljenih kratic
kratica angleˇsko slovensko
P2P peer to peer enak z enakim
ICO initial coin offering prva ponudba kovancev
PoS proof of stake dokaz o deleˇzu
LPoS liquid proof of stake likviden dokaz o deleˇzu DPoS delegated proof of stake delegiran dokaz o deleˇzu RPC remote procedure call oddaljeni klic podprograma DDB distributed database porazdeljena podatkovna baza API application programming interface aplikacijski programski vmesnik UTXO unspent transaction output neporabljen znesek transakcije TZIP Tezos improvement proposal predlog za izboljˇsanje Tezosa OPAM OCaml package manager upravitelj paketov OCaml RPC remote procedure call klic oddaljenega postopka SSH secure shell protocol protokol varne lupine KVM kernel-based virtual machine jedrna navidezna naprava
IP internet protocol internetni protokol
APT advanced package tool napredno orodje za pakete
NFT non-fungible token nedeljiv ˇzeton
FA1.2 financial application 1.2 finanˇcna aplikacija 1.2 FA2 financial application 2 finanˇcna aplikacija 2
Povzetek
Naslov: Postavitev vozliˇsˇca in analiza verige blokov Tezos Avtor: Avguˇstin Kastelic
Tehnologija verige blokov zajema domene kriptografije, raˇcunalniˇskih omreˇzij in raˇcu- nalniˇske varnosti. Od leta 2008 je napredovala skozi tri generacije in mnoge primere uporabe. Vsaka generacija na izviren naˇcin nadgrajuje prejˇsnjo, vendar osnovna ideja decentraliziranega sistema, ki omogoˇca soglasje brez zaupanja med posameznimi ak- terji, ostaja enaka. Cilj diplomske naloge je analiza Tezosove verige blokov, postavitev vozliˇsˇca in objava pametnih pogodb. Opisali smo stanje tehnologije verige blokov, teorijo Tezosovega sistema, njegove protokole in sodoben algoritem soglasja, zaradi katerega je uvrˇsˇcen v tretjo generacijo tehnologije verige blokov. Vozliˇsˇca smo posta- vili na samostojnem streˇzniku, ki gostuje dve navidezni napravi za Tezosovo vozliˇsˇce na glavnem in testnem omreˇzju. Testirali smo tudi objavo in uporabo Tezosovih pa- metnih pogodb s standardi FA1.2 in FA2. Rezultati diplomske naloge koristijo vsem, ki jih zanima delovanje in razvoj na verigi blokov Tezos.
Kljuˇcne besede: Tezos, tehnologija verige blokov, likviden dokaz o deleˇzu, postavitev vozliˇsˇca, ustvarjanje in potrjevanje blokov, objava pametnih pogodb.
Abstract
Title: Node setup and analysis of the Tezos blockchain Author: Avguˇstin Kastelic
Blockchain technology includes the domains of cryptography, computer networks, and security. Since 2008, it has progressed through three generations and many differ- ent use cases. Each generation builds on the previous one in an original way, but the basic idea of a decentralized system that allows consensus without trust between individual actors remains the same. The aim of this thesis is to analyze the Tezos blockchain, evaluate Tezos node and smart contracts. The publication describes the state of blockchain technology, the theory of the Tezos system, its protocols, and the modern consensus algorithm that makes it a third-generation blockchain technology.
A stand-alone server was set up to host two virtual machines for two Tezos nodes on the mainnet and testnet. The origination and use of Tezos smart contracts were tested with FA1.2 and FA2 standards. The results of this publication could be valuable to anyone interested in the development on the Tezos blockchain.
Keywords: Tezos, blockchain technology, liquid proof of stake, node setup, baking and endorsing blocks, smart contracts origination.
Poglavje 1 Uvod
1.1 Predstavitev domene
Kriptovalute so se razvile iz potrebe po elektronskem denarju. Opravljajo razliˇcne funkcije denarja kot menjalni posrednik, plaˇcilno sredstvo, merilo vrednosti, hranilec vrednosti in svetovni denar. Mnoge kriptovalute temeljijo na tehnologiji verige blo- kov. Tehnologija verige blokov zajema domene kriptografije, raˇcunalniˇskih omreˇzij in raˇcunalniˇske varnosti. Opisuje decentraliziran sistem raˇcunalnikov, ki omogoˇca nepo- sredno izmenjavo informacij. Informacije so razdeljene v sekvenˇcne bloke, kjer se lahko hrani stanje posameznih raˇcunov, veljavne transakcije, pametne pogodbe ali drugi podatki. Bitcoin je kriptovaluta prve generacije, ki uporabnikom omogoˇca finanˇcno neodvisnost brez centralne organizacije. Razvila ga je anonimna oseba ali skupina s psevdonimom Satoshi Nakamoto, ki je v beli knjigi predstavila odprtokoden proto- kol za prenos in ustvarjanje sredstev. Ima visoko deljivost, prenosljivost, vzdrˇzljivost, prepoznavnost in predvidljivo ponudbo novih kovancev. Predstavnik druge generacije kriptovalut je Ethereum. Poleg transakcij hrani tudi metapodatke o transakcijah in pametne pogodbe. Tretja generacija uporablja bolj uˇcinkovit algoritem za usklajevanje informacij v decentraliziranem sistemu, reˇsuje tudi problem skalabilnosti in omogoˇca laˇzjo nadgradljivost. Lastnosti tretje generacije bomo v diplomski nalogi raziskali na primeru Tezos.
1.2 Cilji diplome
Diplomska naloga raziskuje arhitekturo verige blokov Tezos z razlago vlog posame- znih akterjev v sistemu. Akterje bomo analizirali pri potrjevanju transakcij in obde- lavi pametnih pogodb. Pomemben del sistema so vozliˇsˇca, ki so povezana v omreˇzje
1
enakovrednih vrstnikov P2P. Opisan bo pristop usklajevanja informacij v omreˇzju in predstavljen postopek postavitev vozliˇsˇca z naˇceli raˇcunalniˇske varnosti. Pri razlagi pametnih pogodb bomo pregledali in izvedli operacije na dveh konkretnih primerih.
Govorili bomo tudi o naˇcinih pridobivanja in hranjenja informacij, ki se uporabljajo za pametne pogodbe. Primerjali bomo lahko cene posameznih operacij na verigi blokov in razloˇzili, zakaj stanejo kolikor stanejo. Raziskali bomo tudi faze glasovanja v Tezosovi decentralizirani organizaciji, ki skrbi za nadaljnji razvoj projekta.
Prvi rezultat diplomske naloge bo vzpostavljeno vozliˇsˇce na streˇzniku, ki ustrezno sodeluje pri zaˇsˇciti omreˇzja Tezos. Uˇcinkovitost bomo merili tako, da bomo primer- jali ˇstevilo dodeljenih blokov s ˇstevilom uspeˇsno ustvarjenih blokov. Drugi rezultat bo dokumentiran postopek objave in opravljanja operacij na primeru dveh pametnih pogodb. Rezultati bodo koristili tistim, ki ˇzelijo vedeti, kako deluje in kako sodelovati v verigi blokov Tezos.
1.3 Pregled sorodnih del
Med pregledanimi publikacijami sorodnih del lahko izpostavimo dve relevantni razi- skavi. Prva publikacija [28] sploˇsno opisuje tehnologijo veriˇzenja blokov. Piˇse o zgodo- vini kriptovalut, kjer navede razloge za nastanek in osnovne principe gibanja. Povezuje koncepte tehnologije veriˇzenja blokov in podrobno razlaga decentralizacijo, psevdoni- mnost, transparentnost in nespremenljivost blokov. Nadaljuje z arhitekturo veriˇzenja blokov, kjer opiˇse vozliˇsˇca, transakcije, bloke, kljuˇce in naslove. Kljuˇcni del so tudi varnostni mehanizmi tehnologije veriˇzenja blokov. Zakljuˇci z razliˇcnimi domenami tehnologije veriˇzenja blokov in njihovim potencialom.
Druga publikacija [35] opisuje razvoj aplikacije na Ethereum verigi blokov. Razlo- ˇ
zena je arhitektura in delovanje Ethereum omreˇzja, navedena so tudi uporabljena orodja in programski jezik. Poglobi se v razvoj aplikacije za mnoˇzico prodajnih ˇzetonov ter analizira ˇcas razvoja, hitrost postavitve vozliˇsˇca in teˇzave pri razvoju.
1.4 Struktura diplome
V uvodnem delu diplomske naloge so predstavljeni domena, cilji, sorodna dela in struk- tura diplome. Drugo poglavje vsebuje pregled stanja kriptovalut s kratko zgodovino tehnologije verige blokov. Tretje poglavje zajema teorijo celotnega Tezosovega sistema.
Zaˇcne se z razlago razliˇcnih protokolov, ki ga sestavljajo, nato predstavi Tezosov al- goritem soglasja – likviden dokaz o deleˇzu, ki zajema podroˇcje ustvarjanja blokov,
Diplomska naloga 3 nagrad in stroˇskov. Nadaljuje se z opisom posameznih faz glasovanja in zakljuˇci s podpoglavjem o pametnih pogodbah. Cetrto poglavje predstavi orodja in tehnolo-ˇ gije v Tezosovem sistemu. Sprva se poglobi v arhitekturo vozliˇsˇca, nato pa naˇsteje ˇse razliˇcne tehnologije pametnih pogodb. Peto poglavje opisuje analizo, naˇcrtovanje, nameˇsˇcanje, vzdrˇzevanje in testiranje strojne in programske opreme Tezosovega vo- zliˇsˇca. Zadnjo poglavje na podoben naˇcin predela ˇse postopek objave in interakcije dveh pametnih pogodb. Vsebuje tudi pregled stroˇskov vseh izvedenih operacij. V zakljuˇcku so navedene sklepne ugotovitve diplomske naloge.
Poglavje 2
Pregled stanja
Tehnologija verige blokov je od leta 2009, ko je bila objavljena prva verzija Bitcoinove programske opreme, moˇcno napredovala [37]. Z napredkom se je spremenilo tudi javno mnenje o tehnologiji. Bitcoin se je najprej razˇsiril v krogu kriptografov, ki so ga spre- jeli z zanimanjem in sodelovanjem. Tako se je oblikovala prva skupina uporabnikov, ki so s sodelovanjem v P2P omreˇzju pomagali vzpostaviti prvo digitalno, decentra- lizirano in javno knjigo transakcij. Rudarjenje nagrad je bilo na zaˇcetku enostavno tudi z vsakdanjo raˇcunalniˇsko opremo in mnogi uporabniki so se gibanju prikljuˇcili iz radovednosti.
Skeptiki so zaˇceli Bitcoin primerjati s piramidno shemo, kjer je Satoshi Nakamoto na samem vrhu. Cena Bitcoina je z visokim nihanjem vseeno rasla, ko so se oblikovale prve spletne menjalnice leta 2010, kjer so lahko uporabniki virtualne ˇzetone kupovali in prodajali za pravi denar. Zaradi anonimne narave uporabnikov je bila v oˇceh medijev celotna tehnologija verige blokov primerna samo za nelegalne dejavnosti. Leta 2011 so se oblikovali prvi alternativni ˇzetoni, ki so z razliˇcnimi pristopi poskuˇsali izboljˇsati Bitcoin [30]. Prevare in vdori med projekti alternativnih ˇzetonov so bili pogosti, kar je upoˇcasnjevalo sprejetje tehnologije verige blokov. Kljub temu so visoki potencialni donosi in osnovna ideja decentralizacije pripeljali mnoˇzico novih uporabnikov. Do leta 2014 je cena Bitcoina iz 0,09 USD zrasla na veˇc kot 1000 USD [31]. Belo knjigo Ethereuma je Vitalik Buterin objavil leta 2013, ko je predstavil idejo za verigo blokov z vgrajenim programskim jezikom, ki se lahko uporablja za pisanje pametnih pogodb.
Leta 2015 pa je izˇsla prva verzija programske opreme. Ethereum je z inovacijami pametnih pogodb in aktivno decentralizirano organizacijo oblikoval drugo generacijo kriptovalut, medtem pa se je razvoj Bitcoina zaradi nesoglasja med rudarji in razvijalci upoˇcasnil. Funkcija Bitcoina se je iz digitalnega denarja preoblikovala v finanˇcno sredstvo za shranjevanje vrednosti, varovanje pred inflacijo in trˇzno negotovostjo.
5
Med vzponom prve in druge generacije so okoljevarstveniki zaˇceli opozarjati na koliˇcino elektriˇcne energije, ki je porabljena za dokaz o delu. Tako se je pojavila priloˇznost za tretjo generacijo kriptovalut, ki za algoritem soglasja uporablja alterna- tivne pristope z manjˇso porabo energije. Med prvimi projekti, ki so poskusili oblikovati novo generacijo verige blokov, je bil tudi Tezos in z njim se je izboljˇsalo tudi javno mnenje o tehnologiji verige blokov. Zagotovil je tudi upravljanje decentralizirane orga- nizacije na verigi blokov in formalizacijo programske kode. Tehnologija verige blokov danes igra pomembno vlogo na podroˇcju dobavnih verig in ˇcezmejnih plaˇcil. Upo- rablja se tudi za varovanje osebnih in zdravstvenih podatkov ter sledljivost izdelkov [37]. Odprtokodne decentralizirane aplikacije oblikujejo zaupanje uporabnikov z viˇsjo stopnjo preglednosti in predvidljivosti od centraliziranih aplikacij.
Pregled stanja tehnologije verige blokov nam pomaga razumeti, zakaj smo za ana- lizo izbrali Tezos in kaj je vplivalo na nekatere odloˇcitve pri oblikovanju nove generacije kriptovalut. Tabela 2.1 v ta namen prikazuje tudi lastnosti Bitcoina, Ethereuma in Tezosa. Tezos je v primerjavi s sistemi Bitcoin in Ethereum boljˇsi na podroˇcjih:
• nadgradljivost, saj z upravljanjem decentralizirane organizacije na verigi blokov omogoˇca redne in usklajene nadgradnje protokola;
• razˇsirljivost, saj so samostojne programske komponente oblikovane v nadgradlji- vih modulih;
• poraba energije, saj uporablja uˇcinkovitejˇsi algoritem soglasja;
• formalizacija kode, saj lahko s sklepanjem temeljnih resnic in manipulacijo for- malnih izrazov, ki predstavljajo ukaze v kodi, izpeljemo dokaz pravilnosti kode.
Bitcoin Ethereum Tezos
Simbol BTC ETH XTZ
Zaˇcetek delovanja jan 2009 jul 2015 sep 2018
Algoritem soglasja PoW PoW LPoS
Letna poraba energije 160 TWh 75 TWh 0.000277 TWh
Upravljanje izven verige izven verige na verigi
Formalizacija kode ne ne da
Povpreˇcen ˇcas bloka 10 min 13 sek 1 min
Najveˇcja velikost bloka 1 MB 80 KB 500 kB
Tabela 2.1: Tabela lastnosti razliˇcnih tehnologij verige blokov.
Poglavje 3 Tezos
Da bi laˇzje razumeli delovanje Tezosovega sistema, moramo najprej predstaviti kratko zgodovino, terminologijo in glavne protokole, ki ga oblikujejo. Tezos je decentralizirana veriga blokov, ki omogoˇca neposredne transakcije in sluˇzi kot platforma za izvrˇsevanje pametnih pogodb [36]. Izvorna kriptovaluta na verigi blokov je tez s simbolom XTZ.
Uporablja odprtokoden algoritem za usklajevanje informacij imenovan dokaz o deleˇzu.
Tezos je bil prviˇc omenjen 3. avgusta 2014 v dokumentu [32], ki je opisoval takratne probleme Bitcoin omreˇzja in predlagane reˇsitve. Bela knjiga [33] je bila objavljena 2. septembra 2014. Oba dokumenta je napisal Arthur Breitman in jih objavil pod psevdonimom LM Goodman. Aprila 2017 je bila v ˇSvici ustanovljena neprofitna or- ganizacija, namenjena podpori pri razvoju Tezosa in sorodnih tehnologij, imenovana Tezos Foundation. Organizacija je julija 2017 na zaˇcetni ponudbi kovancev (ang. ini- tial coin offering ali ICO) zbrala 232 milijonov dolarjev [34]. Prvo testno omreˇzje je bilo vzpostavljeno v juliju 2018, glavno omreˇzje pa deluje od septembra 2018.
3.1 Samonadgrajujoˇ ca veriga blokov
Protokol verige blokov sestavljajo trije neodvisni protokoli:
• omreˇzni protokol odkriva nove bloke in posreduje transakcije;
• transakcijski protokol doloˇca pravila veljavne transakcije;
• protokol soglasja skrbi za usklajevanje informacij v verigi blokov.
Transakcijski protokol in protokol soglasja skupaj lahko imenujemo tudi protokol verige blokov [33]. Posamezne protokole lahko loˇceno nadgradimo ali zamenjamo, saj neodvisno opravljajo svoje naloge. Za tovrstne spremembe poteka glasovanje na verigi blokov, ki je bolj podrobno opisano v poglavju 3.4.
7
3.1.1 Omreˇ zni protokol in omreˇ zna lupina
Tezos implementira omreˇzni protokol v omreˇzni lupini, ki ne vpliva na transakcij- ski protokol ali na protokol soglasja [32]. Omreˇzna lupina tako neodvisno povezuje omreˇzje enakovrednih vrstnikov in s tem omogoˇca nemoteno delovanje protokola ve- rige blokov. Najzahtevnejˇsa funkcija omreˇzne lupine je, da zavaruje vozliˇsˇca pred napadom za zavrnitev storitve. Za izboljˇsanje raˇcunalniˇske varnosti na vozliˇsˇcu je kljuˇcno razumeti lastnosti omreˇzne lupine, saj moramo vedeti, katerim napadom smo z izbranim omreˇznim protokolom izpostavljeni. Ker je IP naslov in namen streˇznika v omreˇzju enakovrednih vrstnikov enostavno odkriti, moramo za zaˇsˇcito pred vdorom namestiti dodatno varnostno programsko opremo, namen katere je opisan v petem poglavju pri postavitvi vozliˇsˇca. Omreˇzni protokol oblikuje koncepta transakcije in blokov, transakcija pa je zapis spremembe globalnega stanja v omreˇzju. Vozliˇsˇce lahko transakcijo ustvari samo ali pa je poslana iz drugega vozliˇsˇca. ˇCe je transakcija ve- ljavna, je posredovana naprej po omreˇzju. Novo ustvarjene transakcije zdruˇzujemo v bloke, ti pa so povezani v verigo blokov. Bloki, katerih ˇcasovni ˇzig je le nekaj minut v prihodnosti, se v vozliˇsˇcu hranijo, ostali pa so zavrˇzeni. Protokol mora upoˇstevati, da lahko na drugih vozliˇsˇcih pride do ˇcasovnega zamika in da je lahko ˇcasovni ˇzig v bloku ponarejen. Da ˇsˇciti pred napadom za zavrnitev storitve, doloˇca tudi primerno velikost transakcij in blokov.
V omreˇzju se lahko zaradi nesoglasja med vozliˇsˇci iz verige blokov oblikuje veˇc vilic (ang. forks). Vsakemu bloku pripiˇsemo ustreznost, ki doloˇca kakovost verige, ki vodi do tega bloka. To merilo se izraˇcuna s pravili v protokolu soglasja. V vozliˇsˇcu ne hranimo celotnega drevesa blokov, saj bi bili s tem izpostavljeni napadu za zavrnitev storitve, kjer napadalec proizvede veliko ˇstevilo nizko ocenjenih veljavnih vej. Omreˇzna lupina vzdrˇzuje le najbolj primerno verigo blokov, ki je znana vozliˇsˇcu. Pri tem mora upoˇstevati, da lahko zlonamerno vozliˇsˇce posreduje ponarejeno oceno veljavnosti nove veje. Poslediˇcno sosednje vozliˇsˇce procesira bloke na napaˇcni verigi, vendar protokol narekuje, da nizko ocenjene verige proizvedejo manjˇse ˇstevilo blokov. Vozliˇsˇce po nekaj prejetih blokih odkrije ponarejeno oceno verige. Omreˇzni protokol poskuˇsa povezati ˇ
cim veˇcje ˇstevilo vozliˇsˇc, vendar zazna odklopljena in blokira zlonamerna vozliˇsˇca.
Spremembe v omreˇznem protokolu so razmeroma nesporne. Sprva se lahko po- javijo nesoglasja, vendar so na sploˇsno interesi razliˇcnih akterjev v sistemu na tem podroˇcju usklajeni. Prav tako ni nujno, da vsi akterji sledijo spremembam soˇcasno.
Ceprav zdravo omreˇˇ zje zahteva poenoten pristop ter konkurenˇcne inovacije omreˇznega protokola, na sploˇsno krepijo kriptovaluto.
Diplomska naloga 9
3.1.2 Transakcijski protokol
Translacijski protokol opisuje pravila veljavne transakcije [32]. V njem so zapisane vse informacije o verigi blokov, zlasti tiste, ki so pomembne za interakcijo med vozliˇsˇci.
Opisuje dejavnosti verige blokov in transakcij. Vsaka transakcija vsebuje poljubno mnogo operacij, ki premaknejo tez med raˇcuni ali izvedejo kodo pametne pogodbe.
Spremembe protokola transakcij so bolj sporne kot spremembe omreˇznega pro- tokola. Medtem ko lahko majhna skupina akterjev enostransko zamenja algoritem v omreˇzni lupini, je sprememba protokola transakcij bolj zapletena. Zahteva sodelovanje veˇcine rudarjev, kar imenujemo mehka vilica (ang. soft fork). Mehka vilica pogosto ne vpliva na lahke odjemalce konˇcnih uporabnikov, temveˇc le na kljuˇcne akterje v sistemu, ki upravljajo vozliˇsˇca.
Teˇzavnost posodabljanja posameznih protokolov moramo upoˇstevati pri naˇcrto- vanju vzdrˇzevanja vozliˇsˇca, da ne zamudimo kljuˇcnih posodobitev. V poglavju 5.5 je naveden primer, kjer smo morali prekiniti delovanje vozliˇsˇca in posodobiti programsko opremo pred mehko vilico v omreˇzju, da smo lahko nadaljevali s peko blokov brez prekinitev.
3.1.3 Protokol soglasja
Protokol soglasja omogoˇca, da platforma doseˇze soglasje pri globalnem stanju verige blokov [32]. Opisuje, kako vozliˇsˇca skupaj doloˇcijo in gradijo na najbolj kakovostni verigi blokov. Doloˇca tudi, kdaj je posamezno vozliˇsˇce na vrsti, da proizvede nov blok. Vsak protokol soglasja za doloˇcanje teh pravil uporablja algoritmom soglasja.
V Tezosovem primeru je to likviden dokaz o deleˇzu (ang. liquid proof of stake ali LPoS), ki je opisan v poglavju 3.3. Z uporabo tega protokola poteka tudi glasovanje za vsako spremembo, dodatek ali nadgradnjo Tezosove verige blokov. Da lahko glasovanje poteka na decentraliziran naˇcin v verigi blokov, mora programski jezik OCaml [10], ki ga uporablja Tezos, prepoznati tri glavne elemente na verigi blokov: transakcije, bloki in razliˇcni protokoli. Kateri koli modul, ki je napisan v OCalm in je implementiran v verigi blokov, se lahko posodobi.
Protokol soglasja je osrednji protokol, ki ga je najteˇzje spreminjati; pogosto zahteva trdo vilico (ang. hard fork), ki razveljavi stare bloke. Trda vilica zahteva, da vsi akterji v sistemu programsko opremo posodobijo na najnovejˇso verzijo.
3.2 Izviren protokol
Izviren protokol je zaˇcetni nabor protokolov, ki je bil predstavljen v Tezosovi beli knjigi [33]. Ta protokol je upravljal Tezosovo verigo blokov pred prvim glasovanjem za posodobitve. Doloˇcil je zaˇcetna pravila in parametre protokola na podroˇcju ekonomije, pametnih pogodb ter prvotni mehanizem za doloˇcanje soglasja. Doloˇcene trditve in predpostavke v beli knjigi so bile sˇcasoma popravljene. Zapisali so, da bodo verigo blokov zaˇceli z desetimi milijardami kovancev, dodan pa je bil popravek, da je ˇstevilo zaˇcetnih kovancev odvisno od prodaje na zaˇcetni ponudbi kovancev. Podobno so tudi prvoten predlog dveh decimalnih mest spremenili na osem decimalnih mest, s ˇ
cimer so poveˇcali razdeljivost kovanca. Da bi lahko ˇze v prvem letu vpeljali ˇcim veˇc sprememb protokola, so skrajˇsali dolˇzino volilnega cikla. Zaradi dodeljevanja blokov neaktivnim denarnicam in zaradi negotovosti glede stopnje udeleˇzbe na glasovanjih so doloˇcili, da so vse leto dni neaktivne denarnice izbrisane skupaj z vsebovanimi ˇ
zetoni. Pravilo so posodobili, tako da neaktivni naslovi ne bodo izbrisani, temveˇc bodo izkljuˇceni le iz seznama delegatov, ki so opraviˇceni za ustvarjanje blokov, in jim ne bo dovoljeno glasovati, dokler ne bodo ponovno aktivirani. Izviren protokol je tako po nekaj spremembah postal temelj pri oblikovanju prvega testnega omreˇzja.
3.3 Likviden dokaz o deleˇ zu
Obstaja mnogo algoritmov soglasja in vsi imajo svoje prednosti in slabosti. Pri obli- kovanju posameznih algoritmov soglasja si pomagamo s teorijo iger, kjer oblikujemo doloˇcene predpostavke o racionalnem obnaˇsanju razliˇcnih akterjev v sistemu. Akterji v sistemu so lahko zlonamerni ali praviˇcni, zato mora dober algoritem soglasja predvideti razliˇcne toˇcke napada in opisati, kako jih sistem zavaruje. Ena od pogostih predpo- stavk je, da bo vsaj polovica akterjev oziroma vozliˇsˇc v sistemu ves ˇcas praviˇcnih.
Naloga algoritma je, da pravilno nagradi praviˇcne akterje in kaznuje zlonamerne. Na- grada za poˇsteno sodelovanje mora biti viˇsja od potencialnega dobiˇcka zlonamernih akterjev.
Pri algoritmu soglasja dokaz o delu, ki ga uporablja Bitcoin, so obiˇcajni uporabniki izkljuˇceni iz postopka dodeljevanja blokov, saj ta zahteva visoko porabo energije. Za uspeh pri rudarjenju se morajo rudarji povezati v velike skupine, ki med seboj de- lijo stroˇske in nagrade za proizvedene bloke. Poslediˇcno je omreˇzje zaradi napaˇcnih spodbud v protokolu manj decentralizirano. Koliˇcina porabljene energije zniˇzuje javno mnenje in zavira nadaljnji razvoj Bitcoina.
Diplomska naloga 11 Zaradi teh pomanjkljivosti se je razvila ideja za dokaz o deleˇzu, kjer namesto vi- soke porabe energije akterji v sistemu pravico za izdelavo bloka pridobijo sorazmerno z velikostjo njihovega deleˇza kriptovalute. Poznamo veˇc vrst PoS algoritmov. Najbolj preprosta oblika dokaza o deleˇzu uporabnikom z manjˇsimi sredstvi ne omogoˇca sode- lovanja pri iskanju konsenza in zato se nagrade delijo le med premoˇznejˇse uporabnike.
To teˇzavo reˇsuje delegiran dokaz o deleˇzu, saj vsem uporabnikom omogoˇci delegiranje delegatom, ki so zadolˇzeni za ustvarjanje blokov. Nagrade za ustvarjen blok se so- razmerno delijo med vse delegirane uporabnike. Tezos v protokolu soglasja uporablja algoritem soglasja LPoS. Likviden dokaz o deleˇzu je bil ustvarjen, da bi odpravil po- manjkljivosti navadnega dokaza o deleˇzu in delegiranega dokaza v deleˇzu [29]. LPoS v primerjavi z DPoS zniˇzuje nekatere vstopne zahteve za postavitev vozliˇsˇca in ne ome- juje ˇstevila vozliˇsˇc v omreˇzju. S tem izboljˇsa decentralizacijo, varnost in zanesljivost glasovanja, vendar ˇzrtvuje del hitrosti in razˇsirljivosti.
Tezosov algoritem soglasja LPoS smo raziskali v fazi analize 5.1 pred postavitvijo vozliˇsˇca, saj je pomembno razumeti, kako vpliva na zahteve vozliˇsˇca. Za uspeˇsno Tezosovo vozliˇsˇce ne potrebujemo zmogljivih grafiˇcnih kartic, temveˇc osnovno strojno opremo in ustrezno veliko vsoto tezov.
3.3.1 Ustvarjanje blokov
Uporabniki lahko svoje ˇzetone delegirajo delegatom, ˇce sami ne ˇzelijo ali niso zmoˇzni aktivno sodelovati v algoritmu soglasja. Delegati potrebujejo znanje o gostovanju in raˇcunalniˇski varnosti za upravljanje vozliˇsˇca v omreˇzju. Z delegacijo se prenese samo pravica za ustvarjanje blokov, v zameno pa dobijo sorazmeren del nagrade iz izbranega vozliˇsˇca. Uporabnik lahko delegirane ˇzetone ˇse vedno uporablja enako kot nedelegirane, vendar bo vsaka sprememba stanja vplivala na ˇstevilo delegiranih ˇzetonov.
Da bi vozliˇsˇce uˇcinkoviteje spremljalo stanje raˇcunov za razdelitev pravic do ustvar- janja blokov, so delegirani ˇzetoni zdruˇzeni v zvitke. Vsak zvitek pripada doloˇcenemu delegatu, pravice do peˇcenja pa bodo nakljuˇcno dodeljene tem zvitkom. Velikost zvitka je trenutno doloˇcena na 8000 XTZ, vendar se bo kmalu posodobila na 2000 XTZ.
Delegat pri ustvarjanju blokov sodeluje v treh vlogah:
• pek (ang. baker) ustvarja nove bloke;
• potrjevalec (ang. endorsers) potrjuje veljavne bloke drugih pekov;
• obtoˇzevalec (ang. accuser) spremlja delo drugih pekov in potrjevalcev in prijavi nepravilno vedenje.
Slika 3.1: Diagram akterjev in operacij pri ustvarjanju blokov.
Na enake tri komponente je po modulih razdeljena tudi programska oprema, ki jo delegati gostujejo na vozliˇsˇcih. Vloge delegata in najbolj pogoste operacije so pri- kazane na sliki 3.1. Ko pek ustvarja nove bloke, to dejanje imenujemo peka (ang.
baking). Peki so nakljuˇcno izbrani s seznama vseh vozliˇsˇc, ki so se razglasila za de- legate, sorazmerno s koliˇcino teza, ki ga imajo. Za vsak blok je izbranih veˇc pekov, ki imajo pravico ustvariti blok po prednostnem seznamu. Pek z najviˇsjo prioriteto bo prvi poskusil ustvariti blok. ˇCe mu to ne uspe v doloˇcenem ˇcasovnem roku, bo moˇznost dobil naslednji pek v prioritetnem seznamu. Blok, ki ga ustvari pek, ki nima prednosti, bo neveljaven in ga bo omreˇzje zavrnilo. Preden pek ustvari blok, mora izbrati in validirati vse vsebovane transakcije. Nato lahko zapeˇce naslednji blok in ga doda v verigo ter spremembo stanja v verigi sporoˇci omreˇzju.
Pek je lahko oznaˇcen kot aktiven ali pasiven, a pasivnega peka ni mogoˇce izbrati za peko ali potrjevanje. Pek postane pasiven v ciklu n, ˇce v preteklih petih ciklih ni ustvaril nobenega bloka ali potrditve. Ta mehanizem skrbi, da se novi bloki in potrditve ne dodeljujejo delegatom, ki ne vzdrˇzujejo svojih vozliˇsˇc. ˇCe ima delegat majhno delegacijo, bo morda oznaˇcen kot pasiven, ˇceprav ima delujoˇce vozliˇsˇce. V tem primeru mora v Tezosovem omreˇzju ponovno registrirati vozliˇsˇce, da ni izkljuˇcen iz seznama vozliˇsˇc za dodeljevanje blokov.
Ce pek ravna nepoˇsteno, ima protokol vgrajen mehanizem, zaradi katerega lahkoˇ izgubi svoj varnostni depozit. Za ustvarjanje bloka mora namreˇc zamrzniti del svojih ˇ
zetonov, ki mu bodo ob praviˇcnem delovanju vrnjeni. Za vsak ustvarjen blok mora zamrzniti 512 XTZ in za vsako potrditev bloka 64 XTZ. Ko delegat speˇce ali potrdi
Diplomska naloga 13 nov blok, se varnostni depozit samodejno prenese na depozitni raˇcun, kjer je zamr- znjen za pet ciklov, nato pa se samodejno prenese nazaj na pekov glavni raˇcun. Zaradi varnostnih depozitov je v omreˇzju ves ˇcas v ta namen zaklenjenih pribliˇzno 8,5 % vseh tezov. To pomeni tudi, da mora imeti vsak delegat v lasti veˇc kot 8,5 % vseh delegira- nih tezov, saj lahko za varnostni depozit porabi le svoje ˇzetone. ˇCe ima delegat v lasti premajhen odstotek vseh delegiranih ˇzetonov, bo izgubil del potencialne nagrade do- deljenih blokov, ki jih brez sredstev za varnostni depozit ne more ustvariti ali potrditi.
S tem mehanizmom si decentralizirana skupina pekov poˇsteno razdeli delo v omreˇzju in hkrati kaznuje nepoˇstene akterje.
Za pravilno ustvarjen blok prejme pek poleg omreˇzne nagrade tudi vsoto vseh provizij za transakcije v bloku. Omreˇzna nagrada se izraˇcuna po naslednji formuli:
Brb =ne×Bre Kjer velja, da je:
• Brb nagrada omreˇzja za ustvarjen blok;
• ne ˇstevilo potrjevalcev ustvarjenega bloka;
• Bre pekova nagrada za vsako potrditev bloka.
Za blok z visoko prioriteto veljaBre = 1,25XT Z in za blok z nizko prioriteto Bre= 0,1875XT Z [26]. ˇCe izraˇcunamo omreˇzno nagrado za blok z visoko prioriteto, dobimo 40 XTZ:
Brb = 32×1,2500 = 40
Potrjevalci lahko preverijo bloke, ki so jih izdelali drugi peki, tako da v omreˇzje poˇsljejo operacijo potrdi (ang. endorse). Vsak blok ima lahko do 32 potrditvenih reˇz, ki jih zapolni 32 razliˇcnih potrjevalcev; ker pa se pravice potrjevanja dodeljujejo nakljuˇcno, je mogoˇce, da bo lahko potrjevalec doloˇcen blok potrdil veˇc kot enkrat.
Potrjevalci so nagrajeni za vsako potrditev bloka po naslednji formuli:
Er=ns×Erb Kjer velja:
• Er nagrada omreˇzja za potrjen blok;
• ns ˇstevilo zapolnjenih potrditvenih reˇz;
• Erb potrjevalˇceva nagrada za vsako potrditev bloka.
Za blok z visoko prioriteto velja Erb = 1,25 XT Z in za blok z nizko prioritetoErb = 0,833333 XT Z [26]. Skupna nagrada za potrditev bloka z visoko prioriteto je enaka kot omreˇzna nagrada za ustvarjen blok. Ta vrednost se razdeli med vse potrjevalce sorazmerno z njihovim ˇstevilom zapolnjenih reˇz.
Obtoˇzbe lahko vloˇzi vsak obtoˇzevalec, ˇce ugotovi, da sta bili na bloku za isto potrditveno reˇzo izvedeni dve potrditvi ali ˇce je pek ustvaril dva bloka z isto viˇsino.
Obtoˇzeni pek ali potrjevalec izgubi celoten varnostni depozit in nagrade, ki jih je zasluˇzil pred obtoˇzbo v ciklu. Polovica ˇzetonov se v tem primeru zavrˇze, polovica pa gre obtoˇzevalcu v obliki nagrade za ustvarjen blok. Obtoˇzevalec lahko namreˇc obtoˇzbo sproˇzi le, ko je na vrsti, da ustvari nov blok, v katerega doda operacijo obtoˇzi (ang.
accuse).
Ustvarjeni bloki so zdruˇzeni v cikle. Vsak cikel vsebuje 4096 blokov, kar pomeni, da traja pribliˇzno tri dni. Stanje zvitkov se zajame vsakih 256 blokov, s tem se pravice peˇcenja posodobijo ˇsestnajstkrat na cikel. Vse spremenljivke se lahko z glasovanjem spreminja. Mehanizem ustvarjanja blokov upoˇstevamo v fazi analize 5.1 in testira- nja 5.6 vozliˇsˇca, kjer doloˇcamo zahteve za merjenje uspeˇsnosti in razloˇzimo rezultat zanesljivosti vozliˇsˇca.
3.3.2 Inflacijski model
Tezosovi ˇzetoni imajo predvidljivo letno inflacijo, kar pomeni, da zaradi pritoka novih ˇ
zetonov obstojeˇci ˇzetoni uporabnikov predstavljajo manjˇsi deleˇz skupne vsote vseh ˇ
zetonov. Ob konstantnem povpraˇsevanju tezov bi zaradi zaradi omreˇznih nagrad, ki poveˇcujejo ponudbo tezov, izgubili del kupne moˇci. ˇCe seˇstejemo nagrade omreˇzja za peko in potrditev blokov, vsak nov blok z visoko prioriteto ustvari 80 novih ˇzetonov.
Mehanizem prioritete blokov je zasnovan tako, da je v povpreˇcju nov blok ustvarjen enkrat na minuto, kar nanese pribliˇzno 42 milijonov XTZ na leto (80XT Z×60minut×
24 ur×365 dni). Na zaˇcetku Tezosove verige blokov je bilo v omreˇzju 763 milijonov XTZ, zato je letna stopnja inflacije tezov pribliˇzno 5,5 %:
42.000.000
763.000.000 = 42
763 ≈5,5%
3.3.3 Stroˇ ski operacij na verigi blokov
Med razliˇcne operacije na verigi blokov, ki jih lahko izvajajo vsi uporabniki, sodijo transakcije in objava ter interakcije s pametnimi pogodbami.
Prvi stroˇsek vsake operacije je stroˇsek obdelave (ang. gas), ki meri, koliko ˇcasa vozliˇsˇce porabi za izvedbo programa [27]. Stroˇsek obdelave nima direktno doloˇcene
Diplomska naloga 15 cene z enoto ˇzetonov, vendar bo pek, ki mora izbrati med veˇc transakcijami, veliko bolj verjetno vkljuˇcil transakcijo z nizkim stroˇskom obdelave, ker je njeno izvajanje in potrjevanje cenejˇse. Hkrati pek daje prednost transakcijam z visokimi pristojbinami.
To pomeni, da obstaja implicitni stroˇsek obdelave, ki je povezan s ponujeno pristojbino in s stroˇskom obdelave v primerjavi s pristojbinami drugih transakcij. Ker je prepu- stnost operacij v omreˇzju omejena, je viˇsina pristojbine za stroˇsek obdelave odvisna od obremenjenosti omreˇzja. Tezosovi ˇzetoni, porabljeni v ta namen, so izplaˇcani peku, ki je transakcijo umestil v svoj blok.
Da se koda pametne pogodbe, njene spremenljivke in rezultati shranijo na javni verigi blokov, je potrebno plaˇcati dodaten stroˇsek skladiˇsˇcenja za vsak bajt prostora, ki ga porabijo. Enota ˇzetonov, ki je potrebna za vsak bajt porabljenega prostora, je doloˇcena. Stroˇsek skladiˇsˇcenja je nujen, saj prepreˇcuje zlorabo prostora na vozliˇsˇcu.
Tezosovi ˇzetoni, porabljeni v ta namen, so uniˇceni (ang. burnt). Razvijalci pametnih pogodb so zaradi obeh stroˇskov motivirani pisati kratko in optimizirano kodo.
Preden poˇsljemo transakcijo, ki nosi operacijo, lahko preverimo njene stroˇske. ˇCe smo zadovoljni s stroˇskom obdelave in stroˇskom skladiˇsˇcenja transakcije, jo lahko izve- demo zares, vendar je vedno dobro doloˇciti izrecno omejitev za oba stroˇska. Transakcija se ne izvede, ˇce je katera koli od obeh omejitev preseˇzena. Pek bo bolj verjetno vkljuˇcil operacijo z niˇzjimi omejitvami stroˇskov, ker za izvedbo potrebuje manj performanˇcnih virov, zato je v interesu uporabnika, da izbere meje, ki so ˇcim bliˇzje dejanski uporabi.
Za operacijo lahko plaˇcamo pristojbine, ki jih priˇcakuje pek za porabo performanˇcnih virov, ali pa izsilimo operacijo z nizkimi pristojbinami, pri ˇcemer tvegamo, da je v nov blok ne bo vkljuˇcil noben pek.
3.3.4 Validacija operacij
Vozliˇsˇce omogoˇca validacijo operacije, preden jo poˇslje v omreˇzje, tako da prepro- sto simulira uporabo operacije v trenutnem kontekstu [27]. Brez tega mehanizma bi vozliˇsˇce, ˇce bi samo poslali neveljavno operacijo, to operacijo vseeno posredovalo v Te- zosovo omreˇzje. Ko je neveljavna operacija vkljuˇcena v blok, je potrebno plaˇcilo vseh obiˇcajih stroˇskov operacije, ˇceprav operacija zaradi neveljavnosti ne spremeni stanja v verigi blokov. Da bi se izognili temu primeru, odjemalec najprej zaprosi vozliˇsˇce za validacijo transakcije in jo ˇsele nato poˇslje. Enaka validacija se uporabi, ko ob izvedbi operacije v ukazni vrstici dodamo moˇznost --dry-run, vendar se ob predloˇzitvi te moˇznosti transakcija ne poˇslje, tudi ˇce se izkaˇze za veljavno.
Druga pomembna uporaba tovrstnega potrjevanja je doloˇcanje mejnih vrednosti stroˇskov obdelave in skladiˇsˇcenja. Vozliˇsˇce najprej simulira izvajanje programa pame-
tne pogodbe in spremlja koliˇcino porabljenih stroˇskov. Nato odjemalec poˇslje tran- sakcijo z ustreznimi omejitvami stroˇskov na podlagi tistih, ki jih je navedlo vozliˇsˇce ob simulaciji. ˇCe transakcijo poˇsljemo, ne da bi navedli omejitve stroˇskov, jih vozliˇsˇce izraˇcuna namesto nas. Razlaga inflacijskega modela, stroˇskov in validacije operacij na verigi blokov nam pomaga razumeti razliˇcne cene testiranih operacij v ˇsestem poglavju.
3.4 Potek glasovanja
V kontekstu samonadgrajujoˇce verige blokov lahko Tezosovo vozliˇsˇce razdelimo na omreˇzno lupino in ekonomski protokol [13]. Ekonomski protokol zajema naloge, opi- sane v transakcijskem protokolu 3.1.2 in protokolu soglasja 3.1.3. Opisuje posamezne programske module vozliˇsˇca, ki jih je mogoˇce spremeniti z glasovanjem. Na verigi blokov obstaja mehanizem za predlaganje sprememb ekonomskega protokola, glaso- vanje za ali proti tem predlaganim spremembam in, odvisno od rezultata glasovanja, aktiviranje teh sprememb ali ne. Postopki predlaganja, glasovanja in aktiviranja so del samega ekonomskega protokola, zato se lahko spreminjajo tudi sama pravila o spremembah.
3.4.1 Faze glasovanja
Postopek spreminjanja je sestavljen iz petih faz. Vsaka faza traja 40960 blokov, kar pomeni pet ciklov ali pribliˇzno dva tedna [23]. V nadaljevanju navedene faze si obiˇcajno sledijo eno za drugo in skupaj trajajo pribliˇzno dva meseca in pol, nato pa se celoten postopek glasovanja zaˇcne znova. Zaporedje faz in moˇzne operacije delegatov v vsaki fazi so prikazane na sliki 3.2.
V fazi predlogov lahko delegati predloˇzijo predloge sprememb protokola z uporabo operacije predlagaj (ang. proposal) ali pa podprejo obstojeˇc predlog z operacijo glasuj (ang. ballot). Vsak delegat lahko predloˇzi najveˇc 20 predlogov. Ob koncu faze za oddajo predlogov se izbere predlog z najveˇcjo podporo in preide se v fazo raziskovanja.
Podpora se meri s skupnim ˇstevilom zvitkov ter vseh delegatorjev, ki podpirajo doloˇcen predlog. ˇCe ni predlogov ali ˇce imajo enako ˇstevilo glasov, se postopek vrne v novo fazo predlogov.
V raziskovalni fazi lahko delegati za izbran predlog oddajo glasovnico z operacijo glasuj. Ce udeleˇˇ zba pri glasovanju doseˇze kvorum in je podpora za predlog dovolj velika, se postopek premakne v fazo ohlajanja, v nasprotnem primeru se postopek premakne nazaj v fazo predlogov.
Diplomska naloga 17
Slika 3.2: Diagram poteka glasovanja.
V fazi ohlajanja se na verigi blokov ne zgodi niˇc posebnega, izven verige pa lahko delegati predlog preberejo bolj natanˇcno, uporabniki razpravljajo o posameznih toˇckah predloga in razvijalci lahko opravijo dodatne teste. Ob koncu tega obdobja se postopek premakne v fazo promocije, ko lahko delegati na verigi blokov ponovno glasujejo ali se postopek premakne v obdobje sprejemanja ali pa se vrne v fazo predlogov.
V fazi sprejemanja se na verigi ne zgodi niˇc posebnega, razen v zadnjem bloku.
Zunaj verige razvijalci objavijo orodja, ki vkljuˇcujejo podporo za protokol, ki bo kmalu aktiviran, drugi akterji posodobijo svojo infrastrukturo za podporo novo objavljenim orodjem, razvijalci pametnih pogodb pa lahko zaˇcnejo delati s funkcijami, ki bodo kmalu na voljo. Ob koncu obdobja se predlog aktivira. To pomeni, da se zadnji blok obdobja ˇse vedno tolmaˇci s sedanjim ekonomskim protokolom, prvi blok po obdobju pa se tolmaˇci z novim. Nato se zaˇcne nova faza predlogov.
3.5 Prenos sredstev in pametne pogodbe
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 prevajalnika 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 programskih 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.
4.2 Tehnologije pametnih pogodb
Michelson [8] je domensko specifiˇcen jezik, ki se uporablja za pisanje pametnih pogodb v sistemu Tezos [15]. Za hranjenje parametrov uporablja sklad, je moˇcno tipiziran in zasnovan za laˇzje formalno preverjanje, da lahko razvijalci laˇzje dokazujejo lastnosti pametnih pogodb. Ker gre za nizkonivojski jezik, je njegova uporaba precej omejena, saj si veˇcina razvijalcev ne vzame ˇcasa, da bi se ga nauˇcila, s tem pa ni omejeno le pisanje, temveˇc tudi berljivost pametnih pogodb. Da bi se temu izognili, je bilo razvitih veˇc Michelsonovih prevajalnikov, ki so pripeljali do veˇc visokonivojskih programskih jezikov, ki so bliˇzje navadam razvijalcev.
Slika 4.2: Diagram nivojev programskih jezikov za pametne pogodbe.
SmartPy [16] je intuitiven in uˇcinkovit visokonivojski jezik pametnih pogodb ter ra-
Diplomska naloga 25 zvojna platforma, ki razvijalcem omogoˇca pisanje pametnih pogodb v jeziku Python.
LIGO [7] je statiˇcno tipiziran visokonivojski jezik, ki se prevede v jezik Michelson.
Trenutno podprte sintakse JsLIGO, PascaLIGO, CameLIGO in ReasonLIGO, so obli- kovane tako, da so podobne programskim jezikom JavaScript, Pascal, Caml ali Reason.
Poleg tega sta Morley in Lorentz knjiˇznici za pisanje pogodb v jeziku Haskell. Jezik pametnih pogodb Juvix prav tako podpira jezik Michelson in vkljuˇcuje standardno knjiˇznico s primitivnimi tipi in operacijami Michelson. Diagram visokonivojskih in nizkonivojskih programskih jezikov na sliki 4.2 prikazuje, kako se koda izven verige prevede v kodo na verigi blokov, kjer se po objavi z interakcijami v naslednjih blo- kih lahko proˇzijo tudi operacije pametne pogodbe. Tehnologije pametnih pogodb smo pregledali v fazi naˇcrtovanja pametnih pogodb 6.2, da bi laˇzje izbrali ustrezen pristop za razvoj pametnih pogodb.
Poglavje 5
Postavitev vozliˇ sˇ ca
5.1 Analiza
V fazi analize za postavitev vozliˇsˇca smo doloˇcili tri oblike zahtev:
• zahteve strojne opreme;
• zahteve programske opreme in
• lastne zahteve, s katerimi bomo merili uspeˇsnost vozliˇsˇca.
Zahteve strojne opreme so navedene na spletnem mestu Tezos Agora Wiki [19]. Za pravilno delovanje Tezosovega vozliˇsˇca potrebujemo vsaj dve procesorski jedri in 8 GB velik glavni pomnilnik. Ker Tezosovo vozliˇsˇce hrani celotno zgodovino vseh transakcij od izvornega bloka, potrebujemo ˇcim hitrejˇsi disk z vsaj 100 GB prostora. Da ne zgreˇsimo dodeljenih blokov ali potrditev, mora strojna oprema delovati ves ˇcas brez prekinitev. V ta namen potrebujemo konstanten dovod napajanja in stabilno povezavo na internet. Za veˇcjo varnost naˇsih sredstev je priporoˇcljiva tudi uporaba samostojne denarnice na strojni opremi, kot je Ledger [6] ali Trezor [24].
Programsko opremo Tezosovega vozliˇsˇca lahko sicer za test namestimo na ope- racijskem sistemu macOS ali Windows, vendar je za dolgoroˇcne projekte priporoˇcena uporaba operacijskega sistema Linux. Potrebujemo namreˇc preverjeno okolje z aktivno zaˇsˇcito, ki lahko nameˇsˇca varnostne posodobitve brez prekinitve delovanja. Sami smo odgovorni za nameˇsˇcanje dodatne programske opreme, ki ˇsˇciti pred napadi in nas opo- zori v primeru vdora. Priporoˇcljiva je tudi uporaba dodatnega procesa, ki nadzoruje delovanje Tezosove programske opreme, tako da jo v primeru napake ponovno zaˇzene in zabeleˇzi sporoˇcilo napake.
Na koncu faze analize smo doloˇcili ˇse lastne zahteve, ki potrjujejo uspeˇsno vzpo- stavljeno Tezosovo vozliˇsˇce. V ta namen smo morali najprej raziskati parametre, ki bi
27
jih lahko zajeli za merjenje uspeha. Analizo smo tako nadaljevali s ponovnim branjem Tezosove bele knjige [33], vendar njena vsebina ni posodobljena na najnovejˇse stanje v omreˇzju, zato smo se pri doloˇcanju teh zahtev opirali tudi na spletna mesta Tezos Wiki [22], Tezos Agora Wiki [19] in Open Tezos [12]. Bistvo vozliˇsˇca je, da ustvari ˇcim veˇcje ˇstevilo dodeljenih blokov in zapolni ˇcim veˇcje ˇstevilo dodeljenih potrditvenih reˇz v drugih blokih, saj s tem poveˇca dobiˇckonosnost omreˇznih nagrad. ˇCe torej beleˇzimo odstotek zgreˇsenih blokov in potrditev, lahko ocenimo zanesljivost vsakega vozliˇsˇca.
Uporabniki, ki so delegirali svoje teze delegatu, ki upravlja vozliˇsˇce z niˇzjo zaneslji- vostjo, bodo dobili manjˇse nagrade kot ˇce bi delegirali delegatu z viˇsjo zanesljivostjo.
Zanesljivost vozliˇsˇca je tako dober parameter za merjenje uspeha in je tudi javno do- stopen za vsa vozliˇsˇca na spletnem raziskovalcu Tezosove verige blokov TzKT [18]. Da bi doloˇcil ciljni odstotek zanesljivosti za naˇse vozliˇsˇce, smo izraˇcunali povpreˇcje zane- sljivosti prvih dvajsetih vozliˇsˇc, razvrˇsˇcenih po najviˇsji delegaciji. Izraˇcunana vrednost znaˇsa 98 %. Na postavljenem vozliˇsˇcu smo ˇzeleli dokazati enak odstotek zanesljivosti, zato smo si zadali cilj, da na Tezosovem omreˇzju od 50 zaporedno dodeljenih blokov ustvarimo vsaj 49 in medtem tudi od 1500 dodeljenih potrditvenih reˇz zapolnimo vsaj 1470. Dodaten parameter, ki vpliva na za dobiˇckonosnost vozliˇsˇca, je tudi cena po- stavitve in vzdrˇzevanja, zato smo za eno od lastnih zahtev upoˇstevali tudi ˇcim niˇzjo ceno uporabljene strojne in programske opreme. Zadnja lastna zahteva za laˇzji pre- gled projekta je bila, da moramo vse opravljeno delo in novo terminologijo podrobno dokumentirati.
5.2 Naˇ crtovanje
V fazi naˇcrtovanje smo z upoˇstevanjem vseh zahtev oblikovali naˇcrt za postavitev vozliˇsˇca. Da bi imeli popolno kontrolo nad celotno arhitekturo vozliˇsˇca, smo se odloˇcili, da bomo programsko opremo gostovali doma na lastni strojni opremi. Izbrali smo rabljen streˇznik HP ProLiant DL360 G7, ki ima dva procesorja s skupaj 24 navideznimi jedri in 32 GB velik glavni pomnilnik. Ceprav je streˇˇ znik star skoraj deset let, je ustrezal projektu, saj iˇsˇcemo preverjeno napravo, ki jo lahko kupimo, nadgradimo in vzdrˇzujemo razmeroma poceni. Ustvarjen je za neprekinjeno delovanje in ob tem ne porabi veliko energije. Za operacijski sistem smo izbrali Ubuntu Server 20.04.2 LTS, saj je preverjena distribucija Linuxa z rednimi varnostnimi posodobitvami, ki jo lahko namestimo povsem brezplaˇcno. Operacijski sistem je prilagojen za streˇznike, zato ne vsebuje normalnega grafiˇcnega namizja, temveˇc le preprost vmesnik z ukazno vrstico.
Ker je zmogljivost streˇznika precej veˇcja od minimalnih zahtev vozliˇsˇca, smo si
Diplomska naloga 29 zamislili dve navidezni napravi z enakim operacijskim sistemom. Na prvi navidezni napravi smo naˇcrtovali Tezosovo vozliˇsˇce na testnem omreˇzju in na drugi Tezosovo vozliˇsˇce, povezano na glavno omreˇzje. Za oba sistema smo namenili 8 navideznih jeder in 10 GB glavnega polnilnika, saj nismo ˇzeleli, da bi vozliˇsˇce ob veˇcji obremenitvi zaradi posodobitev sistema ali druge programske opreme naletelo na teˇzave zaradi premajhne zmogljivosti.
Da bi bilo vozliˇsˇcu v razmeroma kratkem obdobju dodeljeno 50 blokov, s katerimi lahko dokaˇzemo vsaj 98-odstotno zanesljivost vozliˇsˇca, bi morali na glavnem Tezoso- vem omreˇzju kupiti teze v vrednosti nekaj deset tisoˇc evrov. Zato smo se odloˇcili, da je uspeˇsnost najbolje meriti na vozliˇsˇcu, ki je povezano na testno omreˇzje, kjer lahko testne teze preprosto zahtevamo iz vodnjaka brez plaˇcila. Izbrali smo takrat najno- vejˇse testno omreˇzje imenovano Florence. Vsako vozliˇsˇce na testnem omreˇzju prispeva tudi pri preizkuˇsanju bodoˇcih protokolov, preden so uporabljeni na glavnem omreˇzju.
Tezosovo vozliˇsˇce, ki je povezano na glavno omreˇzje, tako ni namenjeno za ustvarjanje blokov, temveˇc je bolj primerno za testiranje pametnih pogodb, saj lahko na glavnem omreˇzju bolj realno ocenimo stroˇske posameznih operacij.
Pred nameˇsˇcanjem programske opreme smo preverili ˇse potrebne verzije program- skih komponent, ki jih potrebujemo za vozliˇsˇce na glavnem in na testnem omreˇzju. Za dokumentiranje celotnega postopka smo izbrali urejevalnik besedil Typora s sintakso Markdown.
5.3 Nameˇ sˇ canje strojne in programske opreme
5.3.1 Nameˇ sˇ canje strojne opreme
Ko smo dobili streˇznik, smo se nanj najprej povezali z lokalnim zaslonom in tipkovnico, da smo pognali diagnozo glavnega pomnilnika in trdih diskov. Ker diagnoza ni vrnila napak, smo za hitrejˇse branje in pisanje dva 300 GB velika diska nastavili v naˇcin RAID 0. Streˇznik smo nato namestili v streˇzniˇsko omaro in povezali na omreˇzno stikalo. Omreˇzno stikalo je povezano na usmerjevalnik, ki upravlja zasebno omreˇzje in je naprej povezan direktno na modem ponudnika internetnih storitev.
5.3.2 Nameˇ sˇ canje in nastavljanje operacijskega sistema
Nadaljeval sem z nameˇsˇcanjem operacijskega sistem Ubuntu Server 20.04.2 LTS, ki je potekalo brez zapletov. Prvi cilj na novem operacijskem sistemu je bil, da na njem omogoˇcimo dostop na daljavo, zato smo streˇzniku nastavili statiˇcni IP. Preden smo
omogoˇcili SSH, smo spremenili privzeto ˇstevilko vrat in prepovedali vstop komur koli, ki ne ustreza paru kljuˇcev iz naˇsega raˇcunalnika. Za dodatno zaˇsˇcito pred vdorom smo vzpostavili tudi poˇzarni zid in namestili programsko opremo Fail2ban [3]. Od te toˇcke naprej je bil glavni operacijski sistem na streˇzniku zaˇsˇciten in do njega smo lahko dostopali preko statiˇcnega raˇcunalnika v lokalnem omreˇzju. V naslednjem koraku smo z uporabo orodja KVM [5] vzpostavili dve navidezni napravi. Za laˇzje upravljanje odprtih vrat na usmerjevalniku morata navidezni v omreˇzju delovati avtonomno, zato smo nastavili navidezni most, ki omogoˇca, da se v omreˇzje poveˇzeta z lastnimi IP naslovi. Zatem smo na obeh navideznih napravah namestili enak operacijski sistem kot na samem streˇzniku. Na enak naˇcin smo vzpostavili tudi statiˇcen IP in varen dostop na daljavo. Z ukazno vrstico smo nastavili, da se ob zagonu streˇznika samodejno priˇzgeta tudi obe navidezni napravi.
5.3.3 Nameˇ sˇ canje Tezosove programske opreme
Pred nameˇsˇcanjem Tezosove programske opreme smo posodobili operacijski sistem na streˇzniku in navideznih napravah ter jih ponovno zagnali. Zaˇceli smo s prvim vozliˇsˇcem, ki deluje na testnem omreˇzju Florence. Najprej smo poskusili programske komponente vozliˇsˇca zgraditi lokalno iz izvorne kode, vendar smo naleteli na teˇzave z manjkajoˇcimi knjiˇznicami. Ker vse potrebne knjiˇznice niso bile jasno navedene za grajenje testnih programskih komponent iz izvorne kode, smo se odloˇcili izbrati laˇzjo pot in jih namestiti z uporabo programske opreme APT [1]. Ukazi za samodejni prenos in namestitev programskih komponent so prikazani na sliki 5.1.
Slika 5.1: Ukazi za prenos in namestitev Tezosove programske opreme.
Prvi ukaz posodobi seznam APT paketov, da bo pravilno prepoznal ostale Tezosove pakete, ki sestavljajo programske komponente vozliˇsˇca. Verzijo nameˇsˇcenih paketov smo preverili tako, da smo v ukazni vrstici poklicali paket tezos-node z zastavo - -version. Izpis ukaza smo nato primerjali z najnovejˇso verzijo, ki je navedena na spletnem mestu.
Diplomska naloga 31
5.3.4 Registracija vozliˇ sˇ ca
Preden se lahko vozliˇsˇce prikljuˇci v omreˇzje, moramo zanj ustvariti unikatno identiteto z registracijo. Ustvarjena je zgolj omreˇzna identiteta, ki sluˇzi pri povezovanju v P2P omreˇzju in ni povezana z naslovi raˇcunov v verigi blokov. Vsebino ustvarjene identitete lahko izpiˇsemo tako, da se v vmesniku z ukazno vrstico najprej premaknemo v skrito mapo tezos-node in z naslednjim ukazom izpiˇsemo datoteko identity.json. Vsi ukazi za registracijo in izpis identitete so vidni na sliki 5.2. Identiteta vsebuje par kriptografskih kljuˇcev, ki jih vozliˇsˇca uporabljajo za ˇsifriranje medsebojno poslanih sporoˇcil in ˇzig proti neˇzelenim sporoˇcilom, ki dokazuje, da je bilo ustvarjanju te identitete namenjeno dovolj raˇcunalniˇske moˇci. Dokaz o delu poskrbi, da zlonamerna vozliˇsˇca ne morejo prehitro menjati svojih identitet, saj je naˇs streˇznik za generiranje veljavne identitete porabil skoraj dve minuti.
Slika 5.2: Ukaz za generiranje in izpis identitete Tezosovega vozliˇsˇca.
5.3.5 Nastavitve vozliˇ sˇ ca
Ko prviˇc zaˇzenemo vozliˇsˇce, se bo v Tezosovem omreˇzju predstavilo z novo ustvarjeno identiteto. Zatem zaˇcne graditi lokalno stanje verige blokov, kar vkljuˇcuje vse podatke od izvirnega bloka do danes. Navaden naˇcin usklajevanja preko P2P omreˇzja lahko traja veˇc dni, vendar lahko vozliˇsˇce ugasnemo in ponovno zaˇzenemo z vsaj delno poso- dobljenim stanjem verige, kar je ˇcas usklajevanja v naˇsem primeru skrajˇsalo na dve uri.
Zajeto stanje verige blokov lahko prenesemo iz temu namenjenih spletnih strani ali ga ustvarimo sami na drugem, usklajenem vozliˇsˇcu. Ko prejmemo zajeto stanje, je ne- mogoˇce preveriti, ali so prejeti podatki dejansko del trenutne glavne verige Tezosovega omreˇzja. Zato moramo v primeru, da zajeto stanje pridobimo iz nezaupljivega vira obvezno preveriti rezultat zgoˇsˇcevalne funkcije zadnjega bloka. Vrednost zgoˇsˇcevalne funkcije lahko primerjamo s tisto, ki jo zagotovi drugo vozliˇsˇce pod nadzorom uporab- nika, ali pa jo potrdimo z veˇc vozliˇsˇci zaupanja vrednih uporabnikov. Ostale more-
bitne neskladnosti med bloki bo vozliˇsˇce ob zagonu preverilo samodejno s ponovnim izraˇcunom vrednosti zgoˇsˇcevalnih funkcij v glavah vseh blokov, ki so vkljuˇceni v zaje- tem stanju.
Ker smo ˇzeleli, da se vozliˇsˇce poveˇze na testno omreˇzje Florence, smo pognali ukaz, ki spremeni nastavitve vozliˇsˇca, ki so privzeto nastavljene za glavno omreˇzje. Nato smo prenesli zajeto stanje verige blokov iz spletnega mesta XTZ-Shots [25] in preverili veljavnost prenesenih podatkov. Izbrali smo srednje teˇzek arhiv, ki se je z velikostjo 20 GB prenaˇsal 40 minut. Nastavitve vozliˇsˇca in prenos zajetega stanja naredimo s prvim in drugim ukazom na sliki 5.3. Zadnji ukaz na sliki pa zajeto stanje verige blokov pravilno uvozi v mapo vozliˇsˇca in vsebuje tudi rezultat zgoˇsˇcevalne funkcije zadnjega bloka.
Slika 5.3: Ukazi za spremembo privzetih nastavitev in prenos zajetega stanja verige blokov.
5.4 Registracija delegata in delegacije
Za ustvarjanje blokov vsako vozliˇsˇce potrebuje delegata. ˇStevilo dodeljenih blokov in potrditvenih reˇz je namreˇc sorazmerno s ˇstevilom tezov, ki jih zbere delegat. Delegat lahko za vse teze priskrbi sam ali s pomoˇcjo uporabnikov, ki mu delegirajo svoja sred- stva. Ker smo se odloˇcili, da bomo bloke ustvarjali le na testnem omreˇzju, smo lahko sredstva preprosto zahtevali iz vodnjaka na spletnem mestu Tezos Faucet [20]. Ko na spletni strani zahtevamo testne teze, se izpiˇse testni uporabniˇski raˇcun z nakljuˇcnimi podatki. Izpis vsebuje vrsto varnostnih besed, zasebni kljuˇc, ˇstevilo tezov, rezultat zgoˇsˇcevalne funkcije javnega kljuˇca, geslo in naslov elektronske poˇste. V enakem vr- stnem redu si sledijo vrednosti na primeru uporabniˇskega raˇcuna 5.4.
Na ta naˇcin smo pridobili podatke za ˇstiri uporabnike, ki smo jih po vrsti poi- menovali Alice, Bob, Charlie in David. Vsebino raˇcunov smo na streˇzniku shranili v individualne datoteke in jih nato z uporabo Tezosovega odjemalca aktivirali v vozliˇsˇcu.
Diplomska naloga 33
Slika 5.4: Izpis uporabniˇskega raˇcuna Alice iz Tezosovega vodnjaka za testno omreˇzje.
To smo storili z ukazi, ki so prikazani na sliki 5.5.
Slika 5.5: Ukazi za aktivacijo uporabniˇskih raˇcunov na odjemalcu.
Aktivirane raˇcune lahko v nadaljnjih ukazih naslavljamo z izbranim imenom, kot vidimo na sliki 5.6, kjer smo preverili stanje Davidovega raˇcuna. Poleg tega lahko izpiˇsemo tudi seznam vseh trenutno aktiviranih raˇcunov na odjemalcu.
Slika 5.6: Ukaza za izpis stanja na Davidovem raˇcunu in izpis vseh uporabniˇskih raˇcunov.
Med ustvarjenimi raˇcuni smo za delegata izbrali Alice. Edini kriterij pri izbiri je bil, da mora imeti vsaj 8,5 % vseh skupnih sredstev na vozliˇsˇcu. Registracijo delegata uredimo s prvim ukazom na sliki 5.7. Zatem sledijo ˇse ukazi, ki delegirajo pravico
za ustvarjanje in zapolnjevanje potrditvenih reˇz iz ostalih uporabniˇskih raˇcunov. Po registraciji ali delegacije se pravice posodobijo ˇcez sedem ciklov.
Slika 5.7: Ukazi za registracijo delegata in delegacijo ostalih uporabnikov.
5.5 Vzdrˇ zevanje vozliˇ sˇ ca
Vzdrˇzevanje vozliˇsˇca je vsak teden zahtevalo nekaj ur naˇsega ˇcasa. Postopek smo si olajˇsali s podrobno dokumentacijo vseh sprememb in nastavitev. Na sliki 5.8 lahko vidimo, da celoten projekt zahteva veliko strojne in programske opreme. Noben del opreme ni statiˇcen, temveˇc skozi ˇcas potrebuje vzdrˇzevanje, spremembe ali nadgradnje.
Slika 5.8: Diagram strojne opreme, programske opreme in akterjev v obeh vozliˇsˇcih.
Med prvim vzdrˇzevanjem smo opazili napako, ki se je prenesla iz faze analize in naˇcrtovanja, saj takrat nismo nikjer zasledili, da moramo za pravilno delovanje vo-
