Eseguire un nodo Geth: Go-Ethereum sulla rete Ethereum

Decidi di non affidare più il traffico del tuo wallet a un endpoint Infura. Magari un amico si è offerto di aiutarti a mettere in staking 32 ETH. Magari la tua dApp rischia di rompersi per un solo limite di richieste il giorno del lancio. Qualunque sia il motivo, la frase successiva è sempre la stessa: devi eseguire un nodo Geth.

Quella frase sembra più complessa di quanto non sia in realtà. Geth, abbreviazione di go-ethereum, è il client di esecuzione originale di Ethereum, scritto nel linguaggio di programmazione Go da Jeffrey Wilcke e un team open-source globale nel 2014. Un moderno laptop con un SSD capiente può eseguirlo. Così come un box Hetzner da 30 dollari al mese. Le difficoltà che incontrano gli utenti non sono i comandi di installazione, ma le scelte che li riguardano: quale modalità di sincronizzazione scegliere, quale client di consenso abbinare a Geth, cosa succede dopo la Merge, come mantenere attivo il nodo quando il disco si riempie alle 2 del mattino.

Questa guida illustra l'intero processo. Dall'acquisto dell'hardware all'installazione, dalla sincronizzazione Snap all'accoppiamento post-Merge con un client di consenso, dalla console JavaScript agli account e a Clef, dalla configurazione del validatore ai problemi più comuni. Al termine, saprai esattamente cosa sta facendo la tua macchina quando scorrono i log bianchi e cosa fare quando si fermano.

Cos'è un nodo Geth e perché è importante oggi?

Un nodo Geth è un computer che esegue il client go-ethereum ed è connesso alla rete peer-to-peer di Ethereum. La macchina scarica i blocchi, verifica ogni transazione, esegue gli smart contract sulla Ethereum Virtual Machine e mantiene una copia sincronizzata dello stato globale. Dall'esterno, appare come un processo silenzioso in ascolto su alcune porte. Internamente, è un contabile inflessibile che si rifiuta di fidarsi della parola di chiunque altro per il registro. Mantiene una propria copia dei dati della blockchain, consente al tuo wallet di controllare i saldi dei conti o inviare transazioni alla blockchain e permette alla tua dApp di interagire direttamente con la blockchain anziché tramite API di terzi.

Perché tutto questo è importante nel 2026? Per la concentrazione. La maggior parte del traffico pubblico delle dApp su Ethereum passa attraverso una manciata di provider RPC ospitati: Infura, Alchemy, QuickNode e qualche altro provider più piccolo. Solo Infura ha gestito oltre 600 miliardi di richieste blockchain lo scorso anno. Sono affidabili, per lo più. Sono anche un singolo punto di guasto: quando un provider smette di funzionare in una regione, metà dei wallet puntati a quell'endpoint mostrano saldi obsoleti e transazioni bloccate finché qualcuno non risolve il problema. Gestisci il tuo nodo Geth e questo tipo di guasto non sarà più un tuo problema.

È anche una questione di numeri. Il tracker dei nodi di Etherscan conta circa 13.678 nodi Ethereum attivi in tutto il mondo ad aprile 2026. Gli Stati Uniti ne detengono il 37,55%, ovvero circa 5.171 nodi. La Germania ne ha il 16,05%. La Cina il 12,06%. Creare un nuovo nodo non è un'impresa eroica. È semplicemente utile, e la rete continua silenziosamente a contare sul fatto che le persone lo facciano.

C'è anche una ragione più profonda. Ethereum rimane Ethereum perché chiunque può verificarlo senza chiedere autorizzazione. Geth è il client più diffuso per effettuare questa verifica. Ogni volta che un altro operatore indipendente mette online un nuovo nodo Geth, impadronirsi della blockchain diventa un passo più difficile. Questa logica è preesistente alla fusione e non si è indebolita da allora.

Geth, Go Ethereum e il protocollo Ethereum

Tre nomi, un progetto. Le persone li confondono nelle conversazioni e non succede nulla di strano, ma ecco la vera spiegazione.

