Come configurare un nodo Binance Smart Chain (BSC)

BNB Smart Chain — ancora molto cercata come Binance Smart Chain, il suo nome fino a febbraio 2022 — è una chain EVM che produce un blocco ogni 0,45 secondi dal hard fork Fermi di gennaio 2026, dopo che Maxwell aveva già dimezzato l’intervallo a 0,75 secondi a metà 2025. Questa velocità è piacevole per gli utenti ed esigente per gli operatori di nodi: un full node BSC richiede hardware di livello server e la giusta strategia di sincronizzazione, e sbagliare uno dei due significa un nodo che non raggiunge mai la testa della chain. Questa guida è la versione copia-incolla dove la documentazione ufficiale si ferma: setup basato su snapshot con il fork geth di bnb-chain, un’unità systemd, note di sicurezza per i nodi RPC, calcolo dei tempi di sincronizzazione e dei costi, oltre a uno sguardo onesto su quando non dovreste eseguirne uno affatto.

Cos’è un nodo BSC, e di quale tipo avete bisogno?

Un nodo BSC esegue il client della chain, valida i blocchi e vi fornisce un endpoint JSON-RPC locale con la stessa interfaccia di Ethereum: eth_blockNumber, eth_call, eth_sendRawTransaction e il resto. Nella pratica contano quattro varianti.

Un full node mantiene lo stato recente e serve RPC — il default, e l’argomento di questa guida. Un fast node è un full node avviato con --tries-verify-mode none; la documentazione ufficiale lo consiglia per i workload RPC dove la velocità di import conta più della verifica rigorosa del trie di stato. Un archive node memorizza ogni stato storico, richiede spazio disco nell’ordine dei terabyte a due cifre e ha senso solo per indicizzazione e analytics. Un validator produce blocchi, il che richiede di essere eletti nel piccolo insieme votato con BNB in staking — un argomento a sé, oltre lo scopo di una guida di setup.

E un light node? Il fork geth ha ereditato il codice light-client, ma in pratica quasi nulla su BSC serve i light peer, quindi considerate il “light node BSC” non disponibile. Se un full node pruned è più di quanto vi serve, è esattamente il caso d’uso di un’API — vedi l’ultima sezione.

La stessa scelta in forma di tabella, con i numeri di disco a metà 2026:

BSC e Geth: una codebase, due chain

Il client di BSC è un fork di go-ethereum, mantenuto su github.com/bnb-chain/bsc, e il binario si chiama letteralmente geth. Parla lo stesso JSON-RPC, accetta gran parte degli stessi flag, e aggiunge le specificità di BSC: il consenso proof-of-staked-authority Parlia (un solo processo è l’intero nodo — nessun client di consenso separato come su Ethereum post-merge), più flag come --tries-verify-mode. Ne derivano due conseguenze pratiche. Il vostro tooling Ethereum funziona invariato contro un nodo BSC. E dovete eseguire la build bnb-chain — il Geth upstream non può sincronizzare BSC, che è l’errore da principianti più comune con “bsc geth”.

Requisiti hardware per un nodo BSC

La base viene dal README di bnb-chain/bsc, adattata alla crescita dei dati fino al 2026:

La riga che manda in crisi la maggior parte dei setup sono le IOPS, non la capacità. Con blocchi da 0,45 secondi, il nodo scrive costantemente, e lo storage a blocchi cloud con IOPS di default resta indietro rispetto alla testa della chain e non recupera mai. Il riferimento del README è AWS gp3 con 8.000 IOPS provisionate e latenza di lettura sotto il millisecondo (classe di istanza m5zn.3xlarge su AWS, c2-standard-16 su Google Cloud); un disco NVMe locale in un server dedicato supera questa soglia con margine.

Passo dopo passo: full node BSC dallo snapshot ufficiale

Sincronizzare dal genesis è possibile ed è una cattiva idea. La documentazione stessa lo sconsiglia — suggerisce hardware da 40k+ IOPS per il tentativo, e comunque richiede settimane. Il percorso supportato: scaricare lo snapshot dei dati della chain, avviare il nodo su di esso, lasciarlo recuperare il ritardo. I comandi presuppongono Ubuntu 24.04.

1. Preparare il server

sudo apt update && sudo apt install -y aria2 lz4 unzip jq
sudo useradd --no-create-home --shell /usr/sbin/nologin bsc
sudo mkdir -p /var/lib/bsc
sudo chown bsc:bsc /var/lib/bsc
sudo ufw allow 30311 comment 'bsc p2p'

