Como geramos 96 verificadores eleitos

(Indika) (5 de setembro, 2019)

A última vez que publiquei um artigo foi cinco anos atrás, e era intitulado: Cozinhar um servidor web com o Chef . Cinco anos é muito tempo para não escrever. Não é que eu tenha perdido o interesse pelo assunto; em vez disso, estava aprendendo silenciosamente com os melhores.

O assunto da discussão, no entanto, não mudou, exceto que agora é uma ordem de magnitude maior. Naquela época, eu estava criando um único servidor web e agora estou gerando 96 verificadores eleitos (EVs).

Por que 96?

Na Unificação, estamos mudando o algoritmo de consenso subjacente de Ethereum. Nossa implementação de Governança de Participação Distribuída envolve quatro grupos de 24 EVs, rodando dentro e fora da validação de bloco. A governança dessas rotações é facilitada por meio de um processo de votação e implantação. O resultado final é uma rede de consórcio mais distribuída.

Teorizar esse assunto em white papers e em simulações não pode nos levar muito longe. A melhor maneira de seguir em frente é produzi-lo, brincar com ele e experimentar quaisquer deficiências.

Entrega contínua

Queremos estar em posição de avaliar nossas ideias rapidamente . O desenvolvimento orientado a testes não precisa se limitar a escrever testes de unidade.

Para qualquer Git SHA, queremos ativar qualquer versão de nossa Mainchain executando um único comando, avaliar o estado dele e, em seguida, fazer refinamentos ao seu DNA.

Queremos continuar refinando esse processo, até acreditar que temos algo pronto para produção. O processo de desenvolvimento de software nada mais é do que esta iteração simples:

Quanto mais complexo um sistema se torna, mais difícil se torna cada uma dessas partes. Instanciar 96 EVs é um problema não trivial e é o foco deste artigo.

Definição

Começamos definindo o que queremos implantar. Um cluster instanciado consistirá principalmente em EVs, onde alguns deles têm RPC habilitado e outros não. O cluster também pode incluir um faucet UND, um explorador de bloco e talvez até um nó de monitoramento.

Esses clusters são especificados por arquivos JSON, e a finalidade da pilha de provisionamento pode torná-los assim.

Cada nó dentro do cluster precisa de um identificador exclusivo e o seguinte esquema de endereçamento é escolhido:

x = "{cluster\_name}-{configuration}-{instance\_type}-{index}"

Por exemplo:

alpha-basic-ev-1

No declaração acima, a palavra “básico” refere-se a uma configuração, na qual existem quatro EVs e um explorador de bloco. A palavra “alfa” é o nome do experimento.

The Stack

Poderíamos ter escolhido o Kubernetes.

No entanto, também queremos investir em criando ferramentas que nossa comunidade pode usar para lançar seus próprios EVs. Escolhemos o Ansible por causa de sua simplicidade, e os playbooks direcionados ao CentOS funcionarão em qualquer arquitetura ou podem ser facilmente adaptados.

Além disso, embora eu tenha avaliado o Chef e o Puppet no passado, eu Abandonei os dois pela simplicidade de Ansible. Chef e Puppet precisam de componentes de software na máquina de destino, no entanto, Ansible só precisa de uma conexão SSH.

Não há física quântica aqui com relação à pilha; apenas passos necessários para o sucesso. Nossa pilha é composta por:

  • usuários da AWS e API da AWS
  • modelo de lançamento da AWS
  • tags da AWS
  • inicialização minimalista do bash script
  • Curling um script bash do Github
  • Configurar vars de host Ansible a partir de tags
  • Provisionar o host usando Ansible

API da AWS e usuários da AWS

A AWS oferece controle extremamente granular sobre os serviços de TI por meio de sua API e usuários com permissão. A API pode ser acessada decentemente por meio da biblioteca boto3 do Python. Um precursor do uso da API é a criação do usuário relevante por meio da interface IAM. Um usuário é um ID de acesso de usuário típico e um par secreto.

Um usuário pode ser vinculado a uma ou mais políticas. Uma política consiste em um conjunto de ações permitidas ou negadas em um conjunto de recursos.

Nosso usuário de spawn tem uma política anexada com ações minimalistas para criar instância EC2 e ações para ler todo o conjunto de recursos.

Modelos de lançamento

Um dos principais recursos que a AWS nos oferece são os modelos de inicialização.

Com um modelo de inicialização, é possível especificar uma AMI de base (o identificador da imagem da máquina virtual para construir uma instância) e pré-configurar configurações, incluindo dois componentes essenciais: Tags e um script de execução. Além disso, pode-se especificar o grupo de segurança ao qual a máquina deve pertencer.

Os modelos de inicialização podem ter controle de versão e as instâncias podem ser iniciadas a partir do usuário AWS.

Tags

Cada instância EC2 é única com base nas tags com as quais é configurada. As seguintes informações são enviadas ao nó:

  • Nome (identificador único do nó)
  • Classe (o tipo de instância)
  • Índice ( a posição da instância)
  • Configuração (a variedade de cluster que pode ser instanciado)
  • SHA (um Git SHA)
  • RegistrationIP (o endereço IP do Torre de registro)

Cada uma dessas tags é definida no Ansible hosts vars.

Inicializando com Bash

O script de inicialização Bash prepara o host para provisionamento. Alguns dos trabalhos realizados são a instalação de um ambiente Python básico, a análise de tags AWS, gravá-los no arquivo vars do host Ansible e selecionar o manual apropriado do Ansible para o tipo de nó.

Ansible

Finalmente, o nó é provisionado com Ansible. Não vou divagar sobre o Ansible, pois há outros recursos suficientes na Internet. Não há nada de especial aqui, exceto que normalmente se configura um servidor remoto com Ansible, mas no nosso caso, estamos configurando o servidor local.

Torre de registro

Usamos uma torre de registro em vez de um Bootnode para inicializar a rede. EVs registram seus endereços IP na instanciação com o nó de registro, e uma lista de nós estáticos é obtida antes da ativação do serviço.

A vantagem de usar tal Torre é que podemos começar a registrar dados arbitrários, como estatísticas de saúde, ajudando a fechar o ciclo de avaliação.

Quando um EV é instanciado, ele grava na API de registro, seu nome de cluster, endereço IP, índice e tipo de instância.

Avaliação

O foco principal da avaliação é determinar como o experimento foi bem-sucedido. Quais são as condições de sucesso serão abordadas em outro artigo. No entanto, uma métrica imediata para ficar de olho é o custo.

O preço de uma instância t2-micro é 0,012 / h. O custo de funcionamento de 96 destes por uma hora deve ser de apenas um dólar. Isso pode ser confirmado no Cost Explorer.

Mais

Esta pilha funciona perfeitamente. Um único comando de forma consistente e sem falhas traz uma Mainchain totalmente conectada e com propagação de blocos. O que mais gosto nessa pilha é que ela é disparar e esquecer; Posso instanciar o cluster, desconectar da Internet e fazer malabarismos. Haverá um Mainchain pronto para mim quando eu retornar.

Isso serve como uma base sólida para nossa próxima etapa. Podemos começar avaliando diferentes configurações de nosso DNA de consenso. Estaremos amadurecendo nosso algoritmo de consenso simples atual e avaliando em relação à realidade brutal, em nosso próximo artigo intitulado “Governança de estaca distribuída”.

O código-fonte para a pilha de provisionamento EV pode ser encontrado aqui: https://github.com/unification-com/ev-provision

Junte-se a nós no Unification Gitter: https://gitter.im/unification-com

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *