Assim, sua equipe completou a versão alpha da sua blockchain, e chegou a hora de lançar a testnet e depois a mainnet. Você tem uma verdadeira blockchain, com participantes independentes, um bom modelo econômico, segurança, projetou a governança e agora é hora de experimentar tudo isso na prática. No mundo ideal cripto-anárquico, você publica o genesis block na rede, o código final do nó e os validadores iniciam tudo, levantam todos os serviços auxiliares e tudo acontece naturalmente. Mas isso é num mundo fictício; na realidade, a equipe deve preparar uma boa quantidade de software auxiliar e várias manobras para ajudar os validadores a iniciar uma rede sustentável. É sobre isso que trata este artigo.
O lançamento de redes baseadas em consensos do tipo 'proof-of-stake', onde os validadores são determinados pelos votos dos detentores de tokens do sistema, é um empreendimento bastante específico, pois até mesmo o lançamento de sistemas tradicionais, geridos de forma centralizada, com dezenas e centenas servidores é uma tarefa difícil por si só, e a blockchain precisa ser iniciada com os esforços de participantes leais, mas independentes. E, se em uma corporação, ao iniciar, os administradores têm acesso total a todas as máquinas, logs e monitoramento geral, os validadores não deixarão ninguém perto de seus servidores e, provavelmente, preferirão construir sua infraestrutura de forma independente, pois ela controla o acesso aos principais ativos do validador — os stakes dos votantes. É esse comportamento que permite construir redes seguras e distribuídas — a independência dos provedores de nuvem utilizados, servidores virtuais e 'baremetal', diferentes sistemas operacionais; tudo isso torna os ataques a essa rede extremamente ineficazes — há uma variedade excessiva de software sendo utilizado. Por exemplo, no Ethereum, são utilizadas duas implementações principais do nó, em Go e em Rust, e um ataque que é eficaz para uma implementação não funciona para a outra.
Portanto, todos os processos de lançamento e operação 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á na Europa, o segundo na América do Sul e o terceiro na Ásia, alcançar um funcionamento coordenado de várias dezenas de grupos independentes e motivá-los no resultado é bastante difícil.
Validadores
Vamos imaginar o lançamento de um hipotético blockchain moderno (a maior parte do que está sendo descrito se aplica a blockchains da maioria das famílias modernas de blockchains: Ethereum, EOS, Polkadot, Cosmos e outros, que utilizam consenso proof-of-stake. Os principais protagonistas desses blockchains são equipes de validadores, que instalam seus próprios servidores independentes, validando e produzindo novos blocos, recebendo as recompensas previstas pela rede para aqueles que participam do consenso. Para lançar novas redes, são necessários várias dezenas de validadores (o número que consegue alcançar um consenso de maneira eficiente em segundos), por isso o projeto anuncia um registro, onde os validadores compartilham informações públicas sobre si com os usuários, convencendo-os de que pretendem servir a nova rede de forma qualificada.
A validação é um negócio que permite avaliar com precisão 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ítimo da DAO e responsável, desenvolver o projeto, ou simplesmente oferecer um excelente serviço técnico por dinheiro totalmente transparente e honestamente ganho. Ao calcular a recompensa dos validadores, os projetos se esforçam para levar em conta os custos dos validadores e fazer a recompensa por bloco de forma que esse negócio seja lucrativo, mas que não permita que os validadores quebrem a economia inundando-a com dinheiro e privando os demais usuários da rede.
O negócio de validadores exige alta resiliência dos serviços, o que significa um alto nível de preparação para devops e desenvolvedores, além de recursos computacionais caros. Mesmo sem a necessidade de minerar hashes em redes proof-of-work, um nó de blockchain é um grande serviço que consome muita memória, requer muitos cálculos, valida, grava em disco e transmite grandes volumes de dados na rede. Para armazenamento de logs de transações e cadeias de blocos em um blockchain com milhares de pequenas transações em um bloco, atualmente é necessário 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á exceder 64Gb de memória RAM. Servidores com as características necessárias são bastante caros, e um nó Ethereum ou EOS pode custar entre 100 e 200 $/mês. Adicione a isso o aumento dos custos com mão-de-obra para desenvolvedores e devops trabalhando em turnos, que resolvem problemas até à noite durante o lançamento, já que parte dos validadores pode estar em outro hemisfério. No entanto, em momentos favoráveis, possuir um nó validador pode gerar uma renda significativa (no caso do EOS, até 10.000 $ por dia).
A validação é apenas um dos novos papéis potenciais de TI para empreendedores e empresas. À medida que os programadores criam algoritmos cada vez mais sofisticados que recompensam a honestidade e punem fraude e roubo, surgem serviços que desempenham funções de publicação de dados importantes (oráculos), fiscalização (slashing de depósitos e punição de fraudadores por meio da publicação de provas de fraude), serviços de resolução de disputas, seguros e opções. Até a coleta de lixo é um mercado potencialmente grande em sistemas de contratos inteligentes, onde é necessário pagar pelo armazenamento de dados.
Desafios do lançamento de blockchain
A transparência do blockchain, que permite que qualquer um participe da rede de computadores de qualquer país e a facilidade de conexão à rede por qualquer script kiddie seguindo as instruções no GitHub, nem sempre é uma vantagem. A busca por um novo token frequentemente leva os validadores a "minerar uma nova moeda no início", na esperança de que o preço aumente e de poder vender rapidamente o que ganharam. Além disso, isso significa que qualquer um, até mesmo um anônimo, pode ser seu validador, e é possível votar nele assim como em outros validadores (embora seja difícil para um anônimo reunir votos de stakeholders, então deixemos as histórias assustadoras sobre criptomoedas anônimas para os políticos). No entanto,
A equipe do projeto tem a tarefa de conseguir de alguma forma atrair para sua rede aqueles que, no futuro, possam garantir a operação estável dos nós, entendam de segurança, sejam capazes de resolver problemas rapidamente, cooperar com outros validadores e agir em conjunto — 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çar um software dessa magnitude, inevitavelmente enfrentarão erros no código, configuração de nós, e que a estabilidade da rede depende de quão bem desenvolvedores e validadores resolverão problemas semelhantes em conjunto.
A equipe está pronta para votar no mainnet por quaisquer validadores, mas apenas se soubessem por quais, quais são bons? O maior portfólio? Nesse momento, quase ninguém tem isso. Pelos perfis da equipe no Linkedin? DevOps ou especialistas em segurança experientes não lhe fornecerão nenhum perfil no Linkedin. Pelas declarações no chat, postagens e ajuda a outros na fase de preparação? Isso é bom, mas subjetivo e impreciso.
Em tais condições, resta uma única solução - um jogo que pode resolver os problemas de todos, onde será possível escolher os melhores validadores, mas o principal - testar a resistência do blockchain e realizar um teste de batalha em larga escala do blockchain em condições de uso ativo, mudanças no consenso, surgimento e correção de erros. Pela primeira vez, esse procedimento foi apresentado como um jogo por pessoal do projeto Cosmos, e essa ideia é, sem dúvida, uma excelente maneira de preparar a rede para o lançamento de um mainnet confiável e resiliente.
Jogo dos Validadores
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ça semelhante — os validadores são escolhidos por votação 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ão somados e, no final, uma lista dos principais validadores é construída. Em diferentes blockchains, esse processo é organizado de maneiras diversas, e geralmente é nessa parte que uma nova blockchain se diferencia da original. É válido dizer que, em nosso caso, a EOS realmente justifica o “OS” em seu nome, pois utilizamos a EOS como o sistema operacional base para implementar uma versão modificada da blockchain para as necessidades do DAOBet.
Vou descrever problemas específicos e como eles podem ser resolvidos no âmbito do jogo. Vamos imaginar uma rede onde seu servidor pode ser abertamente atacado, onde, para manter a posição de validador, é necessário 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ário, o validador será removido da lista.
Como selecionar os principais vencedores?
A principal exigência técnica para o jogo é que seus resultados sejam publicamente verificáveis. 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íamos medir o “uptime” de cada validador e recompensar aqueles que estiveram mais online ou que processaram a maior quantidade de tráfego da rede. Poderíamos coletar dados sobre o uso da CPU, memória e recompensar aqueles que trabalharam de forma eficiente. Mas qualquer coleta dessas métricas implica a existência de um centro de coleta, e as nódulos são todos independentes, podendo agir como desejarem e enviar quaisquer dados.
Portanto, a solução natural é que os vencedores sejam definidos com base em dados da blockchain, pois através dela é possível ver quem de os validadores produziu qual bloco e quais transações foram incluídas nele. Chamamos esse número de Validator Points (VP), e ganhá-los é o principal objetivo dos validadores no jogo. No nosso caso, a métrica mais simples, publicamente verificável e eficiente de "utilidade" de um validador é VP = número_de_blocos_produzidos_pelo_validador em um determinado período de tempo.
Essa escolha simples se deve ao fato de que a governança no EOS já prevê muitos dos problemas que surgem, uma vez que o EOS é o sucessor de três gerações de blockchains reais com grande experiência em gerenciamento complexo da rede. Quase quaisquer problemas que um validador tenha com a rede, processador ou disco levam a um único problema — ele assina menos blocos, recebe menos pagamento pelo trabalho, o que nos leva novamente ao número de blocos assinados — para o EOS, essa é uma opção excelente e simples.
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últiplos validadores, faz sentido contar assinaturas individuais dos validadores, e não blocos. Talvez seja válido considerar rodadas de consenso não concluídas, que consomem recursos de outros validadores, em geral isso depende muito do tipo de consenso.
Como modelar condições reais de operação
A tarefa dos fundadores é verificar os validadores em condições próximas 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, é necessário formar uma transação 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âmetros podem ser ajustados para que o fluxo de solicitações seja suficientemente significativo para um teste completo da rede. Portanto, planeje o contrato-faucet antecipadamente, como uma ferramenta importante para o lançamento da rede, e comece a ajustar seus parâmetros desde cedo.
O pedido de tokens do faucet e o voto dos validadores não 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á escrever benchmarks adicionais, permitindo sobrecarregar a rede. Contratos inteligentes especificamente criados com antecedência desempenham um papel especial, permitindo testar subsistemas individuais. Para testar o armazenamento, o contrato armazena dados aleatórios 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ções — ao lançar um fluxo dessas transações em momentos aleatórios, a equipe testa simultaneamente a estabilidade do código e a resistência dos validadores.
Uma questão à parte é a atualização do código dos nós e a realização de hard forks. É necessário que, em caso de surgimento de um bug, vulnerabilidade ou conluio de validadores mal-intencionados, os validadores tenham um plano de ação já ensaiado no jogo dos validadores. Podem ser elaborados esquemas de recompensas em VP para a rápida aplicação do hard fork, por exemplo, penalizando todos os validadores que ainda não atualizaram a nova versão do código do nó, mas isso é difícil de implementar e complica o cálculo. Simular uma situação de emergência para a aplicação do hard fork pode ser artificialmente “quebrando” a blockchain em um bloco específico. A produção de blocos para, e no final, os que ativarem mais cedo e começarem a assinar blocos sairão ganhando, então o VP baseado no número de blocos assinados se aplica bem aqui.
Como informar os participantes sobre o estado da rede e corrigir erros
Apesar da desconfiança entre os validadores, obter informações atualizadas sobre o estado da rede de maneira oportuna é vantajoso para todos, a fim de tomar decisões mais rápidas. Por isso, a equipe do projeto está implementando um serviço para coletar e visualizar diversas métricas dos servidores dos validadores, que permite ver a situação simultaneamente para toda a rede, possibilitando determinar rapidamente o que está acontecendo. Além disso, tanto para os validadores quanto para o projeto, é vantajoso que a equipe do projeto corrija rapidamente os erros encontrados. Portanto, além da coleta de métricas, faz sentido também iniciar a coleta de logs e dados de erros das máquinas dos validadores para uma máquina acessível aos desenvolvedores da blockchain. Ninguém se beneficia de informações distorcidas, portanto, esses serviços são gerenciados pela equipe do projeto e podem ser confiáveis. Faz sentido coletar métricas sistêmicas dos validadores e, necessariamente, as métricas mais importantes da própria blockchain — para a DAOBet — isso inclui o tempo de finalização e a defasagem do último bloco finalizado. Com isso, a equipe vê o aumento do consumo de memória nos nós ao iniciar o benchmark, bem como problemas de validadores isolados.
Pontos importantes sobre a realização do jogo dos validadores
Descobriu-se que, se você deseja permitir oficialmente que os validadores ataquem uns aos outros (não oficialmente, eles já podem fazer isso) — é necessário formular isso legalmente como um teste de segurança, pois, segundo as leis de alguns países, DDoS ou ataques de rede podem resultar em sanções. Outra questão importante é como premiar os validadores. Prêmios naturais são os tokens do projeto, que serão transferidos para o mainnet, mas a distribuição massiva de tokens para qualquer um que conseguir rodar um nó também não é a melhor opção. Provavelmente, você terá que equilibrar entre duas opções extremas:
Distribuir todo o prêmio de acordo com os VP ganhos
isso é muito democrático e permite que todos que investiram tempo e recursos no jogo dos validadores ganhem
mas atrai para o jogo pessoas aleatórias sem a infraestrutura necessária
Distribuir o fundo de prêmios para os validadores do top-N ao final do jogo
as vencedoras provavelmente serão as validators que se mantiveram mais estáveis durante o jogo, muito focadas na vitória
parte dos validadores pode não querer participar, avaliando mal suas chances de vencer, especialmente se houver validadores experientes entre os participantes
A decisão de qual opção preferir é sua
Há também outro ponto — não é certo que dezenas de validadores se apressem em participar do jogo ao seu chamado, e dentre aqueles que decidirem tentar, nem todos instalarão e iniciarão um nó — geralmente, nesta fase, os projetos possuem documentação bastante escassa, aparecem erros e os desenvolvedores que trabalham sob pressão não respondem às perguntas de forma muito ágil. Portanto, antes de iniciar o jogo, é preciso também planejar ações caso o número desejado de validadores não seja alcançado. Nesse caso, no início do jogo, os validadores necessários são iniciados pela equipe do projeto, participam do consenso, mas não podem ser vencedores.
Conclusão
Concluindo, tentei reunir a partir do que foi descrito acima uma lista do que precisa ser pensado, feito e implementado para a realização eficaz do jogo dos validadores
O que deve ser feito para lançar um verdadeiro jogo de validadores:
desenvolver sua própria blockchain 🙂
- criar e implementar uma interface web e fornecer CLI para votação pelos validadores
- fazer com que as métricas da nossa node de validador possam ser enviadas para um serviço centralizado (como o Prometheus)
- levantar um servidor de coleta de métricas (Prometheus + Grafana) para o jogo de validadores
- pensar em como serão calculados os Validator Points (VP)
- desenvolver um script público que calcule o VP do validador com base nos dados da blockchain
- desenvolver uma interface web para mostrar os melhores validadores e o status do jogo de validadores (quanto tempo resta, quantos VP eles têm, etc.)
- desenvolver e automatizar o lançamento de um número arbitrário de nossas próprias nodes, projetar o processo de conexão dos validadores ao jogo (quando e como desligar suas nodes, emitir e retirar votos por elas)
- calcular quantos tokens precisam ser emitidos e desenvolver um contrato faucet
- fazer um script de benchmark (transferências de tokens, uso massivo de storage, uso massivo de rede)
- reunir todos os participantes em um único chat para comunicação rápida
- lançar a blockchain um pouco antes do início do jogo
- aguardar o bloco inicial, começar o jogo
- testar a rede com vários tipos de transações
- implantar o hard fork
- modificar a lista de validadores
- repetir os itens 13, 14, 15 em diferentes ordens, mantendo a estabilidade da rede
- aguardar o bloco final, encerrar o jogo, contar os VP
É importante dizer que o jogo de validadores é uma história nova, e foi realizado apenas algumas vezes, portanto, não deve-se interpretar este texto como um guia pronto. Não existem análogos no negócio de TI moderno — imagine que os bancos estão competindo entre si antes de lançar um sistema de pagamentos, para ver quem consegue realizar melhor as transações dos clientes. Abordagens tradicionais dificilmente ajudarão você a construir grandes redes descentralizadas, então aprenda novos modelos de negócios, promova seus jogos, identifique os dignos, recompense-os e deixe seus sistemas distribuídos funcionarem rapidamente e de forma estável.
Fonte: habr.com