La porta 30311 è la porta peer-to-peer di BSC e l’unica porta blockchain che dovrebbe essere aperta. La porta RPC resta su localhost.

2. Scaricare il binario geth di bnb-chain

cd /tmp
curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest \
  | jq -r '.assets[] | select(.name=="geth_linux") | .browser_download_url' \
  | xargs wget -O geth_linux
chmod +x geth_linux
sudo mv geth_linux /usr/local/bin/geth-bsc
geth-bsc version

Rinominare il binario in geth-bsc previene il classico incidente di avviare un Geth upstream installato dalla distro contro dati BSC.

3. Recuperare config.toml e genesis.json

cd /tmp
curl -s https://api.github.com/repos/bnb-chain/bsc/releases/latest \
  | jq -r '.assets[] | select(.name=="mainnet.zip") | .browser_download_url' \
  | xargs wget -O mainnet.zip
unzip -o mainnet.zip
sudo mv config.toml genesis.json /var/lib/bsc/
sudo chown bsc:bsc /var/lib/bsc/config.toml /var/lib/bsc/genesis.json

Nota: geth-bsc init genesis.json serve solo per la sincronizzazione dal genesis. Con il percorso da snapshot si salta l’init — lo snapshot porta con sé il proprio database.

4. Scaricare ed estrarre lo snapshot

Gli snapshot si trovano su github.com/bnb-chain/bsc-snapshots, il repository ufficiale. A metà 2026 pubblica tre set di dati: lo snapshot pruned, di circa 1,6 TB compresso (solo blocchi recenti — quello giusto per questa guida), lo snapshot completo, di circa 6 TB, e snapshot incrementali che recuperano solo le modifiche rispetto a uno precedente, un’aggiunta dell’era Fermi (BEP-593). La generazione attuale richiede il client v1.7.2 o successivo, requisito già soddisfatto dal download del passo 2. Il repo fornisce anche uno script fetch-snapshot.sh che scarica, controlla il checksum MD5 (flag -c) ed estrae in un solo comando; il percorso manuale sotto mostra cosa succede dietro le quinte. Due modi per portare l’archivio su disco:

cd /var/lib/bsc
# Option A: resumable download, needs space for archive + extracted data
sudo -u bsc aria2c -x8 -s8 -c '<PASTE_SNAPSHOT_URL>'
sudo -u bsc bash -c "lz4 -cd geth.tar.lz4 | tar -x"

# Option B: stream-extract, needs space only once, but no resume
sudo -u bsc bash -c "wget -qO- '<PASTE_SNAPSHOT_URL>' | lz4 -d | tar -x"

aria2c scarica su otto connessioni e riprende dopo le interruzioni (-c) — con il semplice wget, un download multi-terabyte interrotto riparte da zero. Dopo l’estrazione, il database della chain deve trovarsi in /var/lib/bsc/geth/chaindata; il layout dell’archivio è cambiato tra le generazioni di snapshot, quindi spostate se necessario la cartella geth interna in quel punto. Verificate prima di estrarre: confrontate l’MD5 dalla pagina dello snapshot, oppure lasciate che se ne occupi fetch-snapshot.sh -c — un archivio da un terabyte con un bit alterato vi costa una giornata. L’opzione A richiede spazio per l’archivio e i dati estratti contemporaneamente, circa 2 TB di margine per il set pruned, ed è questa la vera ragione dietro la raccomandazione di un disco da 4 TB.

5. Unità systemd

Create /etc/systemd/system/bsc.service:

[Unit]
Description=BSC full node (bnb-chain geth fork)
After=network-online.target
Wants=network-online.target

[Service]
User=bsc
Group=bsc
Type=simple
Restart=always
RestartSec=5
TimeoutStopSec=600
LimitNOFILE=65536
ExecStart=/usr/local/bin/geth-bsc \
  --config /var/lib/bsc/config.toml \
  --datadir /var/lib/bsc \
  --cache 8000 \
  --tries-verify-mode none \
  --history.transactions 0 \
  --rpc.allow-unprotected-txs \
  --http --http.addr 127.0.0.1 --http.port 8545 \
  --http.api eth,net,web3

[Install]
WantedBy=multi-user.target

--tries-verify-mode none è l’interruttore “fast node” della documentazione ufficiale, consigliato per servire RPC quando accettate il compromesso sulla coerenza dello stato. --history.transactions 0 mantiene completo l’indice delle transazioni; guide più vecchie usano per lo stesso scopo il deprecato --txlookuplimit 0. TimeoutStopSec=600 dà al nodo dieci minuti per il flush allo spegnimento — le interruzioni forzate prima o poi corrompono il database.

