Solana’s geographic speed plan trusts validator locations the network cannot verify

Roger Wattenhofer and Quentin Kniep have put forward a proposal to accelerate Solana’s block generation by consecutively scheduling validators that operate close to one another. Because their strategy depends on self-reported validator locations, it introduces a physical metric that the network cannot independently verify into the block-producer ordering process. Each designated block-production turn is referred to as a leader window.

The main objective is to reduce the reliance of fast handovers on operating in close physical proximity to Solana’s largest stake concentrations. In the authors’ simulations, the mean handover delay among honest validators dropped from 36.2 milliseconds down to 17.0 milliseconds, and this improvement was achieved without assigning any validator extra leader windows. At the same time, this reordering alters control continuity, allowing three-window clusters to merge into longer blocks of consecutive control.

Wattenhofer, who serves as Anza’s head of research and is a professor at ETH Zurich, co-authored the geographic scheduling plan alongside Kniep, who identifies as a researcher with both Anza and ETH Zurich. Their draft, designated as SIMD-0675, highlights this inherent tension by documenting six consecutive adversarial windows under the proposed three-window configuration.

Both the scheduling framework and its companion location-registration proposal were submitted as GitHub pull requests on September 29. As of October 7, both remain under review as open proposals reflecting modeled simulations rather than active deployments on a live geographic schedule.

Geographic order for the same allocations

Under this system, Solana would initially compute its standard stake-weighted random leader schedule. A secondary phase would then group those leader windows into smaller segments known as bins, utilizing reported geographic proximity.

A leader is designated as the validator responsible for constructing blocks during a specific window. Every validator keeps the exact same allocation of windows it received in the initial schedule; the modification only affects the timing of those opportunities and the identity of the preceding leader.

This predecessor relationship is critical under Alpenglow’s fast leader handover mechanism, where the outgoing leader transmits its block directly to the incoming one. The authors assert that traditional random scheduling benefits validators situated near major stake clusters because they are more likely to be near their preceding leaders, whereas remote validators frequently encounter lengthy network hops.

By grouping geographically close leaders together, the design aims to provide validators situated outside major hubs with more localized handovers. The intended decentralization advantage acts as an operational incentive to move away from current hubs rather than acting as a mechanism for stake redistribution or extra leader assignments. The underlying simulations focus exclusively on scheduling and latency metrics, leaving actual operator relocations and stake shifts outside of their scope.

The draft pairs a bin size of three windows with a 10% stake floor. This floor dictates the minimum geographic radius a validator’s neighborhood must cover to accumulate sufficient stake. Densely populated regions result in a smaller required radius, whereas sparse areas demand a larger one. The threshold applies to active stake holding valid reported locations. Consequently, a finalized bin may account for less than 10% of total stake and can include multiple windows assigned to the same operator.

The run-length simulation models the mainnet stake distribution from epoch 1038, incorporating 661 validators whose geographic coordinates were verified and corrected using Globalping data. Each simulated epoch encompasses 108,000 leader windows, and final metrics represent averages derived from five random seeds.

Geographic distance dictates bin assignments. To gauge handover speeds, the model associates validators with their closest RIPE Atlas metropolitan area and estimates one-way latency as half of the median round-trip time between those specific regions. Handovers occurring within the same metropolitan area are treated as having zero delay.

Within a standard random schedule, the average delay between honest validators sits at 36.2 milliseconds. Utilizing three-window bins shrinks that figure to 17.0 milliseconds. When examining the median across all handovers—a different statistical population—the metric drops from 23.4 milliseconds down to 4.5 milliseconds.

These figures point toward a substantial modeled decrease in transfer delays. However, slot durations and transaction finality metrics measure separate timeframes than modeled transfer delays. Furthermore, the assumption of zero latency within metropolitan areas simplifies the actual network hurdles validators encounter.

A broader perspective suggests treating geographic location as a useful yet imperfect proxy. An August study released by the Solana Foundation linked greater geographic distances with handoff penalties, though it cautioned that distance itself had not been proven as the root cause, as routing, peering, and validator hardware configurations were not tracked.

Consecutive control and location incentives

The security trade-offs emerge clearly within the same simulation. Consider an adversary controlling 5% of the total stake located in Sydney, with no other validators present in Oceania. The authors characterize this isolated setup as a near worst-case scenario because the attacker can entirely populate bins independently.

This scenario interacts with the 10% stake floor constraint. While the floor guides neighborhood formation, the example of an isolated 5% attacker demonstrates how actual control over a bin can diverge from that radius-based threshold.

