Solana promettait une finalité plus rapide. Les validateurs doivent maintenant prouver que ça fonctionne

Alpenglow traverse les réseaux de test de Solana, tandis que le mainnet s'appuie encore sur son consensus existant. Le changement proposé modifierait la façon dont les validateurs s'accordent sur le fait qu'un bloc est final. Un objectif de 150 millisecondes est une affirmation de performance dans certaines conditions, et non une promesse que chaque paiement d'utilisateur est réglé dans ce délai.

Le changement de consensus le plus important de Solana progresse à travers une série de tests de validateurs. Le tracker des feature gates d'Anza liste SIMD-0326, Alpenglow, parmi les activations mainnet en attente. Il enregistre les positions d'activation sur testnet et devnet et identifie Agave 4.3.0 comme la version logicielle liée à la fonctionnalité. Le plancher de version mainnet indiqué dans le même instantané était 4.2.2, avec 4.3.0 listé comme prochain plancher attendu. Un plancher de version prévu et une fonctionnalité de consensus active sont des jalons différents.

Le rapport précédent sur le testnet décrivait le passage à des tests de validateurs plus larges. Un compte rendu ultérieur sur le devnet mentionnait les deux réseaux de test, tandis que le mainnet continuait avec son consensus actuel. C'est le statut à l'aune duquel tout gain de vitesse promis doit être jugé.

Le 28 septembre était un piège de calendrier

Une entrée du calendrier indiquait que les activations de fonctionnalités sur le mainnet reprendraient le 28 septembre. Elle ne disait pas qu'Alpenglow lui-même serait activé ce jour-là. Le tracker nomme séparément Alpenglow comme en attente. Traiter une date de reprise d'une file de feature gates comme un basculement de protocole planifié a transformé un marqueur de processus en échéance erronée. Une correction du 29 septembre retraçait cette confusion et indiquait qu'Anza avait rejeté la date de lancement revendiquée.

La distinction est importante. Les validateurs peuvent adopter une version logicielle contenant du code dormant sans activer la fonctionnalité. Un plancher de version peut augmenter après qu'un seuil d'enjeu et des époques ont été franchis. Un feature gate distinct peut activer le nouveau comportement. Les utilisateurs qui voient un numéro de version changer sur un tableau de bord n'ont pas pour autant vu un protocole de finalité plus rapide devenir actif.

Le bon angle d'actualité est que le processus de test et d'activation est toujours ouvert après la date largement diffusée. Une fenêtre finale sur le mainnet nécessite un calendrier explicite, une préparation des opérateurs et des preuves issues de tests publics. Aucune de ces étapes n'est remplacée par une publication sur les réseaux sociaux décrivant une mise à niveau comme imminente.

Votor change les votes, tandis que Rotor attend

La proposition SIMD-0326 définit le changement initial principalement autour de Votor, le nouveau mécanisme de consensus. Elle laisse explicitement Rotor, le remplacement proposé pour la diffusion des données, à un changement séparé et conserve initialement la propagation Turbine existante. Les descriptions marketing d'une pile Alpenglow complète peuvent brouiller cette portée.

Le consensus répond au moment où suffisamment de validateurs se sont accordés sur un bloc pour qu'il doive être traité comme final selon le protocole. La propagation des données répond à la question de savoir comment le bloc atteint ces validateurs. L'exécution répond à la question de savoir si une transaction a été exécutée avec succès. Une application attend également que son fournisseur RPC rapporte le résultat. Un vote plus rapide ne peut pas éliminer tous les autres délais de ce parcours.

Le chiffre de 150 millisecondes doit être interprété comme un objectif de finalité dans des conditions de réseau favorables, mesuré au niveau de la couche de consensus. Il ne s'agit pas d'un délai de paiement de bout en bout pour un utilisateur dont le portefeuille doit signer, soumettre, atteindre un leader, être inclus dans un bloc, exécuter et revenir via un service RPC. Un benchmark public utile devrait nommer ses points de départ et d'arrivée. Un chronomètre démarré à la proposition de bloc n'est pas comparable à un chronomètre démarré lorsque le client appuie sur Envoyer.