Il protocollo Ethereum non è un codice. È una specifica, scritta sul "yellow paper" e in una lunga serie di EIP (Ethereum Improvement Protocol), e chiunque può scrivere un client per esso. Go Ethereum, a volte scritto go-ethereum, è l'implementazione in linguaggio Go del protocollo Ethereum. Geth è il programma da riga di comando all'interno di Go Ethereum che si esegue dalla riga di comando, si configura con dei flag e si utilizza per interagire con la rete Ethereum. Tutto il resto nel repository è costituito da librerie e funzioni di supporto che lo supportano. Un "nodo Geth" è semplicemente una macchina su cui è stato avviato Geth, configurandolo in una directory `chaindata` e abilitandolo a comunicare con la rete principale di Ethereum.

Esistono diversi client per lo stesso protocollo. Nethermind, in C#. Besu, in Java. Erigon e Reth, entrambi in Rust. Stesso formato di comunicazione. Codice diverso, prestazioni diverse, storie diverse.

Geth è il più vecchio tra questi. Oltre 400 persone hanno contribuito al suo sviluppo; Péter Szilágyi ne è il responsabile da anni. Il sito ufficiale è la Ethereum Foundation; il codice sorgente si trova su ethereum/go-ethereum su GitHub; la licenza è la GNU General Public License, GPL-3.0 per i binari e LGPL-3.0 per il codice della libreria. La versione stabile attuale, al momento in cui scrivo, è la v1.17.2 — nome in codice "EMF Suppressor" — rilasciata il 30 marzo 2026. Ha corretto tre CVE (CVE-2026-26313, -26314, -26315) e ha insegnato al client come sincronizzarsi con le blockchain la cui cronologia pre-Prague è già stata eliminata.

Insieme a Geth vengono forniti alcuni strumenti complementari. Clef è un firmatario separato che mantiene le chiavi private separate dal nodo stesso. Abigen trasforma un'ABI di Solidity in binding Go effettivamente utilizzabili. Lo strumento `evm` consente di eseguire il bytecode in isolamento quando è necessario eseguire il debug di qualcosa di specifico. Nessuno di questi è obbligatorio. Finirai per aver bisogno di almeno uno di questi strumenti entro una settimana.

Perché eseguire un nodo: privacy, velocità, sovranità

La maggior parte delle persone che gestiscono un proprio nodo Geth lo fanno per uno di questi tre motivi. La privacy prima di tutto. Quando un portafoglio comunica con un RPC ospitato, quel fornitore vede ogni indirizzo, ogni chiamata di contratto e ogni richiesta di quotazione. Un nodo autogestito interrompe questo collegamento. Il fornitore non esiste. Il tuo portafoglio interroga la tua macchina, la tua macchina interroga la rete e solo la tua macchina vede lo schema.

Le prestazioni sono il secondo motivo. Le chiamate RPC ospitate sono soggette a throttling. Il piano gratuito di Infura ha un limite di 100.000 richieste al giorno; il piano Team costa 225 dollari al mese per 75 milioni di richieste giornaliere. Un nodo locale gestisce il traffico alla velocità della memoria con un costo per chiamata pari a zero. Per una dApp che recupera lo stato a ogni caricamento di pagina, la differenza di latenza è notevole. Per un bot di arbitraggio che analizza il mempool, è la differenza tra effettuare l'operazione e vederla passare. La rete principale ha elaborato circa 200,4 milioni di transazioni nel primo trimestre del 2026, con un picco di 2,88 milioni di transazioni il 16 gennaio, quindi un nodo in grado di tenere il passo con la rete sta svolgendo un lavoro reale.

La sovranità è il terzo punto. Se si effettua lo staking su Ethereum, la rete si aspetta che il validatore pubblichi un blocco quando arriva il suo turno. Affidare tale pubblicazione a un RPC condiviso è tecnicamente consentito, ma operativamente fragile. Eseguendo il proprio client di livello di esecuzione, si ha il controllo del proprio slot. Lo stesso vale per gli sviluppatori di dApp, gli analisti on-chain, i ricercatori di MEV e chiunque la cui attività dipenda dalla disponibilità di Ethereum.

Dopo la fusione: Geth e il tuo cliente di consenso

Prima di settembre 2022, un singolo processo Geth si occupava di tutto. Stabiliva una connessione con la rete, eseguiva l'EVM e selezionava il blocco vincente tra quelli in competizione tramite il mining proof-of-work. La fusione (Merge) ha dimezzato questo compito. Geth continua a eseguire l'EVM e a mantenere lo stato. Un secondo programma, il client di consenso, ora gestisce il proof-of-stake: scambia blocchi tra i validatori, vota su quali blocchi sono validi e comunica a Geth quale fork è quello canonico.

