Le cofondateur de Solana, Anatoly Yakovenko, a déclaré qu'Alpenglow aurait pu être livré en moitié moins de temps grâce à un changement plus simple du programme de vote, avant la migration de consensus du 21 octobre qui supprimera les transactions de vote des validateurs des blocs.
Résumé
- Yakovenko a déclaré qu'un changement plus simple du programme de vote aurait pu réduire de moitié le temps de développement d'Alpenglow.
- La suppression des transactions de vote des validateurs réduira les chiffres de TPS affichés sans nécessairement modifier l'activité des utilisateurs.
- Des frais d'admission de 0,8 SOL brûlés par époque remplaceront les frais de vote individuels.
- Certains nœuds RPC pourraient recevoir les mises à jour de finalité plus tard que l'objectif de 150 millisecondes d'Alpenglow.
Yakovenko, dans une publication X du 21 octobre, a fait cette remarque en citant un commentaire célébrant la suppression prévue des votes on-chain et se moquant de la critique récurrente selon laquelle la plupart des transactions par seconde de Solana consistent en votes de validateurs.
« Alpenglow aurait été livré en moitié moins de temps s'ils avaient simplement changé le programme de vote pour la machine à états ag »
La conception publiée d'Anza décrit un remplacement de TowerBFT, le système que les validateurs ont utilisé pour s'accorder sur les blocs, avec un vote direct et des certificats compacts.
La migration du mainnet a été programmée pour le 21 octobre, comme crypto.news l'a précédemment rapporté en couvrant le transfert de consensus prévu. Les directives mises à jour de la Solana Foundation identifient l'époque 1064 comme déclencheur et estiment son début à environ 13h20 UTC.
La page de migration d'Anza sépare l'activation de la fonctionnalité du transfert de consensus. La frontière de migration intervient 5 000 slots plus tard, lorsque les blocs ne portent temporairement que des votes pendant que les validateurs achèvent la transition.
Alpenglow retire les votes des décomptes de transactions affichés
Les directives de migration de la Solana Foundation indiquent aux explorateurs et aux services d'analyse de réinitialiser les bases de référence des décomptes de transactions et des TPS, car les transactions de vote disparaîtront des blocs. Un total incluant les votes diminuera même si les paiements, les échanges et autres transactions non-vote restent inchangés.
La Foundation indique que les services suivant la participation des validateurs doivent remplacer leur lecture des instructions du programme Vote par les données de certificat dans les pieds de bloc. Ses directives notent que le message de pied de page gRPC de Yellowstone ne transmet pas encore ces certificats.
Les développeurs ont eu accès au comportement modifié lorsque Alpenglow a atteint le devnet en septembre, après la transition du testnet. La couverture du 26 septembre décrivait comment les explorateurs doivent garder les blocs candidats concurrents séparés jusqu'à la confirmation, en conservant le bloc sélectionné au lieu de combiner leurs transactions.
La documentation opérateur d'Anza explique comment les plugins obtiennent les métadonnées de remplacement. Agave 4.3 fournit une notification optionnelle de pied de bloc, que les services doivent activer et implémenter s'ils ont besoin des données de pied de page. Ces notifications conservent leur ordre par rapport aux notifications d'entrée.
Selon la même documentation, l'horloge de la chaîne conserve son format existant et sa précision à la seconde entière. Pendant l'exécution des transactions, son horodatage estime quand le bloc parent s'est terminé, et les opérateurs sont invités à continuer de traiter cette valeur comme approximative.
Les frais des validateurs passent à une charge d'époque séparée
La documentation sur les frais de la Solana Foundation indique que la suppression des votes on-chain met fin aux frais payés sur les transactions de vote individuelles. Les validateurs paient plutôt une charge d'admission forfaitaire de 0,8 SOL par époque, dont la totalité est brûlée.
L'argent provient du compte de vote, remplaçant le compte d'identité comme source des paiements liés au vote. Les opérateurs doivent maintenir la charge au-dessus du minimum d'exemption de loyer du compte, selon les mêmes directives.
Le paiement est effectué une époque à l'avance. La première charge au début de l'époque 1064 couvre la participation à l'époque 1065, et un validateur qui ne peut pas payer perd la permission de voter ou de produire des blocs lors de l'époque suivante.
La Foundation indique que l'enregistrement de la clé publique BLS est devenu disponible sur le mainnet le 8 juillet, tandis que la fonctionnalité d'admission a été activée le 22 juillet. Ces changements préparatoires n'ont pas eux-mêmes activé le consensus Alpenglow.
Avant la migration, sa liste de contrôle exige la version 4.3.2 d'Agave, Jito-Solana ou Harmonic Salsa. Firedancer et Frankendancer ne sont pas pris en charge pendant la transition, selon les instructions destinées aux opérateurs de la Fondation.
Deux voies de vote remplacent TowerBFT
Anza décrit Votor comme exécutant deux voies de vote en même temps. L'une finalise un bloc en un seul tour avec des réponses représentant 80 % de l'enjeu, tandis que la seconde utilise deux tours et des seuils de 60 %.
Les votes deviennent des messages directs signés avec la cryptographie BLS, permettant de combiner plusieurs signatures en un certificat compact. Anza indique que les validateurs utilisent leurs propres minuteries pour identifier un leader qui ne répond pas et voter pour le contourner.
La proposition SIMD-0326 publiée documente les alternatives envisagées pendant le développement. Une conception sans finalité en un seul tour offrait une opération plus simple et une tolérance aux pannes byzantines de 33 %, mais ses auteurs ont cité une latence plus mauvaise et une moindre résilience aux pannes parmi les inconvénients.
Une autre alternative utilisait un graphe acyclique dirigé, avec des économies de bande passante possibles. Les auteurs de la proposition ont cité la latence et la difficulté à utiliser pleinement la bande passante parmi ses inconvénients.
La proposition plafonne l'ensemble admis à 2 000 validateurs, en donnant la priorité aux opérateurs ayant le plus d'enjeu. Ses auteurs expliquent que cette limite aide à maintenir les certificats suffisamment petits pour un seul message UDP, tandis que les registres de participation soutiennent les récompenses pour les validateurs qui votent activement.
L'approbation de la gouvernance a précédé la mise en œuvre. En septembre 2025, la proposition Alpenglow a été adoptée avec 98,27 % de soutien parmi les votes exprimés, tandis que l'enjeu participant représentait 52 % du total, selon les chiffres publiés du scrutin complété.
La livraison RPC peut être en retard sur la finalité du consensus
La documentation destinée aux opérateurs d'Anza nuance l'objectif de finalité d'environ 150 millisecondes en expliquant que les nœuds en dehors de l'ensemble admis de validateurs peuvent recevoir le résultat plus tard.
Par la voie par défaut, ces nœuds apprennent la finalité à partir des certificats inclus dans un bloc ultérieur. Anza indique que cela peut ajouter jusqu'à un intervalle de bloc produit, avec des attentes plus longues lorsque des blocs sont sautés ou retardés.
Un validateur admis peut envoyer des messages de consensus directement à un nœud partenaire, laissant la latence réseau entre les partenaires comme principal délai supplémentaire. Si chaque partenaire configuré devient inaccessible, le destinataire revient à apprendre la finalité à partir des pieds de page de blocs ultérieurs.
