Anza researchers' Solana draft halves modeled handover delay with self-reported validator locations

No validator gains or loses a leader window under the plan ^[8]. That leaves position in the queue as the only thing being reallocated. Position matters under Alpenglow's fast leader handover, where the outgoing leader sends its block straight to the next one ^[9]. The authors argue that a random schedule favours validators near large concentrations of stake: they are more likely to follow a nearby leader, while remote operators more often face a long hop ^[9]. Grouping neighbours is meant to give the remote operator the same short hop, and the authors went that way instead of redistributing stake or adding windows ^[10].

The sorting key is a coordinate each validator supplies ^[2]. According to CryptoSlate, a signed coordinate proves it was authorised and that its geometry is valid, while whether the machine actually sits there is left to incentives ^[14]. The simulation did not take self-reports at face value. It used the epoch 1038 mainnet stake distribution, corrected the locations of its 661 validators against Globalping measurements, and ran 108,000 leader windows per epoch across five random seeds ^[12]. So the cut in mean honest-to-honest delay, 19.2 milliseconds or about 53% ^[16], was measured on checked locations. The live schedule would sort on reported ones ^[2].

The latency model also favours the design it evaluates. It maps each validator to the nearest RIPE Atlas metro, takes half the median round-trip time between metros as the one-way delay, and prices any handover inside a single metro at zero ^[13]. A scheme built to put neighbours back to back gains most from that zero. The median across all handovers falls from 23.4 to 4.5 milliseconds ^[5], an 81% drop ^[17]. These are transfer delays, a different interval from slot duration or transaction finality ^[15].

Then there is continuity of control. The draft pairs three-window bins with a 10% stake floor that sets how far a validator's neighbourhood must reach to gather enough stake, so a dense area gets a small radius and a sparse one a large radius ^[11]. A finished bin can still hold under 10% of stake and repeated windows from one operator ^[11]. The six consecutive adversarial windows in the isolated-attacker run ^[6] are two full bins back to back ^[18].

If operators report honestly, remote validators get shorter hops and nobody's allocation changes ^[8]. If some report a location chosen for where it puts them in the queue, the outcome moves toward the case the authors simulated, with an isolated party holding longer runs of control ^[6]. I think the latency case holds up as modeled. The honesty assumption is the risk operators and SOL holders would be taking on, because location is the one scheduling input the chain cannot check ^[14]. That view is wrong if measured handovers on a live deployment come in near the modeled 17.0 milliseconds ^[4] while reported coordinates match independent probes.