La proposition remplace un dispositif de vote par un compromis différent entre sécurité et vivacité. Elle décrit un modèle 20 plus 20 qui peut tolérer une part adverse et une part distincte ne répondant pas, sous des hypothèses énoncées. Les auteurs notent explicitement qu'un vote en un tour n'offre pas le même seuil byzantin de 33 % réalisable par des conceptions en deux tours. Cet aveu doit figurer à côté de l'affirmation de vitesse, et non dans une note de bas de page.

Un test à deux colonnes évite un benchmark trompeur

Une colonne devrait mesurer la finalité du protocole du point de vue d'un validateur : le temps écoulé entre un bloc proposé et un certificat de finalisation, y compris la distribution des résultats lents. La seconde devrait mesurer la transaction confirmée d'un utilisateur : soumission, exécution, inclusion, finalité et réponse RPC. La différence entre ces colonnes représente le travail que le chiffre phare du consensus ne mesure pas.

Supposons qu'un test rapporte 150 millisecondes pour la finalisation après proposition, mais que l'inclusion de la transaction attende un créneau de 350 millisecondes et que la livraison RPC prenne 100 millisecondes supplémentaires. Le client voit au moins 600 millisecondes dans ces hypothèses illustratives, avant d'ajouter la signature ou les tentatives répétées. Le calcul est 350 plus 150 plus 100. Ce sont des durées hypothétiques, et non des mesures d'Alpenglow en production. Elles montrent pourquoi un chiffre de consensus inférieur à la seconde ne correspond pas nécessairement à une expérience de paiement inférieure à la seconde.

La latence médiane peut masquer les cas qui préoccupent le plus les opérateurs. Un validateur bloqué derrière une mauvaise route réseau, une partition temporaire, un vote manquant ou un important travail de rejeu pourrait observer une longue traîne. Les plateformes d'échange et les prestataires de paiement élaborent généralement leurs politiques de finalité pour des conditions défavorables rares, et pas seulement pour une médiane de benchmark. Un déploiement crédible publierait des résultats par centile, le comportement de reprise et les conséquences des échecs de leaders.

La proposition sur la durée des créneaux est une autre variable. Elle vise des réductions par étapes d'un objectif de 400 millisecondes vers 200 millisecondes. L'intervalle entre créneaux et la finalité sont liés mais distincts ; affirmer que chaque créneau plus court prouve que Votor fonctionne confond deux mises à niveau. Le compte de test de validateur antérieur a suivi les tests du protocole avant ce déploiement plus large.

Les validateurs doivent tester les cas de défaillance

Le chemin heureux d'un réseau est l'environnement le plus facile pour produire un chiffre rapide. Un candidat au mainnet doit survivre à des validateurs qui rejoignent tardivement, à des messages retardés entre régions, à des redémarrages logiciels, à des défaillances de leaders et à des vues contradictoires de la chaîne. La proposition de migration Alpenglow traite du passage de l'ancien état de vote au nouveau. Un protocole en régime permanent correct peut malgré tout être mis en difficulté par une mauvaise transition.

Les tests devraient montrer si le cluster parvient à une décision finale cohérente après la guérison d'une partition, avec quelle rapidité il reprend si une part significative de l'enjeu passe hors ligne, et si des nœuds exécutant différentes versions compatibles rapportent le même résultat. Le testnet est précieux parce que des validateurs disposant d'infrastructures différentes rencontrent des conditions qu'un laboratoire contrôlé peut manquer. Il ne peut pas reproduire exactement les incitations économiques et le trafic d'un réseau en production.

La combinaison de clients compte. Le tracker d'Anza a marqué Firedancer et Frankendancer comme non pris en charge pour la ligne Alpenglow dans l'instantané observé. Il s'agit d'un statut de compatibilité dans un calendrier précis, et non d'une affirmation permanente sur l'un ou l'autre client. Une migration en production doit tenir compte de l'enjeu exécutant chaque implémentation ou préciser ce que ces opérateurs doivent modifier.

Les incitations des validateurs font aussi partie du test. L'exécution d'un nouveau protocole de vote peut modifier la bande passante, les exigences matérielles et les coûts de participation. Si des opérateurs plus petits se retirent parce qu'ils ne peuvent pas satisfaire aux exigences, le réseau plus rapide pourrait se retrouver avec moins de participants indépendants. Le nombre réel d'opérateurs et la répartition de l'enjeu après l'activation permettraient de tester ce compromis.

