Come configurare un nodo TRON (il metodo pragmatico)

Chi cerca «tron node» vuole quasi sempre una cosa sola: accesso diretto alla chain su cui transita una quota enorme dell’USDT mondiale. La documentazione ufficiale risponde con una toolchain Java — installare JDK 1.8, clonare java-tron, compilare con Gradle, regolare la JVM. Questa guida prende invece la via pragmatica: il FullNode.jar già pronto dalla pagina delle release, più uno snapshot Lite FullNode, che riduce il fabbisogno di disco da oltre 3 TB a poche centinaia di GB. Docker segue come alternativa senza Java, poi i tempi di sync, un calcolo dei costi e l’onesto punto di pareggio rispetto a un’API.

Cos’è un nodo TRON?

Un nodo TRON esegue java-tron, il client di riferimento, e vi collega alla rete che valida le transazioni ogni 3 secondi. Espone due API per le applicazioni: HTTP sulla porta 8090 e gRPC sulla porta 50051. Attraverso queste potete deployare e chiamare contratti, trasferire TRX e token, e interrogare lo stato della chain — il nodo è il punto d’ingresso per tutto ciò che costruite su TRON.

Il client si muove più in fretta di quanto suggerisca la sua toolchain JDK 8: GreatVoyage-v4.8.0 (Kant) è uscita a febbraio 2026, e la release attuale è v4.8.1.1 (Hypatia, giugno 2026). Quasi ogni release porta l’etichetta «mandatory upgrade», il che condiziona la routine di manutenzione più avanti in questa guida.

Ruoli dei nodi, in ordine di rilevanza. Un FullNode valida e inoltra i blocchi e risponde alle query API; in quasi tutti i casi è quello che vi serve. Un nodo witness produce blocchi, riservato ai 27 super rappresentanti eletti dai voti TRX — per tutti gli altri, il flag --witness non fa nulla di utile. Sull’asse dello storage esistono due varianti: un FullNode standard porta lo storico completo delle transazioni — circa 3 TB a metà 2026 e in crescita; gli snapshot ufficiali di marzo 2026 pesano 2,9–3,1 TB a seconda della variante — mentre un Lite FullNode parte da uno snapshot di solo stato dell’ordine di 100 GB.

Il Lite FullNode copre tutto ciò che serve a un backend di pagamento: stato attuale, nuovi blocchi, broadcast delle transazioni, monitoraggio dei depositi. Ciò che non può fare è rispondere a domande sullo storico precedente al suo snapshot — interrogare una vecchia transazione per ID fallirà. Explorer e piattaforme di analytics hanno bisogno dello storico completo. La maggior parte delle integrazioni no.

I tre ruoli a confronto, con cifre di metà 2026:

Hardware: FullNode vs Lite FullNode

Le righe CPU e RAM ampliano la raccomandazione ufficiale (16 core, 32 GB, «2,5 TB+» — scritta quando la chain era più piccola). La RAM conta doppio su TRON: una volta per l’heap della JVM e una volta per la cache file del sistema operativo, motivo per cui una macchina da 32 GB gira sensibilmente più fluida di una da 16 GB, anche per un nodo Lite.

Passo passo: Lite FullNode con il jar della release

I comandi presuppongono Ubuntu 24.04.

1. Installare Java 8

java-tron punta ancora a JDK 1.8 nel 2026 — una stranezza, ma non negoziabile. Le JVM più recenti falliscono all’avvio.

sudo apt update
sudo apt install -y openjdk-8-jdk
java -version   # deve riportare 1.8.x

2. Creare un utente e le directory

sudo useradd --no-create-home --shell /usr/sbin/nologin tron
sudo mkdir -p /opt/tron /var/lib/tron
sudo chown -R tron:tron /opt/tron /var/lib/tron

3. Scaricare il jar della release e la config mainnet

Nessuna build Gradle necessaria; ogni release di java-tron include un FullNode.jar già pronto:

cd /opt/tron
sudo -u tron wget $(curl -s https://api.github.com/repos/tronprotocol/java-tron/releases/latest \
  | grep browser_download_url | grep FullNode.jar | cut -d '"' -f 4)
sudo -u tron wget https://raw.githubusercontent.com/tronprotocol/tron-deployment/master/main_net_config.conf

Le pagine delle release pubblicano i checksum — eseguite sha256sum FullNode.jar e confrontate prima di lanciare codice che manterrà connessioni di rete aperte per mesi.

4. Ripristinare lo snapshot Lite FullNode

La pagina ufficiale degli snapshot di database sull’hub sviluppatori TRON elenca mirror a Singapore e negli USA che pubblicano archivi freschi ogni giorno, in varianti LevelDB e RocksDB — scegliete LevelDB salvo diversa indicazione della vostra config, perché il motore di database deve corrispondere allo snapshot. Gli archivi Lite seguono l’obiettivo di design di TIP-128, circa il 3% di un database completo; con gli snapshot completi di marzo 2026 a 2,9–3,1 TB (3,6 TB per la variante che aggiunge lo storico dei saldi degli indirizzi), il download Lite si colloca nella fascia bassa delle centinaia di GB. Scegliete il mirror più vicino, copiate il link attuale e:

cd /var/lib/tron
sudo -u tron wget '<PASTE_LITE_SNAPSHOT_URL>'
sudo -u tron tar xzf LiteFullNode_output-directory.tgz

Dopo l’estrazione dovreste avere /var/lib/tron/output-directory con il database. Quella cartella è tutto il trucco del «sync da snapshot» — il nodo parte su quello stato invece di rigiocare anni di blocchi. Se in futuro ripristinate la variante a storico completo, usate la forma in streaming consigliata dai mirror — wget -qO- '<URL>' | tar xz — così l’archivio da 3 TB non finisce mai su disco accanto alla sua copia estratta. Per l’archivio Lite, scaricare e poi estrarre non pone problemi.

5. Unità systemd

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

[Unit]
Description=TRON Lite FullNode (java-tron)
After=network-online.target
Wants=network-online.target

[Service]
User=tron
Group=tron
Type=simple
Restart=always
RestartSec=10
WorkingDirectory=/var/lib/tron
ExecStart=/usr/bin/java -Xmx24g -XX:+UseConcMarkSweepGC \
  -jar /opt/tron/FullNode.jar \
  -c /opt/tron/main_net_config.conf \
  -d /var/lib/tron/output-directory

[Install]
WantedBy=multi-user.target

Due dettagli JVM presi direttamente dalla doc ufficiale: il flag del garbage collector va prima di -jar, non dopo, e -Xmx dovrebbe essere circa l’80% della RAM fisica — 24g è adatto a una macchina da 32 GB; riducetelo su macchine più piccole. systemd ferma il servizio con SIGTERM, che corrisponde all’istruzione kill -15 della doc. Non fate mai kill -9 a un nodo TRON; LevelDB si corrompe, e finirete per ripristinare uno snapshot invece di cenare.

Aprite la porta P2P, tenete private le porte API:

sudo ufw allow 18888 comment 'tron p2p'

Le porte 8090 e 50051 non hanno alcuna autenticazione. Restano chiuse verso internet.

6. Avviare e verificare

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

Quando compaiono i messaggi di blocco, controllate l’altezza:

curl -s http://127.0.0.1:8090/wallet/getnowblock | jq '.block_header.raw_data.number'

Confrontate il numero con l’ultimo blocco su tronscan.org; curl http://127.0.0.1:8090/wallet/getnodeinfo mostra anche il numero di peer e lo stato di sync. Quando la vostra altezza segue quella dell’explorer, il nodo è live.

