Solana has come close to halving its block generation time, as developers prepare to activate the final stage of a network upgrade aimed at bringing block generation time down to 200 milliseconds on Friday, 9 October.
According to Anza, the developer of Solana's Agave validation software, the reduction of the time interval from 250 milliseconds is scheduled for epoch 1053, which is expected to arrive at approximately 15:00 UTC.
The upgrade will allow Solana to process five potential mining slots per second, twice the rate supported by the original configuration with a 400-millisecond interval.
These changes follow three reductions completed since August under SIMD-0525, a proposal designed to improve network response time while keeping overall computational capacity relatively stable.
Solana Prepares Final Time Reduction Under SIMD-0525
Solana began reducing the target slot duration on 21 August, when it was cut from 400 milliseconds to 350 milliseconds. A second reduction to 300 milliseconds followed on 28 August, and on 18 September the target reached 250 milliseconds.
The final stage will complete the planned sequence of steps, reducing the time available to each validator to create a block.
A slot is a short period of time during which a designated validator can process transactions and propose a block. With shorter slots, wallets, exchanges, and decentralized applications can receive information about new transactions more frequently.
In the Solana Foundation's update documentation, the reduction is described as an attempt to improve latency and limit the time during which individual validators control block creation.
Under the existing scheme, validators create blocks over four consecutive time intervals. Previously, each validator had a 1.6-second window for ordering transactions, with the time per interval being 400 milliseconds.
Once the target interval of 200 milliseconds is reached, the same four-slot time interval will last only 800 milliseconds.
Reducing the time window for processing transactions may limit the time validators can use to delay transactions or extract profit from price differences between Solana and other trading venues.
The network will maintain control over the amount of computational work permitted in each block.
Over 250 milliseconds, a block can contain up to 37.5 million compute units. In the final configuration, this limit is reduced to 30 million compute units.
Although blocks are expected to arrive more frequently, each of them will contain proportionally less computational work. The goal of the adjustment is to keep theoretical computational capacity roughly unchanged.
The phased rollout includes safeguards that could prevent further slot reductions if the block skip rate exceeds an acceptable threshold.
Solana's Higher Block Generation Rate Places New Demands on Validators
Shortening slot durations will require validators to operate on a tighter schedule, especially those who submit votes during every available slot.
With the original configuration of a 400-millisecond interval, the network planned to process 2.5 slots per second. With a 200-millisecond interval, the target rises to five.
As a result, validators voting on every slot will need to send votes twice as often, which could potentially increase operational costs and place additional strain on network connections.
Transaction processing is another aspect that needs to be considered when working with electronic wallets and applications.
Solana transactions use the hash of the latest block, which helps prevent the replay of previously processed transactions.
Block hashes remain valid for a limited number of recent blocks. As the network generates slots more frequently, the time available to submit a transaction using a specific block hash shrinks.
Deadlines for transactions requiring manual authorization, multiple signatures, or offline approval may become tighter.
The network's actual performance will depend on how validators respond to the accelerated schedule.
Data from the Solana Compass satellite over recent periods showed that the average duration of time intervals is approximately 266 to 269 milliseconds, which is below the previous target of 250 milliseconds.
The difference between the set target and observed performance indicates that the network does not always achieve the planned duration of the time interval.
Developers have already implemented the 200-millisecond interval configuration on test and dev networks, but mainnet performance will partly depend on how often validators skip the production slots allocated to them.
Read also:
