Cómo montar un nodo TRON (la vía pragmática)

La mayoría de quienes buscan «tron node» quieren una cosa: acceso directo a la cadena por la que circula una parte enorme del USDT mundial. La documentación oficial responde con una cadena de herramientas Java: instalar JDK 1.8, clonar java-tron, compilar con Gradle, ajustar la JVM. Esta guía toma en cambio la vía pragmática: el FullNode.jar ya compilado de la página de releases, más un snapshot de Lite FullNode, lo que reduce el requisito de disco de más de 3 TB a unos pocos cientos de GB. Docker aparece después como alternativa sin Java, y luego los tiempos de sincronización, un cálculo de costes y el punto de equilibrio honesto frente a una API.

¿Qué es un nodo TRON?

Un nodo TRON ejecuta java-tron, el cliente de referencia, y le conecta a la red que valida transacciones cada 3 segundos. Expone dos API para aplicaciones: HTTP en el puerto 8090 y gRPC en el puerto 50051. A través de ellas puede desplegar y llamar a contratos, transferir TRX y tokens, y consultar el estado de la cadena; el nodo es el punto de entrada para todo lo que construya sobre TRON.

El cliente avanza más rápido de lo que sugiere su cadena de herramientas JDK 8: GreatVoyage-v4.8.0 (Kant) salió en febrero de 2026, y la release actual es v4.8.1.1 (Hypatia, junio de 2026). Casi todas las releases llevan la etiqueta «mandatory upgrade», lo que condiciona la rutina de mantenimiento más adelante en esta guía.

Roles de nodo, ordenados por relevancia. Un FullNode valida y retransmite bloques y responde consultas de API; en casi todos los casos, es el que necesita. Un nodo witness produce bloques, algo reservado a los 27 super representantes elegidos por votos TRX; para todos los demás, el flag --witness no hace nada útil. En el eje de almacenamiento hay dos variantes: un FullNode estándar lleva el historial completo de transacciones —alrededor de 3 TB a mediados de 2026 y creciendo; los snapshots oficiales de marzo de 2026 pesan 2,9–3,1 TB según la variante— mientras que un Lite FullNode arranca desde un snapshot solo de estado del orden de 100 GB.

El Lite FullNode cubre todo lo que necesita un backend de pagos: estado actual, bloques nuevos, difusión de transacciones, vigilancia de depósitos. Lo que no puede hacer es responder preguntas sobre historial anterior a su snapshot: consultar una transacción antigua por ID fallará. Los exploradores y las plataformas de analítica necesitan historial completo. La mayoría de las integraciones, no.

Los tres roles uno junto a otro, con cifras de mediados de 2026:

Hardware: FullNode frente a Lite FullNode

Las filas de CPU y RAM amplían la recomendación oficial (16 núcleos, 32 GB, «2,5 TB+», escrita cuando la cadena era más pequeña). La RAM cuenta doble en TRON: una vez para el heap de la JVM y otra para la caché de archivos del sistema operativo, por lo que una máquina de 32 GB va notablemente más fluida que una de 16 GB, incluso para un nodo Lite.

Paso a paso: Lite FullNode con el jar de release

Los comandos asumen Ubuntu 24.04.

1. Instalar Java 8

java-tron todavía apunta a JDK 1.8 en 2026 —una rareza, pero no negociable. Las JVM más nuevas fallan al arrancar.

sudo apt update
sudo apt install -y openjdk-8-jdk
java -version   # debe reportar 1.8.x

2. Crear un usuario y directorios

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. Descargar el jar de release y la config de mainnet

No hace falta compilar con Gradle; cada release de java-tron incluye un FullNode.jar listo:

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

Las páginas de release publican checksums: ejecute sha256sum FullNode.jar y compare antes de correr código que mantendrá conexiones de red abiertas durante meses.

4. Restaurar el snapshot de Lite FullNode

La página oficial de snapshots de base de datos en el hub de desarrolladores de TRON lista mirrors en Singapur y EE. UU. que publican archivos frescos a diario, en variantes LevelDB y RocksDB; tome LevelDB salvo que su config indique lo contrario, porque el motor de base de datos debe coincidir con el snapshot. Los archivos Lite siguen el objetivo de diseño de TIP-128, alrededor del 3 % de una base de datos completa; con los snapshots completos de marzo de 2026 en 2,9–3,1 TB (3,6 TB para la variante que añade historial de saldos de direcciones), eso coloca la descarga Lite en el rango bajo de cientos de GB. Elija el mirror más cercano, copie el enlace actual y:

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

