Rocket Pool
Rocket Pool
  • Português

      • Especificando um Nó de Fallback

      A partir da versão 1.5.0 da stack do Smartnode, você pode fornecer um par de cliente de Execution "fallback" e cliente de Consensus que podem assumir o controle dos seus clientes primários se eles ficarem offline (como porque você usa Geth e precisa fazer poda). Nessa situação, sua máquina de nó primária ainda será responsável por atestar e propor blocos com as chaves de validador do seu megapool, mas se conectará a uma máquina externa para interagir com a camada de Execution e as cadeias Beacon.

      Essencialmente, permite que você use temporariamente outro par de clientes para coisas como consultar as cadeias, enviar transações e receber blocos para atestar. Este par pode ser gerenciado externamente (como no modo Híbrido), ou pode ser outro nó da Rocket Pool (outra máquina no modo Docker que tem as portas API expostas, que abordaremos abaixo).

      Uma vez que os clientes primários do seu nó estejam novamente online, o Smartnode e seu cliente Validator voltarão para eles automaticamente.

      NOTA

      Um nó de fallback não é o mesmo que um nó de "backup". Nós de fallback têm um par de cliente de Execution e Consensus sincronizado com a cadeia e em execução, mas não têm a carteira do seu nó ou suas chaves de validador carregadas.

      Se seu nó principal ficar offline, seu fallback não começará a validar por você.

      Clientes Suportados

      A partir da v1.9.0, todos os nossos clientes de validador suportados adicionaram suporte a Fallback com apenas algumas limitações:

      NomeSuporta FallbackClientes de Fallback Válidos
      LighthouseSimQualquer (proteção doppelganger off)
      Lighthouse (proteção doppelganger on)
      NimbusSimQualquer
      PrysmSimPrysm
      TekuSimQualquer
      LodestarSimQualquer

      Configurando um Novo Nó (Modo Docker)

      Você pode usar uma segunda máquina que você possui localmente, um nó remoto hospedado em um VPS ou um nó baseado em nuvem como um nó de fallback.

      Este exemplo mostra como criar um segundo Smartnode em uma máquina diferente usando o modo Docker, que pode servir como um nó de fallback.

      DICA

      Se você já tem um segundo nó pronto e tem suas portas RPC expostas, sinta-se à vontade para pular esta seção.

      1. Siga os passos no guia de configuração de um nó (local ou remoto).

      2. Quando a máquina estiver pronta, instale a stack do Smartnode.

      3. Execute rocketpool service config para especificar quais clientes você gostaria de usar.

        1. Quando chegar ao final do assistente e ele perguntar se você gostaria de revisar suas configurações, selecione Sim.
        2. Entre nas configurações do Execution Client.
        3. Marque a caixa Expose RPC Ports:
        1. Volte e entre nas configurações do Consensus Client. 5. Marque a caixa Expose API Port (e, se você estiver usando Prysm, a caixa Expose RPC Port também):
        1. Salve as configurações e inicie o Smartnode.

      4. Pule para o guia Protegendo seu Nó para configurar SSH e a postura de segurança adequada nele.

        1. Se você tiver ufw instalado, precisará adicionar regras para permitir tráfego de entrada nas portas API (8545, 8546 e 5052 por padrão; também 5053 se você estiver usando Prysm).

      5. É isso! Você pode parar aqui.

      NOTA

      Não crie uma carteira com rocketpool wallet init ou recupere sua carteira antiga. Deixe este nó sem uma carteira e sem chaves de validador.

      Seu único trabalho é ter um cliente de Execution e um cliente de Consensus sincronizados.

      Conectando seu Nó Principal ao Nó de Fallback

      Assim que tiver um nó de fallback preparado, você pode conectá-lo ao seu nó principal.

      1. Entre na TUI de rocketpool service config e entre nas configurações de Fallback Clients.
      2. Marque a caixa Use Fallback Clients.
      3. Digite a URL RPC para seu cliente de Execution na caixa Execution Client URL. Por exemplo, se o endereço IP do seu nó de fallback for 192.168.1.45 e você tiver seu cliente de Execution na porta padrão de 8545, você digitaria http://192.168.1.45:8545 aqui.
      4. Faça o mesmo para a URL RPC do seu cliente de Consensus de fallback. Seguindo o mesmo exemplo, se você o tiver na porta padrão de 5052, você digitaria http://192.168.1.45:5052 aqui.

      A página final deve ficar assim:

      NOTA

      Usuários do modo nativo podem seguir os mesmos passos, embora a TUI pareça ligeiramente diferente da captura de tela acima.

      Observe que isso fornecerá apenas ao Smartnode em si (o serviço daemon) o suporte de fallback; você terá que atualizar os argumentos do serviço do seu cliente Validator manualmente para dar a ele acesso aos clientes de fallback.

      Pressione enter na caixa final para garantir que seja confirmada, então salve as configurações e aplique as alterações.

      Depois de aplicadas, você pode confirmar a disponibilidade do seu nó de fallback usando o comando rocketpool node sync:

      Your Smartnode is currently using the Ethereum Mainnet.

