Jump’s Firedancer Proposes Removing Solana’s Fixed Block Limits, Scaling With Validator Power

What Happened

The SIMD-0370 proposal would create market-driven incentives where block producers continuously upgrade equipment to pack more transactions and earn higher revenues.

The proposal follows Solana’s overwhelmingly approved Alpenglow consensus upgrade, which received 99.60% validator support with 149.3 million SOL voting in favor.

Alpenglow introduces skip-vote mechanisms that make fixed block limits redundant by automatically bypassing blocks that take too long to execute.

The system relies on Stackelberg competition dynamics where block producers signal network capacity through slightly larger blocks, coordinating upgrades without explicit communication.

Additionally, validators requiring expensive hardware upgrades to remain competitive could exclude smaller operators from the network entirely.

Being a new proposal, developer discussions have also revealed significant concerns about compatibility with future protocol upgrades, particularly multiple concurrent proposer architectures that may require block limits for asynchronous execution.

Market Context

Jump Trading’s Firedancer team has proposed eliminating Solana’s fixed compute unit block limits, allowing validators to dynamically scale transaction capacity based on their hardware performance rather than arbitrary protocol restrictions.

Under the current system, network capacity is artificially constrained by compute unit limits rather than actual validator capabilities.

The proposal would create a competitive flywheel, where block producers must continuously improve their performance to maximize transaction fees and maintain their market share.

Firedancer developers argue that superior validator clients would capture larger market shares as operators seek higher rewards.

Community feedback also highlighted potential failure modes during rapid capacity scaling, including scenarios where advancing execution speeds could push networks below critical vote thresholds.

Why It Matters

They argued that validators with expensive hardware could dominate, while smaller operators struggle to keep pace.

Others question compatibility with future multiple concurrent proposer designs that may require synchronized execution limits.

Hardware Arms Race Could Transform Network Economics

Community members questioned whether new validators could sync from snapshots if block complexity increases rapidly.

The proposal acknowledges these risks but argues that replay performance typically exceeds block production speed, maintaining reasonable barriers for network participation.

Details

Firedancer argues that this creates perverse incentives, where superior hardware provides no competitive advantage, thereby stifling innovation and network growth.

However, despite its innovative sound, the proposal has sparked some community debate, with critics warning about potential centralization.

Validators running slower client software would face reduced profitability, incentivizing rapid adoption of performance improvements across the ecosystem.

This competition would drive faster innovation cycles compared to manual limit increases that require community consensus and lengthy implementation periods.

Validators unable to process these larger blocks would skip them, creating natural feedback loops that prevent excessive block sizes from forming.

Critics raise concerns about centralization pressures as geographic proximity to block producers provides execution advantages.

Technical Hurdles Challenge Implementation Timeline

The Firedancer team argues these features remain uncertain and should not constrain current improvements.