Configuração do Node da BOT Chain: Melhores Práticas

Configuração de Node da BOT Chain: Melhores Práticas

Especificações de Hardware

Para garantir desempenho e confiabilidade ideais, é crucial selecionar o tipo de node apropriado com base em seus requisitos específicos para processamento de transações e consulta de estado na BOT Chain.

Guia de Implantação de Nodes Archive e Full

Clone o repositório e entre no diretório
bash

git clone https://github.com/bl-BOHR/node-deploy.git && cd node-deploy

Conceda permissões de execução (necessário apenas na primeira vez no Linux)
bash

chmod +x BOHR_full_node.sh BOHR_archive_node.sh bin/geth*

Inicialize e inicie o node
- Node Full:
- bash
```
./BOHR_full_node.sh reset
```
- Node Archive:
- bash
```
./BOHR_archive_node.sh reset
```
Visualizar logs Os logs do Node estão localizados em: .local/fullnode/node/BOHR-node.log

Configuração Recomendada

Para usuários que precisam de acesso ao estado mundial mais recente em um modo leve, o node rápido é a escolha ideal. Ele exige menos da CPU e do espaço em disco do seu sistema.

Processador: CPU mínima de 2 núcleos.
Memória: Pelo menos 4 GB de RAM.
Armazenamento: Solid State Drive (SSD) com capacidade mínima de 128 GB.
Rede: Conexão de internet estável e de alta velocidade, mínimo de 1 MBps.

Node Archive

Para acesso abrangente a todo o estado mundial histórico da Mainnet da BOT, considere implantar um Node Archive. Instruções detalhadas estão disponíveis no repositório GitHub da BOT Chain. (Um link externo para o nosso repositório é necessário aqui.)

Processador: CPU mínima de 4 núcleos.
Memória: Pelo menos 8 GB de RAM.
Armazenamento: SSD com capacidade mínima de 1 TB (SSDs NVME são recomendados para um desempenho ótimo).
Rede: Conexão de internet estável e de alta velocidade, mínimo de 2 MBps.

Full Node

Para obter o estado mundial mais recente e verificar a validade do estado ou gerar provas de dados, um Full Node padrão é adequado.

Processador: CPU mínima de 4 núcleos.
Memória: Pelo menos 8 GB de RAM.
Armazenamento: Solid State Drive (SSD) com capacidade mínima de 1 TB.
Rede: Conexão de internet estável e de alta velocidade, mínimo de 2 MBps.

Configuração de Peers

Mainnet

Não há necessidade de especificar Static Nodes, apenas Bootnodes são necessários para a Mainnet e já estão configurados no código. Além disso, certifique-se de usar o arquivo config.toml da versão mais recente.

Testnet

A Testnet ainda precisa configurar os StaticNodes manualmente e, portanto, a lista de StaticNodes está contida no config.toml da versão mais recente.

Solução de problemas para falta de peers na Testnet

Verifique se há problemas de configuração, como ID de cadeia errada, arquivo/diretório de configuração incorreto.
Certifique-se de atualizar o arquivo config.toml conforme a versão mais recente.
Não use bootnodes na Testnet, não é necessário.
Excluir o arquivo/diretório geth/nodes e geth/nodekey pode ajudar.
Baixe novamente o snapshot e tente novamente.

Armazene seu BOT com uma Hardware Wallet

Os ativos mais valiosos de um Validator são duas chaves: uma para assinar transações e outra para assinar blocos.

Protegendo seu RPC de Full Node contra Hackers

Por favor, não exponha seus endpoints RPC a redes públicas.

Chaves Privadas da Conta

Para proteger seu BOT, não compartilhe suas 24 palavras com ninguém. A única pessoa que deve sabê-las é você. Em resumo, os HSMs são peças de hardware acessíveis, de alto desempenho e portáteis que ajudam a gerar, armazenar e gerenciar suas chaves privadas com segurança. Ataques de malware e a extração remota de chaves privadas são muito mais difíceis quando um HSM é configurado corretamente.

Vulnerabilidades de Software

Para proteger seu BOT, você deve baixar software apenas de fontes oficiais e garantir que esteja sempre usando a versão mais recente e segura.

Executando o Servidor como um Daemon

É importante manter o geth em execução o tempo todo. Existem várias maneiras de conseguir isso, e a solução mais simples que recomendamos é registrar o geth como um serviço systemd para que ele seja iniciado automaticamente após reinicializações do sistema e outros eventos.

Configurar um Node de Backup

Execute o Validator Node em modo Archive
Desligue os Nodes graciosamente
Monitoramento ativo com ferramentas

Etapas para Executar um Node de Backup