Un certificat rapide et un certificat lent répondent à des conditions différentes

Le protocole ne dépend pas d'une route qui se termine toujours en 150 millisecondes. SIMD-0326 définit la finalisation rapide lorsque les validateurs représentant 80 % de l'enjeu notarisent un bloc en un seul tour. Sa route plus lente repose sur deux tours impliquant 60 % de l'enjeu et à la fois des certificats de notarisation et de finalisation. Un leader peut échouer à livrer un bloc valide à temps, auquel cas les validateurs peuvent voter pour sauter ce slot. La conception inclut des certificats pour les slots sautés et un chemin de repli. Un benchmark phare qui ne mesure que la route rapide à 80 % omettrait précisément les situations qui rendent la finalité précieuse.

La distinction peut être mise à l'épreuve de manière pratique. Pour chaque slot proposé dans une journée, comptez la part finalisée avec le certificat rapide, la part utilisant le chemin plus lent et la part sautée. Donnez la médiane ainsi que les 95e et 99e percentiles séparément pour chaque classe. Une médiane rapide est utile, mais un opérateur doit savoir à quelle fréquence le réseau quitte le chemin rapide et combien de temps il met ensuite à récupérer. Un service de paiement traitant des milliers de reçus par jour peut connaître un événement de longue traîne même si cet événement est rare pour un transfert individuel.

Un certificat est un enregistrement compact et vérifiable d'un accord pondéré par l'enjeu. Ce n'est pas un vote d'un nombre fixe de machines. Dix petits validateurs ne peuvent pas remplacer un validateur représentant une grande quantité d'enjeu simplement en le surpassant en nombre. Rapporter des nombres de validateurs sans la distribution de l'enjeu fausserait donc le test de sécurité. Les chiffres corrects sont l'enjeu participant à chaque tour, l'enjeu hors ligne et l'enjeu en désaccord. Ces chiffres ont besoin d'horodatages car les attributions d'enjeu et la disponibilité des opérateurs changent.

La proposition indique qu'un bloc finalisé directement décide aussi ses ancêtres : les blocs antérieurs dans sa chaîne deviennent finalisés et les slots omis sont traités comme sautés. Cela signifie qu'un tableau de bord peut montrer la finalité arrivant par groupes après une période lente. Une mesure qui moyenne les temps d'achèvement apparents de ces ancêtres en un seul chiffre attractif serait difficile à comparer avec un utilisateur qui a attendu pendant la pause. Le test devrait conserver l'heure de proposition d'origine de chaque bloc et l'heure d'observation du certificat.

Les auteurs du protocole ne revendiquent pas le même seuil adverse que toute conception concurrente. Leur cadre 20 plus 20 accepte un équilibre différent entre les fautes byzantines et l'enjeu non réactif en échange d'un chemin normal plus court. Savoir si ce compromis est acceptable est un jugement de gouvernance éclairé par la modélisation des menaces et les preuves de performance, et non une question tranchée par une seule démonstration du cas le plus rapide. La section de sécurité inhabituellement franche de SIMD-0326 permet de rapporter le compromis sans attribuer de motifs à l'un ou l'autre camp.

Changer de consensus nécessite un bloc de départ partagé

Le document de migration aborde un problème qu'un graphique de vitesse ne peut pas montrer. L'ancien et le nouveau consensus ne peuvent pas fonctionner en toute sécurité comme des historiques indépendants après la bascule. Les validateurs doivent s'accorder sur le dernier bloc ancien qui devient le parent du premier bloc Alpenglow. Le document appelle ce point partagé le bloc de genèse Alpenglow. Si les opérateurs ne s'accordent pas sur celui-ci, leurs certificats de finalité ultérieurs se référeraient à des historiques incompatibles.

Le transfert proposé commence après un slot d'activation de fonctionnalité, mais la frontière utilisée pour la migration se situe 5 000 slots plus tard. L'intervalle supplémentaire vise à éviter le début d'une époque. Le processus attend ensuite un bloc remplissant une forte condition de confirmation optimiste, avec des votes représentant au moins 82 % de l'enjeu dans le schéma spécifié par la proposition. Les validateurs signent un vote de genèse pour un bloc ancêtre commun. Un certificat de genèse à 82 % leur donne la preuve de basculer. L'arithmétique de ces seuils fait partie de la conception de la migration, distincte de la route de finalisation rapide à 80 % de Votor après la bascule.

