Installer un nœud TRON (la méthode pragmatique)

La plupart des personnes qui recherchent « tron node » veulent une chose : un accès direct à la chaîne qui fait transiter une part énorme de l’USDT mondial. La documentation officielle répond avec une chaîne d’outils Java — installer JDK 1.8, cloner java-tron, compiler avec Gradle, régler la JVM. Ce guide prend plutôt la voie pragmatique : le FullNode.jar prêt à l’emploi de la page des releases, plus un snapshot Lite FullNode, ce qui fait passer le besoin en disque de plus de 3 To à quelques centaines de Go. Docker suit comme alternative sans Java, puis viennent les temps de synchronisation, un calcul de coûts et le seuil de rentabilité honnête face à une API.

Qu’est-ce qu’un nœud TRON ?

Un nœud TRON fait tourner java-tron, le client de référence, et vous connecte au réseau qui valide les transactions toutes les 3 secondes. Il expose deux API pour les applications : HTTP sur le port 8090 et gRPC sur le port 50051. Elles permettent de déployer et d’appeler des contrats, de transférer des TRX et des tokens, et d’interroger l’état de la chaîne — le nœud est le point d’entrée pour tout ce que vous construisez sur TRON.

Le client évolue plus vite que sa chaîne d’outils JDK 8 ne le laisse penser : GreatVoyage-v4.8.0 (Kant) est sortie en février 2026, et la release actuelle est v4.8.1.1 (Hypatia, juin 2026). Presque chaque release porte l’étiquette « mandatory upgrade », ce qui façonne la routine de maintenance plus loin dans ce guide.

Les rôles de nœud, triés par pertinence. Un FullNode valide et relaie les blocs et répond aux requêtes API ; dans presque tous les cas, c’est celui qu’il vous faut. Un nœud witness produit des blocs, ce qui est réservé aux 27 super représentants élus par les votes TRX — pour tous les autres, le flag --witness ne sert à rien. Côté stockage, il existe deux variantes : un FullNode standard porte l’historique complet des transactions — environ 3 To mi-2026 et en croissance ; les snapshots officiels de mars 2026 pèsent 2,9 à 3,1 To selon la variante — tandis qu’un Lite FullNode démarre depuis un snapshot d’état seul de l’ordre de 100 Go.

Le Lite FullNode couvre tout ce dont un backend de paiement a besoin : l’état actuel, les nouveaux blocs, la diffusion de transactions, la surveillance des dépôts. Ce qu’il ne peut pas faire : répondre à des questions sur l’historique antérieur à son snapshot — interroger une ancienne transaction par ID échouera. Les explorateurs et plateformes d’analytics ont besoin de l’historique complet. La plupart des intégrations, non.

Les trois rôles côte à côte, avec des chiffres mi-2026 :

Matériel : FullNode vs Lite FullNode

Les lignes CPU et RAM étendent la recommandation officielle (16 cœurs, 32 Go, « 2,5 To+ » — écrite quand la chaîne était plus petite). La RAM compte double sur TRON : une fois pour le tas de la JVM, une fois pour le cache fichiers du système d’exploitation, ce qui explique qu’une machine à 32 Go tourne nettement plus souplement qu’une machine à 16 Go, même pour un nœud Lite.

Étape par étape : Lite FullNode avec le jar de release

Les commandes supposent Ubuntu 24.04.

1. Installer Java 8

java-tron cible encore JDK 1.8 en 2026 — une bizarrerie, mais non négociable. Les JVM plus récentes échouent au démarrage.

sudo apt update
sudo apt install -y openjdk-8-jdk
java -version   # doit annoncer 1.8.x

2. Créer un utilisateur et des répertoires

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. Télécharger le jar de release et la config mainnet

Aucun build Gradle nécessaire ; chaque release java-tron fournit un FullNode.jar prêt à l’emploi :

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

Les pages de release publient des sommes de contrôle — exécutez sha256sum FullNode.jar et comparez avant de lancer du code qui maintiendra des connexions réseau ouvertes pendant des mois.

4. Restaurer le snapshot Lite FullNode

La page officielle des snapshots de base de données sur le hub développeur TRON liste des miroirs à Singapour et aux États-Unis qui publient des archives fraîches chaque jour, en variantes LevelDB et RocksDB — prenez LevelDB sauf indication contraire de votre config, car le moteur de base de données doit correspondre au snapshot. Les archives Lite suivent l’objectif de conception de TIP-128, environ 3 % d’une base de données complète ; avec les snapshots complets de mars 2026 à 2,9–3,1 To (3,6 To pour la variante qui ajoute l’historique des soldes d’adresses), cela place le téléchargement Lite dans la fourchette basse des centaines de Go. Choisissez le miroir le plus proche, copiez le lien actuel et :

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

Après extraction, vous devriez avoir /var/lib/tron/output-directory contenant la base de données. Ce dossier est toute l’astuce du « sync depuis snapshot » — le nœud démarre sur cet état au lieu de rejouer des années de blocs. Si vous restaurez un jour la variante historique complète, utilisez la forme en flux recommandée par les miroirs — wget -qO- '<URL>' | tar xz — pour que l’archive de 3 To ne se retrouve jamais sur le disque à côté de sa copie extraite. Pour l’archive Lite, télécharger puis extraire ne pose pas de problème.

5. Unité systemd

Créez /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

Deux détails JVM tirés directement de la doc officielle : le flag du garbage collector se place avant -jar, pas après, et -Xmx devrait représenter environ 80 % de la RAM physique — 24g convient à une machine de 32 Go ; réduisez sur des machines plus petites. systemd arrête le service avec SIGTERM, ce qui correspond à l’instruction kill -15 de la doc. Ne faites jamais kill -9 sur un nœud TRON ; LevelDB se corrompt, et vous restaurerez un snapshot au lieu de dîner.

Ouvrez le port P2P, gardez les ports API privés :

sudo ufw allow 18888 comment 'tron p2p'

Les ports 8090 et 50051 ne portent aucune authentification. Ils restent fermés à Internet.

6. Démarrer et vérifier

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

Une fois les messages de bloc affichés, vérifiez la hauteur :

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

Comparez ce nombre avec le dernier bloc sur tronscan.org ; curl http://127.0.0.1:8090/wallet/getnodeinfo affiche en plus le nombre de pairs et le statut de synchronisation. Quand votre hauteur suit celle de l’explorateur, le nœud est en ligne.

Un mot sur la production de blocs, puisque la doc officielle y consacre des pages : un nœud witness n’a de sens que pour les 27 super représentants élus. La mécanique — le flag --witness plus la clé privée du SR dans la liste localwitness de main_net_config.conf, ou la variante keystore-plus-mot-de-passe si vous refusez les clés en clair — est documentée en amont. Pour tous les autres, un simple FullNode est la bonne cible.

Docker au lieu de Java

Les principaux guides TRON évitent tous Docker, alors que l’image officielle fait de l’exigence JDK 8 le problème de quelqu’un d’autre :

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

Le montage de volume réutilise le snapshot Lite de l’étape 4, démarrer le conteneur n’est donc pas une resynchronisation. Lier 8090 et 50051 à 127.0.0.1 garde les API privées tandis que le port P2P reste accessible. Pour des réglages personnalisés, montez votre main_net_config.conf dans le conteneur et passez -c en argument de commande ; sans cela, l’image tourne avec les valeurs par défaut du mainnet. Si votre hôte fait déjà tourner d’autres conteneurs, c’est le montage le plus propre — une seule mise à jour d’image remplace toute la stack Java.

Temps de synchronisation et gestion des snapshots

De l’arithmétique, pas des promesses. Une archive Lite de 150 Go à 50 Mo/s soutenus se télécharge en environ 50 minutes ; l’extraction ajoute quelques minutes sur du NVMe. Le snapshot a au plus un jour, et TRON produit environ 28 800 blocs par jour à son rythme de 3 secondes — un nœud sain importe bien plus vite que le temps réel, donc le rattrapage coûte de quelques minutes à quelques heures. Total : un Lite FullNode opérationnel en un après-midi.

Pour un nœud à historique complet, le même calcul fait mal : 3 To+ à 100 Mo/s signifient plus de 8 heures de téléchargement avant même que l’extraction commence, et une synchronisation depuis la genèse sans aucun snapshot tourne pendant des semaines. Une asymétrie à connaître : java-tron fournit un outil qui réduit une base de données FullNode au format Lite, mais il n’existe pas de chemin du Lite vers le complet — si vous aurez un jour besoin de l’historique complet, partez du snapshot complet.

Flux d’événements et gRPC

Interroger les blocs par HTTP fonctionne, mais java-tron peut aussi pousser. Le mécanisme d’abonnement aux événements, activé dans le bloc event.subscribe de main_net_config.conf, publie des déclencheurs pour les nouveaux blocs, transactions, logs de contrat et événements de contrat — dans une file ZeroMQ intégrée pour les configurations légères, ou via des plugins vers Kafka ou MongoDB pour de vrais pipelines.