Instale a versão mais recente do geth
Sincronize com a altura mais recente usando o modo de sincronização rápida. Você pode baixar o snapshot mais recente ou iniciar a sincronização rápida assim que seu node estiver totalmente sincronizado
Desligue seu node graciosamente kill -HUP $(pgrep geth)
Reinicie seu node.

Por que o Node ficará Offline por um Tempo Após a Reinicialização? ou O que Acontecerá se o Cliente For Encerrado Forçadamente?

Após rodar (sincronizado) por um longo período e ser abruptamente encerrado, apenas nodes arquivados devem ressincronizar rapidamente após a reinicialização.

Etapas para reproduzir:

Execute o node sincronizado por um período de tempo.
Encerre bruscamente o node (kill -9 ou falha do sistema).
Reinicie o node, observe de onde ele ressincroniza a partir da altura do bloco de 1 hora atrás.

Razões

Se o Geth falhar (ou não for desligado graciosamente), o estado recente mantido na memória é perdido e precisa ser regenerado. Leva muito tempo para o Geth restaurar os estados.

A razão principal é que o geth limpa o trie de estado periodicamente. O período é definido como trieTimeout em config.toml.

Como Atualizar um Node de Backup para se Tornar um Node Validator?

Você pode parar de minerar novos blocos enviando comandos para o geth console

Conecte-se ao seu Validator Node com geth attach ipc:path/to/geth.ipc

miner.stop()

Em seguida, deixe o node de backup retomar a validação,

miner.start()

Protegendo os Validators

Cada candidato a Validator é encorajado a operar suas operações de forma independente, pois diversas configurações aumentam a resiliência da rede. Devido ao alto investimento feito pelos Validators, é altamente essencial protegê-los contra diferentes ataques DoS e DDoS. Nesta seção, discutiremos o mecanismo de segurança adotado pela BOT Chain para seus Validators.

Sentry Nodes (Proteção DDoS)

Os Validators são responsáveis por garantir que a rede possa resistir a ataques de negação de serviço. Uma maneira recomendada de mitigar esses riscos é que os Validators estruturem cuidadosamente sua topologia de rede em uma arquitetura de Sentry Node. Os Sentry Nodes podem ser rapidamente criados ou ter seus endereços IP alterados. Como os links para os Sentry Nodes estão em um espaço de IP privado, um ataque baseado na internet não pode perturbá-los diretamente. Isso garantirá que as propostas de bloco e os votos dos Validators sempre cheguem ao resto da rede.

Para configurar sua arquitetura de Sentry Node, você pode seguir as instruções abaixo:

Construa uma rede privada e configure conexões privadas confiáveis entre o validator node e seu Sentry.

Por favor, não exponha seus endpoints RPC de fullnode do Validator à rede pública.

Instale seu fullnode

Defina o Sentry como peers para o Validator Node

No console do Sentry Node, execute admin.nodeInfo.enode. Você deve obter algo semelhante a isto.

enode://f2da64f49c30a0038bba3391f40805d531510c473ec2bcc7c201631ba003c6f16fa09e03308e48f87d21c0fed1e4e0bc53428047f6dcf34da344d3f5bb69373b@[::]:30306?discport=0

!!! Nota: [::] será analisado como localhost (127.0.0.1). Se seus nodes estiverem em uma rede local, verifique cada máquina host individual e encontre seu IP com ifconfig. Se seus peers não estiverem na rede local, você precisa saber seu endereço IP externo (use um serviço) para construir a URL do enode. Copie este valor e no console do primeiro node, execute,

Atualize o arquivo config.toml do Validator Node

# make node invisible
NoDiscovery = true
# connect only to sentry
StaticNodes = ["enode://f2da64f49c30a0038bba3391f40805d531510c473ec2bcc7c201631ba003c6f16fa09e03308e48f87d21c0fed1e4e0bc53428047f6dcf34da344d3f5bb69373b@[10.1.1.1]:30306"]

Isso retornará verdadeiro se for bem-sucedido, mas isso não significa que o node foi adicionado com sucesso.

Para confirmar, execute admin.peers e você deverá ver os detalhes do node que acabou de adicionar.

Dessa forma, seu Validator Node tentará se conectar apenas com os Sentry Nodes fornecidos.

Confirme a conexão

Para confirmar, execute admin.peers e você deverá ver os detalhes do node que acabou de adicionar.

Configuração do Firewall

O geth usa várias portas TCP para diferentes propósitos.

O geth usa uma porta de escuta (TCP) e uma porta de descoberta (UDP), ambas na 31000 por padrão.

Se você precisar executar o JSON-RPC, também precisará da porta TCP 8545. Note que a porta JSON-RPC não deve ser aberta para o mundo exterior, porque a partir dela você pode realizar operações de administração.

← Tipos de nós Endpoint JSON-RPC →