Una parola sulla produzione di blocchi, dato che la doc ufficiale vi dedica intere pagine: un nodo witness ha senso solo per i 27 super rappresentanti eletti. La meccanica — il flag --witness più la chiave privata del SR nella lista localwitness di main_net_config.conf, oppure la variante keystore-più-password se rifiutate chiavi in chiaro — è documentata a monte. Per tutti gli altri, un semplice FullNode è l’obiettivo giusto.

Docker invece di Java

Le guide TRON più in alto nei ranking saltano tutte Docker, eppure l’immagine ufficiale rende il requisito JDK 8 un problema di qualcun altro:

docker pull tronprotocol/java-tron
docker run -d --name tron --restart unless-stopped \
  -p 127.0.0.1:8090:8090 -p 127.0.0.1:50051:50051 \
  -p 18888:18888 -p 18888:18888/udp \
  -v /var/lib/tron/output-directory:/java-tron/output-directory \
  tronprotocol/java-tron

Il mount del volume riutilizza lo snapshot Lite del passo 4, quindi avviare il container non è una risincronizzazione. Vincolare 8090 e 50051 a 127.0.0.1 mantiene le API private mentre la porta P2P resta raggiungibile. Per impostazioni personalizzate, montate la vostra main_net_config.conf nel container e passate -c come argomento da riga di comando; senza, l’immagine gira con i default di mainnet. Se il vostro host esegue già altri container, questo è il setup più pulito — un solo aggiornamento dell’immagine sostituisce tutto lo stack Java.

Tempo di sync e gestione degli snapshot

Aritmetica, non promesse. Un archivio Lite da 150 GB a 50 MB/s sostenuti si scarica in circa 50 minuti; l’estrazione aggiunge minuti su NVMe. Lo snapshot ha al massimo un giorno, e TRON produce circa 28.800 blocchi al giorno al suo ritmo di 3 secondi — un nodo sano importa molto più veloce del tempo reale, quindi recuperare costa da pochi minuti a poche ore. Totale: un Lite FullNode funzionante in un pomeriggio.

Per un nodo a storico completo lo stesso calcolo fa male: 3 TB+ a 100 MB/s significano oltre 8 ore di download prima ancora che inizi l’estrazione, e un sync dal genesis senza alcuno snapshot dura settimane. Un’asimmetria da conoscere: java-tron include un toolkit che riduce un database FullNode al formato Lite, ma non esiste un percorso da Lite a completo — se prevedete di aver bisogno dello storico completo, partite dallo snapshot completo.

Flussi di eventi e gRPC

Interrogare i blocchi via HTTP funziona, ma java-tron può anche fare push. Il meccanismo di sottoscrizione eventi, attivato nel blocco event.subscribe di main_net_config.conf, pubblica trigger per nuovi blocchi, transazioni, log di contratto ed eventi di contratto — in una coda ZeroMQ integrata per setup leggeri, o tramite plugin verso Kafka o MongoDB per pipeline vere e proprie.

Per il rilevamento dei depositi, questo sostituisce la scansione dei blocchi: sottoscrivere gli eventi di contratto, filtrare per il contratto USDT, confrontare il destinatario con i vostri indirizzi cliente. Un dettaglio decide la correttezza. I trigger semplici scattano non appena arriva un blocco, ma un blocco TRON diventa irreversibile solo quando abbastanza super rappresentanti lo hanno confermato; le varianti di trigger solidified scattano in quel momento, e sono quelle da usare per accreditare i saldi cliente. Un deposito accreditato da un blocco non solidificato può, raramente, sparire in caso di riorganizzazione.

La seconda interfaccia macchina è gRPC sulla porta 50051: le stesse operazioni wallet dell’HTTP, ma tipizzate in protobuf e più veloci per chiamata sotto carico, motivo per cui la maggior parte degli indexer e dei backend di exchange su TRON la usa. Una ripartizione pratica: gRPC per le letture massive del vostro indexer, HTTP per controlli ad hoc come le curl di questa guida, e l’API solidity (porta 8091, se abilitata) per query che devono vedere solo stato irreversibile.

Quanto costa un nodo TRON

