Yakovenko de Solana remet en question la construction d'Alpenglow alors que les transactions de vote sortent

Le co-fondateur de Solana, Anatoly Yakovenko, a déclaré qu'Alpenglow aurait pu être expédié en moitié moins de temps grâce à un changement de programme de vote plus simple, 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 de programme de vote plus simple aurait pu réduire de moitié le temps de développement d'Alpenglow.
• La suppression des transactions de vote des validateurs fera baisser les comptes TPS sans nécessairement changer l'activité des utilisateurs.
• Un frais d'admission de 0,8 SOL brûlé par époque remplacera les frais de vote individuels.
• Certains nœuds RPC pourraient recevoir des mises à jour de finalité plus tard que l'objectif de 150 millisecondes d'Alpenglow.

Yakovenko, dans un post X du 21 octobre, a fait cette remarque en citant un commentaire célébrant la suppression prévue des votes en chaîne et en se moquant des critiques récurrentes selon lesquelles la plupart des transactions par seconde de Solana consistent en votes de validateurs.

"Alpenglow aurait été expédié en moitié moins de temps s'ils avaient simplement changé le programme de vote pour le faire passer à la machine d'état ag"

Le design publié par Anza décrit un remplacement pour 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 l'a précédemment rapporté crypto.news en couvrant le transfert de consensus prévu. Les nouvelles directives de la Solana Foundation identifient l'époque 1064 comme le déclencheur et estiment son début à environ 13h20 UTC.

La page de migration d'Anza sépare l'activation des fonctionnalités du transfert de consensus. La limite de migration arrive 5 000 slots plus tard, lorsque les blocs portent temporairement uniquement des votes pendant que les validateurs terminent la transition.

Alpenglow supprime les votes des comptes de transactions principaux

Les directives de migration de la Solana Foundation indiquent aux explorateurs et aux services d'analyse de réinitialiser les bases de données de comptes de transactions et de TPS car les transactions de vote disparaîtront des blocs. Un total qui inclut des votes diminuera même si les paiements, les échanges et d'autres transactions non liées aux votes restent inchangés.

La Fondation dit que les services suivant la participation des validateurs doivent remplacer leur lecture des instructions du programme de vote par des données de certificat dans les pieds de page des blocs. Ses directives notent que le message de pied de page gRPC de Yellowstone ne transmet pas encore ces certificats.

Les développeurs avaient accès au comportement modifié lorsque Alpenglow a atteint le devnet en septembre, après la transition du testnet. La couverture du 26 septembre a décrit comment les explorateurs doivent garder les blocs candidats concurrents séparés jusqu'à confirmation, conservant le bloc sélectionné au lieu de combiner leurs transactions.

La documentation de l'opérateur d'Anza explique comment les plugins obtiennent les métadonnées de remplacement. Agave 4.3 fournit une notification de pied de page de bloc optionnelle, que les services doivent activer et mettre en œuvre s'ils ont besoin de 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 informés de continuer à traiter cette valeur comme approximative.

Les frais des validateurs passent à un frais d'époque séparé

La documentation des frais de la Solana Foundation indique que la suppression des votes en chaîne met fin aux frais payés sur les transactions de vote individuelles. Les validateurs paient plutôt un frais d'admission fixe de 0,8 SOL par époque, avec la totalité du montant brûlé.

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 le frais au-dessus du minimum exempt de loyer du compte, selon les mêmes directives.

Le paiement est effectué une époque à l'avance. Le premier frais au début de l'époque 1064 couvre la participation à l'époque 1065, et un validateur qui ne peut pas payer perd le droit de voter ou de produire des blocs dans l'époque suivante.

La Fondation 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 d'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 le transfert, selon les instructions de l'opérateur de la Fondation.

Deux chemins de vote remplacent TowerBFT

Anza décrit Votor comme fonctionnant avec deux chemins de vote en même temps. L'un finalise un bloc en un seul tour avec des réponses de 80 % des mises, tandis que le second 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 dit que les validateurs utilisent leurs propres minuteurs pour identifier un leader non réactif et voter pour le sauter.

La proposition SIMD-0326 publiée documente les alternatives considérées lors du développement. Un design 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 listé une latence pire et une résilience aux pannes inférieure 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 listé la latence et la difficulté d'utiliser pleinement la bande passante parmi ses inconvénients.

La proposition limite l'ensemble admis à 2 000 validateurs, en priorisant les opérateurs ayant les mises les plus élevées. Ses auteurs expliquent que cette limite aide à garder les certificats suffisamment petits pour un seul message UDP, tandis que les enregistrements 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 un soutien de 98,27 % parmi les votes exprimés, tandis que la mise en participation représentait 52 % du total, selon les chiffres publiés du bulletin de vote complété.

La livraison RPC peut être en retard par rapport à la finalité du consensus

La documentation de l'opérateur d'Anza qualifie l'objectif de finalité d'environ 150 millisecondes en expliquant que les nœuds en dehors de l'ensemble de validateurs admis peuvent recevoir le résultat plus tard.

Par le chemin par défaut, ces nœuds apprennent la finalité à partir des certificats inclus dans un bloc ultérieur. Anza dit 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 le principal retard supplémentaire. Si chaque partenaire configuré devient injoignable, le destinataire revient à apprendre la finalité à partir des pieds de bloc ultérieurs.