6. Avviare e verificare

sudo systemctl daemon-reload
sudo systemctl enable --now bsc
journalctl -fu bsc

Un output sano è un flusso costante di righe “Imported new chain segment”. Confrontate la vostra altezza con un explorer pubblico:

curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \
  http://127.0.0.1:8545

Convertite il risultato esadecimale e confrontatelo con bscscan.com. Quando eth_syncing restituisce false e l’altezza corrisponde, il nodo è live.

Mettere in sicurezza un nodo RPC BSC

L’unità sopra collega l’RPC a 127.0.0.1, il che è corretto per un nodo usato solo da software locale. Se altre macchine hanno bisogno di accesso, non aprite la porta 8545 grezza verso internet. Mettete nginx o Caddy davanti, con TLS, un token di autenticazione o un’allowlist di IP, e rate limiting. Mantenete --http.api su eth,net,web3 — non esponete mai admin, debug o txpool su un nodo raggiungibile. Gli endpoint BSC pubblici non autenticati vengono scoperti e bersagliati entro pochi giorni, e chiamate eth_getLogs senza restrizioni possono mettere in ginocchio anche hardware potente. La porta P2P 30311 resta l’unica porta blockchain aperta. Vale la pena citare una differenza rispetto a Ethereum: qui non c’è engine API né segreto JWT, perché Parlia non richiede un client di consenso separato — il firewall e il binding a localhost sono l’intero perimetro, quindi devono essere corretti.

Monitoraggio e controlli di salute

Un nodo BSC fallisce in un modo tipico: il processo continua a girare mentre il nodo resta indietro rispetto alla testa. I controlli di uptime a livello di processo se lo perdono completamente, quindi controllate invece lo stato di sincronizzazione e l’altezza.

# false = at the head; a sync object = still catching up
curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' \
  http://127.0.0.1:8545

# peer count as hex
curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}' \
  http://127.0.0.1:8545

Il controllo più rigoroso confronta il vostro eth_blockNumber con una seconda fonte — un endpoint pubblico o un explorer — ogni pochi minuti, e allerta se il divario cresce. Calibrate la soglia sul ritmo di BSC: 400 blocchi sembrano tanti e sono tre minuti di tempo chain con blocchi da 0,45 secondi. Soglie copiate dal tooling Ethereum sono qui decisamente troppo permissive.

Il fork eredita lo stack di metriche di Geth. Iniziate con --metrics (endpoint Prometheus sulla porta 6060, tenetelo su localhost), e le dashboard Grafana standard di Geth funzionano in gran parte senza modifiche. Prima di qualsiasi dashboard, impostate due alert: uso disco sopra l’85% e altezza di blocco locale ferma per cinque minuti. Un journalctl -u bsc --since -24h | grep -ci error giornaliero in una mail cron completa il quadro — conteggi di errore in aumento anticipano la maggior parte dei fallimenti di giorni.

Tempo di sincronizzazione, e perché gli snapshot restano utili

Aritmetica invece di promesse: lo snapshot pruned da 1,6 TB, a 100 MB/s sostenuti, richiede circa 4,5 ore per il download, a 50 MB/s circa 9. L’estrazione è vincolata dal disco e aggiunge qualche ora su NVMe. Lo snapshot è indietro di uno o due giorni rispetto alla testa della chain; un nodo sano importa più volte più veloce del tempo reale, quindi recuperare il ritardo costa ore, non giorni. In totale, pianificate una giornata lavorativa. La sincronizzazione dal genesis, per contro, gira per settimane su hardware estremo — motivo per cui la raccomandazione ufficiale è lo snapshot, punto.

Crescita dello stato e pruning

Il database continua a crescere dopo il primo giorno — stato con ogni nuovo contratto e account, dati di blocco al ritmo dettato dai blocchi da 0,45 secondi. La crescita esatta dipende dall’attività di rete; invece di fidarvi di un numero fisso, eseguite du -sh /var/lib/bsc/geth/chaindata settimanalmente e costruite la vostra linea di tendenza. Lo schema da aspettarsi: centinaia di GB a trimestre, non all’anno.

