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 sustained high throughput, resource constraints - including CPU, storage I/O, and bandwidth - begin to impact validator performance. A node operating below the required capacity may still validate correctly, but will gradually fall behind the current chain state.

In practice, this manifests as:

• The node initially remains close to the tip of the chain
• Under continuous overload, it begins to lag - first by one block, then progressively more
• If selected as leader while behind, it may fail to produce a valid block within the required time window
• Missed or invalid leadership results in penalties, reduced future allocation, or temporary removal from rotation

Crucially, the network does not wait for underperforming nodes.

ITZA is designed to tolerate short-term variance in node performance, but under sustained overload, slower validators are penalized or excluded, allowing the cluster to continue operating at the capacity supported by active, synchronized participants.

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.

Validator Bandwidth Requirements Based on TPS

Each transaction on the ITZA Blockchain averages 180 to 183 bytes, depending on whether the sender repeats or varies. For benchmarks or high-throughput testing, transactions sent to the leader are approximately 180 bytes each. Once processed, these are propagated across the network as full block entries at around 183 bytes per transaction, or as low as 150 bytes if senders are reused (typical in synthetic tests). For a validator targeting 10,000 TPS on a single cluster, this translates to a sustained upload requirement of 12 to 14.6 Mbps. Validators planning for 30,000 TPS should expect to provision 36 to 44 Mbps, ensuring enough headroom for propagation, block headers, and protocol overhead.

Validators operating multiple clusters must multiply these figures by the number of clusters they manage, as each cluster's traffic is handled independently.

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.