An attacker controlling the concluding leader of one bin can maintain control across the boundary into the next. Under the proposed parameters, the longest sequence of adversarial control observed spanned six windows, formed by two back-to-back bins. This dynamic highlights that adjacent bins can stretch consecutive control beyond the intended bin limits.

The draft concedes that regional power failures, network outages, or jurisdictional interruptions could impact consecutive leaders under this model, potentially triggering longer sequences of skipped slots than what would occur under a fully random schedule. It also notes an increased risk of localized censorship during network operations.

Adopting the draft’s baseline assumptions of four slots per leader window alongside 200-millisecond slots, a three-window bin theoretically lasts for 2.4 seconds. While this figure defines a single bin under specific timing parameters, regional disruptions can span across multiple bin boundaries.

The authors acknowledge another balance between speed and security. An alternative approach introduced on October 2 would sequence leaders along the shortest geographic route inside each bin. The draft declines to implement this alternative, noting that it would compromise the symmetry of the randomized schedule and make adjacent slots easier to predict for co-located malicious validators.

The complementary SIMD-0674 specification aims to embed self-reported coordinates directly into validator vote accounts. Cryptographically signed updates would verify who authorized a given registration, and geometric checks would confirm that the reported point sits near the Earth’s surface. However, the physical location of the underlying machine remains unverified by these checks.

Consequently, SIMD-0675 depends largely on an economic rationale: submitting a false, distant location will frequently position a validator behind leaders located further away from its actual hardware, ultimately resulting in slower handovers for the misrepresenting node.

The authors tested this premise by selecting the largest validator across ten distinct cities, keeping their physical hardware stationary while altering their registered city. A modeled validator in Ashburn managed to reduce its average handover delay from 23.7 milliseconds down to 21.0 milliseconds by claiming to be in São Paulo, marking a reported improvement of 2.7 ± 0.2 milliseconds.

Aside from this instance, the authors noted no other non-equivalent misrepresentation yielding gains greater than 0.3 milliseconds.

This experiment relied on RIPE Atlas latency metrics to form neighborhoods and bins, whereas the proposed scheduling protocol relies strictly on geographic distance. Because these individual incentive outcomes leave coordinated dishonest location reporting and its impact on consecutive control unaddressed, questions remain.

While false reporting typically harms the speed of the validator executing it, the Ashburn exception complicates the argument for relying entirely on economic incentives to ensure truthful physical location reporting.

Timing compensation and the review ahead

Another variable within the proposal has the potential to overshadow the core speed claims. SIMD-0675 proposes increasing the HANDOVER_COMPENSATION parameter from 25 milliseconds to 50 milliseconds, even as overall transfer delays decrease.

This separate compensation mechanism accounts for optimistic block production activities that occur prior to ParentReady, which is the protocol event that initiates the official production timer. Compensation subtracts duration from the initial slot’s production budget following that event and shifts leader-window timeouts earlier. This represents an internal timing adjustment rather than financial remuneration for validators.

The geographic simulation extends the duration between receiving a prior leader’s block and the ParentReady event from 23.2 milliseconds to 46.2 milliseconds. This distinct time gap accounts for the higher compensation setting, even while transfer latency metrics decline.

At present, the scheduling pull request has received no formal reviews. The location-registration pull request secured approval from user buffalojoec on October 5, accompanied by a reservation regarding the potential need to separate vote-account structural updates, but it remains open. Similarly, the Solana Foundation’s October 1 changelog designates both changes as proposals while listing Alpenglow under Devnet feature gates.

Because the scheduling protocol affects network consensus, its implementation requires a specific feature gate, though the current draft leaves its feature key and tracking metrics blank. The suggested rollout plan would deploy the new algorithmic model starting two epochs after activation.

Ultimately, the core question for reviewers is whether the modeled decreases in latency and co-location advantages sufficiently justify altering the continuity and structure of block production.

Frequently Asked Questions

• What is the main goal of Solana’s proposed geographic speed plan? The proposal seeks to reduce block handover delays by scheduling nearby validators consecutively, minimizing dependence on operating near major stake hubs.
• How does the proposal handle validator locations? It relies on self-reported geographic locations provided by validators, paired with an economic incentive structure where false reporting generally results in slower handovers.
• What are the main security risks identified in the draft? Grouping validators geographically can increase the risk of extended consecutive control by adversarial nodes, potentially leading to longer sequences of skipped slots or localized censorship.
• Are these changes currently live on the Solana network? No, the scheduling and location-registration changes are currently open pull requests and modeled simulations rather than deployed features.

---