Pour la détection de dépôts, cela remplace le scan de blocs : s’abonner aux événements de contrat, filtrer sur le contrat USDT, faire correspondre le destinataire à vos adresses clients. Un détail décide de la justesse. Les déclencheurs simples se déclenchent dès qu’un bloc arrive, mais un bloc TRON ne devient irréversible que lorsque suffisamment de super représentants l’ont confirmé ; les variantes de déclencheurs solidified se déclenchent à ce moment-là, et ce sont elles qu’il faut utiliser pour créditer les soldes clients. Un dépôt crédité depuis un bloc non solidifié peut, rarement, disparaître lors d’une réorganisation.

La seconde interface machine est gRPC sur le port 50051 : les mêmes opérations wallet que HTTP, mais typées en protobuf et plus rapides par appel sous charge, ce qui explique que la plupart des indexeurs et backends d’exchange sur TRON l’utilisent. Une répartition pratique : gRPC pour les lectures en masse de votre indexeur, HTTP pour les vérifications ponctuelles comme les appels curl de ce guide, et l’API solidity (port 8091, si activé) pour les requêtes qui ne doivent voir que l’état irréversible.

Ce que coûte un nœud TRON

Une démarche de calcul, pas une grille tarifaire. Un Lite FullNode nécessite 8 à 16 cœurs, 32 Go de RAM et environ 500 Go de NVMe — territoire d’un VPS haut de gamme ou d’un serveur dédié d’entrée de gamme, ce qui, chez les hébergeurs européens, représente un ordre de grandeur situé entre quelques dizaines et quelques centaines d’euros par mois. Un nœud à historique complet nécessite la classe 3 To+ NVMe, donc un vrai serveur dédié dans une fourchette de quelques centaines d’euros.

Ajoutez vos heures : une demi-journée de mise en place avec ce guide, des mises à jour java-tron tous les quelques mois, et un rafraîchissement de snapshot occasionnel après un incident. Le Lite FullNode est le cas rare où l’auto-hébergement d’infrastructure blockchain est réellement bon marché — tant que le chiffre d’affaires de personne ne dépend de sa disponibilité à 3 heures du matin.

Supervision et contrôles de santé

Tout ce qui vaut la peine d’être vérifié se trouve derrière un seul endpoint. /wallet/getnodeinfo retourne la version du client, le nombre de pairs, le dernier bloc et le dernier bloc solidifié en un seul appel :

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

Un nœud sain montre la tête avançant toutes les 3 secondes et le bloc solidifié environ 19 à 20 blocs derrière — c’est la profondeur de confirmation des deux tiers des 27 SR, environ une minute de temps de chaîne. Pour l’alerting, comparez votre tête à tronscan ou à un second nœud toutes les quelques minutes et alertez quand l’écart dépasse 40 blocs, deux minutes de temps de chaîne. systemctl is-active tron plus le nombre de pairs du même appel couvre la vivacité.

Comme ce nœud est une JVM, surveillez la mémoire séparément : jstat -gcutil $(pgrep -f FullNode.jar) 10s montre la pression du garbage collector, et des temps de full-GC croissants apparaissent dans cette sortie avant que le nœud ne commence à prendre du retard. Complétez avec df -h /var/lib/tron à un seuil de 85 % — un nœud Lite croît lentement, mais il croît, et le même cron qui vous envoie le statut de synchronisation peut ajouter la ligne disque gratuitement.

Maintenance et mises à jour

Les releases java-tron arrivent tous les quelques mois, et la plupart portent l’étiquette « mandatory upgrade » — Kant (v4.8.0, février 2026), Democritus (v4.8.1) et Hypatia (v4.8.1.1, juin 2026) toutes les trois. Mandatory signifie que le réseau active les changements de règles selon un calendrier et que les anciennes versions se retrouvent du mauvais côté du consensus — traitez donc les releases TRON comme les opérateurs BSC traitent les hard forks : abonnez-vous au flux de releases de tronprotocol/java-tron et mettez à jour dans la fenêtre annoncée.

La mise à jour conserve la base de données. Téléchargez le nouveau FullNode.jar, comparez sha256sum avec la page de release, arrêtez le service (systemd envoie SIGTERM, l’arrêt propre documenté), remplacez le jar dans /opt/tron, redémarrez. Le nœud rejoue les quelques minutes manquées et revient à la tête peu après.