Tras extraer debería tener /var/lib/tron/output-directory con la base de datos. Esa carpeta es todo el truco del «sync desde snapshot»: el nodo arranca sobre ese estado en lugar de reproducir años de bloques. Si alguna vez restaura la variante de historial completo, use la forma en streaming que recomiendan los mirrors —wget -qO- '<URL>' | tar xz— para que el archivo de 3 TB nunca esté en disco junto a su copia extraída. Para el archivo Lite, descargar y luego extraer no supone ningún problema.

5. Unidad systemd

Cree /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

Dos detalles de JVM directamente de la documentación oficial: el flag del garbage collector va antes de -jar, no después, y -Xmx debería ser aproximadamente el 80 % de la RAM física —24g encaja en una máquina de 32 GB; redúzcalo en máquinas más pequeñas. systemd detiene el servicio con SIGTERM, que coincide con la instrucción kill -15 de la documentación. Nunca haga kill -9 a un nodo TRON; LevelDB se corrompe, y acabará restaurando un snapshot en lugar de cenar.

Abra el puerto P2P, mantenga privados los puertos de la API:

sudo ufw allow 18888 comment 'tron p2p'

Los puertos 8090 y 50051 no llevan autenticación. Permanecen cerrados hacia internet.

6. Iniciar y verificar

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

Cuando aparezcan mensajes de bloque, compruebe la altura:

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

Compare el número con el último bloque en tronscan.org; curl http://127.0.0.1:8090/wallet/getnodeinfo muestra además el recuento de pares y el estado de sincronización. Cuando su altura siga a la del explorador, el nodo está en vivo.

Una palabra sobre la producción de bloques, ya que la documentación oficial le dedica muchas páginas: un nodo witness solo tiene sentido para los 27 super representantes elegidos. La mecánica —el flag --witness más la clave privada del SR en la lista localwitness de main_net_config.conf, o la variante keystore-más-contraseña si rechaza claves en texto plano— está documentada en el proyecto upstream. Para todos los demás, un FullNode simple es el objetivo correcto.

Docker en lugar de Java

Las guías de TRON mejor posicionadas se saltan Docker, y sin embargo la imagen oficial convierte el requisito de JDK 8 en problema de otro:

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

El montaje del volumen reutiliza el snapshot Lite del paso 4, así que iniciar el contenedor no es una resincronización. Vincular 8090 y 50051 a 127.0.0.1 mantiene las API privadas mientras el puerto P2P sigue accesible. Para ajustes personalizados, monte su main_net_config.conf en el contenedor y pase -c como argumento de comando; sin eso, la imagen corre con los valores por defecto de mainnet. Si su host ya ejecuta otros contenedores, este es el montaje más limpio: una sola actualización de imagen reemplaza todo el stack de Java.

Tiempo de sincronización y manejo de snapshots

Aritmética, no promesas. Un archivo Lite de 150 GB a 50 MB/s sostenidos se descarga en unos 50 minutos; la extracción añade minutos en NVMe. El snapshot tiene como máximo un día, y TRON produce unos 28.800 bloques al día a su ritmo de 3 segundos: un nodo sano importa mucho más rápido que en tiempo real, así que ponerse al día cuesta minutos a unas pocas horas. Total: un Lite FullNode funcionando en una tarde.

Para un nodo de historial completo, el mismo cálculo duele: 3 TB+ a 100 MB/s significan más de 8 horas de descarga antes de que empiece siquiera la extracción, y sincronizar desde el génesis sin ningún snapshot dura semanas. Una asimetría a conocer: java-tron incluye una herramienta que reduce una base de datos de FullNode a formato Lite, pero no hay camino de Lite de vuelta a completo; si alguna vez necesitará el historial completo, empiece con el snapshot completo.

Flujos de eventos y gRPC

Sondear bloques por HTTP funciona, pero java-tron también puede empujar datos. El mecanismo de suscripción a eventos, activado en el bloque event.subscribe de main_net_config.conf, publica disparadores para nuevos bloques, transacciones, logs de contrato y eventos de contrato —en una cola ZeroMQ integrada para configuraciones ligeras, o mediante plugins hacia Kafka o MongoDB para pipelines reales.

Para la detección de depósitos, esto reemplaza el escaneo de bloques: suscribirse a eventos de contrato, filtrar por el contrato de USDT, cotejar el destinatario con sus direcciones de clientes. Un detalle decide la corrección. Los disparadores simples se activan en cuanto llega un bloque, pero un bloque de TRON solo se vuelve irreversible cuando suficientes super representantes lo han confirmado; las variantes de disparador solidified se activan en ese momento, y son las que hay que usar para acreditar saldos de clientes. Un depósito acreditado desde un bloque no solidificado puede, raramente, desaparecer en una reorganización.

La segunda interfaz de máquina es gRPC en el puerto 50051: las mismas operaciones de wallet que HTTP, pero tipadas en protobuf y más rápidas por llamada bajo carga, razón por la que la mayoría de los indexadores y backends de exchange en TRON lo usan. Un reparto práctico: gRPC para las lecturas masivas de su indexador, HTTP para comprobaciones puntuales como los curl de esta guía, y la API solidity (puerto 8091, si está habilitada) para consultas que solo deben ver estado irreversible.

Cuánto cuesta un nodo TRON

Una vía de cálculo, no una lista de precios. Un Lite FullNode necesita 8–16 núcleos, 32 GB de RAM y unos 500 GB de NVMe —territorio de un VPS de gama media-alta o un servidor dedicado de entrada, lo que en hosts europeos supone, como orden de magnitud, un importe mensual entre decenas y unos pocos cientos de euros. Un nodo de historial completo necesita la clase 3 TB+ NVMe, es decir, un servidor dedicado de verdad en la franja baja a media de los cientos de euros.

Sume sus horas: medio día de instalación siguiendo esta guía, actualizaciones de java-tron cada pocos meses, y algún refresco de snapshot ocasional tras un fallo. El Lite FullNode es el caso raro en el que auto-alojar infraestructura blockchain resulta realmente barato, siempre que los ingresos de nadie dependan de que siga funcionando a las 3 de la madrugada.

Monitorización y comprobaciones de salud

Todo lo que merece la pena comprobar está detrás de un endpoint. /wallet/getnodeinfo devuelve la versión del cliente, el recuento de pares, el último bloque y el último bloque solidificado en una sola llamada:

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

Un nodo sano muestra la cabeza avanzando cada 3 segundos y el bloque solidificado unos 19–20 bloques por detrás; esa es la profundidad de confirmación de dos tercios de los 27 SR, alrededor de un minuto de tiempo de cadena. Para alertas, compare su cabeza con tronscan o un segundo nodo cada pocos minutos y avise cuando el hueco supere los 40 bloques, dos minutos de tiempo de cadena. systemctl is-active tron más el recuento de pares de la misma llamada cubre la vivacidad.

Como este nodo es una JVM, vigile la memoria por separado: jstat -gcutil $(pgrep -f FullNode.jar) 10s muestra la presión de garbage collection, y los tiempos crecientes de full-GC aparecen en esa salida antes de que el nodo empiece a retrasarse. Complételo con df -h /var/lib/tron a un umbral del 85 %; un nodo Lite crece despacio, pero crece, y el mismo cron que le envía por correo el estado de sincronización puede añadir la línea de disco gratis.

Mantenimiento y actualizaciones

Las releases de java-tron llegan cada pocos meses, y la mayoría llevan la etiqueta «mandatory upgrade» —Kant (v4.8.0, febrero de 2026), Democritus (v4.8.1) e Hypatia (v4.8.1.1, junio de 2026), las tres. Mandatory significa que la red activa cambios de reglas según un calendario y las versiones antiguas acaban en el lado equivocado del consenso, así que trate las releases de TRON como los operadores de BSC tratan los hard forks: suscríbase al feed de releases de tronprotocol/java-tron y actualice dentro de la ventana anunciada.

La actualización conserva la base de datos. Descargue el nuevo FullNode.jar, compare sha256sum con la página de release, detenga el servicio (systemd envía SIGTERM, el apagado limpio documentado), sustituya el jar en /opt/tron, reinicie. El nodo reproduce los pocos minutos que se perdió y vuelve a la cabeza poco después.

Dos tareas más lentas merecen su sitio en la lista. La base de datos Lite crece con el estado más su cola de bloques acumulada; cuando supere lo cómodo, restaure un snapshot Lite fresco —el mismo movimiento que en la recuperación tras un fallo, y la razón por la que este montaje mantiene barata la recuperación. Y vigile el requisito de Java: el build x86 estándar sigue apuntando a JDK 1.8 a mediados de 2026, mientras que la v4.8.1 añadió builds ARM sobre JDK 17. La restricción se afloja, pero hasta que las notas de release digan otra cosa, un servidor estándar se queda en Java 8.

Seguridad: dos puertos de API, cero autenticación

