feat(net): optional anonymous transaction broadcast over Tor

[tanderbold]

What

Adds an optional feature to anonymize the origin of transactions a node broadcasts, by
relaying them over Tor instead of advertising them to directly-connected P2P peers. Off by
default (node.tor.enabled = false) — no behaviour change unless explicitly enabled.

Why

When a node submits a transaction through its own broadcast API, it advertises that transaction
to its sync peers, which exposes the node's IP as the transaction's origin. For users who need
origin privacy this links their IP to their transactions. Block sync and normal P2P traffic are
too heavy to run over Tor, but a single transaction is tiny — so only the outbound transaction
broadcast is routed through Tor, while block sync and everything else keep running on the clear
net.

How

When node.tor.enabled is true, a submitted transaction is still validated and pushed locally as
usual, but instead of being advertised to sync peers it is relayed via the native TRON P2P
protocol through the local Tor SOCKS5 proxy to standard, unmodified full nodes learned from the
discovery layer that are NOT current sync peers. Those nodes re-gossip it as they would any peer's
transaction, hiding the origin.

• Persistent tunnel pool — reaching a Tor peer and completing the handshake costs several
  seconds, paid per connection, not per transaction. The service keeps a pool of persistent,
  handshaked Tor tunnels to verified at-head relays, reused for every broadcast and kept alive by
  answering keep-alive pings.
• Batched & async — transactions are buffered and flushed as a single TransactionsMessage
  batch (capped) over broadcastCount tunnels in parallel, so a burst is delivered in about one
  round-trip; broadcastTransaction enqueues and returns immediately.
• Anonymity — each tunnel advertises a fresh random public IP (never the real one) and a fresh
  random node id per hello, so tunnels can't be clustered or linked to the clear-net node; SOCKS
  connects by raw IP (no DNS leak); there is no clear-net fallback on failure.
• Resilience — no transaction is lost if Tor or a relay is down or degraded: it stays buffered
  until a tunnel can be (re)built; expired transactions are evicted; a stalled tunnel's write is
  bounded and the tunnel is rebuilt; pool refill is adaptive with exponential backoff so a
  congested Tor isn't flooded with circuit requests; and, optionally, the node signals NEWNYM
  over the Tor control port to rebuild circuits with fresh exit IPs when no tunnel can be built.

libp2p is used as a library only; it is not modified.

Configuration (node.tor)

node.tor {
  enabled = false
  socksHost = "127.0.0.1"
  socksPort = 9050
  connectTimeout = 30000
  readTimeout = 30000
  broadcastCount = 2          # number of relays to push each transaction to
  circuitIsolation = true     # a distinct Tor circuit per connection
  controlPort = 0             # optional: Tor ControlPort for NEWNYM recovery
  controlPassword = ""
}

Testing

• Automated — end-to-end delivery over a persistent tunnel via an in-process SOCKS5 forwarder
  and a stub node; Tor-outage and relay-degradation recovery; NEWNYM on a stuck pool; and routing
  (Tor path when enabled, normal P2P broadcast when disabled). All tests and checkstyle pass.
• Live — validated end-to-end on the Nile testnet: a 45-minute run at 5–10 tx/min with 200-tx
  spikes every 5 minutes delivered every transaction on-chain, while block sync continued on the
  clear net.

[bladehan1]

Whether to support Tor network broadcasting should be thoroughly discussed in the issues section.
This PR should be closed for now, and we'll wait for a clear demand before pushing it forward.

[317787106]

@tanderbold Thank you for the contribution and the detailed implementation.

After evaluation, java-tron does not plan to support Tor integration at this time. Transactions are already propagated through the P2P gossip network, which makes reliably identifying the original sender difficult in practice.

Although this does not provide a formal anonymity guarantee, routing transaction broadcasts through Tor offers limited additional benefit for the current threat model and user demand.

Meanwhile, Tor integration introduces considerable implementation, configuration, testing, security, and long-term maintenance complexity. We do not believe the incremental benefit currently justifies that cost.

We may revisit this decision if there is clear user demand and a well-defined threat model that cannot be adequately addressed by the existing P2P propagation mechanism. For now, we may close this PR. Thank you again for your work and understanding.