Le calendrier des leaders décide quel validateur a le droit de produire un slot. Il attribue aujourd'hui à chaque validateur des fenêtres de quatre slots consécutifs par époque, selon un tirage aléatoire pondéré par le stake, mécanisme hérité de la sélection des producteurs de blocs par preuve d'enjeu. Ce tirage ignore la position physique des machines. Deux leaders successifs peuvent partager le même centre de données ou se trouver aux antipodes, et le relais coûte alors des dizaines de millisecondes de pur délai de propagation.

Que change SIMD-0675 au calendrier existant ?

SIMD-0675 ne remplace pas le tirage. La proposition ajoute une étape de post-traitement qui réordonne le calendrier produit par SIMD-0180, afin que les leaders consécutifs soient géographiquement proches et que le passage de relais rapide d'Alpenglow perde moins de temps. Chaque validateur conserve exactement le même nombre de fenêtres de leader qu'avant, seul leur ordre change. Le réordonnancement repose sur deux paramètres. STAKE_FLOOR fixe, pour chaque emplacement, le plus petit rayon contenant au moins cette fraction du stake total : les zones denses obtiennent un petit rayon, les validateurs isolés un grand. RUN_LENGTH fixe la taille des groupes, les leaders compatibles s'accumulant dans un même panier qui est mélangé puis écrit d'un bloc dans le calendrier final dès qu'il atteint la taille voulue.

Comment un validateur déclare-t-il sa position ?

C'est l'objet de SIMD-0674. Le validateur enregistre sa position physique dans son compte de vote, sous la forme d'un triplet d'entiers en coordonnées ECEF, un repère cartésien centré sur la Terre, via une nouvelle instruction du programme Vote. Les calculs qui touchent au consensus, contrôle de validité et distance de corde au carré, se font en arithmétique entière exacte sur 64 bits, sans virgule flottante ni trigonométrie. Le texte étend SIMD-0185 (Vote Account v4) et reprend le schéma d'enregistrement de SIMD-0387. Rien n'empêche techniquement un validateur de déclarer une position fausse. Les simulations de SIMD-0675 couvrent ce cas de figure, et l'analyse publiée par Solana le 14 octobre 2026 indique qu'un STAKE_FLOOR élevé rend cette attaque par fausse position plus coûteuse.

Que disent les simulations sur les paramètres ?

L'analyse du 14 octobre détaille le cadre retenu :

  • les 124 emplacements où tournent les validateurs Solana aujourd'hui, regroupés en six macrorégions
  • 6 250 réseaux synthétiques, obtenus en redistribuant nœuds et stake avec différents niveaux de concentration
  • 108 000 fenêtres de leader par calendrier simulé, avec une latence déduite de la seule distance

À STAKE_FLOOR de 10 %, le gain moyen sur le relais passe de 15,8 ms pour un RUN_LENGTH de 2 à 33,9 ms pour un RUN_LENGTH de 50. Le gain augmente avec RUN_LENGTH et diminue quand STAKE_FLOOR monte. L'analyse recommande de maintenir STAKE_FLOOR autour de 10 %. Au-delà, l'Asie, qui pèse environ 10,4 % du stake aujourd'hui, perd ses paniers locaux. Pour RUN_LENGTH, elle écarte toute valeur supérieure à 7 et place la fourchette utile entre 3 et 7. Dans un commentaire du 15 octobre sur la pull request, un relecteur juge 3 le choix le plus conservateur, sans argument fort contre 7. Les auteurs précisent n'avoir ajouté aucun emplacement nouveau, faute d'indice qu'un autre site soit prêt à héberger des nœuds Solana. La géographie simulée reste donc aussi déséquilibrée qu'aujourd'hui, et les conclusions sont conditionnées à cet état.

Qui est concerné par le changement ?

Pour les utilisateurs et les développeurs d'applications, une latence de relais plus basse signifie moins de temps mort entre deux leaders, donc davantage de slots par unité de temps réel. Le document prévient en revanche que les émetteurs de transactions ne doivent plus supposer que deux leaders consécutifs sont géographiquement indépendants. Les validateurs installés dans des zones peu denses sont ceux qui y gagnent le plus, puisqu'ils auront bien plus souvent un prédécesseur proche qu'aujourd'hui. Pour les contributeurs au cœur du protocole, le calcul du calendrier devient plus complexe et dépend de positions déclarées. Sur le MEV, le cadre de simulation suggère une hausse absolue limitée des opportunités liées aux fenêtres consécutives, à STAKE_FLOOR de 10 %.

Où en sont les deux propositions ?

Les deux pull requests ont été ouvertes le 29 septembre 2026 sur le dépôt des SIMD. SIMD-0674 a reçu le 5 octobre l'approbation d'un contributeur, qui a aussi signalé qu'un SIMD dédié à un Vote Account v5 pourrait être préférable, piste suivie par SIMD-0677. La fusion exige au moins une approbation d'un membre d'Anza et une d'un membre de Firedancer. Les deux textes restent au statut de brouillon, sans date d'activation. Les simulations jointes à SIMD-0675 s'appuient sur la distribution du stake de l'époque 1038 relevée sur le réseau principal, par opposition aux réseaux de test, avec des latences mesurées par RIPE Atlas, là où l'analyse du 14 octobre travaille sur des distances. SIMD-0675 propose au passage de faire passer le paramètre HANDOVER_COMPENSATION de SIMD-0630 de 25 ms à 50 ms. Trois pull requests marquées « work in progress » référencent ces travaux côté Firedancer depuis le 15 octobre, dont une sur l'enregistrement de la position des validateurs.