Los puertos 8090 (HTTP) y 50051 (gRPC) aceptan a cualquiera que pueda alcanzarlos: sin tokens, sin cuentas, nada. Un nodo montado como en esta guía no guarda claves privadas, así que un puerto expuesto no pierde fondos directamente, pero regala a extraños un servicio RPC gratuito, y bucles de consultas intensivas contra los endpoints de bloques devorarán la I/O de disco de la máquina hasta dejar sin recursos a su propio software. Asuma que cualquier puerto accesible desde internet ya está siendo escaneado hoy.

El firewall del paso 5 es la política: ufw default deny incoming, luego SSH y 18888 (TCP y UDP) —nada más. Cuando otras máquinas necesiten la API, cree un túnel con WireGuard o SSH, o ponga nginx delante con TLS y una lista blanca de IP, y aun así reenvíe solo los endpoints que realmente use. Tras cada cambio de configuración, compruebe qué escucha realmente con ss -tlnp: java-tron puede abrir puertos adicionales desde el archivo de configuración, entre ellos la API solidity en 8091, y un puerto olvidado es un puerto sin proteger.

Un caso especial. Si alguna vez pone una clave witness en una máquina, esa máquina deja de ser infraestructura y se convierte en un hot wallet. Sepárela del servicio RPC, y trate su archivo de configuración —que puede contener la clave en texto plano— con el mismo cuidado que le daría a la propia clave.

Solución de problemas

El arranque falla de inmediato con un error de versión de Java

UnsupportedClassVersionError o similar significa que la JVM es versión 11 o más nueva. Seleccione Java 8 con sudo update-alternatives --config java, o evite el problema por completo con la imagen Docker.

OutOfMemoryError o pausas de GC de varios minutos

-Xmx está mal dimensionado. Siga la regla del 80 % de la RAM, pero deje varios GB para la caché de archivos del SO, y no co-aloje otros servicios hambrientos de memoria. En una máquina de 16 GB, -Xmx12g es el tope.

El nodo arranca pero se queda en la altura del snapshot

Sin pares. Compruebe que el puerto 18888 está abierto para TCP y UDP, mire el recuento de pares en /wallet/getnodeinfo, y verifique el reloj con timedatectl —NTP debe estar activo. Justo después del primer arranque, dé unos minutos al descubrimiento de pares antes de indagar más.

Errores de base de datos tras un fallo o reinicio

Un kill -9, un OOM kill o un corte de luz corrompe la base de datos. La solución más rápida es también la prevista: borrar output-directory, restaurar un snapshot Lite fresco, reiniciar —ese es el beneficio del pequeño tamaño del snapshot. Prevención: detenga siempre vía systemd, y mantenga suficiente RAM libre para que el kernel nunca mate Java por OOM.

El nodo se sigue retrasando respecto a la cabeza

Los pares están conectados, los bloques llegan, pero el hueco con tronscan crece. Compruebe en este orden: latencia de disco (benchmark de lectura aleatoria con fio —LevelDB en almacenamiento de red o SATA es la causa clásica), presión de GC (jstat -gcutil, vea la sección de monitorización), luego contención de CPU por workloads co-alojados. El ritmo de 3 segundos de TRON perdona pausas cortas; un retraso que crece durante horas significa que la máquina no da abasto, y ningún flag de configuración arregla hardware infradimensionado.

El disco se llena

df -h, luego du -h --max-depth=2 /var/lib/tron. El hallazgo habitual es un archivo de snapshot olvidado —el .tgz puede rivalizar en tamaño con la base de datos extraída. Si output-directory en sí ha superado el volumen, restaure el snapshot Lite más reciente en un disco mayor; la restauración reinicia a la vez la cola de bloques acumulada. La alerta del 85 % de la sección de monitorización convierte esto en una entrada de calendario en lugar de una caída del servicio.

Por qué se ejecuta un nodo TRON: USDT

La respuesta dominante es USDT-TRC20. Comisiones bajas y bloques de 3 segundos convirtieron a TRON en un raíl por defecto para exchanges y proveedores de pago, y decenas de miles de millones de dólares en USDT circulan por la cadena. Con su propio nodo puede vigilar depósitos de clientes y difundir pagos sin intermediarios, precisamente por lo que las empresas de pagos preguntan por nodos TRON mucho más a menudo que por la mayoría de otras cadenas.

