Solana Plan Groups Validators by Location, With Unverified Data

Researchers at Anza and ETH Zurich have proposed changing Solana’s leader schedule so nearby validators produce blocks consecutively. The design lowers modeled handover delays but relies on validator locations that the network cannot independently verify.

Roger Wattenhofer, Anza’s head of research and an ETH Zurich professor, and Anza and ETH Zurich researcher Quentin Kniep submitted the proposals as pull requests on Sept. 29. The schedule proposal, SIMD-0675, and its location-registration companion, SIMD-0674, remained open as of Oct. 7.

Solana would first create its usual stake-weighted random schedule, which assigns validators windows for producing blocks. A second process would arrange those windows into three-window groups, or bins, based on geographic distance. Validators would keep the same number of windows; only their order and timing would change.

The proposal targets handovers under Alpenglow, Solana’s planned fast-leader-handover system. In that system, one leader sends its block directly to the next scheduled leader. The researchers’ model assumes random scheduling can produce longer network transfers for validators outside major stake centers. Grouping nearby validators would create more local handovers.

A simulation using Solana’s mainnet stake distribution from epoch 1038 reduced the average handover delay between honest validators from 36.2 milliseconds under a random schedule to 17 milliseconds with three-window bins. The median delay across all simulated handovers fell from 23.4 milliseconds to 4.5 milliseconds.

The simulation covered 661 validators, 108,000 leader windows per epoch and five random seeds. It used validators’ nearest RIPE Atlas metropolitan areas and estimated one-way latency as half the median round-trip time between those areas. Handovers within the same metro area were assigned zero delay. The results therefore represent scheduling and estimated network latency, not performance from a deployed geographic schedule.

SIMD-0674 would store self-reported coordinates in validator vote accounts. Signed updates would identify the account that authorized a registration, while a geometric check would confirm that the reported point is near Earth’s surface. Neither check would confirm the physical location of the validator’s machine.

SIMD-0675 uses an economic incentive to discourage false reporting. A validator that reports a distant location could be placed behind leaders that are farther from its actual server. In a test of the largest validator in each of 10 cities, however, a validator physically located in Ashburn, Virginia, reduced its modeled average handover delay from 23.7 milliseconds to 21 milliseconds by reporting São Paulo as its location. The researchers found no other non-equivalent false location that improved performance by more than 0.3 milliseconds.

That test used RIPE Atlas latency to create neighborhoods and bins, while the proposed schedule uses geographic distance. It did not assess coordinated false reports or their effect on consecutive block production.

The schedule also changes how long a validator or group of validators can produce blocks in succession. In a simulation involving an adversary with 5% of total stake operating alone in Sydney, the longest adversarial sequence reached six windows, or two adjacent three-window bins. The proposal identifies regional outages, network disruptions and jurisdictional actions as possible causes of longer skipped-slot sequences and regional censorship than under a fully random schedule.

The draft combines three-window bins with a 10% stake floor. The floor determines how far a validator’s geographic neighborhood must extend to include enough active stake with valid locations. With four slots per leader window and 200-millisecond slots, one three-window bin would span 2.4 seconds, although adjacent bins could extend that period.

SIMD-0675 would also raise HANDOVER_COMPENSATION from 25 milliseconds to 50 milliseconds. The setting accounts for block production completed before the ParentReady event and shifts leader-window timeouts earlier. It is a timing adjustment, not additional validator compensation. In the geographic simulation, the interval from receiving the previous leader’s block to ParentReady increased from 23.2 milliseconds to 46.2 milliseconds.

The location-registration proposal received one approval on Oct. 5, with a suggestion to separate changes to vote-account layouts. The schedule proposal had no reviews at that point. Solana’s Foundation listed both changes as proposed, while Alpenglow remained behind devnet feature gates. If approved and activated, the new scheduling algorithm would begin two epochs after activation.