Quindi, ogni moderna configurazione Geth è una coppia di processi, non un singolo processo. Scegli un client di consenso da eseguire in parallelo. Le opzioni sono Lighthouse (Rust), Prysm (Go), Teku (Java), Nimbus (Nim) e Lodestar (TypeScript). I due processi comunicano tra loro tramite un canale privato chiamato Engine API, protetto da un segreto JWT che generi una sola volta e passi a entrambi i lati con `--authrpc.jwtsecret`.

Avviando Geth da solo, senza un client di consenso, i log mostreranno un messaggio del tipo "Rete post-unione, ma nessun client beacon rilevato. Si prega di avviarne uno per seguire la catena!". Il nodo rimarrà lì, educato ma inutile. Geth da solo non è più un nodo Ethereum completo. La coppia è l'unità.

In questo contesto, la diversità dei client è fondamentale. La comunità di Ethereum chiede agli operatori di distribuirsi tra le implementazioni su entrambi i lati della divisione, perché se più di due terzi dei validatori finiscono per utilizzare lo stesso client difettoso, questi validatori si troveranno a dover affrontare la penalità completa di 32 ETH in caso di malfunzionamento. Gli ultimi dati di clientdiversity.org indicano che Geth rappresenterà circa il 41% dei client di esecuzione nel 2026; il report di Stake.fish del 2026 parla di una percentuale più vicina al 50%. In entrambi i casi, si tratta di un calo rispetto a oltre l'86% del 2023, ma comunque superiore alla soglia di sicurezza del 33% che la comunità considera ideale. Ecco perché alcuni nuovi operatori scelgono deliberatamente Nethermind, Besu o Reth, anche se Geth rappresenta il primo passo più semplice.

Pectra, l'aggiornamento Prague + Electra attivato il 7 maggio 2025, ha anche ridefinito le attività quotidiane degli operatori. L'EIP-7251 ha aumentato il saldo effettivo massimo per validatore da 32 ETH a 2.048 ETH. Un operatore di staking che prima doveva gestire 1.000 validatori individuali ora può consolidarli in 16 grandi gruppi. L'EIP-6110 ha ridotto il tempo di attesa tra il deposito e l'attivazione da circa 12 ore a circa 13 minuti. L'EIP-7002 ha dato ai validatori la possibilità di avviare autonomamente i prelievi, invece di dover chiedere al firmatario del deposito originale di farlo. Gestire uno stack di validatori accoppiati a Geth nel 2026 è sostanzialmente più semplice rispetto al 2024.

Hardware: CPU, RAM e SSD per i nodi Geth

Gli standard hardware richiesti nel 2026 saranno più elevati di quanto ammesso dai documenti ufficiali. Pianificate per i prossimi tre anni, non per gli ultimi tre.

Lo storage è l'aspetto che sorprende maggiormente i nuovi operatori. Un nodo Geth completo, sincronizzato e ottimizzato, occupa oggi circa 650 GB. La documentazione di Geth afferma che aggiunge circa 14 GB a settimana. Aggiungete un client di consenso, un margine di crescita per alcuni mesi e tutto il traffico L2 RPC che intendete gestire. In questo modo, raggiungerete rapidamente una capacità compresa tra 4 e 8 TB di NVMe.

Un appunto sul tipo di disco. Gli SSD SATA funzionano tecnicamente. Tuttavia, bloccano la sincronizzazione e perdono le attestazioni sotto carico. Nel 2026, NVMe non sarà più un'opzione. I dischi rigidi tradizionali non sono più una soluzione praticabile da anni. Se il vostro provider offre SATA solo nel piano più economico, pagate di più. Il calcolo è impietoso: un disco SATA bloccato vi costa premi validatori persi a ogni epoca.

La RAM è la seconda trappola. La pagina ufficiale dell'hardware di Geth, aggiornata l'ultima volta nel 2023, indica ancora 16 GB. Entro il 2026, Cherry Servers, Chainstack e bacloud avranno tutti adottato 32 GB come livello minimo di utilizzo, con 64 GB come soluzione ideale. Geth memorizza una porzione consistente dello stato nella cache. Il client di consenso ne vuole la sua parte. Aggiungete Prometheus, Grafana e qualsiasi altro componente che effettivamente utilizzate, e 16 GB si esauriranno rapidamente.

