---
title: "Nó completo"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Nó completo
> 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
- [Cliente leve](/pt-br/crypto/light-client/)
- [Nó RPC](/pt-br/crypto/rpc-node/)
- [Raiz de estado](/pt-br/crypto/state-root/)
## Fontes
- [Nodes and clients](https://ethereum.org/developers/docs/nodes-and-clients/) - Ethereum.org (acessado: 2026-08-12)
- [Node architecture](https://ethereum.org/developers/docs/nodes-and-clients/node-architecture/) - Ethereum.org (acessado: 2026-08-12)
- [Spin up your own Ethereum node](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (acessado: 2026-08-12)
- [Ethereum Archive Node](https://ethereum.org/developers/docs/nodes-and-clients/archive-nodes/) - Ethereum.org (acessado: 2026-08-12)
- [Client diversity](https://ethereum.org/developers/docs/nodes-and-clients/client-diversity/) - Ethereum.org (acessado: 2026-08-12)
- [Sync modes](https://geth.ethereum.org/docs/fundamentals/sync-modes) - go-ethereum (acessado: 2026-08-12)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (acessado: 2026-08-12)
- [Weak subjectivity](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (acessado: 2026-08-12)
Source: https://wiki.fcontext.com/pt-br/crypto/full-node/index.mdx