Un percorso di calcolo, non un listino prezzi. Un Lite FullNode richiede 8–16 core, 32 GB di RAM e circa 500 GB di NVMe — territorio di un VPS di fascia medio-alta o di un server dedicato entry-level, il che presso host europei significa, come ordine di grandezza, un importo mensile tra decine e poche centinaia di euro. Un nodo a storico completo richiede la classe 3 TB+ NVMe, quindi un vero server dedicato nella fascia bassa-media delle centinaia di euro.

Aggiungete le vostre ore: mezza giornata per il setup seguendo questa guida, aggiornamenti di java-tron ogni pochi mesi, e un occasionale refresh dello snapshot dopo un crash. Il Lite FullNode è il raro caso in cui l’auto-hosting di infrastruttura blockchain è davvero economico — finché i ricavi di nessuno dipendono dal fatto che resti attivo alle 3 di notte.

Monitoraggio e controlli di salute

Tutto ciò che vale la pena controllare sta dietro un singolo endpoint. /wallet/getnodeinfo restituisce versione del client, numero di peer, ultimo blocco e ultimo blocco solidificato in un’unica chiamata:

curl -s http://127.0.0.1:8090/wallet/getnodeinfo | jq \
  '{version: .configNodeInfo.codeVersion, peers: .currentConnectCount,
    head: .block, solidified: .solidityBlock}'

Un nodo sano mostra la head che avanza ogni 3 secondi e il blocco solidificato circa 19–20 blocchi indietro — quella è la profondità di conferma dei due terzi dei 27 SR, circa un minuto di tempo chain. Per gli alert, confrontate la vostra head con tronscan o un secondo nodo ogni pochi minuti e allertate quando il gap supera 40 blocchi, due minuti di tempo chain. systemctl is-active tron più il numero di peer dalla stessa chiamata copre la liveness.

Poiché questo nodo è una JVM, monitorate la memoria separatamente: jstat -gcutil $(pgrep -f FullNode.jar) 10s mostra la pressione di garbage collection, e tempi di full-GC crescenti compaiono in quell’output prima che il nodo inizi a rimanere indietro. Completate con df -h /var/lib/tron a una soglia dell’85% — un nodo Lite cresce lentamente, ma cresce, e lo stesso cron job che vi manda via mail lo stato del sync può portarsi dietro gratis la riga del disco.

Manutenzione e aggiornamenti

Le release di java-tron arrivano ogni pochi mesi, e la maggior parte porta l’etichetta «mandatory upgrade» — Kant (v4.8.0, febbraio 2026), Democritus (v4.8.1) e Hypatia (v4.8.1.1, giugno 2026) tutte e tre. Mandatory significa che la rete attiva i cambi di regole secondo un calendario e le versioni vecchie finiscono dal lato sbagliato del consenso, quindi trattate le release TRON come gli operatori BSC trattano gli hard fork: iscrivetevi al feed delle release di tronprotocol/java-tron e aggiornate entro la finestra annunciata.

L’aggiornamento mantiene il database. Scaricate il nuovo FullNode.jar, confrontate sha256sum con la pagina della release, fermate il servizio (systemd invia SIGTERM, lo shutdown pulito documentato), sostituite il jar in /opt/tron, riavviate. Il nodo rigioca i pochi minuti persi e torna alla head poco dopo.

Due compiti più lenti meritano un posto nella lista. Il database Lite cresce con lo stato più la coda di blocchi accumulata; quando supera la soglia di comfort, ripristinate uno snapshot Lite fresco — la stessa mossa del recovery dopo un crash, ed è il motivo per cui questo setup mantiene il recovery economico. E tenete d’occhio il requisito Java: il build x86 standard punta ancora a JDK 1.8 a metà 2026, mentre la v4.8.1 ha aggiunto build ARM su JDK 17. Il vincolo si sta allentando, ma finché le release notes non dicono altro, un server standard resta su Java 8.