Deux tâches plus lentes méritent leur place sur la liste. La base Lite grandit avec l’état plus sa queue de blocs accumulée ; quand elle dépasse le confortable, restaurez un snapshot Lite frais — le même geste que pour la récupération après incident, et la raison pour laquelle ce montage garde la récupération bon marché. Et surveillez l’exigence Java : le build x86 standard cible toujours JDK 1.8 mi-2026, tandis que la v4.8.1 a ajouté des builds ARM sous JDK 17. La contrainte se desserre, mais tant que les notes de release ne disent pas autre chose, un serveur standard reste sur Java 8.

Sécurité : deux ports API, zéro authentification

Les ports 8090 (HTTP) et 50051 (gRPC) acceptent quiconque peut les atteindre — aucun token, aucun compte, rien. Un nœud configuré comme dans ce guide ne détient aucune clé privée, donc un port exposé ne fait pas perdre d’argent directement, mais il offre gratuitement un service RPC à des inconnus, et des boucles de requêtes intensives contre les endpoints de bloc épuiseront l’I/O disque de la machine jusqu’à affamer votre propre logiciel. Partez du principe que tout port accessible depuis Internet est scanné dès aujourd’hui.

Le pare-feu de l’étape 5 fait office de politique : ufw default deny incoming, puis SSH et 18888 (TCP et UDP) — rien d’autre. Quand d’autres machines ont besoin de l’API, passez par un tunnel WireGuard ou SSH, ou placez nginx devant avec TLS et une liste blanche d’IP, et même dans ce cas ne relayez que les endpoints réellement utilisés. Après chaque changement de configuration, vérifiez ce qui écoute vraiment avec ss -tlnp : java-tron peut ouvrir des ports supplémentaires depuis le fichier de configuration, dont l’API solidity sur 8091, et un port oublié est un port non protégé.

Un cas particulier. Si vous placez un jour une clé witness sur une machine, cette machine cesse d’être de l’infrastructure et devient un hot wallet. Séparez-la du service RPC, et traitez son fichier de configuration — qui peut contenir la clé en clair — avec le soin que vous accorderiez à la clé elle-même.

Dépannage

Le démarrage échoue immédiatement avec une erreur de version Java

UnsupportedClassVersionError ou une erreur similaire signifie que la JVM est en version 11 ou plus récente. Sélectionnez Java 8 avec sudo update-alternatives --config java, ou contournez complètement le problème avec l’image Docker.

OutOfMemoryError ou pauses GC de plusieurs minutes

-Xmx est mal dimensionné. Suivez la règle des 80 % de la RAM, mais laissez plusieurs Go pour le cache fichiers de l’OS, et n’hébergez pas d’autres services gourmands en mémoire à côté. Sur une machine de 16 Go, -Xmx12g est le plafond.

Le nœud démarre mais reste bloqué à la hauteur du snapshot

Aucun pair. Vérifiez que le port 18888 est ouvert en TCP et UDP, regardez le nombre de pairs dans /wallet/getnodeinfo, et vérifiez l’horloge avec timedatectl — NTP doit être actif. Juste après le premier démarrage, laissez quelques minutes à la découverte de pairs avant de creuser davantage.

Erreurs de base de données après un crash ou un redémarrage

Un kill -9, un OOM kill ou une coupure de courant corrompt la base de données. La correction la plus rapide est aussi celle prévue : effacer output-directory, restaurer un snapshot Lite frais, redémarrer — c’est le bénéfice de la petite taille du snapshot. Prévention : toujours arrêter via systemd, et garder assez de RAM libre pour que le noyau ne tue jamais Java par OOM.

Le nœud continue de prendre du retard sur la tête

Les pairs sont connectés, les blocs arrivent, mais l’écart avec tronscan s’agrandit. Vérifiez dans cet ordre : la latence disque (benchmark de lecture aléatoire fio — LevelDB sur stockage réseau ou SATA est la cause classique), la pression GC (jstat -gcutil, voir la section supervision), puis la contention CPU due à des workloads co-hébergés. Le rythme de 3 secondes de TRON tolère de courtes pauses ; un retard qui grandit pendant des heures signifie que la machine ne suit pas, et aucun flag de configuration ne répare du matériel sous-dimensionné.

Le disque se remplit