Your eth2 client is on the correct network.

Your primary execution client is fully synced.
Your fallback execution client is fully synced.
Your primary consensus client is fully synced.
Your fallback consensus client is fully synced.

      Se mostrar que tanto o cliente de Execution quanto o de Consensus de fallback estão sincronizados, então está tudo pronto!

      Testando os Clientes de Fallback

      Se você quiser ter certeza absoluta de que sua configuração funcionará testando os clientes de fallback, simplesmente pare os clientes de Execution e Consensus no seu nó principal:

      docker stop rocketpool_eth1 rocketpool_eth2

      Então execute qualquer comando que consulte a cadeia, como rocketpool network stats. Você verá uma mensagem de aviso no topo indicando que um (ou ambos) dos seus clientes primários estão offline e que está revertendo para os clientes de fallback:

      NOTE: primary clients are not ready, using fallback clients...
 Primary EC status: unavailable (Sync progress check failed with [Post "http://eth1:8545": dial tcp: lookup eth1 on 127.0.0.11:53: no such host])
 Primary CC status: unavailable (Sync progress check failed with [Could not get node sync status: Get "http://eth2:5052/eth/v1/node/syncing": dial tcp: lookup eth2 on 127.0.0.11:53: no such host])

========== General Stats ==========
Total Value Locked:          1196.926316 ETH
Deposit Pool Balance:        23.586761 ETH
Minipool Queue Demand:       0.000000 ETH
Deposit Pool ETH Used:       6.809609%

============== Nodes ==============
Current Commission Rate:     5.000000%
Node Count:                  16
Active Minipools:            36
    Initialized:             0
    Prelaunch:               0
    Staking:                 36
    Withdrawable:            0
    Dissolved:               0
Finalized Minipools:         30

=========== Megapools ============
Megapool contracts deployed: 10
Total megapool validators:  86
     Staking:                51
     In Prestake:            6
     In Queue:               10
     Exited:                 14
     Locked:                 1
     Exiting:                2
     Dissolved:              2

========== Smoothing Pool =========
Contract Address:            0xE8D1136ac49DBe6ac8f299130253004DC63841a1
Nodes Opted in:              3
Pending Balance:             0.000000

============== Tokens =============
rETH Price (ETH / rETH):     1.185477 ETH
RPL Price (ETH / RPL):       0.000639 ETH
Total RPL staked:            33406.127068 RPL
Total Megapool RPL staked:   11406.127068 RPL
Total Legacy RPL staked:     22000.000000 RPL

      Finalmente, inicie seus clientes primários novamente:

      docker start rocketpool_eth1 rocketpool_eth2

      E pronto! Sua configuração de fallback está funcionando.

      Próximos Passos

      Tenha ou não optado por criar e/ou executar um nó de fallback para sua configuração, o próximo passo é aprender sobre taxas de prioridade. Clique na próxima seção do guia quando estiver pronto para prosseguir.