Torej, vaša ekipa je končala alpha različico vašega blokchaina in prišel je čas za zagon testne mreže, nato pa še glavne mreže. Imate pravi blokchain, z neodvisnimi sodelujočimi, dobro ekonomsko strukturo, varnostjo, zasnovali ste upravljanje in zdaj je čas, da vse to preizkusite v praksi. V idealnem kriptoanarhičnem svetu objavite genesis block, končno kodo nod in validatorji vse sami zaženejo, postavijo vse podporne storitve in vse se zgodi samo od sebe. Ampak to je v izmišljenem svetu, v resničnem pa mora ekipa pripraviti precej podporne programske opreme in različnih manipulacij, da pomaga validatorjem vzpostaviti stabilno mrežo. O tem govori ta članek.
Zagon mrež na osnovi konsenzov tipa "proof-of-stake", kjer se validatorji določajo z glasovi imetnikov tokenov sistema, je precej specifično dejanje, saj je tudi zagon tradicionalnih, centralizirano upravljanih sistemov s desetinami in stotinami strežnikov sama po sebi ni preprosta naloga, blokchain pa je potrebno zagnati z trudom zvestih, a neodvisnih sodelujočih. In, če v korporaciji ob zagonu skrbniki imajo popoln dostop do vseh strojev, dnevnikov, skupnega nadzora, validatorji ne pustijo nikogar do svojih strežnikov in verjetno bodo raje zgradili svojo infrastrukturo sami, saj to nadzoruje dostop do glavnih sredstev validatorja — staking glasov. To vedenje omogoča gradnjo distribucijskih varnih mrež — neodvisnost uporabljenih oblačnih ponudnikov, virtualnih in "baremetal" strežnikov, različni operacijski sistemi, vse to naredi napade na to mrežo izjemno neučinkovite — preveč različne programske opreme se uporablja. Na primer, v Ethereumu se uporabljata dve glavne implementacije nod, v Go in v Rust, in napad, učinkovit za eno implementacijo, ne deluje za drugo.
Zato morajo biti vsi procesi zagon in delovanje blockchainov organizirani tako, da lahko kateri koli validátor, ali pa celo majhna skupina validátorjev, kadarkoli vrže svoje računalnike skozi okno in odide, pri čemer ne sme nič razpadati in preostali validatorji morajo še naprej učinkovito podpirati delovanje omrežja in povezovati nove validatore. Pri zagonu omrežja, ko je en validátor v Evropi, drugi v Južni Ameriki, tretji pa v Aziji, je precej težko doseči usklajeno delovanje več deset neodvisnih skupin in jih zanimati za rezultat.
Validatorji
Predstavljajmo si zagon hipotetičnega sodobnega blockchaina (večina opisanega velja za blockchain, ki temelji na katerem koli sodobnem družinskem blockchainu: Ethereum, EOS, Polkadot, Cosmos in drugih, ki predvidevajo konsenzus proof-of-stake. Glavni akterji takih blockchainov so ekipe-validatori, ki postavljajo svoje neodvisne strežnike, ki validirajo in proizvajajo nove bloke, in prejemajo nagrade, predvidene s strani omrežja za tiste, ki sodelujejo v konsenzusu. Za zagon novih omrežij je potrebnih več deset validatorjev (toliko jih lahko za zdaj relativno učinkovito dosega konsenz za sekunde), zato projekt razglasi registracijo, kjer validatori delijo javne informacije o sebi z uporabniki, prepričujejo jih, da nameravajo kakovostno služiti zagnanemu omrežju.
Validiranje je posel, ki omogoča izjemno natančno oceno potencialnega dohodka validatora, hitro premikanje zmogljivosti med projekti, ob uspehu izbrane omrežne situacije pa lahko validátor kot polnopravni član DAO in odgovorna oseba razvija projekt ali preprosto zagotavlja odlično tehnično storitev za popolnoma pregledna in pošteno zaslužena sredstva. Pri izračunu nagrad za validatore projekti poskušajo upoštevati stroške validatorjev in narediti nagrado za bloke tako, da je ta posel dobičkonosen, hkrati pa ne omogoča validátorjem, da rušijo ekonomijo tako, da jih zasipajo z denarjem ter jemljejo ostalim uporabnikom omrežja.
Poslovna uloga validatora zahtijeva osiguranje visoke otpornosti usluga, što podrazumijeva visoki nivo obučenosti devopsa i programera, te skupe računske resurse. Čak i bez potrebe za rudarenjem heševa u proof-of-work mrežama, blockchain čvor je velika usluga koja zahtijeva mnogo memorije, troši mnogo računalnih resursa, validira, zapisuje na disk i šalje velike količine podataka u mrežu. Za pohranu logova transakcija i lanaca blokova za blockchain s nekoliko tisuća malih transakcija u bloku danas je potrebna pohrana od 50 Gb ili više, a za blokove to bi trebao biti SSD. Državna baza podataka blockchaina s podrškom za pametne ugovore već može premašiti 64Gb RAM-a. Serveri s potrebnim karakteristikama su prilično skupi; čvor Ethereum ili EOS može koštati od 100 do 200 $/mjesečno. Dodajte tome povećane troškove rada za cjelodnevni rad programera i devopsa, koji vrijeme otkrivaju probleme i noću, jer dio validatora može biti na drugoj hemisferi. Ipak, u sretnim trenucima, posjedovanje validatornog čvora može donijeti ozbiljan prihod (u slučaju EOS — do 10 000$ dnevno).
Validacija je samo jedna od novih potencijalnih IT uloga za poduzetnike i tvrtke, kako programeri izmišljaju sve složenije algoritme koji nagrađuju poštenje i kažnjavaju prijevaru i krađu, pojavljuju se usluge koje obavljaju funkcije objavljivanja važnih podataka (orakuli), nadziru (slashovanje depozita i kažnjavanje prevaranata objavljivanjem dokaza o prevari), usluge rješavanja sporova, osiguranja i opcija, čak je i garbage collection potencijalno veliko tržište u sustavima pametnih ugovora, gdje je potrebno platiti za pohranu podataka.
Problemi pokretanja blockchaina
Odprtost blockchain-a, ki omogoča prosto sodelovanje v delovanju mreže računalnikov iz vseh držav in enostavnost povezovanja v mrežo za vsakogar po navodilih na GitHub-u, ni vedno prednost. V iskanju novega žetona pogosto spodbudi validatorje, da "rudarijo novo kovancem ob zagonu", v upanju na rast cene in možnost hitrega prodajanja zasluženega. To prav tako pomeni, da je vaš validator lahko kdorkoli, celo neznana oseba, za katerega lahko glasujete tako kot za druge validatorje (resda bo neznanemu težko pridobiti glasove deležnikov, zato strašne zgodbe o anonimnih kriptovalutah pustimo politiki). Kljub temu,
Ekipa projekta ima nalogo — kako pridobiti v svojo mrežo tiste, ki bodo v prihodnosti sposobni zagotavljati stabilno delovanje vozlišč, razumeti varnost, hitro reševati težave, sodelovati z drugimi validatorji in delovati skupaj — od teh lastnosti v veliki meri odvisna kakovost tistega žetona, v katerega so udeleženci mreže pripravljeni vložiti svoje čas in sredstva. Razumne ustanovitelje, ki ocenjujejo tveganja, dobro razumejo, da se ob zagonu takšnega obsega programske opreme nujno srečajo z napakami v kodi, konfiguraciji vozlišč, in da je stabilnost mreže odvisna od tega, kako dobro bodo razvijalci in validatorji skupaj reševali take težave.
Ekipa je pripravljena glasovati v mainnetu za katerega koli validatorja, samo dobro bi bilo vedeti za katere, kateri so dobri? Največje portfelje? Trenutno jih skoraj nihče nima. Po profilih ekipe na LinkedIn-u? Izkušeni devops ali varnostni strokovnjaki vam ne bodo dali nobenih profilov na LinkedIn-u. Po izjavah v klepetu, objavah in pomoči drugim v pripravljalni fazi? Dobro, vendar subjektivno in netočno.
V takšnih razmerah ostane le eno — igrica, ki dobro rešuje težave vseh — igro, v kateri bo mogoče izbrati najboljše validatorje, vendar glavno — preveriti blockchain na trdnost in izvesti obsežno testiranje blockchain-a v pogojih aktivne uporabe, sprememb v konsenzu, nastajanja in odpravljanja napak. To proceduro so prvič predstavili kot igro fantje iz projekta Cosmos, in ta ideja je nedvomno odlična priprava mreže na zagon zanesljivega in odpornim mainnet-a.
Igra validatorjev
Opisujem igro validatorjev tako, kot smo jo zasnovali za blockchain DAO.Casino (DAOBet) na podlagi fork-a EOS, ki se imenuje Haya in ima podoben mehanizem upravljanja - validatorje izbirajo glasovi z katerega koli računa, pri čemer je del ravnotežja, s katerim glasujejo za validatorja, zamrznjen. Vsak račun, ki ima na ravnotežju glavni žeton BET, lahko glasuje za izbranega validatorja s katerim koli delom svojega ravnotežja. Glasovi se seštevajo in na podlagi tega se gradi seznam najboljših validatorjev. V različnih blockchainih je ta proces organiziran na različne načine, in običajno je prav v tej točki nov blockchain drugačen od matičnega, in treba je reči, da v našem primeru EOS popolnoma upravičuje “OS” v svojem imenu, dejansko uporabljamo EOS kot osnovni operacijski sistem za uvajanje modificirane različice blockchaina za potrebe DAOBet.
Opisoval bom posamezne težave in kako jih lahko rešimo v okviru igre. Predstavljajmo si omrežje, v katerem je vaš strežnik lahko odprto napaden, kjer je za ohranitev pozicije validatorja potrebno neprekinjeno sodelovati z omrežjem, promovirati svojega validatorja in poskrbeti, da proizvaja bloke ter jih pravočasno dostavlja ostalim validatorjem, sicer bo validator izpadel iz seznama.
Kako izbrati najboljše zmagovalce?
Glavna tehnična zahteva za igro je, da so njeni rezultati javno preverljivi. To pomeni, da morajo biti rezultati igre: seznam najboljših zmagovalcev, oblikovani strogo na osnovi podatkov, ki jih lahko preveri vsak udeleženec. V centraliziranem sistemu bi lahko merili “dostopnost” vsakega validatorja in nagradili tiste, ki so bili največ online ali so preusmerili maksimum omrežnega prometa. Lahko bi zbirali podatke o obremenitvi procesorja, pomnilnika in nagradili tiste, ki so pošteno delali. Vendar pa vsak tak zbir podatkov pomeni obstoj centralne točke zbiranja, pa tudi vozlišča so neodvisna in se lahko obnašajo, kot želijo in pošiljajo poljubne podatke.
Zato je naravna rešitev ta, da morajo zmagovalci biti določeni na podlagi podatkov iz verige blokov, saj je mogoče videti, kateri od validatorjev je ustvaril kateri blok in katere transakcije so bile vanj vključene. To število smo poimenovali Validator Points (VP), in njihovo pridobivanje je glavni cilj validatorjev v igri. V našem primeru je najpreprostejša, javno preverljiva in učinkovita metrika 'uporabnosti' validatorja VP = število blokov, ki jih je validator ustvaril v določenem časovnem obdobju.
Ta preprosta izbira je utemeljena s tem, da governance v EOS že predvideva številne težave, saj je EOS naslednik že treh generacij dejansko delujočih blokovnih verig z bogatimi izkušnjami pri kompleksnem upravljanju omrežja, in praktično katere koli težave validatorja s omrežjem, procesorjem, diskom vodijo le v en problem — podpira manj blokov, prejavlja manjše plačilo za delo, kar nas spet pripelje k številu podpisanih blokov — za EOS je to odlična in preprosta možnost.
Pri drugih blokovnih verigah se lahko način štetja Validator Points razlikuje, na primer pri konsenzusih, temelječih na pBFT (Tendermint/Cosmos, Aura konsenzus iz Parity Substrate), kjer mora biti vsak blok podpisan s strani več validatorjev, ima smisel šteti posamezne podpise validatorjev, namesto blokov, mogoče je smiselno upoštevati ne zaključene runde konsenzusa, ki trošijo vire drugih validatorjev, na splošno pa to močno odvisno od tipa konsenzusa.
Kako modelirati resnične pogoje delovanja
Naloga ustanoviteljev je preveriti validatorje v pogojih, ki so čim bližje realnosti, pri tem pa nimajo nobene centralizirane kontrole. Ta problem se lahko reši z vsemi poznanim 'faucet' pametnim pogodom, ki enakomerno razdeli osnovne tokene validatorjem in vsem zainteresiranim. Da pridobite tokene na svoj račun, morate oblikovati transakcijo in doseči, da jo omrežje vključi v blok. Tako mora validator nenehno polniti svoj račun z novimi tokenskimi in glasovati zase, da se povzpne v vrh. To delovanje ustvarja stalno obremenitev omrežja, parametre pa je možno prilagoditi tako, da je tok zahtev dovolj resen za temeljito testiranje omrežja. Zato načrtujte 'faucet' pametni pogodbo vnaprej kot pomembno orodje za zagon omrežja in začnite prilagajati njene parametre že zgodaj.
Zahteva za tokene iz 'faucet' in glasovanje validatorjev še vedno ne do konca pošteno emulira delovanje blockchaina, še posebej v izjemno obremenjenih režimih. Zato se bo ekipi blockchaina vseeno, na ta ali oni način, treba pisati dodatne benchmarke, ki omogočajo obremenitev omrežja. Posebno vlogo pri tem igrajo vnaprej zasnovani pametni pogodki, ki omogočajo testiranje posameznih podsistemov. Za testiranje shranjevanja pametni pogodki shranjujejo naključne podatke v blockchain, medtem ko testni pogodki za preverjanje omrežnih virov zahtevajo veliko količino vhodnih podatkov, kar povečuje obseg transakcij—zagon toka takih transakcij ob naključnih trenutkih omogoča ekipi hkratno testiranje stabilnosti kode in vzdržljivosti validatorjev.
Poseben izziv predstavlja posodobitev kode vozlišč in izvajanje hard forkov. Potrebno je, da imajo validatorji v primeru pojava napak, ranljivosti ali zarote zlonamernih validatorjev pripravljen akcijski načrt, že dolgo preizkušan v igri validatorjev. Tukaj je mogoče zasnovati sheme dodeljevanja VP za hitro izvajanje hard forka, na primer s kaznovanjem vseh validatorjev, ki še niso prenesli nove različice kode vozlišča, a to ni enostavno izvesti in zaplete štetje. Simulirati situacijo nujne uporabe hard forka lahko umetno 'pokvarimo' blockchain na določenem bloku. Proizvodnja blokov se ustavi in na koncu bodo v prednosti tisti, ki se bodo prej vključili in začeli podpisovati bloke, tako da je VP na podlagi števila podpisanih blokov tukaj dobro utemeljen.
Kako obvestiti udeležence o stanju omrežja in odpraviti napake
Kljub nezaupanju med validatorji je pomembno, da pravočasno pridobivajo aktualne informacije o stanju omrežja, kar je vsem v korist, da lahko hitreje sprejemajo odločitve. Zato ekipa projekta uvaja storitev za zbiranje in vizualizacijo številnih metrik iz strežnikov validatorjev, ki omogoča hkratno pogled na situacijo za celo omrežje, kar hitro omogoči ugotovitev, kaj se dogaja. Poleg tega je v obeh, validatorjih in projektu, koristno, da ekipa projekta hitro odpravlja ugotovljene napake. Zato se poleg zbiranja metrik smiselno takoj zažene tudi zbiranje logov in podatkov o napakah iz validatorjev na stroju, dostopnem razvijalcem blockchaina. Tukaj nikomur ni v interesu zavajati informacij, zato te storitve uvaja ekipa projekta in jim je mogoče zaupati. Smiselno je zbirati sistemske metrike z validatorjev ter nujno najpomembnejše metrike samega blockchaina — za DAOBet sta to čas finalizacije in zaostanek zadnjega finaliziranega bloka. Tako ekipa vidi povečanje porabe pomnilnika na vozliščih ob zagonu benchmarka, težave posameznih validatorjev.
Pomembne točke za izvajanje igre validatorjev
Kot se je izkazalo, če želite uradno dovoliti validatorjem, da napadajo medsebojno (neformalno to že lahko počnejo) — morate to pravno posebej opredeliti kot testiranje varnosti, saj vas lahko v nekaterih državah kaznujejo za DDoS ali omrežne napade. Še eno pomembno vprašanje je, kako nagraditi validatorje. Naravne nagrade so žetoni projekta, ki bodo preneseni v glavno omrežje, a množična razdelitev žetonov vsakomur, ki lahko zažene vozlišče — prav tako ni najboljša možnost. Verjetno boste morali najti ravnotežje med dvema ekstremnima možnostma:
Razdeliti celoten nagradni sklad v skladu z zasluženimi VP
to je zelo demokratično in omogoča zaslužek vsem, ki so investirali čas in sredstva v igro validatorjev
vendar privablja k igri občasne ljudi brez ustrezne infrastrukture
Razdeliti nagradni sklad najboljšim N validatorjem na koncu igre
zmagovalci bodo verjetno tisti validatorji, ki so najbolj dosledno vztrajali med igro in so zelo resno usmerjeni k zmagi
del validatorjev ne bo želelo sodelovati, ker nizko ocenjujejo svoje možnosti za zmago, še posebej, če so v sestavi sodelujočih uveljavljeni validatorji
Kateremu predlogu dati prednost — je vaša odločitev
Obstaja še en vidik — povsem ni jasno, ali se bodo desetine validatorjev z veseljem odzvale na vašo prošnjo za sodelovanje v igri, od tistih, ki se bodo odločili poskusiti, pa ne bodo vsi niti namestili in zagnali vozlišča — ponavadi imajo projekti v tej fazi precej skromno dokumentacijo, pojavijo se napake, razvijalci, ki delajo pod časovnim pritiskom, pa ne odgovarjajo prehitro. Zato je pred začetkom igre treba tudi predvideti ukrepe, če število validatorjev ne bo doseženo. V tem primeru se na začetku igre z ekipo projekta zaženejo manjkajoči validatorji, sodelujejo pri doseganju soglasja, vendar ne morejo postati zmagovalci.
Zaključek
Na koncu sem poskušal sestaviti seznam stvari, ki jih je treba izumiti, narediti in zagnati za učinkovito izvedbo igre validatorjev
Kaj je treba storiti za zagon prave igre validatorjev:
razviti svojo blockchain 🙂
- izdelati in postaviti spletni vmesnik ter zagotoviti CLI za glasovanje za validatorje
- Poskrbeti, da lahko metrike z aktivne validating node pošiljajo v centralizirano storitev (na primer Prometheus)
- Postaviti strežnik za zbiranje metrik (Prometheus + Grafana) za igro validatorjev
- Izumiti, kako se bodo izračunavale Validator Points (VP)
- Razviti javni skript za izračun VP validatorjev na podlagi podatkov iz blockchaina
- Razviti spletni vmesnik za prikaz top validatorjev in stanja igre validatorjev (koliko časa je še do konca, kdo ima koliko VP itd.)
- Razviti in avtomatizirati zagon poljubnega števila lastnih nod, načrtovati postopek povezovanja validatorjev v igro (kdaj in kako izklopiti svoje node, oddajati in umikati glasove za njih)
- Izračunati, koliko žetonov je treba podeliti in razviti pogodbo-faucet
- Narediti benchmark skript (prenosi žetonov, masovno uporabo shranjevanja, masovno uporabo omrežja)
- Zbrati vse udeležence v enem klepetu za hitro komunikacijo
- Zagnati blockchain malo pred začetkom igre
- Počakati na začetni blok, začeti igro
- Preizkusiti mrežo z več vrstami transakcij
- Izvesti hard fork
- Spremeniti seznam validatorjev
- Ponoviti točko 13, 14, 15 v različnih vrstnih redih, pri čemer ohranjati stabilnost mreže
- Počakati na končni blok, končati igro, izračunati VP
Treba je omeniti, da je igra validatorjev nova zgodba in je bila izvedena le nekajkrat, zato tega bes teksta ne jemljite kot končni priročnik. V sodobnem IT poslu ni analogov - predstavljajte si, da se banke pred zagon sistemov plačevanja med seboj tekmujejo, kdo bolje izvaja transakcije strank. Tradicionalni pristopi vam verjetno ne bodo pomagali pri ustvarjanju velikih decentraliziranih omrežij, zato obvladujte nove poslovne modele, organizirajte svoje igre, določite dostojne, nagradite jih in naj delujejo vaši distribuirani sistemi hitro in stabilno.
Izvor: habr.com
