Tron

A Tron node runs a single java-tron process. On the first deploy, the node seeds from a recent community snapshot to cut sync time. To deploy one, open Deploy Node, pick an executor that supports Tron, then choose the network, node type, client (java-tron), and version. The wizard offers exactly what your executor declares.

​

Networks and resources

Tron runs on mainnet. Defaults are pre-filled in the deploy wizard per node type; lower them with caution.

​

Clients

In-place update steps are available between the listed versions; the ones carrying a security fix are marked security-urgent, the rest are optional — see Update a node’s version. Event streaming needs 4.8.2 or newer.

​

Ports

Ports are managed for you and aren’t user-overridable. Direct publishes both 8090 and 50051; Local closes both; Public domain proxies the HTTP API and keeps gRPC local (see gRPC and WebSocket ports). The solidity and PBFT ports are never published.

​

Node types

Tron offers Full and Lite, and the choice is really a choice of snapshot:

• Full — seeds from the full compressed snapshot and keeps deep block and transaction history. Heaviest on disk.
• Lite — seeds from the lite snapshot, so the node starts at a recent block instead of carrying history back toward genesis. Roughly a quarter of the disk on mainnet, and it serves current chain state and transactions the same way.

Both types serve the same APIs and both bootstrap from a snapshot rather than syncing from genesis (see Snapshot bootstrap). A Lite node answers history queries for the blocks it actually holds and returns empty for the range it doesn’t — including for transactions you broadcast through it, so the usual build → sign → broadcast → poll-the-receipt flow works on either type.

​

Config overrides

Tron config keys are set the same way as on any node, at deploy time — see Edit a running node. Settings that control networking, ports, and the data directory are managed and rejected if you try to set them. The keys you can override are: The rest of the node config stays intact; your overrides are merged on top.

​

Event streaming to MongoDB

A Tron node can stream chain events to a MongoDB destination through java-tron’s event plugin. It’s optional and off by default. Configure it in the deploy wizard’s Connections step (Tron always shows this step), or later on the node’s Connections tab — see Connections. It needs java-tron 4.8.2 or newer and a reachable MongoDB (host, port, database, username, and password). You choose which event streams to write: A deployment writes at most two of the streams above at once, and always at least one; the finality watermark is separate. Each stream lands in its own MongoDB collection, named <node-id>_<topic> by default — you can override the names, but they must differ between streams, and if several nodes share one database, keep their collection names distinct to avoid collisions. That two-stream limit and the decoded-or-raw choice belong to the deploy wizard. The node’s Connections tab edits the plugin at the level of java-tron’s individual topics (block, transaction, contractevent, contractlog, solidity, solidityevent, soliditylog), each with its own options, so a running node can carry any combination. Hub checks topic keys when you save: a misspelled topic is refused with component '<role>' has unknown client option '<path>' instead of being silently ignored. Optional filters (fromBlock, toBlock, contract addresses, and topics) narrow what’s written to the contract event and log streams; they don’t apply to blocks, transactions, or the watermark. Historical replay is off unless you set a start block.

​

Resuming a historical backfill

With a start block set and at least one stream enabled, a pre-start step runs on every node start and asks MongoDB (with a 5-second timeout) how far each enabled collection got. Replay then resumes from the lowest of those highest blocks, minus a safety margin of 1,000 blocks, and never earlier than your configured start block — so a restart continues the backfill instead of starting it over. Re-writing the blocks in the margin is harmless, because events are upserted.

• A collection is empty — replay starts from the configured start block.
• MongoDB doesn’t answer — the node keeps the resume point it used last time.
• The resume step itself is unavailable — the node still starts, using the resume point written on an earlier start, or the configured start block if there is none.

Credentials are write-only: the password is never shown back, appearing only as Provided / Missing in the review. Turning streaming off on Save removes the plugin and its stored credentials, but doesn’t delete any data already in MongoDB.

​

Snapshot bootstrap

On the first deploy, the node seeds from a recent compressed snapshot on a pinned mirror instead of syncing block-by-block from genesis, which cuts sync time sharply. The archive it pulls depends on the node type you chose. If the data directory already holds a synced database, the snapshot step is skipped.

​

Metrics

Block height, peer count, and last-block age are surfaced in the node view — see Node monitoring. java-tron exposes no sync-progress ratio, so Novacula judges sync from head freshness instead: while the node’s latest block is older than the freshness threshold, it reports Syncing, and it flips to Running only once the head catches up to the network tip.

​

Where to next

• Deploy a node
• Edit a running node
• Provision on bare metal · Provision on Kubernetes