servere<\/a> er i sig selv en vanskelig opgave, og blockchain skal startes med indsatsen fra loyale, men uafh\u00e6ngige deltagere. Og hvis, i et firma, administratorerne har fuld adgang til alle maskiner, logs, og generel overv\u00e5gning, s\u00e5 vil validatorerne n\u00e6gte adgang til deres servere og sandsynligvis foretr\u00e6kke at bygge deres egen infrastruktur, da den kontrollerer adgangen til validatorens prim\u00e6re aktiver \u2014 stemmeindsatserne. Denne adf\u00e6rd muligg\u00f8r opbygningen af distribuerede sikre netv\u00e6rk \u2014 uafh\u00e6ngigheden af de anvendte cloud-udbydere, virtuelle og 'baremetal' servere, forskellige operativsystemer, alt dette g\u00f8r angreb p\u00e5 et s\u00e5dant netv\u00e6rk ekstremt ineffektive \u2014 der anvendes for meget forskelligt software. For eksempel i Ethereum bruges der to prim\u00e6re implementeringer af noden, den p\u00e5 Go og den p\u00e5 Rust, og et angreb, der er effektivt for \u00e9n implementering, virker ikke for en anden.<\/p>\n<\/p>\n
Derfor skal alle processer til start og drift af blockchains organiseres, s\u00e5 enhver validator, eller endda en lille gruppe af validatorer, p\u00e5 ethvert tidspunkt kan kaste deres computere ud af vinduet og forlade systemet, uden at noget g\u00e5r i stykker, og de resterende validatorer fortsat effektivt kan opretholde netv\u00e6rket og tilslutte nye validatorer. Ved opstart af netv\u00e6rket, n\u00e5r en validator er i Europa, en anden i Sydamerika og en tredje i Asien, er det temmelig vanskeligt at opn\u00e5 enighed blandt flere dusin uafh\u00e6ngige grupper og motivere dem til resultatet. <\/p>\n
<\/p>\n
Validatorer<\/h2>\n <\/p>\n
Lad os forestille os lanceringen af en hypotetisk moderne blockchain (det meste af det beskrevne g\u00e6lder for blockchains baseret p\u00e5 enhver moderne familie af blockchains: Ethereum, EOS, Polkadot, Cosmos og andre, der anvender proof-of-stake konsensus. De prim\u00e6re akt\u00f8rer i s\u00e5danne blockchains er validatorhold, der opretter deres egne uafh\u00e6ngige servere, validerer og producerer nye blokke og modtager de bel\u00f8nninger, der er afsat af netv\u00e6rket til dem, der deltager i konsensus. For at starte nye netv\u00e6rk kr\u00e6ves der flere dusin validatorer (s\u00e5 mange kan nu mere eller mindre effektivt n\u00e5 konsensus p\u00e5 sekunder), derfor annoncerer projektet registreringen, hvor validatorer deler offentlige oplysninger om sig selv med brugerne, og overbeviser dem om, at de er villige til at levere kvalitetsservice til det nye netv\u00e6rk.<\/p>\n
<\/p>\n
Validatorvirksomhed er en forretning, der g\u00f8r det muligt at estimere validatorens potentielle indkomst meget pr\u00e6cist, hurtigt flytte ressourcer mellem projekter, og i tilf\u00e6lde af succes med det valgte netv\u00e6rk, kan validatoren, som et fuldt medlem af DAO og ansvarlig part, udvikle projektet, eller blot levere en fremragende teknisk service for helt transparente, \u00e6rligt tjente penge. Ved beregning af bel\u00f8nningen til validatorerne pr\u00f8ver projekterne at tage h\u00f8jde for validatorernes omkostninger og g\u00f8re bel\u00f8nningen for blokke s\u00e5dan, at denne forretning er rentabel, men samtidig ikke tillader validatorer at kollapse \u00f8konomien ved at oversv\u00f8mme dem med penge og ber\u00f8ve de \u00f8vrige brugere af netv\u00e6rket.<\/p>\n
<\/p>\n
Virksomhedens validatorer kr\u00e6ver en h\u00f8j grad af p\u00e5lidelighed i tjenesterne, hvilket betyder, at devops- og udviklerteamene skal have et h\u00f8jt niveau af forberedelse og kostbare beregningsressourcer. Selv uden behov for at mine hashes i proof-of-work-netv\u00e6rk, er en blockchain-node en stor tjeneste, der optager meget hukommelse, forbruger mange beregninger, validerer, registrerer data p\u00e5 disk og sender store m\u00e6ngder data ud i netv\u00e6rket. For at lagre transaktionslister og blockchains for blokke med flere tusinde sm\u00e5 transaktioner kr\u00e6ves der i \u00f8jeblikket opbevaring p\u00e5 over 50 Gb, og for blokke skal dette v\u00e6re SSD. State-databaserne for blockchains med st\u00f8tte for smart contracts kan allerede overstige 64Gb RAM. Servere med de n\u00f8dvendige specifikationer er ret dyre, en Ethereum- eller EOS-node kan koste fra 100 til 200 $\/m\u00e5ned. Tils\u00e6t hertil den \u00f8gede l\u00f8nudgift for udviklere og devops, der arbejder d\u00f8gnet rundt for at l\u00f8se problemer, selv om natten, da nogle validatorer let kan befinde sig p\u00e5 den anden halvkugle. Ikke desto mindre kan ejerskab af en validator-node i gunstige \u00f8jeblikke generere betydelige indt\u00e6gter (i tilf\u00e6lde af EOS \u2013 op til 10.000 $ per dag).<\/p>\n
<\/p>\n
Validering er kun en af de nye potentielle IT-roller for iv\u00e6rks\u00e6ttere og virksomheder, efterh\u00e5nden som programm\u00f8rer finder p\u00e5 stadig mere sofistikerede algoritmer, der bel\u00f8nner \u00e6rebarhed og straffer bedrag og tyveri. Der opst\u00e5r tjenester, der offentligg\u00f8r vigtige data (orakler), udf\u00f8rer overv\u00e5gning (slashing af indskud og straffelse af bedragere ved at offentligg\u00f8re bevis for bedrageri), tjenester til konfliktl\u00f8sning, forsikringer og optioner; selv garbage collection er et potentielt stort marked i smart contract-systemer, hvor betaling for datalagring er n\u00f8dvendig. <\/p>\n
<\/p>\n
Problemer med at starte en blockchain<\/h2>\n <\/p>\n
Offentligheden af blockchain, som har gjort det muligt for folk fra enhver nation at deltage frit i netv\u00e6rket af computere, samt den nemme adgang for enhver script kiddie via en guide p\u00e5 GitHub, er ikke altid en fordel. Jagten p\u00e5 en ny token tvinger ofte validatorer til at \"mine en ny m\u00f8nt ved starten\" i h\u00e5bet om v\u00e6rdistigning og mulighed for hurtigt at s\u00e6lge det, de har tjent. Det betyder ogs\u00e5, at hvem som helst kan v\u00e6re din validator, selv anonymt, og de kan stemmes p\u00e5 ligesom alle andre validatorer (selv om det vil v\u00e6re vanskeligt for anonymen at samle stemmer fra interessenter, s\u00e5 lad os lade de skr\u00e6mmende fort\u00e6llinger om anonyme kryptovalutaer til politikerne). Alligevel<\/p>\n
<\/p>\n
Projektteamet har en opgave - at f\u00e5 fat i de personer, der i fremtiden kan sikre stabil drift af noder, som har viden om sikkerhed, kan l\u00f8se problemer hurtigt, samarbejde med andre validatorer og handle kollektivt - afh\u00e6ngig af disse kvaliteter vil kvaliteten af den token, som netv\u00e6rksdeltagere planl\u00e6gger at investere deres tid og ressourcer i, v\u00e6re. Ansvarsbevidste grundl\u00e6ggere, n\u00e5r de vurderer risici, forst\u00e5r godt, at ved lanceringen af software af denne st\u00f8rrelse vil der uundg\u00e5eligt opst\u00e5 fejl i koden og konfigurationen af noder, og at netv\u00e6rkets stabilitet afh\u00e6nger af, hvor godt udviklerne og validatorer sammen vil l\u00f8se s\u00e5danne problemer.<\/p>\n
<\/p>\n
Teamet er klar til at stemme i mainnet for enhver validator, men det ville v\u00e6re rart at vide, for hvem, hvilke der er gode? Den med det st\u00f8rste portef\u00f8lje? Det har n\u00e6rmest ingen i \u00f8jeblikket. Ud fra teamprofiler p\u00e5 Linkedin? Erfarne devops eller sikkerhedseksperter vil ikke give jer nogen profiler p\u00e5 Linkedin. Baseret p\u00e5 udtalelser i chatten, opslag og hj\u00e6lp til andre under forberedelserne? Godt, men subjektivt og un\u00f8jagtigt.<\/p>\n
<\/p>\n
Under s\u00e5danne forhold er der kun \u00e9n l\u00f8sning - et spil, der kan l\u00f8se problemer for alle - hvor man kan v\u00e6lge de bedste validatorer, men vigtigst af alt - teste blockchainens robusthed og gennemf\u00f8re en fuldskala feltpr\u00f8ve af blockchainen under aktiv brug, \u00e6ndringer i konsensus og forekomsten og rettelsen af fejl. Denne procedure blev f\u00f8rst pr\u00e6senteret som et spil af drengene fra projektet Cosmos, og denne id\u00e9 er uden tvivl en fremragende m\u00e5de at forberede netv\u00e6rket til lancering af et p\u00e5lideligt og fejltolerant mainnet.<\/p>\n
<\/p>\n
Game of Validators<\/h2>\n <\/p>\n
Jeg vil beskrive validator-spillet, som vi designede til blockchain DAO.Casino (DAOBet) baseret p\u00e5 en fork af EOS, kaldet Haya, der har et lignende governance-system \u2014 validatorer v\u00e6lges ved afstemninger fra enhver konto, hvor en del af balancen, der stemmes for validatoren, fryses. Enhver konto, der har den prim\u00e6re tokens BET p\u00e5 sin balance, kan stemme p\u00e5 den valgte validator med hvilken som helst del af sin balance. Stemmerne summeres, og der udarbejdes en topvaliderliste. I forskellige blockchains er denne proces organiseret forskelligt, og normalt er det netop i denne del, at en ny blockchain adskiller sig fra sin for\u00e6lder. Man m\u00e5 sige, at i vores tilf\u00e6lde lever EOS fuldt ud op til \u201cOS\u201d i sit navn; vi bruger faktisk EOS som det grundl\u00e6ggende operativsystem til at implementere en modificeret version af blockchainen til opgaverne for DAOBet.<\/p>\n
<\/p>\n
Jeg vil beskrive specifikke problemer og hvordan de kan l\u00f8ses indenfor spillet. Lad os forestille os et netv\u00e6rk, hvor din server kan blive \u00e5bent angrebet, hvor du er n\u00f8dt til kontinuerligt at interagere med netv\u00e6rket for at opretholde din position som validator, fremme din validator og s\u00f8rge for, at den producerer blokke og at de kommer til andre validatorer til tiden, ellers vil validatoren blive udelukket fra listen.<\/p>\n
<\/p>\n
Hvordan v\u00e6lger man de bedste vindere?<\/h3>\n <\/p>\n
Det prim\u00e6re tekniske krav til spillet er, at dets resultater skal v\u00e6re offentligt verificerbare. Det betyder, at resultaterne af spillet: TOP-vinderne, skal dannes strengt p\u00e5 baggrund af data, som enhver deltager kan kontrollere. I et centraliseret system kunne vi m\u00e5le \u201cuptime\u201d for hver validator og bel\u00f8nne dem, der har v\u00e6ret online mest, eller der har passeret mest netv\u00e6rkstrafik. Vi kunne indsamle data om CPU-belastning, hukommelse og bel\u00f8nne dem, der har arbejdet h\u00e5rdt. Men enhver s\u00e5dan indsamling af metrics indeb\u00e6rer eksistensen af et centralt knudepunkt, og noderne er alle uafh\u00e6ngige og kan opf\u00f8re sig, som de vil, og sende hvilke som helst data.<\/p>\n
<\/p>\n
Der naturlige l\u00f8sning er derfor, at vindere skal bestemmes ud fra data fra blockchainen, da man kan se, hvilke validatorer der har produceret hvilken blok, og hvilke transaktioner der blev inkluderet i den. Vi har kaldt dette antal Validator Points (VP), og at tjene disse er den prim\u00e6re m\u00e5ls\u00e6tning for validatorerne i spillet. I vores tilf\u00e6lde er den enkleste, offentligt verificerbare og effektive m\u00e5ling af en validators \"nytte\" VP = antal_producerede_valideringsblokke over en given tidsperiode.<\/p>\n
<\/p>\n
Dette enkle valg skyldes, at governance i EOS allerede tager h\u00f8jde for mange opst\u00e5ede problemer, da EOS er en arv af tre generationer af reelt fungerende blockchains med stor erfaring i kompleks netv\u00e6rksstyring. N\u00e6sten enhver validatorproblematik med netv\u00e6rket, CPU eller disk f\u00f8rer kun til \u00e9t problem \u2013 man underskriver f\u00e6rre blokke og modtager mindre betaling for arbejdet, hvilket igen f\u00f8rer os tilbage til antallet af underskrevne blokke \u2013 for EOS er dette et fremragende og simpelt valg.<\/p>\n
<\/p>\n
For andre blockchains kan metoden til beregning af Validator Points variere, for eksempel for pBFT-baserede konsensusmetoder (Tendermint\/Cosmos, Aura konsensus fra Parity Substrate), hvor hver blok skal underskrives af flere validatorer. Det kan give mening at t\u00e6lle individuelle underskrifter fra validatorerne, snarere end blokke, og muligvis ogs\u00e5 tage h\u00f8jde for ikke-afsluttede konsensusrunder, som forbruger ressourcer fra andre validatorer; dette afh\u00e6nger i h\u00f8j grad af typen af konsensus. <\/p>\n
<\/p>\n
Hvordan man modellerer reelle driftsbetingelser<\/h3>\n <\/p>\n
Grundl\u00e6ggernes opgave er at kontrollere validatorer under forhold, der ligner virkeligheden, uden nogen form for centraliseret kontrol. Dette problem kan l\u00f8ses med en faucet-kontrakt, der uddeler lige m\u00e6ngder af den prim\u00e6re token til validatorer og alle interesserede. For at modtage tokens p\u00e5 saldoen skal man oprette en transaktion og sikre, at netv\u00e6rket inkluderer den i en blok. Dermed er det n\u00f8dvendigt for validatoren konstant at opdatere sin saldo med nye tokens og stemme p\u00e5 sig selv for at komme til tops. Denne aktivitet skaber en konstant belastning p\u00e5 netv\u00e6rket, og parametrene kan justeres, s\u00e5 m\u00e6ngden af anmodninger er tilstr\u00e6kkelig stor til en grundig netv\u00e6rkstests. Planl\u00e6g derfor faucet-kontrakten i forvejen som et vigtigt v\u00e6rkt\u00f8j til netv\u00e6rksstart og begynd at tilpasse dens parametre tidligt.<\/p>\n
<\/p>\n
Anmodningen om tokens fra faucet og validatorernes stemmeemulering efterligner alligevel ikke helt arbejdet i blockchain, is\u00e6r under ekstremt belastede tilstande. Derfor bliver blockchain-teamet n\u00f8dt til p\u00e5 den ene eller anden m\u00e5de at skrive yderligere benchmarks, der kan belaste netv\u00e6rket. S\u00e6rligt tilpassede smart contracts spiller en vigtig rolle i dette og g\u00f8r det muligt at teste individuelle undersystemer. For at teste storage gemmer kontrakten tilf\u00e6ldige data i blockchain, og for at kontrollere netv\u00e6rksressourcer kr\u00e6ver testkontrakten en stor m\u00e6ngde inddata, hvilket dermed \u00f8ger m\u00e6ngden af transaktioner \u2014 ved at starte str\u00f8mmen af s\u00e5danne transaktioner p\u00e5 vilk\u00e5rlige tidspunkter tester teamet samtidig stabiliteten af koden og validatorernes robusthed.<\/p>\n
<\/p>\n
Et s\u00e6rskilt sp\u00f8rgsm\u00e5l er opdatering af noderne og udf\u00f8relsen af hard forks. Det er n\u00f8dvendigt, at der, i tilf\u00e6lde af en fejl, s\u00e5rbarhed eller sammensv\u00e6rgelse af ondsindede validatorer, foreligger en handlingsplan for validatorerne, som allerede er afpr\u00f8vet i validatorernes spil. Her kan man finde p\u00e5 ordninger til tildeling af VP for hurtig gennemf\u00f8relse af hard forks, eksempelvis ved at straffe alle validatorer, der ikke har opdateret til den nye version af nodens kode, men det er sv\u00e6rt at implementere, da det komplicerer beregningen. Man kan simulere en situation med akut anvendelse af en hard fork ved kunstigt at \"\u00f8del\u00e6gge\" blockchainen p\u00e5 et bestemt blok. Produktion af blokke stopper, og de, der hurtigst aktiverer sig og begynder at validere blokke, vil v\u00e6re dem, der vinder, s\u00e5 VP baseret p\u00e5 antallet af validerede blokke passer godt ind her.<\/p>\n
<\/p>\n
<\/p>\n
P\u00e5 trods af mistillid mellem validatorerne er det fordelagtigt for alle hurtigt at modtage aktuel information om netv\u00e6rkets tilstand for at tr\u00e6ffe hurtigere beslutninger. Derfor opstiller projektteamet en service til indsamling og visualisering af mange metrikker fra validatorernes servere, hvilket g\u00f8r det muligt at se situationen samlet for hele netv\u00e6rket og hurtigt bestemme, hvad der foreg\u00e5r. Desuden er det i b\u00e5de validatorernes og projektets interesse, at projektteamet hurtigt retter opdagede fejl, s\u00e5 det giver mening at starte med at indsamle logfiler og fejldata fra validatorernes maskiner til en maskine tilg\u00e6ngelig for blockchain-udviklerne. Ingen har interesse i at fordreje information, s\u00e5 disse tjenester opstilles af projektteamet og kan stole p\u00e5. Det giver mening at indsamle systemmetrikker fra validatorerne og, n\u00f8dvendigvis, de mest vigtige metrikker fra blockchainen selv \u2014 for DAOBet er det tid til finalisering og eftersl\u00e6b for den senest finaliserede blok. Takket v\u00e6re dette ser teamet stigninger i hukommelsesforbruget p\u00e5 noderne ved opstart af benchmark, samt problemer hos enkelte validatorer. <\/p>\n
<\/p>\n
Vigtige punkter for afholdelse af validatorernes spil<\/h2>\n <\/p>\n
Det viser sig, at hvis du \u00f8nsker at give validatorerne officiel tilladelse til at angribe hinandens maskiner (uofficielt kan de allerede g\u00f8re dette) \u2014 skal det formuleres juridisk som sikkerhedstest, da lovgivningen i nogle lande kan straffe DDoS- eller netv\u00e6rksangreb. Et andet vigtigt sp\u00f8rgsm\u00e5l er, hvordan man bel\u00f8nner validatorerne. Naturlige pr\u00e6mier er projektets tokens, som overf\u00f8res til mainnet, men en massiv distribution af tokens til enhver, der kan starte en node, er heller ikke den bedste l\u00f8sning. Det vil sandsynligvis kr\u00e6ve, at du balancerer mellem to yderligheder:<\/p>\n
<\/p>\n
Uddel hele pr\u00e6miefonden i overensstemmelse med de optjente VP
<\/p>\n
Uddel pr\u00e6miefonden til top-N validatorer baseret p\u00e5 spillets resultater
<\/p>\n
Hvilket alternativ du foretr\u00e6kker \u2014 er op til dig <\/p>\n
<\/p>\n
Der er ogs\u00e5 et andet aspekt \u2014 det er slet ikke sikkert, at mange validatorer vil str\u00f8mme til at deltage i spillet p\u00e5 din opfordring, og af dem, der beslutter sig for at pr\u00f8ve, vil ikke alle engang installere og starte en node \u2014 normalt har projekter p\u00e5 dette stadium ret sparsomme dokumentation, der optr\u00e6der fejl, og udviklerne, der arbejder under tidspres, svarer ikke alt for hurtigt p\u00e5 sp\u00f8rgsm\u00e5l. Derfor b\u00f8r du f\u00f8r spillets start ogs\u00e5 overveje, hvad der skal g\u00f8res, hvis ikke det \u00f8nskede antal validatorer kan samles. I dette tilf\u00e6lde startes de manglende validatorer af projektteamet ved spillets start, deltager i konsensus, men kan ikke v\u00e6re vindere.<\/p>\n
<\/p>\n
Konklusion<\/h2>\n <\/p>\n
Afslutningsvis har jeg fors\u00f8gt at samle en liste over det, der skal t\u00e6nkes, g\u00f8res og startes for effektivt at gennemf\u00f8re validatorernes spil med ovenst\u00e5ende beskrivelse<\/p>\n
<\/p>\n
Hvad der skal g\u00f8res for at starte et rigtigt spil for validatorer:
<\/p>\n
\nlave og ops\u00e6tte et webinterface og give CLI til at stemme p\u00e5 validatorer<\/li>\n S\u00f8rg for, at metrics fra den k\u00f8rende validatornode kan sendes til en centraliseret service (som f.eks. Prometheus)<\/li>\n Ops\u00e6t en server til indsamling af metrics (Prometheus + Grafana) til validatorernes spil<\/li>\n Find ud af, hvordan Validator Points (VP) skal beregnes<\/li>\n Udvikle et offentligt script, der beregner VP for validatorer baseret p\u00e5 data fra blockchain<\/li>\n Udvikle en webgr\u00e6nseflade til at vise top-validatorer og status for validatorernes spil (hvor lang tid der er tilbage, hvor mange VP hver har osv.)<\/li>\n Udvikle og automatisere opstarten af et vilk\u00e5rligt antal egne noder, designe processen for forbindelsen af validatorer til spillet (hvorn\u00e5r og hvordan man slukker for sine noder, afgiver og tr\u00e6kker stemmer tilbage for dem)<\/li>\n Beregn, hvor mange tokens der skal uddeles, og udvikle en kontrakt-faucet<\/li>\n Lave et benchmark-script (tokenoverf\u00f8rsler, massiv brug af lager, massiv brug af netv\u00e6rk) <\/li>\n Samle alle deltagere i \u00e9n chat for hurtig kommunikation<\/li>\n Lancere blockchain lidt f\u00f8r spillets start<\/li>\n Vent p\u00e5 startblokken, begynd spillet<\/li>\n Teste netv\u00e6rket med flere typer transaktioner<\/li>\n Udf\u00f8re en hard fork<\/li>\n \u00c6ndre listen over validatorer<\/li>\n Gentage pkt. 13, 14, 15 i forskellig r\u00e6kkef\u00f8lge, mens stabiliteten af netv\u00e6rket opretholdes<\/li>\n Vent p\u00e5 den endelige blok, afslut spillet, og beregn VP<\/li>\n<\/ul>\n<\/p>\n
Det skal siges, at validatorernes spil er en ny historie, der kun er blevet afholdt et par gange, s\u00e5 dette tekst skal ikke betragtes som en f\u00e6rdig vejledning. Der findes ingen analoger i den moderne IT-verden \u2013 forestil dig, at banker konkurrerer om, hvem der bedst kan gennemf\u00f8re kundetransaktioner, inden de lancerer deres betalingssystem. Traditionelle metoder vil n\u00e6ppe hj\u00e6lpe dig med at oprette store decentrale netv\u00e6rk, s\u00e5 l\u00e6r nye forretningsmodeller at kende, afhold dine spil, udpeg v\u00e6rdige, bel\u00f8n dem, og lad dine distribuerede systemer fungere hurtigt og stabilt.<\/p>\n
Kilde: 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