Earlier this year, the Quebec protocol upgrade successfully reduced block time from 10s to 8s, marking the 4th block time reduction via seamless protocol upgrades.
Continuing with the plans laid out in the Tezos X roadmap, we intend to include a further reduction of block time from 8 seconds to 6 seconds in the upcoming T protocol proposal.
Besides the lower latency, this would reduce layer 1 finality from 16 seconds to just 12 seconds.
This post aims to give the community a heads-up on this proposed change and the testing involved.
How we test block time reduction
Over the past few months, we have tested this change using the same methodology that was used to ensure safe reduction of blocktime to 10 seconds in the Paris protocol, and to 8 seconds in the Quebec protocol.
In short, to validate this change, we simulate a network designed to closely mirror mainnet conditions:
-
Scale: ~260 active bakers (comparable to mainnet).
-
Hardware (per instance):
-
n2-standard-4 (GCP Compute Engine general-purpose VM)
-
4 vCPUs
-
16 GB RAM
-
NVMe SSD
-
High-throughput, low-latency GCP network
-
-
Processes on each instance:
-
1 Octez node (L1, 2 cores)
-
1 DAL node (1 core)
-
1 baker with a delegate (1 core)
-
-
Additional infrastructure:
-
A bootstrap node (like the Tezos Foundation’s, with a DAL node)
-
Multiple operation injectors (to simulate external applications at real transaction throughput)
-
8 DAL producers (each running an Octez node + DAL node, sustaining target bandwidth of 170 KB/s)
-
-
Monitoring: All nodes include metrics and profiling for observability.
-
Network realism: To mimic real-world conditions, small delays are introduced.
-
Geographical latency: random network delays between 10 ms (close peers) and 150 ms (e.g. Los Angeles ↔ Paris).
-
Signing latency: random delays between 0 ms (Octez wallet) and 500 ms (Ledger Nano S+).
-
Results
Using the current 8-second block time on this setup, we observed results that align with mainnet, validating the accuracy of our simulation.
We then switched to 6-second block time and ran extensive experiments. These showed no negative impact on the health of the chain:
-
Consensus:
-
260 bakers consistently produced blocks at round 0.
-
Block quorum was reached in less than 3 seconds, or half the block time, leaving a margin for safety and remaining close to mainnet observations.
-
-
Bandwidth: The measured bandwidth consumption per baker was 5 Mbits/s.
-
Storage: In line with expectations, we observed a 30% increase in storage consumption, due to the increased number of blocks per minute.
-
DAL: Blocks included 8 DAL commitments and attestations as expected.
Minimal Hardware Requirements
As always, we are focused on ensuring that the Tezos blockchain can be validated on low-spec hardware, which is important for promoting genuine decentralization of the network. Our results confirm that 6-second block time is safe and compatible with existing baker hardware setups, including more recent Raspberry Pi models.
We have adjusted the recommended minimum hardware specifications to include an extra CPU core for those running the DAL, and added a concrete bandwidth recommendation:
-
4 CPU cores (2 for the node, 1 for the DAL node, and 1 for the baker)
-
8 GB RAM + 8 GB swap (or 16 GB RAM)
-
100GB SSD storage (or similar I/O performance)
-
A 10Mbits/s up/down low latency reliable internet connection
Next steps
The T protocol proposal is expected to enter the stabilization phase on October 14, and to be made available for governance injection about a month later.
We invite bakers and community members to:
-
Share details of your current setups
-
Ask questions and raise concerns you might have
This feedback will help us ensure a smooth and inclusive rollout of 6-second block time, should the proposal be adopted.