Tre strumenti tengono la dimensione sotto controllo. geth-bsc snapshot prune-state è il pruning offline integrato: scarta i nodi di stato a cui nulla fa più riferimento, richiede molte ore su un database multi-terabyte, e nel frattempo il nodo non serve nulla. Wipe-and-restore è l’alternativa preferita da molti operatori: ogni pochi mesi, eliminare il datadir e ripristinare lo snapshot pruned più recente. Il downtime totale è spesso inferiore rispetto al pruning, e in più si ottiene un database appena compattato.

Il terzo strumento è arrivato con Fermi: gli snapshot incrementali (BEP-593). Invece di riscaricare 1,6 TB a ogni refresh, recuperate solo ciò che è cambiato dalla generazione di snapshot che già avete, trasformando il refresh periodico da un job notturno a una questione di ore. Il README di bsc-snapshots documenta questo workflow accanto agli archivi classici.

Erigon su BSC — e il suo successore

Per anni la risposta alle esigenze di archive su BSC è stata bsc-erigon, il porting di Erigon fatto da NodeReal: una sincronizzazione archive completa da zero in circa tre giorni, memorizzata in circa 4,3 TB dove il fork geth ne richiede decine. Quel capitolo si è chiuso. La manutenzione è terminata con il 2025, e il repository node-real/bsc-erigon è stato archiviato nell’aprile 2026 — sola lettura, nessuna correzione, nessun supporto per fork futuri. NodeReal indirizza gli operatori verso Reth-BSC, il successore basato su Rust, come client archive consigliato per il futuro.

Cosa significa in pratica a metà 2026: per il nodo RPC pruned di questa guida, il fork geth ufficiale resta il riferimento e la scelta più sicura. Per i workload archive, valutate prima Reth-BSC, e considerate le macchine bsc-erigon esistenti come migrazioni in sospeso — un client non mantenuto perde il prossimo hard fork alla scadenza prevista.

Quanto costa un nodo BSC

Consideratelo un modo per calcolare, non un listino prezzi. La classe 16 core / 64 GB / 4 TB NVMe è territorio da server dedicato — nessun livello VPS onesto lo copre. Presso host europei, macchine con queste specifiche si collocano, come ordine di grandezza, nella fascia bassa-media delle centinaia di euro al mese. Le stesse specifiche costruite da istanze cloud con 8k IOPS provisionate (il riferimento AWS del README) tipicamente atterrano più in alto, spesso di un fattore due o più, perché le IOPS provisionate vengono fatturate separatamente.

Poi aggiungete le vostre ore: setup iniziale di una giornata lavorativa con questa guida, più aggiornamenti per hard fork e refresh degli snapshot per poche ore al mese. Moltiplicate per la vostra tariffa oraria. Per la maggior parte dei team, la voce manodopera finisce per superare quella di hosting — utile saperlo prima di impegnarsi.

Manutenzione: hard fork e aggiornamenti

BSC fa hard fork a un ritmo che sorprende gli operatori Ethereum. Solo il 2025 ha portato Lorentz e Maxwell, ciascuno dimezzando l’intervallo dei blocchi; Fermi è seguito il 14 gennaio 2026 e ha portato i blocchi da 0,75 a 0,45 secondi, aggiungendo al contempo gli snapshot incrementali e rafforzando la fast finality. Ogni fork ha una versione client minima — v1.6.4 per Fermi — e un nodo sotto quella versione si blocca al blocco del fork con errori di consenso. A metà 2026 la linea di release è a v1.7.x, e gli snapshot attuali presuppongono almeno la v1.7.2.

Iscrivetevi quindi al feed delle release di bnb-chain/bsc su GitHub e trattate gli aggiornamenti come routine anziché come eventi. La procedura è breve: scaricare il nuovo geth_linux, verificarlo, fermare il servizio, sostituire /usr/local/bin/geth-bsc, riavviare — il database viene mantenuto. Le release note segnalano le modifiche di configurazione, e BSC rinomina i flag più spesso del Geth upstream, quindi scorretele prima del riavvio, non dopo. Preventivate un quarto d’ora per release, e aspettatevi un fork ogni pochi mesi.

Per i setup di sviluppo, è disponibile una rete privata locale tramite il toolkit BSC-Deploy anziché eseguire nodi mainnet.

Risoluzione dei problemi

Il nodo importa blocchi ma continua a restare indietro rispetto alla testa

Quasi sempre le IOPS del disco. Fate benchmark con fio e confrontate con il riferimento di 8k IOPS; lo storage di rete con IOPS di default è il colpevole abituale. Confermate che --tries-verify-mode none sia impostato. Se l’hardware è sotto la tabella dei requisiti, nessun flag colmerà il divario.