Un validateur recevant le certificat de genèse vérifie ses signatures par rapport aux clés BLS de l'époque concernée et le diffuse. Le plan initialise ensuite Votor à partir du bloc sélectionné et arrête TowerBFT pour les slots ultérieurs. Il annule les blocs après le point de genèse sélectionné et réinitialise l'état associé avant de traiter de nouveaux blocs. Le document soutient que cette annulation est sûre car les transactions des utilisateurs ne sont pas intégrées dans ces blocs intermédiaires. Cette affirmation mérite un test sur le cluster réel ; ce n'est pas quelque chose qu'un opérateur d'application peut vérifier à partir du seul titre de finalité.

Un nœud peut être hors ligne pendant le transfert. Le document décrit comment un validateur qui revient peut apprendre le certificat de genèse à partir d'un instantané ou rattraper son retard après avoir observé un certificat de finalisation Alpenglow valide. C'est ici que l'ingénierie de version rencontre la théorie du consensus. Si un nœud tardif interprète mal la transition, il peut présenter des données obsolètes ou incohérentes même lorsque le cluster majoritaire continue. Les échanges et les fournisseurs de RPC devraient tester les scénarios de redémarrage et de restauration d'instantané, et pas seulement observer le succès de la bascule initiale.

Il existe un coût de vivacité explicite. La proposition de migration indique que le transfert peut interrompre la progression, de manière optimiste pendant un slot au-delà de la frontière. Une attente d'un seul slot n'est pas une garantie maximale de niveau de service. Le post-mortem public après l'activation devrait préciser combien de slots ont été sautés, si l'assemblage des transactions utilisateur a été suspendu, et combien de temps les services externes ont mis pour reprendre la notification normale des confirmations. Un état stable rapide ne peut pas faire disparaître l'intervalle de transition de l'expérience des utilisateurs.

C'est pourquoi la date du mainnet ne peut pas être déduite d'un calendrier logiciel général. Un basculement sûr nécessite un enregistrement de clé BLS compatible, une porte de fonctionnalité adoptée, un bloc de départ partagé, une distribution de certificats, un comportement de retour arrière et une récupération pour les nœuds en retard. Ce sont des tâches observables pour les opérateurs. La spécification de migration leur fournit une liste de contrôle, tandis que l'exercice réel sur le réseau montrera si la liste de contrôle est suffisante.

Les coûts des validateurs pourraient changer qui participe

La mise à niveau a une conception économique ainsi qu'un objectif de latence. Dans le cadre du vote actuel, les opérateurs envoient des transactions de vote et paient les frais associés. SIMD-0326 propose un ticket d'admission de validateur, ou VAT, facturé à la place de ce modèle de frais. Le document donne une estimation initiale d'environ 0,8 SOL par jour, ou 1,6 SOL par époque, et indique que l'intégralité du paiement serait brûlée. Le chiffre est un paramètre initial dans une proposition, pas un relevé de facturation en direct pour chaque validateur.

Un coût d'admission fixe peut simplifier une dépense tout en pesant davantage sur un petit opérateur disposant de peu d'enjeu délégué. Un grand validateur et un petit ne gagnent pas les mêmes récompenses. La question est de savoir si leur économie nette s'améliore après prise en compte des frais de vote économisés, des coûts matériels, de la bande passante et de la VAT. La proposition indique que les opérateurs devraient constater une utilisation réduite des ressources après la migration. C'est un effet attendu, pas un résultat mesuré sur l'ensemble des validateurs en direct.

Une comparaison avant-après utile suivrait les mêmes opérateurs tout au long de la mise à niveau. Pour chaque tranche d'enjeu, comparez les frais de vote quotidiens avant le changement avec la VAT et les coûts d'exploitation après. Comptez la part d'opérateurs indépendants qui cessent de produire des votes ou quittent l'ensemble actif. Une baisse du nombre de machines ne prouverait pas à elle seule une perte de décentralisation si les validateurs partants avaient un enjeu négligeable, mais ce serait un avertissement à examiner. La concentration de l'enjeu et la diversité géographique ajouteraient un contexte nécessaire.