Sicurezza: due porte API, zero autenticazione

Le porte 8090 (HTTP) e 50051 (gRPC) accettano chiunque riesca a raggiungerle — nessun token, nessun account, niente. Un nodo configurato come in questa guida non detiene chiavi private, quindi una porta esposta non fa perdere fondi direttamente, ma regala a sconosciuti un servizio RPC gratuito, e cicli di query intensivi contro gli endpoint dei blocchi consumeranno l’I/O disco della macchina fino a far morire di fame il vostro stesso software. Presupponete che qualunque porta raggiungibile da internet venga già scansionata oggi.

Il firewall del passo 5 è la policy: ufw default deny incoming, poi SSH e 18888 (TCP e UDP) — nient’altro. Quando altre macchine hanno bisogno dell’API, create un tunnel con WireGuard o SSH, oppure mettete nginx davanti con TLS e una allowlist di IP, e anche in quel caso inoltrate solo gli endpoint effettivamente usati. Dopo ogni modifica alla configurazione, controllate cosa ascolta davvero con ss -tlnp: java-tron può aprire porte aggiuntive dal file di configurazione, tra cui l’API solidity sulla 8091, e una porta dimenticata è una porta non protetta.

Un caso speciale. Se mai mettete una chiave witness su una macchina, quella macchina smette di essere infrastruttura e diventa un hot wallet. Separatela dal servizio RPC, e trattate il suo file di configurazione — che può contenere la chiave in chiaro — con la stessa cura che dareste alla chiave stessa.

Risoluzione dei problemi

L’avvio muore immediatamente con un errore di versione Java

UnsupportedClassVersionError o simile significa che la JVM è versione 11 o più recente. Selezionate Java 8 con sudo update-alternatives --config java, oppure aggirate del tutto il problema con l’immagine Docker.

OutOfMemoryError o pause GC di diversi minuti

-Xmx è dimensionato male. Seguite la regola dell’80% della RAM, ma lasciate diversi GB per la cache file del SO, e non co-ospitate altri servizi affamati di memoria. Su una macchina da 16 GB, -Xmx12g è il tetto massimo.

Il nodo si avvia ma resta fermo all’altezza dello snapshot

Nessun peer. Controllate che la porta 18888 sia aperta per TCP e UDP, guardate il numero di peer in /wallet/getnodeinfo, e verificate l’orologio con timedatectl — NTP deve essere attivo. Subito dopo il primo avvio, date alla peer discovery qualche minuto prima di scavare oltre.

Errori di database dopo un crash o un riavvio

Un kill -9, un OOM kill o un’interruzione di corrente corrompe il database. La correzione più rapida è anche quella prevista: cancellare output-directory, ripristinare uno snapshot Lite fresco, riavviare — è questo il beneficio della piccola dimensione dello snapshot. Prevenzione: fermate sempre tramite systemd, e mantenete abbastanza RAM libera perché il kernel non uccida mai Java per OOM.

Il nodo continua a rimanere indietro rispetto alla head

I peer sono connessi, i blocchi arrivano, ma il gap con tronscan cresce. Controllate in quest’ordine: latenza disco (benchmark di lettura casuale con fio — LevelDB su storage di rete o SATA è la causa classica), pressione GC (jstat -gcutil, vedi la sezione monitoraggio), poi contesa CPU da workload co-ospitati. Il ritmo di 3 secondi di TRON perdona brevi stalli; un ritardo che cresce per ore significa che la macchina non tiene il passo, e nessun flag di configurazione ripara hardware sottodimensionato.

Il disco si riempie

df -h, poi du -h --max-depth=2 /var/lib/tron. Il riscontro tipico è un archivio di snapshot dimenticato — il .tgz può rivaleggiare in dimensione con il database estratto. Se output-directory stesso ha superato il volume, ripristinate lo snapshot Lite più recente su un disco più grande; il ripristino azzera al contempo la coda di blocchi accumulata. L’alert all’85% della sezione monitoraggio trasforma questo da un’interruzione a una voce in calendario.

