stre\u017enikov<\/a> sama po sebi ni preprosta naloga, blokchain pa je potrebno zagnati z trudom zvestih, a neodvisnih sodelujo\u010dih. In, \u010de v korporaciji ob zagonu skrbniki imajo popoln dostop do vseh strojev, dnevnikov, skupnega nadzora, validatorji ne pustijo nikogar do svojih stre\u017enikov in verjetno bodo raje zgradili svojo infrastrukturo sami, saj to nadzoruje dostop do glavnih sredstev validatorja \u2014 staking glasov. To vedenje omogo\u010da gradnjo distribucijskih varnih mre\u017e \u2014 neodvisnost uporabljenih obla\u010dnih ponudnikov, virtualnih in \"baremetal\" stre\u017enikov, razli\u010dni operacijski sistemi, vse to naredi napade na to mre\u017eo izjemno neu\u010dinkovite \u2014 preve\u010d razli\u010dne programske opreme se uporablja. Na primer, v Ethereumu se uporabljata dve glavne implementacije nod, v Go in v Rust, in napad, u\u010dinkovit za eno implementacijo, ne deluje za drugo.<\/p>\n<\/p>\n
Zato morajo biti vsi procesi zagon in delovanje blockchainov organizirani tako, da lahko kateri koli valid\u00e1tor, ali pa celo majhna skupina valid\u00e1torjev, kadarkoli vr\u017ee svoje ra\u010dunalnike skozi okno in odide, pri \u010demer ne sme ni\u010d razpadati in preostali validatorji morajo \u0161e naprej u\u010dinkovito podpirati delovanje omre\u017eja in povezovati nove validatore. Pri zagonu omre\u017eja, ko je en valid\u00e1tor v Evropi, drugi v Ju\u017eni Ameriki, tretji pa v Aziji, je precej te\u017eko dose\u010di usklajeno delovanje ve\u010d deset neodvisnih skupin in jih zanimati za rezultat. <\/p>\n
<\/p>\n
Validatorji<\/h2>\n <\/p>\n
Predstavljajmo si zagon hipoteti\u010dnega sodobnega blockchaina (ve\u010dina opisanega velja za blockchain, ki temelji na katerem koli sodobnem dru\u017einskem 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\u017enike, ki validirajo in proizvajajo nove bloke, in prejemajo nagrade, predvidene s strani omre\u017eja za tiste, ki sodelujejo v konsenzusu. Za zagon novih omre\u017eij je potrebnih ve\u010d deset validatorjev (toliko jih lahko za zdaj relativno u\u010dinkovito dosega konsenz za sekunde), zato projekt razglasi registracijo, kjer validatori delijo javne informacije o sebi z uporabniki, prepri\u010dujejo jih, da nameravajo kakovostno slu\u017eiti zagnanemu omre\u017eju.<\/p>\n
<\/p>\n
Validiranje je posel, ki omogo\u010da izjemno natan\u010dno oceno potencialnega dohodka validatora, hitro premikanje zmogljivosti med projekti, ob uspehu izbrane omre\u017ene situacije pa lahko valid\u00e1tor kot polnopravni \u010dlan DAO in odgovorna oseba razvija projekt ali preprosto zagotavlja odli\u010dno tehni\u010dno storitev za popolnoma pregledna in po\u0161teno zaslu\u017eena sredstva. Pri izra\u010dunu nagrad za validatore projekti posku\u0161ajo upo\u0161tevati stro\u0161ke validatorjev in narediti nagrado za bloke tako, da je ta posel dobi\u010dkonosen, hkrati pa ne omogo\u010da valid\u00e1torjem, da ru\u0161ijo ekonomijo tako, da jih zasipajo z denarjem ter jemljejo ostalim uporabnikom omre\u017eja.<\/p>\n
<\/p>\n
Poslovna uloga validatora zahtijeva osiguranje visoke otpornosti usluga, \u0161to podrazumijeva visoki nivo obu\u010denosti devopsa i programera, te skupe ra\u010dunske resurse. \u010cak i bez potrebe za rudarenjem he\u0161eva u proof-of-work mre\u017eama, blockchain \u010dvor je velika usluga koja zahtijeva mnogo memorije, tro\u0161i mnogo ra\u010dunalnih resursa, validira, zapisuje na disk i \u0161alje velike koli\u010dine podataka u mre\u017eu. Za pohranu logova transakcija i lanaca blokova za blockchain s nekoliko tisu\u0107a malih transakcija u bloku danas je potrebna pohrana od 50 Gb ili vi\u0161e, a za blokove to bi trebao biti SSD. Dr\u017eavna baza podataka blockchaina s podr\u0161kom za pametne ugovore ve\u0107 mo\u017ee prema\u0161iti 64Gb RAM-a. Serveri s potrebnim karakteristikama su prili\u010dno skupi; \u010dvor Ethereum ili EOS mo\u017ee ko\u0161tati od 100 do 200 $\/mjese\u010dno. Dodajte tome pove\u0107ane tro\u0161kove rada za cjelodnevni rad programera i devopsa, koji vrijeme otkrivaju probleme i no\u0107u, jer dio validatora mo\u017ee biti na drugoj hemisferi. Ipak, u sretnim trenucima, posjedovanje validatornog \u010dvora mo\u017ee donijeti ozbiljan prihod (u slu\u010daju EOS \u2014 do 10 000$ dnevno).<\/p>\n
<\/p>\n
Validacija je samo jedna od novih potencijalnih IT uloga za poduzetnike i tvrtke, kako programeri izmi\u0161ljaju sve slo\u017eenije algoritme koji nagra\u0111uju po\u0161tenje i ka\u017enjavaju prijevaru i kra\u0111u, pojavljuju se usluge koje obavljaju funkcije objavljivanja va\u017enih podataka (orakuli), nadziru (slashovanje depozita i ka\u017enjavanje prevaranata objavljivanjem dokaza o prevari), usluge rje\u0161avanja sporova, osiguranja i opcija, \u010dak je i garbage collection potencijalno veliko tr\u017ei\u0161te u sustavima pametnih ugovora, gdje je potrebno platiti za pohranu podataka. <\/p>\n
<\/p>\n
Problemi pokretanja blockchaina<\/h2>\n <\/p>\n
Odprtost blockchain-a, ki omogo\u010da prosto sodelovanje v delovanju mre\u017ee ra\u010dunalnikov iz vseh dr\u017eav in enostavnost povezovanja v mre\u017eo za vsakogar po navodilih na GitHub-u, ni vedno prednost. V iskanju novega \u017eetona pogosto spodbudi validatorje, da \"rudarijo novo kovancem ob zagonu\", v upanju na rast cene in mo\u017enost hitrega prodajanja zaslu\u017eenega. To prav tako pomeni, da je va\u0161 validator lahko kdorkoli, celo neznana oseba, za katerega lahko glasujete tako kot za druge validatorje (resda bo neznanemu te\u017eko pridobiti glasove dele\u017enikov, zato stra\u0161ne zgodbe o anonimnih kriptovalutah pustimo politiki). Kljub temu,<\/p>\n
<\/p>\n
Ekipa projekta ima nalogo \u2014 kako pridobiti v svojo mre\u017eo tiste, ki bodo v prihodnosti sposobni zagotavljati stabilno delovanje vozli\u0161\u010d, razumeti varnost, hitro re\u0161evati te\u017eave, sodelovati z drugimi validatorji in delovati skupaj \u2014 od teh lastnosti v veliki meri odvisna kakovost tistega \u017eetona, v katerega so udele\u017eenci mre\u017ee pripravljeni vlo\u017eiti svoje \u010das in sredstva. Razumne ustanovitelje, ki ocenjujejo tveganja, dobro razumejo, da se ob zagonu tak\u0161nega obsega programske opreme nujno sre\u010dajo z napakami v kodi, konfiguraciji vozli\u0161\u010d, in da je stabilnost mre\u017ee odvisna od tega, kako dobro bodo razvijalci in validatorji skupaj re\u0161evali take te\u017eave.<\/p>\n
<\/p>\n
Ekipa je pripravljena glasovati v mainnetu za katerega koli validatorja, samo dobro bi bilo vedeti za katere, kateri so dobri? Najve\u010dje portfelje? Trenutno jih skoraj nih\u010de nima. Po profilih ekipe na LinkedIn-u? Izku\u0161eni devops ali varnostni strokovnjaki vam ne bodo dali nobenih profilov na LinkedIn-u. Po izjavah v klepetu, objavah in pomo\u010di drugim v pripravljalni fazi? Dobro, vendar subjektivno in neto\u010dno.<\/p>\n
<\/p>\n
V tak\u0161nih razmerah ostane le eno \u2014 igrica, ki dobro re\u0161uje te\u017eave vseh \u2014 igro, v kateri bo mogo\u010de izbrati najbolj\u0161e validatorje, vendar glavno \u2014 preveriti blockchain na trdnost in izvesti obse\u017eno testiranje blockchain-a v pogojih aktivne uporabe, sprememb v konsenzu, nastajanja in odpravljanja napak. To proceduro so prvi\u010d predstavili kot igro fantje iz projekta Cosmos, in ta ideja je nedvomno odli\u010dna priprava mre\u017ee na zagon zanesljivega in odpornim mainnet-a.<\/p>\n
<\/p>\n
Igra validatorjev<\/h2>\n <\/p>\n
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\u010duna, pri \u010demer je del ravnote\u017eja, s katerim glasujejo za validatorja, zamrznjen. Vsak ra\u010dun, ki ima na ravnote\u017eju glavni \u017eeton BET, lahko glasuje za izbranega validatorja s katerim koli delom svojega ravnote\u017eja. Glasovi se se\u0161tevajo in na podlagi tega se gradi seznam najbolj\u0161ih validatorjev. V razli\u010dnih blockchainih je ta proces organiziran na razli\u010dne na\u010dine, in obi\u010dajno je prav v tej to\u010dki nov blockchain druga\u010den od mati\u010dnega, in treba je re\u010di, da v na\u0161em primeru EOS popolnoma upravi\u010duje \u201cOS\u201d v svojem imenu, dejansko uporabljamo EOS kot osnovni operacijski sistem za uvajanje modificirane razli\u010dice blockchaina za potrebe DAOBet.<\/p>\n
<\/p>\n
Opisoval bom posamezne te\u017eave in kako jih lahko re\u0161imo v okviru igre. Predstavljajmo si omre\u017eje, v katerem je va\u0161 stre\u017enik lahko odprto napaden, kjer je za ohranitev pozicije validatorja potrebno neprekinjeno sodelovati z omre\u017ejem, promovirati svojega validatorja in poskrbeti, da proizvaja bloke ter jih pravo\u010dasno dostavlja ostalim validatorjem, sicer bo validator izpadel iz seznama.<\/p>\n
<\/p>\n
Kako izbrati najbolj\u0161e zmagovalce?<\/h3>\n <\/p>\n
Glavna tehni\u010dna zahteva za igro je, da so njeni rezultati javno preverljivi. To pomeni, da morajo biti rezultati igre: seznam najbolj\u0161ih zmagovalcev, oblikovani strogo na osnovi podatkov, ki jih lahko preveri vsak udele\u017eenec. V centraliziranem sistemu bi lahko merili \u201cdostopnost\u201d vsakega validatorja in nagradili tiste, ki so bili najve\u010d online ali so preusmerili maksimum omre\u017enega prometa. Lahko bi zbirali podatke o obremenitvi procesorja, pomnilnika in nagradili tiste, ki so po\u0161teno delali. Vendar pa vsak tak zbir podatkov pomeni obstoj centralne to\u010dke zbiranja, pa tudi vozli\u0161\u010da so neodvisna in se lahko obna\u0161ajo, kot \u017eelijo in po\u0161iljajo poljubne podatke.<\/p>\n
<\/p>\n
Zato je naravna re\u0161itev ta, da morajo zmagovalci biti dolo\u010deni na podlagi podatkov iz verige blokov, saj je mogo\u010de videti, kateri od validatorjev je ustvaril kateri blok in katere transakcije so bile vanj vklju\u010dene. To \u0161tevilo smo poimenovali Validator Points (VP), in njihovo pridobivanje je glavni cilj validatorjev v igri. V na\u0161em primeru je najpreprostej\u0161a, javno preverljiva in u\u010dinkovita metrika 'uporabnosti' validatorja VP = \u0161tevilo blokov, ki jih je validator ustvaril v dolo\u010denem \u010dasovnem obdobju.<\/p>\n
<\/p>\n
Ta preprosta izbira je utemeljena s tem, da governance v EOS \u017ee predvideva \u0161tevilne te\u017eave, saj je EOS naslednik \u017ee treh generacij dejansko delujo\u010dih blokovnih verig z bogatimi izku\u0161njami pri kompleksnem upravljanju omre\u017eja, in prakti\u010dno katere koli te\u017eave validatorja s omre\u017ejem, procesorjem, diskom vodijo le v en problem \u2014 podpira manj blokov, prejavlja manj\u0161e pla\u010dilo za delo, kar nas spet pripelje k \u0161tevilu podpisanih blokov \u2014 za EOS je to odli\u010dna in preprosta mo\u017enost.<\/p>\n
<\/p>\n
Pri drugih blokovnih verigah se lahko na\u010din \u0161tetja Validator Points razlikuje, na primer pri konsenzusih, temelje\u010dih na pBFT (Tendermint\/Cosmos, Aura konsenzus iz Parity Substrate), kjer mora biti vsak blok podpisan s strani ve\u010d validatorjev, ima smisel \u0161teti posamezne podpise validatorjev, namesto blokov, mogo\u010de je smiselno upo\u0161tevati ne zaklju\u010dene runde konsenzusa, ki tro\u0161ijo vire drugih validatorjev, na splo\u0161no pa to mo\u010dno odvisno od tipa konsenzusa. <\/p>\n
<\/p>\n
Kako modelirati resni\u010dne pogoje delovanja<\/h3>\n <\/p>\n
Naloga ustanoviteljev je preveriti validatorje v pogojih, ki so \u010dim bli\u017eje realnosti, pri tem pa nimajo nobene centralizirane kontrole. Ta problem se lahko re\u0161i z vsemi poznanim 'faucet' pametnim pogodom, ki enakomerno razdeli osnovne tokene validatorjem in vsem zainteresiranim. Da pridobite tokene na svoj ra\u010dun, morate oblikovati transakcijo in dose\u010di, da jo omre\u017eje vklju\u010di v blok. Tako mora validator nenehno polniti svoj ra\u010dun z novimi tokenskimi in glasovati zase, da se povzpne v vrh. To delovanje ustvarja stalno obremenitev omre\u017eja, parametre pa je mo\u017eno prilagoditi tako, da je tok zahtev dovolj resen za temeljito testiranje omre\u017eja. Zato na\u010drtujte 'faucet' pametni pogodbo vnaprej kot pomembno orodje za zagon omre\u017eja in za\u010dnite prilagajati njene parametre \u017ee zgodaj.<\/p>\n
<\/p>\n
Zahteva za tokene iz 'faucet' in glasovanje validatorjev \u0161e vedno ne do konca po\u0161teno emulira delovanje blockchaina, \u0161e posebej v izjemno obremenjenih re\u017eimih. Zato se bo ekipi blockchaina vseeno, na ta ali oni na\u010din, treba pisati dodatne benchmarke, ki omogo\u010dajo obremenitev omre\u017eja. Posebno vlogo pri tem igrajo vnaprej zasnovani pametni pogodki, ki omogo\u010dajo testiranje posameznih podsistemov. Za testiranje shranjevanja pametni pogodki shranjujejo naklju\u010dne podatke v blockchain, medtem ko testni pogodki za preverjanje omre\u017enih virov zahtevajo veliko koli\u010dino vhodnih podatkov, kar pove\u010duje obseg transakcij\u2014zagon toka takih transakcij ob naklju\u010dnih trenutkih omogo\u010da ekipi hkratno testiranje stabilnosti kode in vzdr\u017eljivosti validatorjev.<\/p>\n
<\/p>\n
Poseben izziv predstavlja posodobitev kode vozli\u0161\u010d in izvajanje hard forkov. Potrebno je, da imajo validatorji v primeru pojava napak, ranljivosti ali zarote zlonamernih validatorjev pripravljen akcijski na\u010drt, \u017ee dolgo preizku\u0161an v igri validatorjev. Tukaj je mogo\u010de zasnovati sheme dodeljevanja VP za hitro izvajanje hard forka, na primer s kaznovanjem vseh validatorjev, ki \u0161e niso prenesli nove razli\u010dice kode vozli\u0161\u010da, a to ni enostavno izvesti in zaplete \u0161tetje. Simulirati situacijo nujne uporabe hard forka lahko umetno 'pokvarimo' blockchain na dolo\u010denem bloku. Proizvodnja blokov se ustavi in na koncu bodo v prednosti tisti, ki se bodo prej vklju\u010dili in za\u010deli podpisovati bloke, tako da je VP na podlagi \u0161tevila podpisanih blokov tukaj dobro utemeljen.<\/p>\n
<\/p>\n
<\/p>\n
Kljub nezaupanju med validatorji je pomembno, da pravo\u010dasno pridobivajo aktualne informacije o stanju omre\u017eja, kar je vsem v korist, da lahko hitreje sprejemajo odlo\u010ditve. Zato ekipa projekta uvaja storitev za zbiranje in vizualizacijo \u0161tevilnih metrik iz stre\u017enikov validatorjev, ki omogo\u010da hkratno pogled na situacijo za celo omre\u017eje, kar hitro omogo\u010di 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\u017eene 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\u010de zaupati. Smiselno je zbirati sistemske metrike z validatorjev ter nujno najpomembnej\u0161e metrike samega blockchaina \u2014 za DAOBet sta to \u010das finalizacije in zaostanek zadnjega finaliziranega bloka. Tako ekipa vidi pove\u010danje porabe pomnilnika na vozli\u0161\u010dih ob zagonu benchmarka, te\u017eave posameznih validatorjev. <\/p>\n
<\/p>\n
Pomembne to\u010dke za izvajanje igre validatorjev<\/h2>\n <\/p>\n
Kot se je izkazalo, \u010de \u017eelite uradno dovoliti validatorjem, da napadajo medsebojno (neformalno to \u017ee lahko po\u010dnejo) \u2014 morate to pravno posebej opredeliti kot testiranje varnosti, saj vas lahko v nekaterih dr\u017eavah kaznujejo za DDoS ali omre\u017ene napade. \u0160e eno pomembno vpra\u0161anje je, kako nagraditi validatorje. Naravne nagrade so \u017eetoni projekta, ki bodo preneseni v glavno omre\u017eje, a mno\u017ei\u010dna razdelitev \u017eetonov vsakomur, ki lahko za\u017eene vozli\u0161\u010de \u2014 prav tako ni najbolj\u0161a mo\u017enost. Verjetno boste morali najti ravnote\u017eje med dvema ekstremnima mo\u017enostma:<\/p>\n
<\/p>\n
Razdeliti celoten nagradni sklad v skladu z zaslu\u017eenimi VP
<\/p>\n
Razdeliti nagradni sklad najbolj\u0161im N validatorjem na koncu igre
<\/p>\n
Kateremu predlogu dati prednost \u2014 je va\u0161a odlo\u010ditev <\/p>\n
<\/p>\n
Obstaja \u0161e en vidik \u2014 povsem ni jasno, ali se bodo desetine validatorjev z veseljem odzvale na va\u0161o pro\u0161njo za sodelovanje v igri, od tistih, ki se bodo odlo\u010dili poskusiti, pa ne bodo vsi niti namestili in zagnali vozli\u0161\u010da \u2014 ponavadi imajo projekti v tej fazi precej skromno dokumentacijo, pojavijo se napake, razvijalci, ki delajo pod \u010dasovnim pritiskom, pa ne odgovarjajo prehitro. Zato je pred za\u010detkom igre treba tudi predvideti ukrepe, \u010de \u0161tevilo validatorjev ne bo dose\u017eeno. V tem primeru se na za\u010detku igre z ekipo projekta za\u017eenejo manjkajo\u010di validatorji, sodelujejo pri doseganju soglasja, vendar ne morejo postati zmagovalci.<\/p>\n
<\/p>\n
Zaklju\u010dek<\/h2>\n <\/p>\n
Na koncu sem posku\u0161al sestaviti seznam stvari, ki jih je treba izumiti, narediti in zagnati za u\u010dinkovito izvedbo igre validatorjev<\/p>\n
<\/p>\n
Kaj je treba storiti za zagon prave igre validatorjev:
<\/p>\n
\nizdelati in postaviti spletni vmesnik ter zagotoviti CLI za glasovanje za validatorje<\/li>\n Poskrbeti, da lahko metrike z aktivne validating node po\u0161iljajo v centralizirano storitev (na primer Prometheus)<\/li>\n Postaviti stre\u017enik za zbiranje metrik (Prometheus + Grafana) za igro validatorjev<\/li>\n Izumiti, kako se bodo izra\u010dunavale Validator Points (VP)<\/li>\n Razviti javni skript za izra\u010dun VP validatorjev na podlagi podatkov iz blockchaina<\/li>\n Razviti spletni vmesnik za prikaz top validatorjev in stanja igre validatorjev (koliko \u010dasa je \u0161e do konca, kdo ima koliko VP itd.)<\/li>\n Razviti in avtomatizirati zagon poljubnega \u0161tevila lastnih nod, na\u010drtovati postopek povezovanja validatorjev v igro (kdaj in kako izklopiti svoje node, oddajati in umikati glasove za njih)<\/li>\n Izra\u010dunati, koliko \u017eetonov je treba podeliti in razviti pogodbo-faucet<\/li>\n Narediti benchmark skript (prenosi \u017eetonov, masovno uporabo shranjevanja, masovno uporabo omre\u017eja) <\/li>\n Zbrati vse udele\u017eence v enem klepetu za hitro komunikacijo<\/li>\n Zagnati blockchain malo pred za\u010detkom igre<\/li>\n Po\u010dakati na za\u010detni blok, za\u010deti igro<\/li>\n Preizkusiti mre\u017eo z ve\u010d vrstami transakcij<\/li>\n Izvesti hard fork<\/li>\n Spremeniti seznam validatorjev<\/li>\n Ponoviti to\u010dko 13, 14, 15 v razli\u010dnih vrstnih redih, pri \u010demer ohranjati stabilnost mre\u017ee<\/li>\n Po\u010dakati na kon\u010dni blok, kon\u010dati igro, izra\u010dunati VP<\/li>\n<\/ul>\n<\/p>\n
Treba je omeniti, da je igra validatorjev nova zgodba in je bila izvedena le nekajkrat, zato tega bes teksta ne jemljite kot kon\u010dni priro\u010dnik. V sodobnem IT poslu ni analogov - predstavljajte si, da se banke pred zagon sistemov pla\u010devanja med seboj tekmujejo, kdo bolje izvaja transakcije strank. Tradicionalni pristopi vam verjetno ne bodo pomagali pri ustvarjanju velikih decentraliziranih omre\u017eij, zato obvladujte nove poslovne modele, organizirajte svoje igre, dolo\u010dite dostojne, nagradite jih in naj delujejo va\u0161i distribuirani sistemi hitro in stabilno.<\/p>\n
Izvor: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0418\u0442\u0430\u043a, \u0432\u0430\u0448\u0430 \u043a\u043e\u043c\u0430\u043d\u0434\u0430 \u0437\u0430\u043a\u043e\u043d\u0447\u0438\u043b\u0430 alpha-\u0432\u0435\u0440\u0441\u0438\u044e \u0432\u0430\u0448\u0435\u0433\u043e \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u0430, \u0438 \u043f\u0440\u0438\u0448\u043b\u043e \u0432\u0440\u0435\u043c\u044f \u0437\u0430\u043f\u0443\u0441\u043a\u0430\u0442\u044c testnet, \u0430 \u0437\u0430\u0442\u0435\u043c \u0438 mainnet. \u0423 \u0432\u0430\u0441 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0438\u0439 \u0431\u043b\u043e\u043a\u0447\u0435\u0439\u043d, \u0441 \u043d\u0435\u0437\u0430\u0432\u0438\u0441\u0438\u043c\u044b\u043c\u0438 \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c\u0438, \u0445\u043e\u0440\u043e\u0448\u0435\u0439 \u044d\u043a\u043e\u043d\u043e\u043c\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u043c\u043e\u0434\u0435\u043b\u044c\u044e, \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c\u044e, \u0432\u044b \u0441\u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043b\u0438 governance \u0438 \u0442\u0435\u043f\u0435\u0440\u044c \u043f\u043e\u0440\u0430 \u0431\u044b \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c \u0432\u0441\u0435 \u044d\u0442\u043e \u0432 \u0434\u0435\u043b\u0435. \u0412 \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u043e\u043c \u043a\u0440\u0438\u043f\u0442\u043e\u0430\u043d\u0430\u0440\u0445\u0438\u0447\u0435\u0441\u043a\u043e\u043c \u043c\u0438\u0440\u0435, \u0432\u044b \u0432\u044b\u043a\u043b\u0430\u0434\u044b\u0432\u0430\u0435\u0442\u0435 \u0432 \u0441\u0435\u0442\u044c genesis block, \u043e\u043a\u043e\u043d\u0447\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043a\u043e\u0434 \u043d\u043e\u0434\u044b \u0438 \u0432\u0430\u043b\u0438\u0434\u0430\u0442\u043e\u0440\u044b \u0441\u0430\u043c\u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39478","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t