La CPU è la più semplice delle tre. I moderni processori desktop hanno un margine di manovra enorme. La velocità di clock non è quasi mai il problema. Il numero di core e le istruzioni moderne contano di più. AVX2 mantiene veloce la verifica della firma. Otto core impediscono che un picco di sincronizzazione blocchi il computer. Guardando al futuro, il limite del gas di blocco è passato da 30 milioni a 45 milioni a 60 milioni tra la metà del 2024 e novembre 2025. La Ethereum Foundation ha preannunciato oltre 100 milioni entro il 2026. È questa la curva di riferimento rispetto alla quale dimensionare la macchina, non il carico dell'anno scorso.

Modalità di sincronizzazione Geth per la blockchain di Ethereum

La modalità di sincronizzazione è l'impostazione più importante che un nuovo operatore Geth deve regolare. Una scelta errata può significare sprecare una settimana a scaricare dati di cui non si ha effettivamente bisogno.

Snap è l'impostazione predefinita e quasi sempre la scelta giusta. Acquisisce un'istantanea recente dello stato dai peer, quindi completa silenziosamente le intestazioni e le ricevute sottostanti. Con un hardware decente, si ottiene un nodo Geth funzionante in un paio di giorni. Funziona perfettamente con wallet, dApp e validatori. L'unica cosa che non può fare è rispondere a domande storiche come "qual era il saldo di Vitalik il 7 ottobre 2017?". Se non vi interessa questo aspetto, non dovete più pensare alla modalità di sincronizzazione.

La sincronizzazione completa è ancora presente. La maggior parte degli utenti non ne ha bisogno. La modalità completa ripercorre ogni blocco fino al blocco genesi e riesegue ogni transazione, consentendo al client di verificare la blockchain end-to-end anziché affidarsi allo snapshot. Utile se si è particolarmente preoccupati per gli snapshot o se si sta creando un archivio con cronologia ridotta. Non utile per le normali operazioni.

L'archiviazione è la parte più impegnativa, e il 2025 è l'anno in cui i nodi di archiviazione sono cambiati. Fino alla versione 1.16, un nodo di archiviazione significava da 12 a 20 TB di SSD veloci, essenzialmente un piccolo server. La versione 1.16 ha introdotto una modalità di archiviazione basata su percorsi che memorizza lo stato storico come differenze inverse e riduce i requisiti di spazio su disco a circa 1,9-2,0 TB sulla mainnet. Questo porta l'ingombro di Geth vicino a quello di Erigon (~1,77 TB). Il compromesso, inizialmente, era che l'archiviazione basata su percorsi non supportava le prove Merkle storiche (`eth_getProof` sui vecchi blocchi). Gli indicizzatori DeFi e altri carichi di lavoro che richiedono molte prove necessitavano ancora dell'archiviazione basata su hash legacy. La versione 1.17.0, rilasciata a febbraio 2026, ha aggiunto il supporto per le prove alla modalità basata su percorsi in alcune configurazioni: consultare le note di rilascio per la propria versione esatta. I tipici operatori di archiviazione sono gli esploratori di blocchi, i team forensi e le società di analisi professionali. La maggior parte delle persone che leggono questa guida non ne avrà mai bisogno.

Una nota a margine. La modalità client leggero, il vecchio flag `--syncmode "light"`, è stata deprecata e non è più supportata sulla rete principale. Se un tutorial del 2026 vi dice di avviare Geth in modalità leggera, il tutorial è obsoleto.

Installa Geth su Ubuntu, macOS e Windows

La procedura di installazione è breve. Scegli la piattaforma su cui intendi effettivamente eseguire il programma, non quella presente sul tuo portatile.

Linux / Ubuntu (il sistema operativo di uso comune)

La maggior parte dei nodi Geth in produzione risiede su Ubuntu. Il team di Ethereum gestisce un PPA e con tre comandi tramite il gestore di pacchetti di Ubuntu è possibile ottenere un eseguibile funzionante:

```

sudo add-apt-repository -y ppa:ethereum/ethereum

sudo apt-get update

sudo apt-get install ethereum

```

Esegui `geth version` per confermare. Il PPA tiene traccia dell'ultima versione stabile. In produzione, di solito si blocca una build funzionante con un comando come `apt-get install ethereum=1.17.2-...` e si aggiorna con una frequenza più regolare rispetto a "quando apt ne ha voglia".