Perché si fa girare un nodo TRON: USDT

La risposta dominante è USDT-TRC20. Commissioni basse e blocchi da 3 secondi hanno reso TRON un binario predefinito per exchange e provider di pagamento, e decine di miliardi di dollari in USDT circolano sulla chain. Con il proprio nodo potete osservare i depositi dei clienti e trasmettere i pagamenti senza intermediari, ed è esattamente per questo che le aziende di pagamento chiedono di nodi TRON molto più spesso che di quasi tutte le altre chain.

La meccanica merita un livello di dettaglio in più, perché condiziona l’architettura. Un deposito USDT non è un trasferimento TRX — è una chiamata allo smart contract USDT, quindi non compare mai nelle semplici query di saldo TRX. Rilevarlo significa decodificare gli eventi di transfer TRC-20 in ogni blocco, oppure sottoscriverli tramite il meccanismo di eventi descritto sopra, e accreditare solo dopo la solidificazione: circa 19 blocchi, un minuto circa. I pagamenti hanno un’economia propria. Un trasferimento USDT consuma energy, e un wallet senza TRX in staking paga quell’energy bruciando TRX — circa 6,4 TRX verso un indirizzo che già detiene USDT e circa 13,4 TRX verso uno vuoto, al prezzo dell’energy di 100 Sun in vigore dalla proposal #104. Le operazioni ad alto volume mettono invece TRX in staking per l’energy, a cui servono i meccanismi di freeze e delega.

Ma sia chiaro cosa vi dà un nodo grezzo: endpoint HTTP e gRPC, nient’altro. Rilevare il deposito USDT di un cliente significa scansionare ogni blocco alla ricerca di eventi di transfer TRC-20 contro la vostra lista di indirizzi, gestendo da soli conferme e retry. E il sistema di commissioni di TRON — bandwidth, energy, freeze di TRX, sponsorizzazione delle commissioni per gli utenti — è un campo di studio a sé; il calcolatore di commissioni TRON mostra quanto costa davvero un trasferimento USDT prima che ci costruiate sopra.

Nodo proprio — o API?

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

Fate girare il nodo quando leggete la chain su larga scala — indicizzazione, monitoraggio della rete oltre i vostri indirizzi, alimentazione di gRPC nella vostra pipeline — o quando la policy esclude terze parti. Il basso costo del Lite FullNode fa sì che i workload di lettura intensiva si ammortizzino in fretta; è uno dei nodi self-hosted più economici tra le grandi chain.

Usate un’API quando il nodo sarebbe solo idraulica per i pagamenti. Sopra un nodo sincronizzato dovreste comunque costruire generazione indirizzi per cliente, rilevamento depositi TRC-20, consegna webhook, storage delle chiavi e gestione commissioni. L’API TRON di Chaingateway è esattamente questo strato sotto forma di endpoint REST: importare indirizzi (POST /api/v2/tron/addresses/import), inviare USDT e altri token TRC-20 (POST /api/v2/tron/transactions/trc20) o asset TRC-10, congelare e delegare risorse per l’energy (POST /api/v2/tron/freeze, POST /api/v2/tron/delegate), e ricevere webhook di deposito firmati HMAC; le consegne fallite compaiono in GET /api/v2/tron/webhooks/notifications/failed e possono essere reinviate tramite l’endpoint di retry.

Il punto di pareggio come calcolo: (server + refresh degli snapshot + le vostre ore × la vostra tariffa) contro un piano su /it/pricing/. Per i casi d’uso deposito-e-payout, il lato API resta più piccolo fino a una scala seria; per la lettura grezza della chain, il lato nodo vince quasi subito. Il quickstart e la guida ai webhook coprono un primo test end-to-end, e la prova di 7 giorni non richiede KYC (registrazione).

Fate girare anche chain EVM? Vedete le guide di setup per Ethereum e BNB Smart Chain.