Minha jornada para me tornar um validador no Ethereum 2.0, parte 2

blog 1NewsDevelopersEnterpriseBlockchain ExplainedEvents and ConferencesPressboletins informativos

Assine a nossa newsletter.

Endereço de email

Nós respeitamos sua privacidade

HomeBlogDevelopers

Minha jornada para me tornar um validador no Ethereum 2.0, parte 2

Quais são algumas coisas que você deve considerar ao escolher hardware e software para executar um cliente validador Ethereum 2.0? Por Coogan Brennan 5 de dezembro de 2020Postado em 5 de dezembro de 2020

Minha jornada para me tornar um validador no Ethereum 2 0 Parte 2

Nota: Você ainda pode se tornar um validador na rede Ethereum 2.0! Haverá um tempo de espera para ser ativado como um validador – a partir de 4 de dezembro de 2020, o tempo de espera é de aproximadamente 9,9 dias. Veja as etapas para estaqueamento na Parte 1 desta série.

  1. Isenção de responsabilidade
  2. Introdução
  3. Considerações de configuração do validador
  1. Hardware de Prova Futura
  2. Para executar ou não executar um cliente Eth1?
  3. Hospedagem Virtual vs. Local
  4. Escolha do cliente Eth2 e como evitar penalidades
  • Configurando a instância AWS
    1. Sistema operacional
    2. Preços
    3. Armazenar
    4. Portas
    5. Chaves SSH e lançamento de instância
    6. Instalando Teku
      1. Requisitos
      2. Instalar binário
      3. Criar usuário não root
      4. Criar serviço systemd
      5. Lançar
      6. Isenção de responsabilidade

        Esta é uma postagem que estou escrevendo como funcionário da ConsenSys e alguém que planeja apostar na cadeia de beacon. A declaração anterior significa que eu priorizo ​​os produtos ConsenSys (os produtos ConsenSys são normalmente os melhores da categoria para Ethereum, e também tenho acesso a equipes de engenharia que podem me ajudar a responder perguntas e solucionar problemas). A última afirmação significa que estou otimizando o custo e a facilidade de uso: não tenho milhares de ETH para gerar recompensas substanciais, então estou pegando alguns atalhos. Estas são decisões que tomei para tornar a aposta no Ethereum 2.0 tão simples e acessível para os indivíduos quanto possível, mas vêm com compensações para descentralização e privacidade No entanto, você pode seguir as linhas gerais do tutorial abaixo e fazer escolhas diferentes. Na verdade, se você pode fazer isso, eu o encorajo a! 

        Por último, apostar no Ethereum 2.0 é altamente experimental e envolve um compromisso de longo prazo (estou reservando três anos). Não participe se você não se sentir confortável com o atendente de alto nível de risco com algo ainda em desenvolvimento. Se você não tem certeza se deve apostar, por favor junte-se ao Discórdia ConsenSys e pergunte no canal # teku-public. 

        Introdução

        No post anterior, discutimos as razões para a implantação do Ethereum 2.0 e analisamos a implantação da 32 ETH no contrato de depósito mainnet do Ethereum 1.0. Abordamos a geração de chaves e como o processo de implantação Plataforma de lançamento liga Ethereum 1.0 a 2.0.

        Em 23 de novembro, a quantidade mínima de ETH apostada para lançar Ethereum 2.0 – cerca de 524.288 – foi atingida. As pessoas podem continuar a apostar no contrato e o número de validadores aumentou para mais de 33.000 em 4 de dezembro.

        Aaron Davis da MetaMask compartilha suas idéias no canal interno de staking ConsenSys Slack 

        Embora tenha sido extremamente emocionante entrar no bloco Genesis como um validador, segundos depois tive uma experiência semelhante à de meu colega Aaron Davis em nosso canal interno de staking ConsenSys: Para que tarefa maluca eu me inscrevi? Felizmente, tenho acesso a pessoas incrivelmente brilhantes e técnicas, caridosas o suficiente para dar a este rube algumas dicas, sugestões e percepções sobre como operar a infraestrutura de piquetagem. Espero passar uma fração desse conselho valioso aqui para qualquer outra parte interessada.

        Esta é a primeira parte deste artigo: Quais são algumas coisas que você deve considerar ao escolher hardware e software para executar um cliente validador Ethereum 2.0? A segunda parte percorrerá a combinação específica de hardware / software que escolhi para meu cliente validador. As escolhas que você fizer para sua configuração dependerão de seus recursos, inclinação pessoal e capacidade técnica. Farei o meu melhor para destacar como os preconceitos pessoais e as circunstâncias informaram minhas escolhas.

        Por último, antes de começarmos, quero reiterar que essas postagens são quase como entradas de diário para minha experiência de piquetar 32 ETH (embora sejam entradas de diário com extensos acréscimos técnicos). Como tal, posso mudar um pouco a minha abordagem à medida que a cadeia de balizas avança. Por exemplo, entrei pensando que definitivamente usaria a AWS. Como você lerá abaixo, agora estou reconsiderando isso. Também vou ser muito claro sobre o elemento financeiro da aposta. O piqueteamento é uma forma de apoiar o ecossistema Ethereum, mas para uso público sustentável, também deve ser acessível e possível para quem tem a ETH.. 

        Hardware de Prova Futura

        Os requisitos básicos para executar um validador hoje são relativamente fáceis de satisfazer. Mara Schmiedt e Collin Meyers ‘ Guia do Validador on Bankless tem um bom resumo dos requisitos mínimos. O aspecto mais desafiador para determinar o equipamento validador Ethereum 2.0 é equilibrar as necessidades atuais do Beacon Chain Fase 0 com quaisquer demandas futuras atualmente desconhecidas à medida que o desenvolvimento continua. (Isso não é uma preocupação se você se sentir confortável em manter um olhar atento ao seu validador e se for capaz de lidar com as alterações de forma rápida e fácil) 

        Ben Edgington, gerente de projetos da Teku e editor da Eth2.news, me forneceu alguns casos extremos em que a rede pode exigir mais do cliente validador. No curto prazo, a maior preocupação seria algo como o incidente do servidor de horário Medalla, em que um bug e a correção subsequente no cliente Prysm interromperam a finalização no testnet (a grosso modo, a rede não poderia “produzir blocos”). Como não havia finalidade na rede (sem “blocos confirmados”), os validadores tiveram que manter muito mais transações em sua RAM do que o normal. 

        Máquinas com 8 GB de RAM – o que teria sido mais do que suficiente em circunstâncias normais – começaram a encontrar problemas de “falta de memória” que podem ter levado a cortes. Um pico como este, embora incomum, não está fora de questão para a rede principal da Fase 0.

        Ambigüidades de configuração futuras para a rede são a fusão de Ethereum 1.0 e 2.0 e a introdução de fragmentação. Ainda não sabemos quando essas fusões acontecerão ou exatamente o que exigirão. Eu gostaria de ter um backbone de CPU forte indo para a Fase 0 (4 núcleos virtuais, 16 GB de RAM com SSD de 100 GB) e, em seguida, focar minha atenção para ajustes futuros em torno do espaço de armazenamento (deixando espaço de manobra aqui). Por favor, note que isso pode acabar sendo um exagero e consumir recompensas de aposta.

        Essas são as “incógnitas conhecidas” do futuro, vamos discutir os principais pontos de decisão de configuração para validadores hoje.

        Executar ou não executar um cliente Eth1?

        É um rito de passagem que tento submeter nossos alunos do bootcamp o mais rápido possível: sincronizar um cliente Ethereum 1.0. É um segredo aberto que hospedar um nó Ethereum 1.0 “completo” é um ato de amor, e não uma solução endurecida do Dilema do Prisioneiro. “Full” deve ser colocado entre aspas porque até mesmo os desenvolvedores principais do Ethereum têm dificuldade em concordar sobre uma definição do que “nó completo” realmente significa.

        Uma coisa com a qual todos podemos concordar: leva mais tempo e armazenamento para sincronizar um cliente Ethereum 1.0 do que você imagina. Nossos validadores precisam ter uma maneira de consultar o banco de dados de rede Ethereum 1.0 (veremos o motivo um pouco mais tarde). Se quiser economizar espaço e dor de cabeça de sincronizar localmente, você pode usar um endpoint Infura, que está disponível gratuitamente com registro. 

        Mesmo que isso economize armazenamento significativo e preocupação logística, ele sacrifica uma certa quantidade de descentralização para as redes Eth1 e Eth2 simultaneamente. Se Infura fosse cair, o que é extremamente raro, mas ocorre, isso causaria um efeito cascata entre os validadores Ethereum 2.0 usando-o para seu endpoint Ethereum 1.0. Algo a considerar!

        (Só para ficar claro: a dificuldade de sincronizar um nó completo do Ethereum tem a ver com a natureza do estado mundial do Ethereum, não com os desenvolvedores principais do Ethereum 1.0 que fizeram um trabalho incrível ao lidar com este problema extremamente desafiador.)

        Hospedagem Virtual vs Local

        A próxima consideração para mim foi hospedar um nó validador localmente (em minha casa) ou virtualmente (em um provedor de serviços virtuais como Amazon Web Services (AWS), Digital Ocean, etc.). Como mencionei no artigo anterior, não confio em mim mesmo para executar um nó validador consistente de casa, mesmo em um laptop antigo armazenado em algum lugar. Desajeitado e idiota, eu chutaria ou esqueceria.

        Estou optando por executar meu nó na AWS porque é com isso que estou mais familiarizado (depois de passar por todo esse processo, no entanto, estou questionando esta decisão. Discutirei isso mais tarde). A compensação aqui é novamente a descentralização: se a AWS cair ou tiver algum problema (como fez recentemente), Estou à mercê deles. Se um número suficiente de pessoas estiver executando nós na AWS, isso pode afetar a rede Ethereum maior.

        As pessoas provavelmente irão se auto-selecionar para este A hospedagem local é um tipo especial de projeto e nem todos têm o tempo, recursos ou compromisso necessários. Embora a hospedagem virtual seja uma força centralizadora, estou optando por ir com ela devido à sua facilidade de uso e (espero) tempo de atividade garantido. 

        Se você gostaria de executar um nó validador localmente, você ainda pode seguir a direção geral deste tutorial, Excelente série de tutoriais de Somer Esat com diferentes clientes ou até sincronizar um Raspberry Pi Modelo 4B com 8 GB de RAM com Ethereum no ARM. (A sincronização no Raspberry Pi ainda é muito experimental e as pessoas devem esperar até que Ethereum na equipe ARM confirme sua estabilidade)

        Escolha do cliente Eth2 e como evitar penalidades

        Outra escolha importante é o cliente Ethereum 2.0 entre os clientes existentes: Farol, Lodestar, Nimbus, Prysm e Teku. Sou fortemente inclinado a Teku e não sou experiente o suficiente para debater os pontos mais delicados dos clientes. Este artigo é uma visão geral decente do desempenho do cliente no Medalla. (Lembre-se de que o Medalla exigiu muito mais dos processadores do que o mainnet.)

        O Proof of Stake incorpora desincentivos explícitos para encorajar o comportamento correto na rede. Estes assumem a forma de validadores de dinging por estarem offline e o movimento mais dramático de agentes de corte por tomarem ações maliciosas contra a rede, intencionalmente ou não.

        O problema mais comum será garantir que seu validador esteja disponível para a rede. Isso significa ter certeza de que seu validador está online. Existe a abordagem DevOps para esse problema – criar o sistema de monitoramento e alerta para alertá-lo se o seu validador ficar offline – que não abordarei aqui.

        Mas existe outra maneira de não estar disponível para a rede, que é se o seu cliente começar a se comportar mal por um motivo ou outro. Depois de o bug do servidor de tempo causou uma desaceleração da rede no Medalla, os desenvolvedores principais do Eth2 se uniram para desenvolver “[Um] formato padrão para transferir o histórico de assinatura de uma chave permite que os validadores alternem facilmente entre clientes sem o risco de assinar mensagens conflitantes.” Nem todos os clientes têm essa proteção, mas o Teku tem. Aqui é onde você pode ler sobre como usar a proteção Slash da Teku (executado por padrão), incluindo a migração entre nós Teku ou um nó não Teku para Teku.

        Se você tiver problemas com seu cliente e precisar reiniciar a rede inteira, deve estar ciente da Subjetividade Fraca. A Prova de Trabalho permite que qualquer pessoa volte ao bloco de gênese da rede e construa de forma confiável o estado da rede a partir do zero. O Proof of Stake, no entanto, tem um problema a esse respeito: se um terço dos validadores de rede em um determinado ponto sair, ainda assim, continuar a assinar blocos e atestados, eles podem alterar o estado da rede e alimentar esses dados falsos para um nó sincronizado com o rede se os agentes maliciosos pegarem o nó de sincronização antes que o nó de sincronização alcance onde os validadores retiraram seus fundos. Você pode ler mais sobre isso aqui, mas a resposta curta é que você precisa ter um “ponto de verificação de subjetividade fraca” ou um arquivo de estado codificado, essencialmente um arquivo da rede. Teku fornece sinalizadores de inicialização para ambos.

        A última preocupação com a penalidade é a mais séria: Cortar. O corte ocorre quando um staker trabalha contra as regras da rede. É diferente de ser penalizado por estar offline. Ele está trabalhando ativamente contra a rede, enviando informações conflitantes do validador. Existem alguns materiais realmente excelentes para aprender mais sobre cortes e como evitá-los:

        A principal lição é não executar uma chave validadora em vários clientes. Aparentemente, foi isso que causou o primeiro evento de corte de todos os tempos, que ocorreu em 2 de dezembro. Houve vários cortes desde então! Se você estiver migrando de uma instância para outra, verifique quádruplamente se você não terá duas máquinas trabalhando com a mesma chave:

        Papa Ben fala como se fosse. Fonte

        Especificações de configuração do AWS + Infura + Teku Validator

        Minha configuração de bloco Genesis:

        Sistema operacional: Ubuntu Server 20.04 LTS (HVM) (Amazon Web Service)

        Processador: Processador Intel Xeon Platinum série 8000, 3,1 GHz. (Amazon Web Service)

        Memória: 4 núcleos virtuais, 16 GB de RAM (Amazon Web Service)

        Armazenar: SSD de 100 GB, 300/3000 IOPS (Amazon Web Service)

        Cliente Ethereum 1.0: Endpoint Infura (nível gratuito)

        Cliente Ethereum 2.0: Teku

        Analisando todas as considerações acima, não tenho certeza sobre a melhor abordagem para construir uma configuração de validador. Para mim, gostaria de escolher uma máquina e geralmente não me preocupo em trocá-la por pelo menos dois anos. Isso ajuda com o custo geral do validador (posso obter um desconto significativo ficando com um provedor virtual por alguns anos) e não sou particularmente ágil com a rotação de servidores. Essa abordagem à prova de futuro ou de “especificações exageradas”, espero, torne minha vida nos próximos dois anos um pouco mais fácil.

        Inicialmente, eu estava confiante de que a AWS era a melhor plataforma virtual e é o serviço que usarei neste post e no próximo. No entanto, depois de passar por todo o processo, percebi que a AWS pode ser um exagero para o desenvolvedor individual. A verdadeira força da AWS parece ser sua capacidade de escalar dinamicamente para atender à demanda, que tem um custo premium. Isso faz sentido do ponto de vista econômico para um projeto de nível empresarial em grande escala, mas individual Ethereum 2.0 atual os requisitos do cliente não exigem tal rigor.

        Continuarei com a AWS, mas também considerarei a opção de executar uma instância no Digital Ocean, que pode ser mais apropriada para um desenvolvedor individual. Mais sobre isso em uma data posterior.

        Configurar conta Infura

        Estou optando por usar o Infura como meu endpoint Ethereum 1.0. Por enquanto, a cadeia de beacon está observando o Contrato de Depósito no Ethereum 1.0 para ativar novos stakers quando eles tiverem depositado corretamente 32 ETH e enviado as assinaturas BLS apropriadas.

        No futuro, a cadeia de beacon começará a testar o processamento adicional, começando a usar informações de estado do Ethereum 1.0 para criar pontos de verificação paralelos na cadeia de beacon.

        Como mencionamos acima, existem duas maneiras principais de ter visibilidade da rede Ethereum 1.0. Uma é sincronizar e manter ativamente um nó Ethereum 1.0, que cria um banco de dados estadual Ethereum 1.0 local. A outra é usar um serviço como o Infura, que fornece um endpoint Ethereum 1.0 fácil, acessível através de HTTPS ou WebSockets.

        Cadastre-se para uma conta aqui. Depois de criar uma conta, clique no logotipo da Ethereum no lado esquerdo.

        Clique em “Criar Novo Projeto” no canto superior direito

        Nomeie seu projeto (o meu é “Eth 2 Validator”) e vá para “Configurações”, certifique-se de que seus endpoints de rede sejam “Mainnet” e copie o endpoint HTTPS:

        Estaremos usando isso mais tarde para o nosso comando de inicialização do cliente Teku!

        Configurando a instância AWS

        Configurar uma instância EC2 na Amazon é simples. Faremos alguns ajustes aqui e ali para ajudar nossa instância virtual a funcionar bem com Teku.

        Crie uma conta da AWS (diferente de uma conta da Amazon.com) e faça login no console da AWS. Vá para a página EC2, que será semelhante a esta:

        Clique no botão “Iniciar instância”. Você verá a seguinte tela:

        Sistema operacional

        É aqui que selecionamos a imagem da máquina (que considero um sistema operacional) que gostaríamos de usar em nossa instância virtual. Estou selecionando Ubuntu Server 20.04, que é um ambiente de servidor baseado em Linux. O ambiente Ubuntu Server tem algumas diferenças de otimização principais do ambiente Ubuntu Desktop. A principal diferença para nossos propósitos é que o Ubuntu Server não possui uma interface gráfica de usuário (GUI). Para onde estamos indo, há apenas uma linha de comando! Me traz de volta aos meus dias de Apple II.

        Depois de selecionar nosso sistema operacional, escolhemos nosso tipo de instância:

        Acho este menu bastante opressor, então vou dividi-lo um pouco para você. Aqui, estamos selecionando o núcleo de computação / potência de RAM / CPU para nossa máquina. É a “memória bruta” ou “memória ativa” da máquina e separada do armazenamento (disco rígido) de um dispositivo. Pense nisso como o mecanismo de nossa instância virtual, na qual executaremos nosso sistema operacional Ubuntu Server. A AWS os separa em famílias de instâncias separadas denotadas pela combinação de letra / número na coluna da extrema esquerda.

        As famílias de instâncias têm diferentes arranjos de hardware, assim como diferentes motores de carros têm diferentes configurações de pistões, plugues e combustíveis para atender a diferentes demandas. Vamos nos concentrar em duas de suas famílias de instâncias de “computação geral”, m5 e t3.

        Estou selecionando a instância m5.xlarge, que fornece 4 núcleos de computação virtual (vCPUs) e 16 GB de RAM. Depois de executar o Ethereum 2.0 mainnet por um dia ou mais, minha máquina não usou mais do que 4% da vCPU disponível. Conforme mencionado na seção “Provas futuras” acima, as demandas de rede Ethereum 2.0 só irão crescer. Mas, nos próximos meses, na ausência de grandes picos de rede prolongados, provavelmente ficaria bem com uma instância m5.large (2 núcleos virtuais / vCPUs, 8 GB de RAM)

        Pessoal técnico mais experiente do que eu também recomendou a instância t3.large como uma opção razoável para Ethereum 2.0. t3.large tem 2 vCPUs e 8 GB de memória, o mesmo que m5.large, mas a família t3 foi desenvolvida para uma atividade de rede mais “burstable” (picos na CPU) em vez da família m5 desenvolvida para cargas de CPU consistentes.

        Preços

        A última coisa a mencionar antes de passarmos para o armazenamento é o preço. AWS é cara em comparação com outras opções como o Digital Ocean. Você paga pela CPU (sua família de instâncias) e armazenamento (seu disco rígido) separadamente com base no que você usa. A CPU é paga por hora. Como os validadores precisam estar online 24 horas, você pode usar a tabela de preços abaixo (a partir de dezembro de 2020) para fazer alguns cálculos aproximados: 

        Esses são preços sob demanda. AWS fornece algo chamado Preços de instância reservada, onde se você prometer ter uma instância virtual de um a três anos, você pode obter uma redução de custo de até 50-60% na tabela de preços acima. (Obrigado a Jason Chroman por esta dica!)

        Na página inicial do EC2, clique em “Instâncias reservadas” no menu à esquerda, mostrado abaixo:

        Clique em “Comprar Instância Reservada”:

        No menu que aparece, coloque os detalhes do tipo de instância e a quantidade de tempo desejada para ver o preço (estou escolhendo m5.xlarge e um prazo de 36 meses):

        Clique em “Pesquisar” e veja as opções de preço:

        Há um desconto significativo no preço, mais de 50%, eu acredito, mas estou preso por três anos. Depois de comprar a instância reservada, a AWS a aplica a uma caixa virtual existente ou a aplicará assim que for iniciada. Lembre-se de que NÃO inclui espaço de armazenamento (disco rígido). 

        Observação: não estou fazendo isso ainda, pois ainda não estou convencido de que a AWS é a melhor opção para um indivíduo que estaca de um a três nós validadores Ethereum 2.0. Estou executando uma instância com preços sob demanda para ver como vai antes de comprometer. 

        Armazenar

        Voltando ao nosso processo de inicialização da instância, estamos indo para a guia “Adicionar armazenamento”

        O brilhante pessoal técnico que consultei recomendou uma quantidade de armazenamento de SSD de uso geral de 100 GB. O armazenamento normalmente não é um gargalo com clientes Eth2. No entanto, este é sem executando um cliente Eth1 completo. Para armazenamento Eth1, uma estimativa conservadora seria de cerca de 1 TB. Certifique-se de levar isso em consideração se você não estiver usando o Infura.

        Não conheço a unidade na coluna IOPS na imagem acima, mas é a entrada-saída do disco rígido que se comunica com a CPU. Este é um gargalo clássico para a sincronização completa do nó Eth1. Se você deseja sincronizar um cliente Eth1 completo nesta máquina e está tendo problemas, este pode ser um lugar para procurar.

        Portas

        Ignorando “Adicionar tags”, vá para “Configurar grupo de segurança”. Estas são as diferentes aberturas criadas para diferentes tipos de comunicação de entrada e saída com a instância.

        A AWS abre automaticamente a porta SSH tradicional, pois é a principal forma de interagirmos com a instância. Moeda de caju e Somer Esat’s Os guias excelentes recomendam desativar o acesso por senha para SSH, mas veremos quando iniciarmos a instância que não é a opção padrão para AWS. No entanto, é bom randomizar sua porta SSH para um número entre 1024-65535. Isso evita que agentes mal-intencionados façam varredura na rede da porta SSH padrão. Veja como proteger sua porta SSH em geral aqui e especificamente para AWS aqui.

        Temos que adicionar duas regras de segurança para acomodar o cliente Teku e isso tem a ver com a comunicação ponto a ponto. As redes blockchain são descentralizadas no sentido de que os nós conversam diretamente entre si. Em vez de consultar um nó central, um nó individual desenvolverá e manterá uma compreensão do estado da rede “fofocando” com muitos nós. Isso significa que, quando um cliente aperta a mão de outro, eles trocam informações sobre a rede. Feito o suficiente com diferentes nós, as informações se propagam por toda a rede. Atualmente, meu nó do Validador Eth2 tem 74 pares com os quais está conversando.

        Teku se comunica com outros nós na porta 9000, então vamos abrir isso para UDP e TCP, dois tipos diferentes de protocolos de comunicação. 

        Depois, deve ser parecido com isto:

        Chaves SSH e lançamento de instância

        Por último, vá para “Review and Launch”, uma visão geral das escolhas feitas. Depois de aprovado, haverá um menu pop-up sobre as chaves SSH. Não estou mostrando o meu porque contém informações confidenciais. Ou seja, o par de chaves usado para autenticar e fazer login na instância virtual via SSH (linha de comando local). Se você ainda não tem um par, a AWS irá gerar um para você. Você deve fazer o download e tratá-lo como uma chave privada Ethereum! É a única maneira de se conectar à sua instância e a AWS não vai salvá-la para você.

        Quando tudo estiver ótimo, esta janela aparecerá:

        OK! Isso é feito, vamos prosseguir para acessar e proteger nossa instância e, em seguida, instalar e executar o Teku!

        Acessando Instância

        A principal forma de acessar a instância AWS é por meio de SSH, “Um protocolo criptográfico para operar serviços de rede com segurança em uma rede não segura.” Conforme mencionado anteriormente, a AWS por padrão desativa a autenticação de senha para acessar a instância. Você só pode usar o par de chaves gerado antes do lançamento da instância. O par de chaves deve ter um arquivo .pem terminando. 

        A AWS fornece uma maneira limpa de obter seu comando SSH. Ao clicar na instância em execução na página principal do EC2, há um botão no canto superior direito que diz “conectar”:

        Na próxima página, haverá um comando SSH específico para sua instância. Será estruturado assim:

        ssh -i "PATH_TO_AWS_KEYPAIR.pem" [email protegido]_IDENTIFIER.compute-ZONE.amazonaws.com

        Inserir este comando em um terminal iniciará a sessão SSH. Na primeira vez, a máquina local perguntará se você gostaria de confiar na impressão digital ECDSA fornecida pela AWS. Isso é para evitar um ataque man-in-the-middle e, se preocupado, um usuário pode obter a impressão digital de sua instância seguindo essas etapas.

        Em um terminal separado da sessão SSH atual, transfira os arquivos de chave do validador necessários para executar o Teku. Na postagem anterior do blog, vimos como piquetar 32 ETH e obter as chaves do validador para Ethereum 2.0. No final, ficamos com esta estrutura de arquivo:

        eth2deposit-cli / └── validator_key_info / ├── KEYSTORE-M_123456_789_ABCD.json ├── KEYSTORE-M_123456_789_ABCD.txt └── DEPOSIT_DATA_YOUR_TIMESTAMP_HERE.json

        Precisamos transferir o arquivo validator_key_info para nossa instância virtual. O protocolo de cópia segura (scp) nos permite fazer isso com segurança. Adapte o comando scp genérico abaixo usando o caminho para o diretório acima e o comando SSH anterior:

        scp -r -i "PATH_TO_AWS_KEYPAIR.pem" / PATH_TO_KEYS / eth2deposit-cli / validator_key_info / [email protegido]_IDENTIFIER.compute-ZONE.amazonaws.com:~

        (Observe o “: ~” no final de todo o comando.)

        Você deverá ver uma transferência de arquivo ocorrer. Se você navegar de volta para sua sessão SSH e digitar ls, deverá ver o diretório transferido.

        Instalando Teku

        Agora que temos os arquivos validadores de que precisamos, vamos instalar o Teku. Primeiro, temos que atualizar os programas existentes e instalar os sistemas Java necessários:

        Instale Java

        atualização apt sudo && sudo apt install default-jre && sudo apt install default-jdk

        Verifique se o Java instalado foi bem-sucedido com:

        java -version

        Instale o binário

        Encontre a versão estável mais recente do Teku aqui. Copie o endereço do link para o arquivo tar.gz e, em seguida, faça o download da sessão SSH. Esta é a minha aparência, sua versão provavelmente será diferente:

        curl -JLO https://bintray.com/consensys/pegasys-repo/download_file?file_path=teku-20.11.1.tar.gz

        Descompacte o arquivo baixado com o seguinte comando. Se você tiver uma versão diferente, substitua esse nome de arquivo em teku-20.11.1.tar.gz:

        tar -zxvf teku-20.11.1.tar.gz

        Para fins de limpeza, remova o arquivo tar.gz.

        Depois de todas essas etapas, veja como seu diretório inicial deve ficar (o número da versão do Teku e o conteúdo podem ser diferentes:

        ubuntu / └── teku-20.11.1 / ├── LICENÇA ├── bin / ├── lib / ├── license-dependency.html ├── teku.autocomplete.sh └── validator_key_info / ├── KEYSTORE -M_123456_789_ABCD.json ├── KEYSTORE-M_123456_789_ABCD.txt └── DEPOSIT_DATA_YOUR_TIMESTAMP_HERE.json

        Crie um usuário não root

        Esta etapa foi copiada de Somer Esat excelente tutorial Ubuntu / Teku

        Vamos criar um usuário não root chamado teku que pode operar o Teku. Digite o seguinte:

        sudo useradd –no-create-home –shell / bin / false teku 

        Vamos criar um diretório de dados personalizado para Teku também e, em seguida, dar ao usuário teku acesso a ele:

        sudo mkdir / var / lib / teku && sudo chown -R teku: teku / var / lib / teku

        Criar serviço systemd

        Esta etapa é adaptada de Somer Esat excelente tutorial Ubuntu / Teku

        Esta etapa criará um serviço que executará o Teku em segundo plano. Também permitirá que a máquina reinicie automaticamente o serviço se ele parar por algum motivo. Esta é uma etapa necessária para garantir que nosso validador funcione 24-7.

        Crie o arquivo de serviço usando o editor de texto nano:

        sudo nano /etc/systemd/system/teku.service

        Neste arquivo (que deve estar vazio), vamos colocar uma série de comandos para o systemd executar quando iniciarmos o serviço. Este é o código abaixo, você terá que incluir nos seguintes itens que coletamos ao longo desta jornada:

        • Ponto final Infura Eth1 HTTP
        • validator_key_info caminho do diretório com dois arquivos válidos relacionados à chave
        • Caminho de dados personalizados (lib / var / teku)

        Coloque esses valores no código em negrito abaixo e copie tudo para o editor de texto nano:

        [Unit] Descrição = Teku Beacon Node Wants = network-online.target After = network-online.target [Service] Type = simple User = teku Group = teku Restart = sempre RestartSec = 5 ExecStart = / home / ubuntu / teku-20.11 .1 / bin / teku –network = mainnet –eth1-endpoint = INFURA_ETH1_HTTP_ENDPOINT_GOES_HERE –validator-keys = / home / ubuntu / validator_key_info / KEYSTORE-M_123456_789_ABCD.json: /home/ubuntu/validator_key_info/validator_keys/KEYSTORE.txt_123_123_ –rest-api-enabled = true –rest-api-docs-enabled = true –metrics-enabled –validators-keystore-locking-enabled = false –caminho-base de dados = / var / lib / teku [Instalar] WantedBy = multi-user.target

        Digite command-X e, em seguida, digite “Y” para salvar suas alterações

        Temos que reiniciar “systemctl” para atualizá-lo:

        sudo systemctl daemon-reload

        Inicie o serviço:

        sudo systemctl start teku

        Verifique se está começando bem:

        sudo systemctl status teku

        Se você vir algum erro, obtenha mais detalhes executando:

        sudo journalctl -f -u teku.service

        Você pode interromper o serviço Teku executando:

        sudo systemctl stop teku

        Verifique a página de solução de problemas do Teku para erros comuns ou verifique a discórdia Teku, que é monitorado pela equipe.

        Quando sentir que tudo resolvido, habilite o serviço para reiniciar se ele for encerrado executando:

        sudo systemctl enable teku

        Aí está! As coisas deveriam estar cozinhando agora. Ao inspecionar o serviço Teku, você verá uma série de registros observando um evento de sincronização, este é o seu validador sincronizando a cadeia de beacon. Assim que chegar à cabeça, esses logs mudarão para ler Slot Event, e você também verá o desempenho do seu atestado e bloqueará as propostas.

        Lançar

        Fonte: Beaconcha.in

        No dia 1º de dezembro às 12h UTC, os primeiros blocos da Beacon Chain foram validados. O primeiro bloco veio de Validator 19026, com o graffiti enigmático, “Sr. F estava aqui.” Doze segundos depois veio o próximo bloco, graffiti indicando que o validador pode estar localizado em Zug, Suíça. A cadeia Eth2 Beacon cresceu continuamente, bloco a bloco a cada 12 segundos. Então veio o próximo obstáculo: validadores suficientes estariam online para finalizar a primeira Epoch? Sim! 82,27% dos validadores atestaram a validade da Epoch 0, o proverbial andar térreo da Beacon Chain. Você pode ler mais sobre o lançamento do Beacon Chain e o que vem a seguir aqui. 

        Fonte: Beaconcha.in

        Estamos agora na Epoch 760, o que significa que a cadeia de balizas está funcionando perfeitamente há quase uma semana. 

        Aqui está uma foto da minha perspectiva do momento de gênese, usando a configuração descrita nesta postagem:

        Na próxima edição, faremos uma recapitulação de como as coisas estão indo. Vou acessar as métricas da Teku, discutir o custo de execução da AWS e discutir brevemente o estado da rede.

        Fique atento!

        Recursos e links

        Agradecimentos a James Beck, Meredith Baxter, Jason Chroman, Aaron Davis, Chaminda Divitotawela, Ben Edgington, The Dark Jester, Somer Esat, Joseph Lubin, Collin Meyers, Nick Nelson, Mara Schmiedt, Adrian Sutton e Alex Tudorache pelo suporte e assistência técnica.

        Ethereum 2.0NewsletterSubscreva nossa newsletter para obter as últimas notícias da Ethereum, soluções empresariais, recursos para desenvolvedores e muito mais.