macOS (adatto agli sviluppatori)

Su macOS, Homebrew si occupa di tutto. Bastano due righe:

```

brew tap ethereum/ethereum

brew install ethereum

```

I Mac sono ottimi per gli esperimenti sulle testnet e lo sviluppo di dApp. Tuttavia, quasi nessuno esegue un validatore sulla mainnet su un Mac. La gestione dell'alimentazione è troppo aggressiva e macOS metterà tranquillamente in standby il nodo beacon nel momento sbagliato.

Windows

Sono disponibili programmi di installazione `.exe` e archivi `.zip` su geth.ethereum.org e sulla pagina delle release del progetto su GitHub. Avvia il programma di installazione, lascia che modifichi la tua variabile PATH, quindi apri il prompt dei comandi o PowerShell ed esegui `geth version`. Dovrebbe rispondere.

Windows Server può ospitare un nodo Geth autonomo perfettamente funzionante. Gli stack di validatori tendono a preferire Linux perché i client di consenso vengono distribuiti principalmente con Linux, ma è possibile combinare sistemi operativi diversi. Il resto di questa guida utilizza lo stile della shell Linux per i comandi. La traduzione in PowerShell è principalmente una questione di separatori di percorso e di un diverso modo di gestire le continuazioni di riga.

Docker

Il comando `docker pull ethereum/client-go:stable` crea un container pulito. Docker è di gran lunga il modo più semplice per testare una nuova versione di Geth senza compromettere il sistema host. È anche una valida soluzione di produzione se il team è già abituato ai container. Un avvertimento: il volume Docker che contiene i dati della blockchain deve essere su un'unità NVMe. Posizionarlo su un normale volume EBS, un datastore su disco rigido o un volume Docker Desktop su Mac riprodurrà tutti i problemi di "sincronizzazione bloccata" di cui si parla su Reddit.

Costruire dalla sorgente

Per compilare da sorgente è necessario Go 1.23 o versioni successive, oltre a un compilatore C. `make geth` compila solo Node.js. `make all` fornisce la suite completa di utilità: geth, clef, abigen, evm, devp2p, rlpdump. Utilizzate le compilazioni da sorgente quando desiderate una versione non ancora pacchettizzata o quando avete una patch privata che non volete mantenere come fork.

Esecuzione di Geth: First Sync e della console JSON-RPC

Binario installato, segreto JWT generato, client di consenso pronto. Il primo comando su un server della rete principale è più o meno questo:

```

getth \

--mainnet \

--datadir /var/lib/geth \

--syncmode snap \

--http \

--http.addr 127.0.0.1 \

--http.port 8545 \

--http.api eth,net,web3 \

--authrpc.addr 127.0.0.1 \

--authrpc.port 8551 \

--authrpc.jwtsecret /etc/geth/jwt.hex \

--authrpc.vhosts localhost

```

Tre porte svolgono questo compito. La 30303 su TCP e UDP rappresenta la tua linea peer-to-peer con il resto di Ethereum. La 8545 è la porta HTTP-RPC attraverso cui transitano il tuo wallet e i tuoi script. La 8551 è l'API Engine, raggiungibile solo dal tuo client di consenso e protetta dal segreto JWT.

Per interagire con il nodo in esecuzione, collega la console Geth. (Si tratta di una console JavaScript collegata alle API del nodo.) Apri una seconda shell:

```

geth attach http://127.0.0.1:8545

```

Ora ogni metodo JSON-RPC è una chiamata JavaScript. `eth.blockNumber`. `net.peerCount` (una trentina è un buon valore sulla rete principale). `eth.syncing` restituisce `false` una volta che il nodo si è sincronizzato. Vuoi un saldo? `web3.fromWei(eth.getBalance('0x...'), 'ether')`. Questa è tutta la superficie interattiva.

Poi c'è il file di log. Controllalo. La riga che devi vedere è "Imported new chain segment". Significa che Geth ha preso il controllo e sta tenendo il passo, elaborando ogni nuovo elenco di transazioni dalla rete blockchain di Ethereum man mano che vengono inviate. Se nei log compare solo "Looking for peers" e nient'altro, il firewall sta bloccando le transazioni P2P in entrata. Apri la porta 30303 su TCP e UDP, riavvia Geth e riprova. Nella maggior parte dei casi, questa è la soluzione.

