Ir para o conteúdo
Financial Context Wiki

Nó completo

Guia de verificação sobre nós completos, clientes de execução e consenso do Ethereum, checkpoints de sincronização, estado atual e histórico, pruning, privacidade RPC, finalidade e dimensionamento operacional.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Um nó completo baixa os dados exigidos pelo protocolo, verifica blocos e transições segundo regras locais, segue a cadeia selecionada por elas e rejeita dados inválidos sem terceirizar a decisão a um RPC. “Completo” descreve responsabilidade de verificação, não retenção permanente de todo estado histórico, produção de blocos, staking, API pública ou imunidade a erros.

No Ethereum proof-of-stake, ele combina cliente de execução e de consenso. O primeiro valida transações e payloads, mantém o estado e expõe JSON-RPC; o segundo valida consenso, aplica fork choice e acompanha justificação e finalidade. Cliente validador é opcional e serve apenas para propor e atestar com validadores em staking.

Como funciona

  1. Defina objetivo e snapshot: protocolo, cadeia, gênese, forks, chainId, hashes atual/finalizado, versões, sync, checkpoint, pruning, RPC, horizonte histórico e uptime.
  2. Instale releases verificadas. Conecte execução e consenso por Engine API local autenticada; adicione validador só para staking. Separe dados, portas, RPC e chaves.
  3. Inicialize da âncora correta. Full sync valida da gênese; snap/checkpoint parte de estado autenticado e valida adiante. Confira gênese, checkpoint, chain ID, fork digest e head finalizado independentemente.
  4. Monitore peers, atrasos, Engine API, state roots, relógio, disco, I/O, memória, CPU, erros e forks. “Sincronizado” exige clientes concordando e importando dados válidos.
  5. Ajuste retenção à consulta. Nó podado guarda estado atual e dados suficientes, mas pode regenerar ou negar estado antigo. Archive materializa estados históricos. Light client verifica compromisso mais estreito e solicita dados.
  6. Exponha o mínimo RPC. Mantenha admin/Engine locais, autentique, filtre e limite; não publique debug, trace, contas ou txpool sem controle. Teste latest, safe e finalized, histórico, logs e envio.
  7. Reconcilie e recupere. Compare hashes, roots e checkpoints; ensaie desligamento, restore, rebuild, upgrade, fork, disco, peers e failover. Separe saída verificada de claims externos.

Exemplos calculados

  • Banda. Um bloco a cada 12 seconds com 150 kB gera 86,400 / 12 = 7,200 blocks/day e 7,200 * 150 kB = 1,080,000 kB = 1.08 GB/day decimais antes de overhead. São premissas, não constantes.
  • Disco. Base 1.20 TB, crescimento 18 GB/month, por 30 months: 1,200 + 18 * 30 = 1,740 GB. Reserva de 25%: 1,740 * 1.25 = 2,175 GB, ou 2.175 TB.
  • Disponibilidade. Em 30 days = 720 hours, manutenção 2 hours, falha CL 3 hours, energia 1 hour, sem sobreposição. Downtime 6 hours; disponibilidade (720 - 6) / 720 = 99.1666666667%. Processo ativo pode estar stale.
  • Estado histórico. Snapshot 18,000,000, alvo 18,250,000: replay de 250,000 blocks. A 500 blocks/second, ideal 250,000 / 500 = 500 seconds = 8.3333333333 minutes, excluindo I/O, recibos, reorg e cache.

Riscos

  • Cadeia, gênese, forks ou chainId errados.
  • Checkpoint malicioso ou stale.
  • Cliente desatualizado em upgrade.
  • Divergência EL/CL ou Engine API indisponível.
  • Bug de cliente servindo dados errados.
  • Monocultura e falhas correlacionadas.
  • Poucos peers, eclipse ou peers maliciosos.
  • Deriva do relógio.
  • Disco cheio/lento ou banco corrompido.
  • Confundir uptime com sync/finalidade.
  • Confundir head, safe e finalized.
  • Esperar todo histórico de nó podado.
  • Supor que archive contém índices off-chain.
  • Expor Engine/admin/debug/trace/txpool.
  • Vazar endereços, consultas ou intenção.
  • RPC sobrecarregar validação.
  • Restaurar backup stale/inconsistente.
  • Perder chaves por co-localização.
  • Tratar chain data como prova de frontend/oracle.
  • Aplicar modelo Ethereum a outra chain.

Equívocos comuns

  • Todo nó completo é archive permanente.
  • Rodar nó torna o operador validador.
  • “Sincronizado” garante cadeia finalizada correta.
  • RPC próprio elimina todo risco.
  • Mais disco, peers ou uptime prova correção.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...