La proposition indique qu'un validateur insuffisamment financé serait retiré de l'ensemble actif. Cela fait de la gestion du solde de tickets un enjeu de disponibilité. Les opérateurs ont besoin d'alertes avant que les fonds ne s'épuisent, et les délégants doivent comprendre ce qui se passe si leur validateur choisi devient inactif. La différence entre un protocole de consensus qui fonctionne en laboratoire et un réseau qui fonctionne jour après jour inclut le financement banal des comptes. Le rapport précédent sur la gouvernance des validateurs Solana décrit le chemin de décision formel ; la participation continue après la mise en œuvre est un test distinct.

La question de production n'est pas simplement de savoir si 150 millisecondes sont réalisables. Il s'agit de savoir si un ensemble suffisamment large de validateurs peut fournir cette performance sans une augmentation non signalée des coûts ou de la fragilité opérationnelle. Une finalité plus rapide avec une base d'opérateurs plus étroite serait un résultat différent de la promesse complète de la proposition. La latence et la participation nécessitent toutes deux une référence prise avant le changement.

Une transaction peut être finale alors qu'un service est encore en retard

Un dépôt sur un échange illustre l'écart entre la finalité de la chaîne et le solde utilisable d'un utilisateur. D'abord, le client soumet une transaction signée. Le transfert atteint un leader et est inclus dans un bloc. Les validateurs votent et un certificat de finalisation se forme. Un service RPC observe le certificat et le signale. Le moniteur de dépôt de l'échange identifie l'adresse et l'actif, effectue ses contrôles de politique et crédite le compte. Le changement de consensus raccourcit principalement un intervalle dans cette séquence.

Un échange peut attendre plus longtemps par choix. Il pourrait exiger des contrôles supplémentaires pour les dépôts importants, comparer les résultats entre plusieurs fournisseurs RPC, ou retarder le crédit pendant un incident. Cela ne signifie pas que la chaîne a échoué à son objectif de finalité. Cela signifie qu'un benchmark de chaîne ne peut pas être présenté comme le temps de crédit garanti du client. Une affirmation produit équitable devrait distinguer la finalité du bloc, la visibilité RPC et la propre décision de crédit de l'institution.

L’erreur inverse est également possible. Une application peut afficher un succès en attente dès que son nœud RPC voit un bloc, avant que le certificat de finalisation n’arrive. Un utilisateur pourrait voir une coche verte rapide alors que l’assurance la plus forte du protocole arrive plus tard. Lors de la migration, une application qui continue d’étiqueter son statut d’engagement pré-mise à niveau de la même manière devrait être testée par rapport aux nouvelles sémantiques. Une interface de portefeuille visuellement inchangée peut masquer un modèle de risque modifié.

Pour les applications décentralisées, un bloc final ne garantit pas un échange favorable. Une transaction peut s’exécuter et échouer selon une règle de l’application, payer des frais, ou se régler à un prix que l’utilisateur n’attendait pas dans les paramètres soumis. La finalité de consensus signifie que le registre a décidé de ce résultat. Elle ne certifie pas qu’un contrat intelligent est sûr ou qu’une entrée d’oracle était correcte. La mise à niveau devrait être créditée pour la propriété plus étroite qu’elle est conçue pour améliorer.

Pour rendre l’affirmation falsifiable, les fournisseurs d’infrastructure pourraient publier des horodatages appariés pour un échantillon de transactions : arrivée à leur service, première inclusion, observation du certificat, réponse RPC et crédit visible par le client. Ils devraient divulguer les observations manquantes et les tentatives. Comparer ces intervalles avant et après l’activation, avec des charges et des conditions de frais similaires, montrerait combien du parcours total Alpenglow a réellement raccourci. Ce serait une preuve plus solide que de répéter l’objectif du livre blanc.

Le cas le plus fort est une réelle amélioration du règlement

