Solana validators are caught in a dilemma between revenue and efficiency: Is delayed blocks a new strategy?

By Jack Kubinec

Compiled by: TechFlow

As Solana’s code issues have been gradually resolved over the past few years, block times (the time it takes for the network to generate a new block of transactions) have dropped significantly, even below its nominal 400 milliseconds.

However, over the past month, an interesting trend has emerged: the median block time (a key performance indicator in the blockchain network, reflecting the speed at which the blockchain network processes transactions and generates blocks) has surged, and Solana has slowed down the rate at which it adds new transactions to the blockchain. The reason is a new validator strategy, which suggests that it may be more profitable to generate blocks slowly. According to Blockworks, Anza, Jito, and Marinade are considering solving this problem.

Each Solana block has a validator that takes on the role of leader — responsible for collecting transactions, creating blocks, and broadcasting them to the network. Leaders collect transaction fees for creating blocks. More order flow means more opportunities for fees, so a validator might choose to process a transaction in 500 milliseconds instead of 300 milliseconds to increase earnings.

At a basic level, some Solana validators appear to be waiting as long as possible to get more transactions into blocks and maximize their revenue. This behavior has led to an increase in Solana’s cycle length.

This is obviously not an ideal situation for a network that aims to be as fast as Nasdaq. In addition, fewer periods means less opportunity for compounding of staking rewards, a point made by Max Kaplan, CTO of Sol Strategies.

Solana provides a mechanism called grace ticks, which is a delay period that allows a leader to still successfully submit a block. This mechanism is designed to prevent validators in remote locations from being unfairly penalized, but it also opens the door for validators to intentionally delay submitting blocks.

Additionally, Solana’s alternative client, Frankendancer, recently released a revenue-maximizing scheduler.

According to Kaplan, validators running the client appear to be packing blocks at a slightly slower rate than normal. However, Kaplan added that Frankendancer’s delays are negligible compared to more severe delayers and he does not consider this a “bad thing.” In addition, block delays are not a new concept on proof-of-stake blockchains. However, the Firedancer upgrade may make this strategy more prominent on Solana. Jump has not yet commented on this.

Interestingly, Firedancer software engineer Michael McGee described this phenomenon on the Lightspeed podcast this week. He mentioned: “One thing we’re seeing with current validators is that…[validators] tend to create more profitable blocks by delaying transaction execution.”

Blockworks Research analyst Victor Pham noted that Solana validators with more noticeable block delays are often running modified versions of the Agave-Jito client.

For example, in mid-June, during epoch 802, Galaxy and Kiln both had median block times of over 570 milliseconds. Some unflagged validators also ran slower, while Temporal’s validators had a median block time of 475 milliseconds, according to Solana Compass data.

Kiln co-founder Ernest Oppetit acknowledged that its validator — the sixth-largest staked validator on the Solana network — had been delaying block slots for a period of time, but said that this behavior has now stopped.

“At Kiln, we pride ourselves on offering the highest APY on the market without sacrificing security. We are constantly doing R&D on different parts of our stack, including our timing strategy, and are in ongoing discussions with clients, client teams, and the foundation. Currently, we follow the spec and no longer delay blocks, but many other validators still do so. We believe that the incentive problem (fast block generation leads to reduced rewards) ultimately needs to be solved at the protocol level,” said Oppetit.

“I can say that we are not the reason people are aware of this,” said Ben Coverston, director of engineering at Temporal, when asked about his validators’ apparent participation in the slow block trend.

A Galaxy spokesperson said: “As a service provider, we support validator configurations that prioritize maximizing customer staking rewards. On Solana, this may mean proposing slightly slower blocks to ensure higher rewards. Galaxy has been responsive to community feedback and has adjusted block times to be within acceptable ranges.”

However, there is widespread consensus among the Solana validator community that slowing down the network is not appropriate, and slow validators are currently facing public backlash.

They may soon face more substantial penalties. According to Blockworks, Jito plans to blacklist slow validators from its staking pool, which is the largest on the Solana network.

Brian Smith, president of the Jito Foundation, said the organization is “drafting a governance proposal to give a committee the power to remove stragglers from the JitoSOL delegation set. This proposal should be open to the community for discussion within a few days.”

Marinade co-founder Michael Repetny said the staking pool provider is “considering bringing this up as a governance proposal to discuss the pros and cons of making [slow validators] a hard rule/delegation policy violation.”

Protocol-level solutions are also being worked on. Anza’s GitHub repository shows a new proposal that suggests cutting Solana’s grace tick period in half. In addition, Solana’s proposed consensus mechanism reform is also expected to solve this problem.

“Alpenglow will solve this problem by enabling the ability to skip voting,” said Brennan Watt, vice president of core engineering at Anza.

Watt revealed in a recent episode of the Lightspeed podcast that Anza hopes to have Alpenglow live on mainnet before the Solana Breakpoint conference in December this year.