Per l'automazione, ogni libreria Ethereum degna di nota utilizza JSON-RPC su HTTP, oppure su WebSocket se si specifica anche l'opzione `--ws`. ethers.js. web3.js. viem. Il client Go. Il client Python. Tutti trattano il nodo Geth locale esattamente come Infura: basta indirizzarli a `http://127.0.0.1:8545` e il gioco è fatto. Il codice rimane lo stesso. L'unica cosa che cambia è chi risponde alla chiamata.

Utilizzo di Geth: Conti, Clef e Transazioni

Geth include ancora un gestore di account, ma la raccomandazione moderna è di separare la firma dal nodo eseguendo Clef. Clef è un piccolo programma separato che gestisce le chiavi e richiede una conferma esplicita ogni volta che qualcuno tenta di utilizzarle.

La creazione di un account tramite Clef avviene in questo modo:

```

clef newaccount --keystore /var/lib/geth/keystore

```

Clef richiede una password di almeno dieci caratteri. Crea un file keystore crittografato e ti restituisce un indirizzo. Tale indirizzo è un account di proprietà esterna (EOA), dello stesso tipo di un portafoglio hardware o di MetaMask. Niente di particolare.

Per far sì che Geth utilizzi Clef, è necessario puntare il nodo al socket IPC di Clef: `--signer=/path/to/clef.ipc`. Da quel momento in poi, ogni richiesta di transazione, sia che provenga dalla console di Geth o da una dApp che utilizza l'API JSON-RPC, dovrà essere approvata dal terminale Clef. Questo è il modello che il team di Geth raccomanda per il 2026. Le chiavi risiedono al di fuori del nodo. Il nodo, di per sé, non può spendere un singolo wei.

Un trasferimento dalla console si presenta in questo modo:

```

eth.sendTransaction({

from: '0xca57f3b40b42fcce3c37b8d18adbca5260ca72ec',

to: '0xce8dba5e4157c2b284d8853afeeea259344c1653',

value: web3.toWei(0.1, 'ether')

});

```

Clef compare. Confermi. La transazione entra nel mempool e pochi secondi dopo è inclusa in un blocco. Dietro quella singola riga, Geth ha eseguito la ricerca del nonce, la stima della commissione, il passaggio della firma a Clef, la trasmissione e il controllo di inclusione. Lo stesso ciclo si ripete in ogni dApp.

Per operazioni più complesse, lo stesso endpoint JSON-RPC accetta invii di transazioni, sottoscrizioni a eventi, chiamate a funzioni di visualizzazione e tracce. Dal punto di vista di una libreria, la tua istanza Geth locale è indistinguibile da un nodo ospitato, tranne per il fatto che è più veloce, gratuita per ogni chiamata ed è di tua proprietà.

Configurazione del validatore: metti in staking Ether e guadagna ricompense

Una volta che il nodo Geth è sincronizzato e associato a un client di consenso, l'aggiunta di un validatore è principalmente una questione di configurazione. Non è necessario installare un nuovo nodo. Il livello di esecuzione (Geth) continua a svolgere il suo lavoro. Il client di consenso assume il ruolo di validatore: firma le attestazioni a ogni epoca e, quando il protocollo seleziona il validatore, chiede a Geth di assemblare il contenuto del blocco.

Per avviare il sistema sono necessari tre passaggi fondamentali. Il primo consiste nel deposito di 32 ether. Si generano le chiavi del validatore tramite la CLI ufficiale per i depositi, si invia la transazione di deposito al contratto sulla rete principale e si attende l'attivazione. Il secondo passaggio riguarda il processo client del validatore. Questo processo viene eseguito parallelamente al nodo beacon, detiene la chiave di firma e firma le attestazioni secondo una pianificazione prestabilita. Il terzo passaggio riguarda MEV-Boost o una configurazione relay, qualora si desiderino ricompense per l'ordinamento delle transazioni oltre alla ricompensa base. Geth non esegue direttamente il validatore, bensì il client di consenso. Geth è l'endpoint di esecuzione che crea il payload effettivo del blocco quando arriva il turno del validatore.