df -h, puis du -h --max-depth=2 /var/lib/tron. Le constat habituel est une archive de snapshot oubliée — le .tgz peut rivaliser en taille avec la base de données extraite. Si output-directory lui-même a dépassé le volume, restaurez le dernier snapshot Lite sur un disque plus grand ; la restauration réinitialise en même temps la queue de blocs accumulée. L’alerte à 85 % de la section supervision transforme ceci en simple rendez-vous au calendrier plutôt qu’en incident.

Pourquoi faire tourner un nœud TRON : l’USDT

La réponse dominante est l’USDT-TRC20. Des frais bas et des blocs de 3 secondes ont fait de TRON un rail par défaut pour les exchanges et les fournisseurs de paiement, et des dizaines de milliards de dollars d’USDT circulent sur la chaîne. Avec votre propre nœud, vous pouvez surveiller les dépôts clients et diffuser les paiements sans intermédiaire, ce qui explique pourquoi les entreprises de paiement s’intéressent aux nœuds TRON bien plus souvent qu’à la plupart des autres chaînes.

La mécanique mérite un niveau de détail supplémentaire, car elle façonne l’architecture. Un dépôt USDT n’est pas un transfert TRX — c’est un appel au smart contract USDT, il n’apparaît donc jamais dans de simples requêtes de solde TRX. Le détecter implique de décoder les événements de transfert TRC-20 dans chaque bloc, ou de s’y abonner via le mécanisme d’événements décrit plus haut, et de ne créditer qu’après solidification : environ 19 blocs, soit environ une minute. Les paiements ont leur propre économie. Un transfert USDT consomme de l’energy, et un wallet sans TRX staké paie cette energy en brûlant du TRX — environ 6,4 TRX vers une adresse qui détient déjà de l’USDT et environ 13,4 TRX vers une adresse vide, au prix de l’energy à 100 Sun en vigueur depuis la proposition n° 104. Les opérations à volume staken plutôt du TRX pour l’energy, ce à quoi servent les mécanismes de freeze et de délégation.

Mais soyez clair sur ce qu’un nœud brut vous donne : des endpoints HTTP et gRPC, rien de plus. Détecter le dépôt USDT d’un client implique de scanner chaque bloc à la recherche d’événements de transfert TRC-20 correspondant à votre liste d’adresses, en gérant vous-même les confirmations et les tentatives. Et le système de frais de TRON — bandwidth, energy, freeze de TRX, parrainage des frais pour les utilisateurs — est un domaine d’étude à part entière ; le calculateur de frais TRON montre ce qu’un transfert USDT coûte réellement avant que vous ne construisiez autour.

Faire tourner son propre nœud — ou utiliser une API ?

Une comparaison honnête, puisque Chaingateway vend l’alternative.

Faites tourner le nœud quand vous lisez la chaîne à grande échelle — indexation, supervision du réseau au-delà de vos propres adresses, alimentation de gRPC dans votre propre pipeline — ou quand la politique interdit les tiers. Le faible coût du Lite FullNode fait que les workloads de lecture intensive s’amortissent vite ; c’est l’un des nœuds auto-hébergés les moins chers parmi les grandes chaînes.

Utilisez une API quand le nœud ne serait que de la plomberie pour des paiements. Sur un nœud synchronisé, vous devriez en plus construire la génération d’adresses par client, la détection de dépôts TRC-20, la livraison de webhooks, le stockage des clés et la gestion des frais. L’API TRON de Chaingateway est exactement cette couche sous forme d’endpoints REST : importer des adresses (POST /api/v2/tron/addresses/import), envoyer de l’USDT et d’autres tokens TRC-20 (POST /api/v2/tron/transactions/trc20) ou des actifs TRC-10, freezer et déléguer des ressources pour l’energy (POST /api/v2/tron/freeze, POST /api/v2/tron/delegate), et recevoir des webhooks de dépôt signés HMAC ; les livraisons échouées apparaissent sous GET /api/v2/tron/webhooks/notifications/failed et peuvent être renvoyées via l’endpoint de retry.

Le seuil de rentabilité en calcul : (serveur + rafraîchissements de snapshot + vos heures × votre taux) face à un plan sur /fr/pricing/. Pour les cas d’usage dépôt-et-paiement, le côté API reste plus petit jusqu’à une échelle sérieuse ; pour la lecture brute de la chaîne, le côté nœud gagne presque immédiatement. Le quickstart et le guide des webhooks couvrent un premier test de bout en bout, et l’essai de 7 jours ne demande aucun KYC (inscription).

Vous faites aussi tourner des chaînes EVM ? Consultez les guides de configuration pour Ethereum et BNB Smart Chain.