La mecánica merece un nivel más de detalle, porque condiciona la arquitectura. Un depósito de USDT no es una transferencia de TRX: es una llamada al smart contract de USDT, así que nunca aparece en consultas simples de saldo TRX. Detectarlo implica decodificar eventos de transferencia TRC-20 en cada bloque, o suscribirse a ellos mediante el mecanismo de eventos descrito antes, y acreditar solo tras la solidificación: unos 19 bloques, alrededor de un minuto. Los pagos tienen su propia economía. Una transferencia de USDT consume energy, y un wallet sin TRX en staking paga esa energy quemando TRX —unos 6,4 TRX a una dirección que ya tiene USDT y unos 13,4 TRX a una vacía, al precio de energy de 100 Sun vigente desde la propuesta n.º 104. Las operaciones con volumen ponen TRX en staking para energy en su lugar, que es para lo que existen los mecanismos de freeze y delegación.

Pero tenga claro qué le da un nodo en bruto: endpoints HTTP y gRPC, nada más. Detectar el depósito de USDT de un cliente implica escanear cada bloque en busca de eventos de transferencia TRC-20 contra su lista de direcciones, gestionando usted mismo confirmaciones y reintentos. Y el sistema de comisiones de TRON —bandwidth, energy, freeze de TRX, patrocinio de comisiones para usuarios— es un campo de estudio en sí mismo; la calculadora de comisiones de TRON muestra lo que realmente cuesta una transferencia de USDT antes de que construya nada alrededor.

Preguntas frecuentes

¿Cuánto espacio en disco necesita un nodo TRON?

Un Lite FullNode arranca desde un snapshot del orden de 100 GB; reserve 300–500 GB de NVMe para el crecimiento. Un FullNode con historial completo ronda los 3 TB a mediados de 2026 —los snapshots oficiales de marzo de 2026 pesan 2,9–3,1 TB— y la cifra sigue subiendo.

¿Puedo ejecutar un nodo TRON en Windows?

Oficialmente java-tron apunta a Linux y macOS. En Windows, la vía práctica es la imagen Docker, que fija todo el entorno, incluido Java 8.

¿Ejecutar un nodo TRON genera TRX?

No. Las recompensas de bloque van, vía staking, a los 27 super representantes elegidos y a sus votantes. Un FullNode le da acceso independiente a la cadena, no ingresos.

¿Qué versión de Java necesita java-tron?

JDK 1.8 para el build x86 estándar, todavía a mediados de 2026; la v4.8.1 añadió builds ARM sobre JDK 17, pero en un servidor normal, las JVM más nuevas fallan al arrancar. Este es el fallo de configuración más común, y la razón por la que esta guía incluye la imagen Docker.

¿Cuál es la diferencia entre un FullNode y un Lite FullNode?

Mismo software, base de datos distinta. La variante Lite arranca desde un snapshot solo de estado y responde a todo lo relativo al estado actual de la cadena, pero no puede responder consultas sobre transacciones anteriores a su snapshot. Los pagos funcionan; el historial tipo explorador de bloques, no.

¿Ejecutar su propio nodo — o usar una API?

Una comparación honesta, ya que Chaingateway vende la alternativa.

Ejecute el nodo cuando lea la cadena a gran escala —indexación, monitorización de la red más allá de sus propias direcciones, alimentar gRPC a su propio pipeline— o cuando la política prohíba a terceros. El bajo coste del Lite FullNode hace que las cargas de lectura intensiva se amorticen rápido; es uno de los nodos autoalojados más baratos entre las grandes cadenas.

Use una API cuando el nodo solo sería fontanería para pagos. Sobre un nodo sincronizado, tendría además que construir generación de direcciones por cliente, detección de depósitos TRC-20, entrega de webhooks, almacenamiento de claves y gestión de comisiones. La API TRON de Chaingateway es exactamente esa capa en forma de endpoints REST: importar direcciones (POST /api/v2/tron/addresses/import), enviar USDT y otros tokens TRC-20 (POST /api/v2/tron/transactions/trc20) o activos TRC-10, congelar y delegar recursos para energy (POST /api/v2/tron/freeze, POST /api/v2/tron/delegate), y recibir webhooks de depósito firmados con HMAC; las entregas fallidas aparecen en GET /api/v2/tron/webhooks/notifications/failed y pueden reenviarse a través del endpoint de reintento.

El punto de equilibrio como cálculo: (servidor + refrescos de snapshot + sus horas × su tarifa) frente a un plan en /es/pricing/. Para casos de uso de depósito y pago, el lado de la API se mantiene más pequeño hasta una escala seria; para lectura bruta de la cadena, el lado del nodo gana casi de inmediato. El quickstart y la guía de webhooks cubren una primera prueba de extremo a extremo, y la prueba de 7 días no requiere KYC (registro).

¿También ejecuta cadenas EVM? Vea las guías de configuración para Ethereum y BNB Smart Chain.