Quotidianamente, i validatori si preoccupano di tre numeri: attestazioni mancate, tempo di attività della sincronizzazione e pressione del disco. Le attestazioni mancate sono quasi sempre riconducibili a un nodo che è rimasto indietro rispetto al nodo principale, il che a sua volta è quasi sempre riconducibile a problemi di I/O del disco o alla perdita di peer. La pressione del disco su Geth è la causa classica. Se si scende al di sotto delle specifiche NVMe raccomandate, l'efficacia delle attestazioni diminuisce. E con essa, anche le ricompense.

La maggior parte degli utenti che praticano lo staking da casa utilizza un mini-PC dedicato: un Intel NUC, un Beelink o un PC assemblato con processore Ryzen. L'hardware ha un costo una tantum compreso tra 800 e 2.000 dollari. Elettricità e internet aggiungono altri 10-20 dollari al mese. Secondo le stime di Coin Bureau per il 2026, un validatore Hetzner professionale costa tra i 30 e i 40 dollari al mese, un nodo AWS base completo costa meno di 100 dollari e un nodo di archivio AWS si aggira intorno ai 1.500 dollari. Lo staking in solitaria offre un rendimento annuo di circa il 4% sulla ricompensa base, che sale al 5-6% con MEV-Boost; con hardware domestico, il punto di pareggio si raggiunge in circa 4-6 mesi al prezzo attuale di Ether. Alla fine del 2025, la rete contava circa 1,06 milioni di validatori attivi, che detenevano tra i 35 e i 37 milioni di ETH (29-31% dell'offerta totale). Lido da solo controlla il 27,7% del totale in staking. Coinbase, l'8,4%. Ogni ulteriore validatore indipendente sposta silenziosamente tale concentrazione nella direzione opposta, ed è questo uno dei motivi principali per cui lo staking in solitaria è ancora una pratica diffusa.

Testnet vs Mainnet: dove eseguire un nodo Ethereum

Non iniziare sulla rete principale. Gli errori sono a buon mercato su una rete di test, e non c'è niente di più economico che niente. Geth gestisce ogni rete supportata con un singolo flag.

Le due testnet di Ethereum di cui dovresti preoccuparti nel 2026 sono Holesky, la testnet di lunga data incentrata sui validatori, e Sepolia, quella più leggera e focalizzata sulle applicazioni. Vuoi un nodo Geth per Sepolia? Sostituisci `--mainnet` con `--sepolia`. Per Holesky? `--holesky`. La directory dei tuoi dati deve essere un percorso separato dalla directory `chaindata` della tua mainnet. Se riutilizzi la stessa cartella, Geth si rifiuta di avviarsi perché l'ID della catena non corrisponde, un tipo di messaggio di errore che richiede trenta secondi per essere corretto e un'ora per essere individuato.

L'ether sulla testnet è gratuito. Faucet come Paradigm Multifaucet e il faucet di Sepolia all'indirizzo faucet.sepolia.dev distribuiscono una quantità di ETH di Sepolia sufficiente per implementare contratti, eseguire test di integrazione e inviare diverse migliaia di transazioni. L'"ether" è fittizio. Tutto il resto è reale: l'EVM si comporta allo stesso modo, l'API JSON-RPC è la stessa, l'accoppiamento con il client di consenso è lo stesso, le difficoltà operative sono le stesse. Eseguite il vostro stack su Sepolia per una settimana prima di indirizzare qualsiasi cosa verso la mainnet.

Le vecchie reti di test non esistono più. Ropsten, Rinkeby, Kovan, Goerli: tutte dismesse. Se un tutorial ti dice ancora di avviare Geth con `--ropsten`, si tratta di una versione precedente alla fusione e dovresti chiudere la scheda.

Per un ambiente veramente privato, gestisci la tua rete. La modalità `--dev` di Geth avvia una catena a nodo singolo in pochi secondi, il che è ottimo per i test unitari. Per reti private multi-macchina, crea un file `genesis.json` personalizzato, condividilo tra le macchine e avvia ogni processo Geth con `--datadir` puntando a una nuova cartella chaindata. Il framework Kurtosis racchiude tutto questo in un unico comando, se preferisci non effettuare la configurazione manualmente.

Problemi comuni dei nodi Geth e relative soluzioni

La maggior parte degli incidenti che coinvolgono i Geth rientrano in una serie ristretta di schemi. La soluzione è solitamente rapida una volta individuato lo schema.

