Vai al contenuto
Financial Context Wiki

Nodo completo (full node)

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.

Aggiornato

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

Fonti

Navigazione

Cerca nella wiki...