Validator Insight: Burst vs Sustained Throughput.

Why a node can survive 30k+ TPS bursts on home internet - and when bandwidth really becomes the bottleneck.

ITZA is designed for real-world networks, not perfect lab links. In practice, validators see two very different types of load: short, intense bursts of TPS and longer periods of sustained high throughput. A node can often keep up with huge bursts even when its uplink is technically below the "ideal" requirement - but over time, small bandwidth deficits add up.

This section explains how ITZA’s clustered architecture, leader rotation and gossip tree make home-node validation on a basic 35Mbps upload connection viable, and what validators should know about bandwidth when joining high-TPS clusters.

Burst TPS: Short, Intense Spikes

During benchmarks or real-world traffic spikes, clusters can briefly run at extremely high TPS. In our tests, clusters operated in the tens of thousands of transactions per second while validators on consumer-grade uplinks still kept pace.

This is possible because of three design choices:

• Rotating leaders: In ITZA, each validator only leads a fraction of the time (for example, roughly 1/8 of blocks in an eight-validator cluster). Maximum outbound bandwidth is only required during those leadership windows.
• Gossip tree topology: Validators near the edge of the gossip tree act as leaf nodes with very low fanout. They may download every block but only upload their own leader blocks, dramatically reducing their average uplink pressure.
• Tolerated short-term lag: A validator that is slightly under-provisioned may drift behind by a fraction of a block during a short burst, then catch up when it is not leading. As long as the lag stays small, global TPS and finality are unaffected.

The result is that a home validator with modest upload can participate in high-TPS bursts without immediately dragging the cluster down or being slashed. Short stress tests primarily prove that the hardware and software path can handle peak execution and verification load.

Sustained TPS: When Small Deficits Add Up

Over longer runs "millions of transactions instead of a few hundred thousand" bandwidth limits become more important. A validator that is a few Mbps below the ideal outbound rate may still validate correctly, but it will very slowly fall behind.

Over time this looks like:

• Initially, the node is at or near the tip of the chain.
• After many seconds of continuous overload, it is one block behind, then two, then more.
• When it becomes leader while significantly behind, the cluster may need to wait for it to catch up, reducing effective TPS.
• If the gap becomes too large or leadership deadlines are missed, slashing and leadership penalties may apply.

This is the key distinction: ITZA can tolerate short bursts where validators fall slightly behind, but sustained overload eventually forces the network to slow down to match the slowest node in the hot path.

Bandwidth, Fanout and Gossip Position

On ITZA, the bandwidth a validator actually needs depends on more than just TPS:

• Leader share: Validators that lead more often must sustain higher outbound bandwidth, because they are responsible for injecting full blocks into the network.
• Fanout: A validator with fanout 0 (leaf) only uploads what it produces as a leader. A validator closer to the root forwards blocks to multiple peers and therefore needs proportionally more upload capacity.
• Cluster role: Clusters dedicated to heavy DeFi or gaming workloads may run closer to peak capacity for longer, while others might see short, infrequent bursts.

By adjusting gossip topology and leadership distribution, ITZA can match validators to roles that fit their connectivity - for example, placing home nodes as leaves with lower fanout while still allowing them to participate in consensus and earn rewards.

Practical Guidelines for Validators

When planning to validate on ITZA, consider the following:

• Upload matters more than download: High download speeds are useful, but the limiting factor for leadership and fanout is your uplink capacity.
• Sizing for worst case, not average: Aim to provision enough upload to handle your expected leader share and fanout at the cluster’s peak TPS, not just the average TPS.
• Role-aware placement: Validators with smaller uplinks can still be extremely valuable as leaf validators or in less congested clusters, while high-bandwidth validators can anchor the core of high-throughput clusters.
• Test both burst and sustained load: Short benchmarks show that your node can handle peak bursts; longer tests reveal whether your connection can sustain those levels without falling behind.

Why This Matters for ITZA

Many high-speed chains implicitly assume datacenter-grade connectivity for everyone. ITZA is different: it explicitly models the reality of asymmetric consumer internet and uses clustered architecture, leader rotation and gossip trees to make home-node validation practical.

This gives ITZA a unique advantage:

• Home-node friendly: Validators on residential connections can still contribute meaningfully, especially as leaf validators.
• Horizontally scalable: Additional clusters and validators increase capacity rather than concentrating it in a few large operators.
• Realistic decentralization: High performance does not require sacrificing geographic or economic diversity in the validator set.

Taken together, this makes ITZA a rare combination: a chain capable of tens of thousands of TPS per cluster, while still designed for a world where not every validator runs in a megawatt datacenter with a dedicated fiber backbone.