servidores<\/a> \u00e9 uma tarefa dif\u00edcil por si s\u00f3, e a blockchain precisa ser iniciada com os esfor\u00e7os de participantes leais, mas independentes. E, se em uma corpora\u00e7\u00e3o, ao iniciar, os administradores t\u00eam acesso total a todas as m\u00e1quinas, logs e monitoramento geral, os validadores n\u00e3o deixar\u00e3o ningu\u00e9m perto de seus servidores e, provavelmente, preferir\u00e3o construir sua infraestrutura de forma independente, pois ela controla o acesso aos principais ativos do validador \u2014 os stakes dos votantes. \u00c9 esse comportamento que permite construir redes seguras e distribu\u00eddas \u2014 a independ\u00eancia dos provedores de nuvem utilizados, servidores virtuais e 'baremetal', diferentes sistemas operacionais; tudo isso torna os ataques a essa rede extremamente ineficazes \u2014 h\u00e1 uma variedade excessiva de software sendo utilizado. Por exemplo, no Ethereum, s\u00e3o utilizadas duas implementa\u00e7\u00f5es principais do n\u00f3, em Go e em Rust, e um ataque que \u00e9 eficaz para uma implementa\u00e7\u00e3o n\u00e3o funciona para a outra.<\/p>\n<\/p>\n
Portanto, todos os processos de lan\u00e7amento e opera\u00e7\u00e3o de blockchains devem ser organizados de forma que qualquer validador, ou mesmo um pequeno grupo de validadores, possa a qualquer momento jogar seus computadores pela janela e ir embora, sem que nada quebre, e os validadores restantes devam continuar a manter a rede de forma eficiente e conectar novos validadores. Ao iniciar a rede, quando um validador est\u00e1 na Europa, o segundo na Am\u00e9rica do Sul e o terceiro na \u00c1sia, alcan\u00e7ar um funcionamento coordenado de v\u00e1rias dezenas de grupos independentes e motiv\u00e1-los no resultado \u00e9 bastante dif\u00edcil. <\/p>\n
<\/p>\n
Validadores<\/h2>\n <\/p>\n
Vamos imaginar o lan\u00e7amento de um hipot\u00e9tico blockchain moderno (a maior parte do que est\u00e1 sendo descrito se aplica a blockchains da maioria das fam\u00edlias modernas de blockchains: Ethereum, EOS, Polkadot, Cosmos e outros, que utilizam consenso proof-of-stake. Os principais protagonistas desses blockchains s\u00e3o equipes de validadores, que instalam seus pr\u00f3prios servidores independentes, validando e produzindo novos blocos, recebendo as recompensas previstas pela rede para aqueles que participam do consenso. Para lan\u00e7ar novas redes, s\u00e3o necess\u00e1rios v\u00e1rias dezenas de validadores (o n\u00famero que consegue alcan\u00e7ar um consenso de maneira eficiente em segundos), por isso o projeto anuncia um registro, onde os validadores compartilham informa\u00e7\u00f5es p\u00fablicas sobre si com os usu\u00e1rios, convencendo-os de que pretendem servir a nova rede de forma qualificada.<\/p>\n
<\/p>\n
A valida\u00e7\u00e3o \u00e9 um neg\u00f3cio que permite avaliar com precis\u00e3o o potencial de renda de um validador, transferir rapidamente recursos entre projetos e, em caso de sucesso da rede que escolher, o validador pode, como um participante leg\u00edtimo da DAO e respons\u00e1vel, desenvolver o projeto, ou simplesmente oferecer um excelente servi\u00e7o t\u00e9cnico por dinheiro totalmente transparente e honestamente ganho. Ao calcular a recompensa dos validadores, os projetos se esfor\u00e7am para levar em conta os custos dos validadores e fazer a recompensa por bloco de forma que esse neg\u00f3cio seja lucrativo, mas que n\u00e3o permita que os validadores quebrem a economia inundando-a com dinheiro e privando os demais usu\u00e1rios da rede.<\/p>\n
<\/p>\n
O neg\u00f3cio de validadores exige alta resili\u00eancia dos servi\u00e7os, o que significa um alto n\u00edvel de prepara\u00e7\u00e3o para devops e desenvolvedores, al\u00e9m de recursos computacionais caros. Mesmo sem a necessidade de minerar hashes em redes proof-of-work, um n\u00f3 de blockchain \u00e9 um grande servi\u00e7o que consome muita mem\u00f3ria, requer muitos c\u00e1lculos, valida, grava em disco e transmite grandes volumes de dados na rede. Para armazenamento de logs de transa\u00e7\u00f5es e cadeias de blocos em um blockchain com milhares de pequenas transa\u00e7\u00f5es em um bloco, atualmente \u00e9 necess\u00e1rio um armazenamento de pelo menos 50 Gb ou mais, e deve ser um SSD para os blocos. O banco de dados de estado de blockchains que suportam contratos inteligentes pode j\u00e1 exceder 64Gb de mem\u00f3ria RAM. Servidores com as caracter\u00edsticas necess\u00e1rias s\u00e3o bastante caros, e um n\u00f3 Ethereum ou EOS pode custar entre 100 e 200 $\/m\u00eas. Adicione a isso o aumento dos custos com m\u00e3o-de-obra para desenvolvedores e devops trabalhando em turnos, que resolvem problemas at\u00e9 \u00e0 noite durante o lan\u00e7amento, j\u00e1 que parte dos validadores pode estar em outro hemisf\u00e9rio. No entanto, em momentos favor\u00e1veis, possuir um n\u00f3 validador pode gerar uma renda significativa (no caso do EOS, at\u00e9 10.000 $ por dia).<\/p>\n
<\/p>\n
A valida\u00e7\u00e3o \u00e9 apenas um dos novos pap\u00e9is potenciais de TI para empreendedores e empresas. \u00c0 medida que os programadores criam algoritmos cada vez mais sofisticados que recompensam a honestidade e punem fraude e roubo, surgem servi\u00e7os que desempenham fun\u00e7\u00f5es de publica\u00e7\u00e3o de dados importantes (or\u00e1culos), fiscaliza\u00e7\u00e3o (slashing de dep\u00f3sitos e puni\u00e7\u00e3o de fraudadores por meio da publica\u00e7\u00e3o de provas de fraude), servi\u00e7os de resolu\u00e7\u00e3o de disputas, seguros e op\u00e7\u00f5es. At\u00e9 a coleta de lixo \u00e9 um mercado potencialmente grande em sistemas de contratos inteligentes, onde \u00e9 necess\u00e1rio pagar pelo armazenamento de dados. <\/p>\n
<\/p>\n
Desafios do lan\u00e7amento de blockchain<\/h2>\n <\/p>\n
A transpar\u00eancia do blockchain, que permite que qualquer um participe da rede de computadores de qualquer pa\u00eds e a facilidade de conex\u00e3o \u00e0 rede por qualquer script kiddie seguindo as instru\u00e7\u00f5es no GitHub, nem sempre \u00e9 uma vantagem. A busca por um novo token frequentemente leva os validadores a \"minerar uma nova moeda no in\u00edcio\", na esperan\u00e7a de que o pre\u00e7o aumente e de poder vender rapidamente o que ganharam. Al\u00e9m disso, isso significa que qualquer um, at\u00e9 mesmo um an\u00f4nimo, pode ser seu validador, e \u00e9 poss\u00edvel votar nele assim como em outros validadores (embora seja dif\u00edcil para um an\u00f4nimo reunir votos de stakeholders, ent\u00e3o deixemos as hist\u00f3rias assustadoras sobre criptomoedas an\u00f4nimas para os pol\u00edticos). No entanto,<\/p>\n
<\/p>\n
A equipe do projeto tem a tarefa de conseguir de alguma forma atrair para sua rede aqueles que, no futuro, possam garantir a opera\u00e7\u00e3o est\u00e1vel dos n\u00f3s, entendam de seguran\u00e7a, sejam capazes de resolver problemas rapidamente, cooperar com outros validadores e agir em conjunto \u2014 dessas qualidades depende completamente a qualidade do token em que os participantes da rede pretendem investir seu tempo e recursos. Fundadores sensatos, ao avaliar riscos, entendem bem que, ao lan\u00e7ar um software dessa magnitude, inevitavelmente enfrentar\u00e3o erros no c\u00f3digo, configura\u00e7\u00e3o de n\u00f3s, e que a estabilidade da rede depende de qu\u00e3o bem desenvolvedores e validadores resolver\u00e3o problemas semelhantes em conjunto.<\/p>\n
<\/p>\n
A equipe est\u00e1 pronta para votar no mainnet por quaisquer validadores, mas apenas se soubessem por quais, quais s\u00e3o bons? O maior portf\u00f3lio? Nesse momento, quase ningu\u00e9m tem isso. Pelos perfis da equipe no Linkedin? DevOps ou especialistas em seguran\u00e7a experientes n\u00e3o lhe fornecer\u00e3o nenhum perfil no Linkedin. Pelas declara\u00e7\u00f5es no chat, postagens e ajuda a outros na fase de prepara\u00e7\u00e3o? Isso \u00e9 bom, mas subjetivo e impreciso.<\/p>\n
<\/p>\n
Em tais condi\u00e7\u00f5es, resta uma \u00fanica solu\u00e7\u00e3o - um jogo que pode resolver os problemas de todos, onde ser\u00e1 poss\u00edvel escolher os melhores validadores, mas o principal - testar a resist\u00eancia do blockchain e realizar um teste de batalha em larga escala do blockchain em condi\u00e7\u00f5es de uso ativo, mudan\u00e7as no consenso, surgimento e corre\u00e7\u00e3o de erros. Pela primeira vez, esse procedimento foi apresentado como um jogo por pessoal do projeto Cosmos, e essa ideia \u00e9, sem d\u00favida, uma excelente maneira de preparar a rede para o lan\u00e7amento de um mainnet confi\u00e1vel e resiliente.<\/p>\n
<\/p>\n
Jogo dos Validadores<\/h2>\n <\/p>\n
Vou descrever o jogo dos validadores como o projetamos para a blockchain DAO.Casino (DAOBet), baseada no fork da EOS chamado Haya, que possui um mecanismo de governan\u00e7a semelhante \u2014 os validadores s\u00e3o escolhidos por vota\u00e7\u00e3o de qualquer conta, onde parte do saldo usado para votar em um validador fica congelada. Qualquer conta que possua o token principal BET pode votar em um validador escolhido usando qualquer parte de seu saldo. Os votos s\u00e3o somados e, no final, uma lista dos principais validadores \u00e9 constru\u00edda. Em diferentes blockchains, esse processo \u00e9 organizado de maneiras diversas, e geralmente \u00e9 nessa parte que uma nova blockchain se diferencia da original. \u00c9 v\u00e1lido dizer que, em nosso caso, a EOS realmente justifica o \u201cOS\u201d em seu nome, pois utilizamos a EOS como o sistema operacional base para implementar uma vers\u00e3o modificada da blockchain para as necessidades do DAOBet.<\/p>\n
<\/p>\n
Vou descrever problemas espec\u00edficos e como eles podem ser resolvidos no \u00e2mbito do jogo. Vamos imaginar uma rede onde seu servidor pode ser abertamente atacado, onde, para manter a posi\u00e7\u00e3o de validador, \u00e9 necess\u00e1rio interagir continuamente com a rede, promovendo seu validador e garantindo que ele produza blocos e que estes sejam entregues a tempo aos outros validadores; caso contr\u00e1rio, o validador ser\u00e1 removido da lista.<\/p>\n
<\/p>\n
Como selecionar os principais vencedores?<\/h3>\n <\/p>\n
A principal exig\u00eancia t\u00e9cnica para o jogo \u00e9 que seus resultados sejam publicamente verific\u00e1veis. Isso significa que os resultados do jogo: os principais vencedores, devem ser formados estritamente com base em dados que qualquer participante possa verificar. Em um sistema centralizado, poder\u00edamos medir o \u201cuptime\u201d de cada validador e recompensar aqueles que estiveram mais online ou que processaram a maior quantidade de tr\u00e1fego da rede. Poder\u00edamos coletar dados sobre o uso da CPU, mem\u00f3ria e recompensar aqueles que trabalharam de forma eficiente. Mas qualquer coleta dessas m\u00e9tricas implica a exist\u00eancia de um centro de coleta, e as n\u00f3dulos s\u00e3o todos independentes, podendo agir como desejarem e enviar quaisquer dados.<\/p>\n
<\/p>\n
Portanto, a solu\u00e7\u00e3o natural \u00e9 que os vencedores sejam definidos com base em dados da blockchain, pois atrav\u00e9s dela \u00e9 poss\u00edvel ver quem de os validadores produziu qual bloco e quais transa\u00e7\u00f5es foram inclu\u00eddas nele. Chamamos esse n\u00famero de Validator Points (VP), e ganh\u00e1-los \u00e9 o principal objetivo dos validadores no jogo. No nosso caso, a m\u00e9trica mais simples, publicamente verific\u00e1vel e eficiente de \"utilidade\" de um validador \u00e9 VP = n\u00famero_de_blocos_produzidos_pelo_validador em um determinado per\u00edodo de tempo.<\/p>\n
<\/p>\n
Essa escolha simples se deve ao fato de que a governan\u00e7a no EOS j\u00e1 prev\u00ea muitos dos problemas que surgem, uma vez que o EOS \u00e9 o sucessor de tr\u00eas gera\u00e7\u00f5es de blockchains reais com grande experi\u00eancia em gerenciamento complexo da rede. Quase quaisquer problemas que um validador tenha com a rede, processador ou disco levam a um \u00fanico problema \u2014 ele assina menos blocos, recebe menos pagamento pelo trabalho, o que nos leva novamente ao n\u00famero de blocos assinados \u2014 para o EOS, essa \u00e9 uma op\u00e7\u00e3o excelente e simples.<\/p>\n
<\/p>\n
Em outras blockchains, a forma de contar os Validator Points pode ser diferente, por exemplo, para consensos baseados em pBFT (Tendermint\/Cosmos, consenso Aura do Parity Substrate), onde cada bloco deve ser assinado por m\u00faltiplos validadores, faz sentido contar assinaturas individuais dos validadores, e n\u00e3o blocos. Talvez seja v\u00e1lido considerar rodadas de consenso n\u00e3o conclu\u00eddas, que consomem recursos de outros validadores, em geral isso depende muito do tipo de consenso. <\/p>\n
<\/p>\n
Como modelar condi\u00e7\u00f5es reais de opera\u00e7\u00e3o<\/h3>\n <\/p>\n
A tarefa dos fundadores \u00e9 verificar os validadores em condi\u00e7\u00f5es pr\u00f3ximas da realidade, sem ter nenhum controle centralizado. Esse problema pode ser resolvido com um contrato-faucet que distribui quantidades iguais do token principal para os validadores e todos os interessados. Para obter tokens no saldo, \u00e9 necess\u00e1rio formar uma transa\u00e7\u00e3o e garantir que a rede a inclua em um bloco. Assim, o validador, para vencer, precisa constantemente renovar seu saldo com novos tokens e votar em si mesmo, subindo para o topo. Essa atividade cria uma carga constante na rede, e os par\u00e2metros podem ser ajustados para que o fluxo de solicita\u00e7\u00f5es seja suficientemente significativo para um teste completo da rede. Portanto, planeje o contrato-faucet antecipadamente, como uma ferramenta importante para o lan\u00e7amento da rede, e comece a ajustar seus par\u00e2metros desde cedo.<\/p>\n
<\/p>\n
O pedido de tokens do faucet e o voto dos validadores n\u00e3o emulam completamente de forma justa o trabalho da blockchain, especialmente em modos de carga extrema. Portanto, a equipe da blockchain, de uma forma ou de outra, ainda precisar\u00e1 escrever benchmarks adicionais, permitindo sobrecarregar a rede. Contratos inteligentes especificamente criados com anteced\u00eancia desempenham um papel especial, permitindo testar subsistemas individuais. Para testar o armazenamento, o contrato armazena dados aleat\u00f3rios na blockchain, enquanto para verificar recursos de rede, o contrato de teste exige um grande volume de dados de entrada, aumentando assim o volume de transa\u00e7\u00f5es \u2014 ao lan\u00e7ar um fluxo dessas transa\u00e7\u00f5es em momentos aleat\u00f3rios, a equipe testa simultaneamente a estabilidade do c\u00f3digo e a resist\u00eancia dos validadores.<\/p>\n
<\/p>\n
Uma quest\u00e3o \u00e0 parte \u00e9 a atualiza\u00e7\u00e3o do c\u00f3digo dos n\u00f3s e a realiza\u00e7\u00e3o de hard forks. \u00c9 necess\u00e1rio que, em caso de surgimento de um bug, vulnerabilidade ou conluio de validadores mal-intencionados, os validadores tenham um plano de a\u00e7\u00e3o j\u00e1 ensaiado no jogo dos validadores. Podem ser elaborados esquemas de recompensas em VP para a r\u00e1pida aplica\u00e7\u00e3o do hard fork, por exemplo, penalizando todos os validadores que ainda n\u00e3o atualizaram a nova vers\u00e3o do c\u00f3digo do n\u00f3, mas isso \u00e9 dif\u00edcil de implementar e complica o c\u00e1lculo. Simular uma situa\u00e7\u00e3o de emerg\u00eancia para a aplica\u00e7\u00e3o do hard fork pode ser artificialmente \u201cquebrando\u201d a blockchain em um bloco espec\u00edfico. A produ\u00e7\u00e3o de blocos para, e no final, os que ativarem mais cedo e come\u00e7arem a assinar blocos sair\u00e3o ganhando, ent\u00e3o o VP baseado no n\u00famero de blocos assinados se aplica bem aqui.<\/p>\n
<\/p>\n
<\/p>\n
Apesar da desconfian\u00e7a entre os validadores, obter informa\u00e7\u00f5es atualizadas sobre o estado da rede de maneira oportuna \u00e9 vantajoso para todos, a fim de tomar decis\u00f5es mais r\u00e1pidas. Por isso, a equipe do projeto est\u00e1 implementando um servi\u00e7o para coletar e visualizar diversas m\u00e9tricas dos servidores dos validadores, que permite ver a situa\u00e7\u00e3o simultaneamente para toda a rede, possibilitando determinar rapidamente o que est\u00e1 acontecendo. Al\u00e9m disso, tanto para os validadores quanto para o projeto, \u00e9 vantajoso que a equipe do projeto corrija rapidamente os erros encontrados. Portanto, al\u00e9m da coleta de m\u00e9tricas, faz sentido tamb\u00e9m iniciar a coleta de logs e dados de erros das m\u00e1quinas dos validadores para uma m\u00e1quina acess\u00edvel aos desenvolvedores da blockchain. Ningu\u00e9m se beneficia de informa\u00e7\u00f5es distorcidas, portanto, esses servi\u00e7os s\u00e3o gerenciados pela equipe do projeto e podem ser confi\u00e1veis. Faz sentido coletar m\u00e9tricas sist\u00eamicas dos validadores e, necessariamente, as m\u00e9tricas mais importantes da pr\u00f3pria blockchain \u2014 para a DAOBet \u2014 isso inclui o tempo de finaliza\u00e7\u00e3o e a defasagem do \u00faltimo bloco finalizado. Com isso, a equipe v\u00ea o aumento do consumo de mem\u00f3ria nos n\u00f3s ao iniciar o benchmark, bem como problemas de validadores isolados. <\/p>\n
<\/p>\n
Pontos importantes sobre a realiza\u00e7\u00e3o do jogo dos validadores<\/h2>\n <\/p>\n
Descobriu-se que, se voc\u00ea deseja permitir oficialmente que os validadores ataquem uns aos outros (n\u00e3o oficialmente, eles j\u00e1 podem fazer isso) \u2014 \u00e9 necess\u00e1rio formular isso legalmente como um teste de seguran\u00e7a, pois, segundo as leis de alguns pa\u00edses, DDoS ou ataques de rede podem resultar em san\u00e7\u00f5es. Outra quest\u00e3o importante \u00e9 como premiar os validadores. Pr\u00eamios naturais s\u00e3o os tokens do projeto, que ser\u00e3o transferidos para o mainnet, mas a distribui\u00e7\u00e3o massiva de tokens para qualquer um que conseguir rodar um n\u00f3 tamb\u00e9m n\u00e3o \u00e9 a melhor op\u00e7\u00e3o. Provavelmente, voc\u00ea ter\u00e1 que equilibrar entre duas op\u00e7\u00f5es extremas:<\/p>\n
<\/p>\n
Distribuir todo o pr\u00eamio de acordo com os VP ganhos
<\/p>\n
Distribuir o fundo de pr\u00eamios para os validadores do top-N ao final do jogo
<\/p>\n
A decis\u00e3o de qual op\u00e7\u00e3o preferir \u00e9 sua <\/p>\n
<\/p>\n
H\u00e1 tamb\u00e9m outro ponto \u2014 n\u00e3o \u00e9 certo que dezenas de validadores se apressem em participar do jogo ao seu chamado, e dentre aqueles que decidirem tentar, nem todos instalar\u00e3o e iniciar\u00e3o um n\u00f3 \u2014 geralmente, nesta fase, os projetos possuem documenta\u00e7\u00e3o bastante escassa, aparecem erros e os desenvolvedores que trabalham sob press\u00e3o n\u00e3o respondem \u00e0s perguntas de forma muito \u00e1gil. Portanto, antes de iniciar o jogo, \u00e9 preciso tamb\u00e9m planejar a\u00e7\u00f5es caso o n\u00famero desejado de validadores n\u00e3o seja alcan\u00e7ado. Nesse caso, no in\u00edcio do jogo, os validadores necess\u00e1rios s\u00e3o iniciados pela equipe do projeto, participam do consenso, mas n\u00e3o podem ser vencedores.<\/p>\n
<\/p>\n
Conclus\u00e3o<\/h2>\n <\/p>\n
Concluindo, tentei reunir a partir do que foi descrito acima uma lista do que precisa ser pensado, feito e implementado para a realiza\u00e7\u00e3o eficaz do jogo dos validadores<\/p>\n
<\/p>\n
O que deve ser feito para lan\u00e7ar um verdadeiro jogo de validadores:
<\/p>\n
\ncriar e implementar uma interface web e fornecer CLI para vota\u00e7\u00e3o pelos validadores<\/li>\n fazer com que as m\u00e9tricas da nossa node de validador possam ser enviadas para um servi\u00e7o centralizado (como o Prometheus)<\/li>\n levantar um servidor de coleta de m\u00e9tricas (Prometheus + Grafana) para o jogo de validadores<\/li>\n pensar em como ser\u00e3o calculados os Validator Points (VP)<\/li>\n desenvolver um script p\u00fablico que calcule o VP do validador com base nos dados da blockchain<\/li>\n desenvolver uma interface web para mostrar os melhores validadores e o status do jogo de validadores (quanto tempo resta, quantos VP eles t\u00eam, etc.)<\/li>\n desenvolver e automatizar o lan\u00e7amento de um n\u00famero arbitr\u00e1rio de nossas pr\u00f3prias nodes, projetar o processo de conex\u00e3o dos validadores ao jogo (quando e como desligar suas nodes, emitir e retirar votos por elas)<\/li>\n calcular quantos tokens precisam ser emitidos e desenvolver um contrato faucet<\/li>\n fazer um script de benchmark (transfer\u00eancias de tokens, uso massivo de storage, uso massivo de rede) <\/li>\n reunir todos os participantes em um \u00fanico chat para comunica\u00e7\u00e3o r\u00e1pida<\/li>\n lan\u00e7ar a blockchain um pouco antes do in\u00edcio do jogo<\/li>\n aguardar o bloco inicial, come\u00e7ar o jogo<\/li>\n testar a rede com v\u00e1rios tipos de transa\u00e7\u00f5es<\/li>\n implantar o hard fork<\/li>\n modificar a lista de validadores<\/li>\n repetir os itens 13, 14, 15 em diferentes ordens, mantendo a estabilidade da rede<\/li>\n aguardar o bloco final, encerrar o jogo, contar os VP<\/li>\n<\/ul>\n<\/p>\n
\u00c9 importante dizer que o jogo de validadores \u00e9 uma hist\u00f3ria nova, e foi realizado apenas algumas vezes, portanto, n\u00e3o deve-se interpretar este texto como um guia pronto. N\u00e3o existem an\u00e1logos no neg\u00f3cio de TI moderno \u2014 imagine que os bancos est\u00e3o competindo entre si antes de lan\u00e7ar um sistema de pagamentos, para ver quem consegue realizar melhor as transa\u00e7\u00f5es dos clientes. Abordagens tradicionais dificilmente ajudar\u00e3o voc\u00ea a construir grandes redes descentralizadas, ent\u00e3o aprenda novos modelos de neg\u00f3cios, promova seus jogos, identifique os dignos, recompense-os e deixe seus sistemas distribu\u00eddos funcionarem rapidamente e de forma est\u00e1vel.<\/p>\n
Fonte: 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