La sincronizzazione si è bloccata a qualche punto percentuale. Il tuo nodo Geth è online ma non riesce a sincronizzarsi: il numero di peer è troppo basso, la larghezza di banda è satura o il disco non riesce a tenere il passo. Controlla `net.peerCount` nella console. Se è inferiore a quindici, la porta P2P in entrata è bloccata dal firewall. Apri le porte TCP e UDP 30303. Se la porta è integrata, esegui `iostat -xm 5` su Linux durante la sincronizzazione; se l'SSD raggiunge il 100% di utilizzo, il collo di bottiglia è l'I/O e hai bisogno di un'unità di archiviazione più veloce. Nota specifica per la versione: Geth v1.17.1 (3 marzo 2026) è stata rilasciata specificamente per correggere una regressione di snap-sync nella v1.17.0; se sei bloccato su questa versione, l'aggiornamento è la soluzione.

"Rete post-unione, ma nessun client beacon rilevato." Il client di consenso non è in esecuzione, il segreto JWT non corrisponde oppure il client di consenso è puntato alla porta AuthRPC errata. Verificare il percorso JWT, la porta 8551 e che entrambi i processi siano stati avviati con lo stesso file segreto.

Il disco si riempie durante la notte. Snap Sync può causare un picco nell'utilizzo del disco durante la fase iniziale di ripristino dello stato. La pulizia viene eseguita automaticamente in seguito. Se hai iniziato con un SSD da 1 TB, la testina alla fine ti raggiungerà. La soluzione è sempre più spazio, non una pulizia più aggressiva, perché la pulizia di Geth è già ottimizzata. Sposta chaindata su un NVMe più grande e usa rsync.

Geth non si avvia: "database compatibile con questa versione di geth non trovato". Un'esecuzione precedente è stata effettuata su un ID di catena diverso, una versione di Geth precedente o uno stato danneggiato. La cartella `chaindata` non corrisponde. Risincronizzare in una nuova directory dei dati oppure ripristinare la versione precedente di Geth.

Il validatore non registra le attestazioni. Se il nodo Geth legge correttamente ogni nuovo blocco ma il validatore continua a non registrare le attestazioni, controlla prima la pressione del disco, poi la rete e infine la CPU. Lo schema negli strumenti di monitoraggio come Netdata è inequivocabile: il PSI (Pressure Stall Information) del disco raggiunge il 30% o più durante le finestre di attestazione.

Le richieste RPC sono lente. Un client dApp che utilizza intensamente `eth_getLogs` o `debug_traceTransaction` può saturare la CPU di Geth. Sposta quel traffico su un nodo separato oppure utilizza `--rpc.gascap` e `--rpc.txfeecap` per limitare le chiamate che richiedono un elevato utilizzo delle risorse.

Un'ultima abitudine. Monitorate costantemente i log durante la prima settimana per assicurarvi che Geth funzioni correttamente anche sotto carico reale. Strumenti come Netdata, Prometheus + Grafana, o semplicemente `journalctl -fu geth`, rendono evidenti i primi malfunzionamenti. Entro la seconda settimana, sarà sufficiente ricevere avvisi in caso di attestazioni mancate e di riempimento del disco.

Geth contro altri client Ethereum: compromessi

Geth è la prima scelta predefinita. Non è l'unica, e la risposta alla domanda "dovrei cambiare?" dipende dalle tue esigenze.

La motivazione principale a favore della scelta di un client diverso da Geth è la diversificazione dei client. Se un singolo client di esecuzione supera la maggioranza qualificata dei due terzi sulla mainnet e rilascia un aggiornamento difettoso, i validatori su quel client rischiano di subire penalità. Suddividere la flotta di validatori su due client dimezza questo rischio. Per un singolo staker domestico, il calcolo è più semplice: scegliete il client che potete mantenere attivo, gestitelo correttamente e cambiate solo in caso di necessità specifiche. L'architettura dei nodi è simile per tutti, quindi il passaggio in un secondo momento è più semplice di quanto sembri. Erigon e Reth, in particolare, sono ormai sufficientemente maturi da poter essere considerati client principali, non più semplici curiosità.

Marco Lucchetti

Marco Lucchetti is a senior content strategist and blockchain analyst at Plisio. With over 7 years of experience in cryptocurrency research, DeFi protocols, and payment technologies, Marco specializes in creating clear, data-driven content for a global crypto audience. His work focuses on transaction tracing, crypto compliance, and the future of blockchain infrastructure.