Les partisans peuvent avancer un argument substantiel. Le chemin de confirmation actuel de Solana a longtemps laissé un écart entre la production rapide de blocs et une finalité plus forte. Si Votor réduit cet écart de manière fiable, un échange peut créditer les dépôts plus tôt, un trader peut réduire l’incertitude après une exécution, et un fournisseur de paiement peut régler avec moins d’attente. La proposition de protocole est une conception d’ingénierie sérieuse, et les validateurs ont déjà passé du temps à la tester hors du réseau principal.

La couverture de gouvernance précédente enregistre la décision des validateurs derrière la proposition. Le chemin de gouvernance des validateurs signifie également que le changement n’est pas simplement une promesse d’entreprise. Les opérateurs doivent adopter le logiciel et participer à l’activation. La porte de fonctionnalité par étapes donne au réseau l’occasion d’exposer les problèmes avant la production. Ces forces ne prouvent pas le niveau de service final, mais elles rendent la phase de test conséquente.

Le cas opposé est un compromis que les auteurs eux-mêmes divulguent : des hypothèses de défaillance différentes accompagnent la conception de vote plus rapide. Les opérateurs doivent également gérer la migration et la compatibilité des clients. Une médiane de 150 millisecondes obtenue sur un cluster de test calme ne répondrait pas à la question de savoir comment le protocole se comporte lorsque l’enjeu significatif est hors ligne ou que les liens réseau sont instables. C’est pourquoi les preuves appartiennent à un rapport de cas de défaillance, pas seulement à une démonstration de vitesse.

La préparation au réseau principal comporte plusieurs portes distinctes

La première est l’adoption du logiciel : suffisamment d’enjeu exécute une version compatible. La deuxième est la vérification du protocole sur testnet et devnet : les votes et les certificats restent corrects dans des conditions normales et défavorables. La troisième est la préparation opérationnelle : les échanges, les fournisseurs RPC, les explorateurs de blocs et les portefeuilles savent comment observer le nouveau signal de finalité. La quatrième est l’activation programmée de la fonctionnalité elle-même.

Le tracker d’Anza indique qu’un plancher de version du réseau principal peut augmenter après que 95 % de l’enjeu adopte une nouvelle version mineure et que deux époques complètes passent. Cette règle régit la version minimale prise en charge ; elle ne doit pas être paraphrasée comme une activation automatique d’Alpenglow à 95 %. La ligne de fonctionnalité indépendante reste l’endroit où vérifier le changement réel en attente.

Aucun test rapporté n’établit que le prix du SOL doit réagir d’une manière particulière. Les prix des jetons intègrent les conditions macroéconomiques, le financement, l’offre, la demande des applications et les attentes concernant les mises à niveau avant le déploiement. Les perspectives d’activation précédentes expliquent pourquoi un jalon de consensus est pertinent sans en faire un catalyseur de prix par définition.

Ce qui manque encore aux preuves publiques

Un plan d'activation final daté et une série publique comparable de mesures de finalité sous diverses charges permettraient aux lecteurs de juger à quel point le réseau est proche de la promesse phare. Les résultats des tests devraient préciser les versions logicielles, l'enjeu participant, les types de clients, les conditions des messages, l'inclusion des transactions et les latences en percentiles. Un seul temps de finalisation dans le meilleur des cas serait incomplet.

Le rapport le plus décisif viendra après le basculement : des observations répétées sur le mainnet de la finalité et du règlement visible par les applications, plus la divulgation de tout événement de récupération. D'ici là, les tests des validateurs montrent que le système proposé est exercé. Cela n'établit pas que chaque utilisateur connaîtra un règlement de 150 millisecondes.

Ce qu'il faut surveiller

• Barrière de fonctionnalité : Le statut explicite d'Alpenglow sur le mainnet d'Anza et le slot d'activation, distincts d'une date générale de version minimale.
• Adoption de l'enjeu : La part de l'enjeu des validateurs exécutant une version qui prend en charge la fonctionnalité.
• Compatibilité des clients : Les mises à jour pour les implémentations de validateurs listées comme non prises en charge dans la ligne actuelle du suivi.
• Tests de défaillance : La récupération publiée et la latence de longue traîne sous partitions, redémarrages et votes manquants.
• Chronologie utilisateur : Les mesures sur le mainnet depuis la soumission jusqu'à la finalité et la notification RPC, pas seulement le temps du certificat.

FAQ