---
title: "Nodo completo (full node)"
description: "Guida orientata alla verifica su nodi completi, client di esecuzione e consenso Ethereum, checkpoint di sincronizzazione, stato corrente e storico, pruning, privacy RPC, finalità e dimensionamento operativo."
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.
# Nodo completo (full node)
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
Un nodo completo scarica i dati richiesti, verifica blocchi e transizioni con regole locali, segue la chain selezionata da tali regole e rifiuta dati peer invalidi senza delegare la decisione a un RPC. “Completo” descrive la responsabilità di verifica, non la conservazione perpetua di ogni stato storico, la produzione di blocchi, lo staking o l’assenza di errori.
Su Ethereum proof-of-stake abbina client di esecuzione e consenso. Il primo valida transazioni e payload, gestisce lo stato e offre JSON-RPC; il secondo valida il consenso, applica fork choice e segue giustificazione e finalità. Il validator client è opzionale e serve per proposta e attestazione con validatori in staking.
## Come funziona
1. Definire obiettivo e snapshot: protocollo, chain, genesis, fork, `chainId`, hash corrente/finalizzato, versioni, sync, checkpoint, pruning, RPC, orizzonte storico e uptime.
2. Installare release verificate. Collegare EL e CL tramite Engine API locale autenticata; aggiungere il validator solo per staking. Separare dati, porte, RPC e chiavi.
3. Avviare dall’anchor previsto. Full sync verifica da genesis; snap/checkpoint parte da stato autenticato più recente e verifica in avanti. Controllare genesis, checkpoint, chain ID, fork digest e head finalizzato indipendentemente.
4. Monitorare peer, lag, Engine API, state root, orologio, disco, I/O, memoria, CPU, errori e fork. “Sincronizzato” richiede accordo e importazione continua.
5. Adattare la retention alle query. Un nodo pruned conserva stato corrente e dati sufficienti, ma rigenera o rifiuta stati vecchi. Archive materializza la storia. Light client verifica commitment più limitati e richiede altri dati.
6. Esporre la minima superficie RPC. Tenere admin/Engine locali, autenticare e limitare; non pubblicare debug, trace, account o txpool. Provare `latest`, `safe` e `finalized`, storico, log e invio.
7. Riconciliare e recuperare. Confrontare hash, root e checkpoint; provare shutdown, restore, rebuild, upgrade, fork, disco, peer e failover. Separare output verificato da claim esterni.
## Esempi svolti
- **Banda.** Un blocco ogni `12 seconds` con `150 kB` produce `86,400 / 12 = 7,200 blocks/day` e `7,200 * 150 kB = 1,080,000 kB = 1.08 GB/day` decimali prima dell’overhead. Sono ipotesi.
- **Spazio disco.** Base `1.20 TB`, crescita `18 GB/month`, per `30 months`: `1,200 + 18 * 30 = 1,740 GB`. Riserva `25%`: `1,740 * 1.25 = 2,175 GB`, ossia `2.175 TB`.
- **Disponibilità.** In `30 days = 720 hours`, manutenzione `2 hours`, guasto CL `3 hours`, corrente `1 hour`, senza sovrapposizione. Downtime `6 hours`; disponibilità `(720 - 6) / 720 = 99.1666666667%`. Processo attivo non significa synced.
- **Stato storico.** Snapshot `18,000,000`, obiettivo `18,250,000`: replay `250,000 blocks`. A `500 blocks/second`, ideale `250,000 / 500 = 500 seconds = 8.3333333333 minutes`, esclusi I/O, receipt, reorg e cache.
## Rischi
- Chain, genesis, fork o `chainId` errati.
- Checkpoint malevolo o obsoleto.
- Client non aggiornato al fork.
- Disaccordo EL/CL o Engine API offline.
- Bug del client e dati errati.
- Monocultura e guasti correlati.
- Peer insufficienti o malevoli, eclipse.
- Deriva dell’orologio.
- Disco pieno/lento o database corrotto.
- Confondere uptime, sync e finalità.
- Confondere head, safe e finalized.
- Esigere tutto lo storico da pruning.
- Presumere indici off-chain in archive.
- Esporre Engine/admin/debug/trace/txpool.
- Perdere privacy da log RPC.
- RPC sottrae risorse alla validazione.
- Ripristinare backup stale/incoerenti.
- Perdere chiavi co-localizzate.
- Confondere chain data e onestà esterna.
- Applicare Ethereum ad altre chain.
## Errori comuni
- Ogni full node è archive permanente.
- Gestire un nodo rende validator.
- “Sincronizzato” garantisce finalità corretta.
- RPC proprio elimina ogni rischio.
- Più disco, peer o uptime prova correttezza.
## Argomenti correlati
- [Light client](/it/crypto/light-client/)
- [Nodo RPC](/it/crypto/rpc-node/)
- [State root](/it/crypto/state-root/)
## Fonti
- [Nodes and clients](https://ethereum.org/developers/docs/nodes-and-clients/) - Ethereum.org (consultato: 2026-08-12)
- [Node architecture](https://ethereum.org/developers/docs/nodes-and-clients/node-architecture/) - Ethereum.org (consultato: 2026-08-12)
- [Spin up your own Ethereum node](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (consultato: 2026-08-12)
- [Ethereum Archive Node](https://ethereum.org/developers/docs/nodes-and-clients/archive-nodes/) - Ethereum.org (consultato: 2026-08-12)
- [Client diversity](https://ethereum.org/developers/docs/nodes-and-clients/client-diversity/) - Ethereum.org (consultato: 2026-08-12)
- [Sync modes](https://geth.ethereum.org/docs/fundamentals/sync-modes) - go-ethereum (consultato: 2026-08-12)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (consultato: 2026-08-12)
- [Weak subjectivity](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (consultato: 2026-08-12)
Source: https://wiki.fcontext.com/it/crypto/full-node/index.mdx