Errori “missing trie node”, o il nodo riparte a sincronizzare dal blocco 0 dopo un ripristino da snapshot

Il layout del datadir è sbagliato. Il database della chain deve trovarsi in <datadir>/geth/chaindata — se il log mostra “Writing custom genesis block”, geth ha trovato un datadir vuoto ed è ripartito da zero. Fermate il servizio, spostate la cartella geth estratta nel posto giusto, riavviate.

Il conteggio dei peer resta vicino allo zero

Verificate che la porta 30311 sia aperta e inoltrata. Un config.toml obsoleto è il secondo sospettato: le liste di bootstrap e nodi statici cambiano nel tempo, quindi riscaricate mainnet.zip dall’ultima release. Su connessioni domestiche, controllate anche il NAT.

lz4 segnala “Decoding error” durante l’estrazione

L’archivio è incompleto. Riprendete il download con aria2c -c e confrontate la dimensione del file con quella indicata sulla pagina dello snapshot prima di estrarre di nuovo. Ricordate che l’opzione A richiede spazio libero per l’archivio e i dati estratti contemporaneamente.

L’OOM killer termina il nodo

journalctl -k | grep -i oom risolve il dubbio. L’unità imposta --cache 8000, e l’uso reale della memoria durante il recupero supera ampiamente il valore della cache — nessun problema con i 64 GB consigliati, sì su hardware ridotto. Abbassate --cache prima di abbassare qualsiasi altra cosa, tenete lo swap attivo come cuscinetto anti-crash, e ricordate che un nodo terminato per OOM non fa il flush di nulla: il prossimo avvio potrebbe presentarvi il caso “missing trie node” sopra descritto.

Il disco si riempie

Prima df -h, poi du -h --max-depth=2 /var/lib/bsc per trovare la crescita. Gli archivi di snapshot dimenticati sono la scoperta più comune — il solo .tar.lz4 pruned pesa circa 1,6 TB, e l’opzione A lo lascia indietro se saltate la pulizia. Se il problema è chaindata stesso, aggiornate dall’ultimo snapshot pruned o eseguite un pruning offline (vedi la sezione sulla crescita dello stato). Sulla curva di crescita di BSC, un disco pieno è un errore di pianificazione, non sfortuna; l’alert all’85% della sezione monitoraggio esiste per darvi la settimana di cui avete bisogno.

Eseguire il proprio nodo — o usare un’API?

Un confronto onesto, dato che Chaingateway vende l’alternativa.

Eseguite il nodo quando consumate JSON-RPC grezzo con volumi pesanti e sostenuti — indicizzazione, backtesting, scansione di log su milioni di blocchi — o quando nessuna terza parte deve trovarsi tra voi e la chain. Un server dedicato è un costo fisso con richieste illimitate, e oltre un certo volume di chiamate batte qualsiasi piano a consumo. Il break-even arriva più rapidamente su BSC che sulla maggior parte delle chain, proprio perché la barriera hardware è alta ma piatta.

Usate un’API quando il nodo sarebbe solo un tubo per i pagamenti. Un full node BSC sincronizzato vi dà eth_sendRawTransaction e log; tutto ciò di cui un sistema di pagamento ha davvero bisogno — indirizzi di deposito per cliente, rilevamento dei trasferimenti BEP-20 in entrata, webhook firmati, storage delle chiavi, retry — è software che dovreste costruire sopra e mantenere in funzione. Quelle ore di ingegneria, alle tariffe della sezione sui costi, superano di gran lunga la bolletta del server.

L’API BNB Smart Chain di Chaingateway copre questo livello come REST: importare indirizzi (POST /api/v2/bsc/addresses/import), inviare token BEP-20 (POST /api/v2/bsc/transactions/bep20), e ricevere webhook di deposito firmati HMAC — GET /api/v2/bsc/webhooks/notifications/failed elenca le consegne fallite, e ciascuna può essere reinviata tramite l’endpoint di retry. Il break-even in una frase: server dedicato più le vostre ore di costruzione e gestione, contro un piano su /it/pricing/. Per i flussi di pagamento, l’API resta più economica ben oltre la scala small-business; per la potenza RPC grezza, il nodo vince presto. Il quickstart e la guida ai webhook vi portano a un primo test in pochi minuti, e la prova di 7 giorni non richiede KYC (registrazione).

Gestite anche altre chain? Vedete le guide di setup per Ethereum e TRON.