Skip to content
Tenzro
← All articles
Networking

Networking for Distributed Inference: Gossip, Re-announcement and Load

A network of machines behind home routers, carrier NAT and corporate proxies still has to deliver every transaction and every heartbeat. How Tenzro's transport, gossip budgets and re-announcement keep messages from getting lost under load.

Tenzro Network
5 min read

Distributed inference is usually discussed as a compute problem. In practice, a network of independently operated machines fails first on messages. A transaction that one validator never saw, a provider heartbeat dropped by a congested neighbour, a node that cannot be reached because it sits behind two layers of NAT: each of these turns into a stuck payment, a request routed to a dead provider, or a node that silently stops participating.

This post covers the transport choices and delivery rules Tenzro uses so that messages arrive under real network conditions and under load.

One endpoint, many protocols

Every Tenzro node runs a single QUIC endpoint, built on iroh. Topic gossip, validator consensus channels, block sync, state sync, inference between nodes, content-addressed blob transfer, and the agent protocols (A2A and MCP) each run on that endpoint under their own ALPN. One endpoint means one NAT traversal, one connection per peer and one place to apply limits.

Identity and address are separated. A node's endpoint key is generated at every start and held only in memory. The machine's hardware key signs a short-lived record naming its current endpoint and the relays it is reachable through; records name relays, never IP addresses. Peers trust an endpoint only through a record the claimed machine identity signed. Every endpoint offers the X25519MLKEM768 hybrid key exchange first, so two nodes always agree on post-quantum key exchange.

Reaching machines nobody can dial

Most edge and home machines sit behind NAT, and a growing share sit behind carrier-grade NAT. A node needs no inbound port and no firewall rule: it works from any network that allows outbound HTTPS. It tries five paths at once:

  1. Port mapping, when the router answers UPnP, PCP or NAT-PMP.
  2. Hole punching, which works when the NAT keeps one public port for all peers (endpoint-independent mapping in RFC 4787 terms).
  3. Birthday punching for one symmetric NAT facing an endpoint-independent one: the node opens 256 sockets toward the peer and the peer sends 1,024 probes to random ports, giving about a 98% chance one lands on a mapping. The birthday approach is well known; the bounds keep it polite, with each attempt capped at five seconds and not repeated for the same peer within ten minutes.
  4. Peer relays: a staked edge operator's node that both sides reach directly over UDP forwards their packets as QUIC datagrams, still end-to-end encrypted.
  5. HTTPS relays on TCP 443 when nothing else works, including networks that block UDP or force a proxy.

Relays are an operator role, not infrastructure one party runs. A relay is admitted only by its operator's signed record and staked bond, validators probe it on the same service-level schedule as any other bonded role, and it only ever sees ciphertext. The node's built-in diagnostic tells an operator which path it is on and what to change:

$ tenzro-node doctor
  NAT          endpoint-independent: every peer sees the same address and port
  reachable    directly, through a port the router mapped
  relay        https://relay.example.org/ (connected)

Gossip that degrades gracefully

Broadcast topics (blocks, certificates, validator announcements, transactions, provider announcements, heartbeats) run on iroh-gossip, which combines HyParView membership with PlumTree broadcast. Gossip is efficient and lossy by design. The question is what gets lost when a node is overloaded.

Tenzro's answer is two budgets per neighbour per window. One covers the topics consensus and sync depend on: certificates, blocks, validator announcements and status. The other covers everything else, transactions included. A message over its budget is dropped without penalty, so a busy relay sheds its excess general traffic and never its certificates. The window, both budgets and the ban length are governed parameters that nodes reread as governance changes them.

Every received message is checked before it is passed on: the neighbour must not be banned and must be within budget, duplicates are dropped, and the message must fit 1 MiB, decode and validate. Neighbours are scored only on invalid messages, and topics join through the best-scored peers. Provider announcements and heartbeats carry a session signature certified by the provider's hardware identity key and are verified against the key registered on chain, never a key the message carries.

Messages that cannot tolerate loss do not use gossip at all. Consensus frames, block sync, data-availability custody, database replication and inference requests each run as point-to-point streams on their own ALPN.

Keeping transactions from getting lost

Lossy gossip plus a busy network can strand a transaction: accepted by the node a wallet talked to, never seen by the validators that would order it. The sender sees "accepted" and then nothing.

Tenzro closes that gap at the origin. The node that admits a transaction over RPC publishes it at once, from the RPC handler rather than its event loop, so a node busy importing blocks does not delay it. Until a block includes the transaction or the mempool drops it, that node publishes it again, first after 5 seconds and then at doubling waits up to 60 seconds, at most 512 transactions per second, in sender and nonce order. A validator whose subscription lagged still receives it, and a sender's later transactions do not queue behind a missing nonce.

Validators handle the other side. When a validator's mempool refuses a transaction for a reason that passes as blocks execute (a nonce window, a pending cap, a rate limit, the fee floor, a full mempool), it holds the transaction, never relays it, and offers it to its mempool again until it is admitted, refused for good or too old:

toml
[held_transactions]
max_age_secs = 300        # dropped after this long
max_held = 4096           # past this many, the oldest is dropped
retry_interval_ms = 1000  # how often the held ones are offered again

A transaction always travels under its origin's envelope; no node republishes it under a new one. Within the validator set, transaction data moves in batches that each validator pushes to every other over its consensus channels, ahead of the vertices that order them.

Latency where it counts

For inference, latency is mostly a routing problem, and the network supplies the inputs. Providers send a signed heartbeat every two seconds; three missed intervals mark one down. Routers measure latency on their own clocks and hedge requests that pass the provider's observed p95. Every node checks the staked relays every five minutes and keeps connections to the two peer relays with the lowest round-trip time. Validators, which talk to every other validator, should have a direct path; one behind an uncooperative NAT still works through relays at higher latency, and the diagnostic says so.

What this means for telcos and infrastructure operators

Design for the networks machines actually sit on: carrier NAT, symmetric NAT, proxies, captive portals, IPv6-only. Separate the traffic that must not be dropped from the traffic that may be. Make the origin responsible for re-announcing until inclusion, with bounded backoff. And make relaying a role anyone can take on and be held to, which is a natural fit for operators with edge sites.

Where Tenzro fits

Built: the single QUIC endpoint with per-protocol ALPNs, signed endpoint records without published addresses, hybrid post-quantum key exchange, five-way NAT traversal including staked peer relays, two-class gossip budgets with governed limits, point-to-point protocols for loss-intolerant flows, origin re-announcement with doubling backoff, validator-held transactions, and the connectivity diagnostic. The network is live in preview; governance decides the steps to testnet and mainnet.

Sources

  1. RFC 9000: QUIC, A UDP-Based Multiplexed and Secure Transport
  2. RFC 4787: NAT Behavioral Requirements for Unicast UDP
  3. iroh-gossip protocol (HyParView membership, PlumTree broadcast)
  4. How NAT traversal works (Tailscale)
  5. RFC 6887: Port Control Protocol (PCP)