De mars 2020 à octobre 2026, chaque bloc de Solana a été estampillé par un compteur qui ne s’arrêtait jamais. Un seul cœur de processeur, sur la machine du leader, prenait un hachage SHA-256, hachait le résultat, hachait de nouveau et ainsi de suite : environ deux millions de fois par slot de 200 millisecondes avec les paramètres d’octobre 2026. Cette chaîne de hachages, c’était le proof of history de Solana, et elle permettait à des milliers de machines qui ne se fiaient pas à la montre des autres de s’accorder sur ce qui venait en premier et sur le tour de chacun pour construire le bloc suivant.
Le 21 octobre 2026 à 13:36:05 UTC, au slot 459 648 000, la porte de fonctionnalité d’Alpenglow s’est activée sur le mainnet, et environ 18 minutes plus tard le réseau a confié son consensus à un nouveau protocole de vote, Votor, à la place de Tower BFT. Anza, l’équipe qui développe le client de validation Agave, écrit désormais sur sa page Alpenglow : « Proof of History is gone » (le proof of history a disparu). Ou presque. Un tick d’un seul hachage clôt encore chaque bloc, un reste que la proposition de migration conserve parce que le supprimer serait « a load of risky work », c’est-à-dire un gros chantier risqué.
Cette leçon explique ce que faisait l’horloge, ce que Solana a bâti autour d’elle, pourquoi l’une et l’autre ont été retirées et qui fait tourner le réseau au 8 novembre 2026. Elle prolonge notre leçon sur le consensus BFT, Tendermint et HotStuff, qui montrait comment les protocoles de vote classiques atteignent un quorum des deux tiers. Rappel tiré de la leçon sur la finalité et les réorganisations : Solana expose trois niveaux d’engagement (processed, confirmed, finalized). Sous Tower BFT, « finalized » voulait dire 31 blocs confirmés empilés par-dessus, soit environ 12,8 secondes avec des slots de 400 millisecondes, et Alpenglow a fondu « confirmed » et « finalized » en une seule étape. Ici, on descend d’un étage, vers l’horloge qui se cachait sous ces niveaux et vers la mécanique qui l’a remplacée. Si les quorums et les fautes byzantines vous sont nouveaux, commencez par le problème des généraux byzantins.
Proof of history Solana : une chaîne de hachages qui compte le temps
Les systèmes distribués n’ont pas d’horloge commune. Chaque serveur garde sa propre heure, la voit dériver et peut mentir à son sujet. Bitcoin esquive la question en n’ordonnant les transactions qu’au moment où un mineur trouve un bloc ; les protocoles BFT classiques les ordonnent par des tours de messages. Le livre blanc d’Anatoly Yakovenko, qui décrit la version 0.8.14 de la conception, proposait une troisième voie : inscrire dans le registre lui-même une trace vérifiable du temps écoulé. Son résumé le dit ainsi : « PoH is used to encode trustless passage of time into a ledger », soit à peu près « le PoH sert à encoder dans un registre le passage du temps sans avoir à faire confiance à personne ».
Séquentiel à produire, parallèle à vérifier
Le mécanisme tient en une ligne. On prend une valeur, on la hache avec SHA-256, on réinjecte la sortie comme entrée suivante et on tient un compteur à côté. Chaque étape a besoin de la sortie précédente : personne ne peut calculer le hachage numéro un million sans avoir calculé les 999 999 précédents, et ajouter des processeurs n’y change rien, car le travail ne se découpe pas. Une longue chaîne est donc la preuve qu’une quantité connue de calcul, et donc à peu près une durée connue sur un matériel connu, s’est écoulée.
La vérification, elle, est une tout autre affaire. Un vérificateur qui reçoit la chaîne avec des points de passage intermédiaires, disons les sorties aux rangs 200, 300 et 400, peut confier chaque segment à un cœur différent et tous les confirmer en même temps, puisque chaque segment part d’un hachage publié. L’exemple du livre blanc répartit la séquence sur une carte graphique de 4 000 cœurs. La production tourne sur un cœur, la vérification sur des milliers, et cette asymétrie est toute l’idée : ce que les cryptographes appellent une fonction à délai vérifiable.
On la confond facilement avec la preuve de travail, qui brûle elle aussi des hachages. Un mineur de Bitcoin cherche en parallèle un hachage chanceux inférieur à une cible, et plus de machines signifient plus de chances ; la leçon précédente de ce parcours sur le hashrate et la difficulté de minage montre comment cette course se mesure. Le générateur de PoH ne cherche rien. Pas de loterie, pas de récompense pour qui fait tourner un second générateur, seulement un compteur qui doit continuer de compter.
Estampiller les transactions dans la séquence
Pour enregistrer un événement, le générateur mélange le hachage de la donnée dans la chaîne : la sortie suivante devient le hachage de la sortie précédente combinée à celui de la donnée. À partir de là, tout le monde peut démontrer deux choses. La donnée existait avant les entrées suivantes, puisqu’elles ont été calculées à partir d’elle. Et elle a été ajoutée après l’entrée précédente, car l’insérer plus tôt changerait tous les hachages en aval. L’ordre est fixé sans qu’aucun message ne circule entre les nœuds.
Ce que donne la chaîne, c’est un ordre et un espacement, pas des dates. Un écart de deux millions de hachages dit qu’autant de travail séquentiel sépare deux événements ; blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il ne dit pas si cela a pris 200 ou 300 millisecondes, car la vitesse de hachage dépend de la puce. Les heures de bloc affichées par les explorateurs ne sont jamais tirées de la chaîne de hachages. Sous Tower BFT, les validateurs joignaient à leurs votes leur propre horodatage d’horloge murale, et les notes de conception d’Anza sur son oracle d’horodatage décrivent une moyenne de ces déclarations pondérée par la mise.
Ce que promettait le livre blanc
Le document associait l’horloge à un algorithme de consensus ; il n’a jamais prétendu en remplacer un. Son résumé indique que le PoH peut réduire la charge de messages quand on l’utilise avec la preuve de travail ou la preuve d’enjeu, ce qui ouvre la voie à une finalité sous la seconde. Il contient aussi une analyse de débit sur un réseau de 1 gigabit par seconde : divisez cette bande passante par des transactions de 176 octets et vous obtenez les fameuses 710 000 transactions par seconde, un plafond théorique fixé par la bande passante, jamais un chiffre mesuré sur le mainnet.
Deux noms que tous les articles sur Solana répètent, Tower BFT et Turbine, n’apparaissent pas dans la version 0.8.14 du document. Le protocole de vote qu’il esquissait était une autre conception de preuve d’enjeu, pensée pour se rétablir après une partition du réseau. Ce qui a été lancé sur Solana en 2020 découle de ce texte sans lui ressembler trait pour trait, ce qui explique en partie pourquoi tant de descriptions du « fonctionnement de Solana » mélangent les pièces.
Le proof of history n’est ni un consensus ni un service d’horodatage
L’erreur la plus répandue tient dans la question « Solana, c’est de la preuve d’enjeu ou du proof of history ? », comme si le réseau avait choisi l’un contre l’autre. Solana a toujours été une chaîne de preuve d’enjeu. Les SOL délégués à un validateur décident de la fréquence à laquelle il dirige, du poids de son vote et de ce qu’il gagne ; notre leçon sur la preuve d’enjeu en détail en explique les mécanismes sur Ethereum, et celle sur les validateurs, le slashing et les récompenses détaille comment les opérateurs sont payés et sanctionnés. Le PoH répondait à une autre question : dans quel ordre les choses se sont-elles passées, et est-ce bien votre tour ? Décider quels blocs comptent a toujours relevé d’un vote distinct.
La deuxième erreur consiste à prendre la chaîne de hachages pour une preuve du temps réel. Personne ne confronte le PoH à l’heure UTC. Un leader doté d’une puce plus rapide hache simplement plus vite, et le protocole réglait cela en fixant le nombre de hachages par tick et en le modifiant au besoin. C’est pourquoi SIMD-0525, la proposition à l’origine des slots plus rapides de 2026, a fait passer les hachages par tick de 62 500 pour des slots de 400 millisecondes à 31 250 pour 200 millisecondes : le nombre était calibré sur une durée attendue, jamais vérifié par rapport à une durée réelle.
Slots, leaders et epochs : un calendrier que chacun peut calculer
Le calendrier des leaders
Solana découpe le temps en slots, et les slots en epochs de 432 000. Pour chaque epoch, tous les validateurs calculent le même calendrier de leaders à partir de la répartition des mises, de sorte que la direction est partagée en proportion de la mise. La documentation d’Anza décrit un calendrier calculé une epoch à l’avance et, dans la conception d’avant Alpenglow, initialisé à partir de la hauteur de tick du PoH. Chaque leader reçoit quatre slots consécutifs. Un échantillon de 24 slots lu sur le RPC public du mainnet le 8 novembre 2026 montrait exactement ce motif, avec un leader détenant huit slots parce que le tirage lui avait attribué deux fenêtres d’affilée.
C’est là que le PoH travaillait au quotidien. Chaque slot comptait 64 ticks, chaque tick un nombre fixe de hachages. Un leader ne pouvait pas démarrer en avance, puisque son premier bloc devait prolonger la chaîne de hachages à partir de la fin du slot précédent. Si le leader précédent restait muet, le suivant devait hacher à travers le slot vide pour prouver que le temps s’était écoulé avant de prendre le relais. L’horloge imposait les tours sans aucun échange de messages pour demander la permission.
Le temps de slot ramené de 400 à 200 ms en quatre étapes
Pendant l’essentiel de sa vie, Solana visait des slots de 400 millisecondes, et beaucoup d’articles l’écrivent encore. Ce chiffre est périmé. SIMD-0525, rédigée par Brennan Watt d’Anza, a abaissé la cible en quatre étapes activées par fonctionnalité entre août et octobre 2026, tout en gardant 64 ticks par slot, des fenêtres de leader de quatre slots et des epochs de 432 000 slots. Chaque porte prend effet une epoch après son activation, et les heures de bloc de la chaîne montrent chaque étape : le slot moyen est passé d’environ 416 à environ 366 millisecondes dans l’epoch commencée le 21 août, et la même baisse se retrouve à chaque palier suivant. Les limites par slot, comme les unités de calcul par bloc, ont été réduites au prorata pour que la capacité par seconde reste à peu près la même.
| Slot cible | En vigueur depuis (2026, premier slot de l’epoch) | Epoch nominale | Fenêtre de leader | Hachages par tick avant Alpenglow | Slot moyen mesuré |
|---|---|---|---|---|---|
| 400 ms | jusqu’au 21 août | 48 heures | 1,6 s | 62 500 | environ 416 ms (epochs 1016-1019) |
| 350 ms | 21 août, 07:45 UTC (epoch 1020) | 42 heures | 1,4 s | 54 687 | environ 365-367 ms (epochs 1020-1023) |
| 300 ms | 28 août, 15:25 UTC (epoch 1024) | 36 heures | 1,2 s | 46 875 | environ 315-317 ms (epochs 1024-1036) |
| 250 ms | 18 septembre, 05:06 UTC (epoch 1037) | 30 heures | 1,0 s | 39 062 | environ 266-269 ms (epochs 1037-1052) |
| 200 ms | 9 octobre, 14:40 UTC (epoch 1053) | 24 heures | 0,8 s | 31 250 | environ 212-218 ms (epochs 1053-1079) |
Les slots tournent un peu plus lentement que la cible, comme ils l’ont toujours fait. Les échantillons de performance du RPC public, le 8 novembre 2026, indiquaient 277 à 284 slots par minute, soit environ 211 à 217 millisecondes chacun. SIMD-0525 donne la motivation sans détour : des slots plus courts réduisent les délais de confirmation, et une fenêtre de leader de 0,8 seconde au lieu de 1,6 divise par deux le temps pendant lequel un leader peut retarder ou réordonner des transactions avant que le suivant ne prenne la main. Un effet de bord pour les utilisateurs : le blockhash récent, que toute transaction doit référencer, expire après 150 blocs ; une transaction signée devient donc caduque en 30 secondes environ, contre une minute auparavant.
Comment un bloc devenait final sous Tower BFT
Des votes à verrouillage doublé
Tower BFT était l’adaptation par Solana de la tolérance byzantine pratique à l’horloge PoH. Les validateurs votaient sur les blocs qu’ils voyaient, par des transactions ordinaires inscrites dans la chaîne, et chaque vote portait un verrouillage (lockout) : l’engagement de ne pas voter pour une branche concurrente pendant un certain nombre de slots. D’après la documentation d’Anza sur Tower BFT, chaque nouveau vote doublait les verrouillages des votes précédents dans la « tour » d’un validateur, si bien que l’engagement d’un vote croissait de 2, 4, 8, 16 slots et ainsi de suite à mesure que d’autres votes s’empilaient. Au bout de 32 votes, le plus ancien atteignait un verrouillage de 2 puissance 32 slots, sortait de la tour et son bloc devenait la racine de ce validateur.
Deux garde-fous évitaient qu’un validateur ne s’enferme sur une branche perdante. Avant de s’engager plus profond, il vérifiait que son vote placé huit rangs plus bas dans la tour était soutenu par deux tiers de la mise. Pour passer sur une autre branche, il lui fallait la preuve que plus de 38 % de la mise s’y trouvait déjà. C’est le PoH qui rendait les verrouillages applicables : ils se comptaient en slots, les slots en ticks, et nul ne pouvait raccourcir un verrouillage en affirmant que le temps avait passé sans montrer les hachages.
Confirmation optimiste et écart de 12,8 secondes
Les portefeuilles n’attendaient pas les racines. Un bloc voté par deux tiers de la mise comptait comme confirmé en une seconde environ, alors que la finalité complète demandait 32 slots. La proposition d’Alpenglow, SIMD-0326, est franche sur son prédécesseur : Tower BFT « does not have a security proof, which is concerning » (n’a pas de preuve de sécurité, ce qui est préoccupant). Il coûtait aussi cher. Chaque validateur payait environ 1 SOL par jour de frais de transactions de vote, selon le même document, et ces votes rivalisaient avec les transactions des utilisateurs pour l’espace de chaque bloc.
Turbine et Gulf Stream : acheminer blocs et transactions
Un leader qui produit un bloc toutes les quelques centaines de millisecondes ne peut pas l’envoyer à tour de rôle à plusieurs centaines de validateurs. Turbine, la couche de propagation des blocs de Solana, découpe chaque bloc en petits paquets appelés shreds, ajoute des shreds de récupération par code correcteur d’erreurs pour qu’un bloc se reconstruise même si des paquets se perdent, et pousse chaque shred dans un arbre de validateurs où les nœuds les plus dotés en mise sont plus proches du leader. La documentation d’Anza précise que l’arbre est rebattu pour chaque shred. Turbine transporte toujours les blocs aujourd’hui : son remplaçant prévu, Rotor, n’est pas en service.
Gulf Stream était le nom d’origine d’une seconde idée : pas de salle d’attente publique. Comme le calendrier des leaders est connu à l’avance, les nœuds RPC transmettent les transactions directement au leader courant et aux suivants au lieu de les faire circuler dans tout le réseau, comme le font Bitcoin et Ethereum avec leurs mempools et marchés de frais. Des mises à jour ultérieures ont déplacé ces connexions vers le protocole QUIC et ajouté une qualité de service pondérée par la mise, qui réserve davantage de la capacité d’entrée d’un leader au trafic relayé par des validateurs dotés de mise. Le nom survit à peine dans le code ; le modèle de transmission, lui, demeure.
Alpenglow : le vote qui a remplacé Tower BFT et l’horloge
Alpenglow a été conçu par Quentin Kniep, Kobi Sliwinski et Roger Wattenhofer, puis spécifié pour Solana dans SIMD-0326. Le vote de gouvernance pondéré par la mise l’a approuvé début septembre 2025 avec environ 98 % des suffrages exprimés en sa faveur, selon Blockworks. La page d’Anza, datée du 5 novembre 2026, indique une activation sur le testnet le 24 septembre et sur le devnet le 25 septembre, avant le mainnet. SIMD-0326 couvre la moitié « vote », Votor. La moitié « diffusion des blocs », Rotor, doit recevoir sa propre proposition plus tard.
Votor : un tour à 80 %, ou deux à 60 %
Sous Votor, chaque validateur fait tourner un minuteur local pour le slot en cours. Si un bloc valide arrive à temps, il vote pour le notariser ; sinon, il vote pour sauter le slot. Les votes ne sont plus des transactions. Ils circulent directement entre validateurs et sont agrégés en signatures BLS compactes appelées certificats. Si 80 % de la mise notarisent un bloc dès ce premier tour, le bloc est final aussitôt, ce que la spécification nomme finalisation rapide. Si 60 % seulement le font, les validateurs lancent un second tour, et 60 % de votes de finalisation concluent l’affaire.
SIMD-0326 définit cinq certificats : notarisation, saut, finalisation, finalisation rapide et notar-fallback. Les votes de repli permettent au réseau de se rétablir quand le premier tour se divise. Il n’y a plus de verrouillages ni de tour de 32 votes : quand un bloc est finalisé, tous ses ancêtres le sont avec lui, et les slots absents de sa chaîne sont traités comme sautés.
Le prix à payer est un autre modèle de fautes. Les protocoles BFT classiques, dont la famille Tendermint de la leçon précédente, restent sûrs jusqu’à un tiers de mise byzantine. Les auteurs d’Alpenglow ont retenu ce qu’ils appellent un modèle 20+20 : un fonctionnement correct avec jusqu’à 20 % de la mise agissant de façon malveillante, plus 20 % de plus simplement hors ligne. La proposition indique qu’elle renonce à la borne byzantine de 33 % en échange d’une finalité en un seul tour et d’une résistance aux pannes de 40 %, et soutient que le marché vaut la peine.
Ce qui change pour les validateurs
Les votes sortant de la chaîne, les frais de vote ont disparu. Pour maintenir l’économie à peu près où elle était, Alpenglow a ajouté un ticket d’admission du validateur, prélevé avant chaque epoch et brûlé plutôt que versé à quelqu’un. Il équivaut à 80 % de l’ancien coût de vote, environ 0,8 SOL par jour. SIMD-0525 le fait varier avec le temps de slot pour que le coût quotidien ne change pas : 1,6 SOL par epoch de 48 heures à 400 millisecondes, 0,8 SOL par epoch de 24 heures à 200. L’ensemble actif est plafonné aux 2 000 validateurs les mieux dotés en mise, très au-dessus du nombre actuel. Les récompenses vont aux votes qu’un leader inclut dans des agrégats huit slots plus tard, et un validateur qui ne gagne rien pendant une epoch quitte l’ensemble actif.
On en voit une trace depuis l’extérieur. Dans chacun des trois échantillons d’une minute renvoyés par le RPC public le 8 novembre 2026, environ 50 000 transactions, le nombre de transactions hors votes était égal au total. Sous Tower BFT, le total incluait les transactions de vote. C’est un contrôle rapide, pas un audit, mais il concorde avec des votes qui ne voyagent plus dans les blocs.
Le basculement du 21 octobre 2026
Changer de consensus sur un réseau en marche sans défaire les paiements déjà confirmés était la partie difficile. SIMD-0384, la proposition de migration, a fixé la frontière 5 000 slots après l’activation de la fonctionnalité, au slot 459 653 000. À partir de là, les blocs ne contenaient que des votes jusqu’à ce qu’un bloc obtienne une forte confirmation optimiste de 82 % de la mise. Les validateurs signaient alors un vote de genèse pour le dernier bloc Tower BFT avant la frontière, et 82 % de ces votes formaient le certificat de genèse. Les blocs postérieurs au bloc de genèse étaient écartés, ce qui était sans risque puisqu’ils ne contenaient aucune transaction d’utilisateur, et Alpenglow prenait le relais.
Sur le mainnet, la porte est devenue active au slot 459 648 000, que la chaîne date du 21 octobre 2026 à 13:36:05 UTC. Les slots 459 653 000 à 459 653 007 n’ont produit aucun bloc ; le premier bloc après la frontière, le slot 459 653 008, porte l’heure 13:54:03 UTC, soit environ 18 minutes après la porte. Le seuil de 82 % s’accompagne d’une courte preuve dans la proposition : avec au plus 19 % de mise malveillante, deux certificats contradictoires ne peuvent pas atteindre 82 % chacun, et les 63 % de mise honnête qui restent suffisent à faire tourner Alpenglow.
Ce qu’il reste du proof of history
La page d’Anza résume le remplacement en une ligne : « Every node runs its own timers and independently identifies a silent leader. » (chaque nœud fait tourner ses propres minuteurs et repère seul un leader silencieux). Un slot dont le leader reste muet se termine par un certificat de saut. SIMD-0326 dit de ces délais : « Their purpose is akin to Proof-of-History, but without any notion of synchronized time. » (leur rôle s’apparente à celui du proof of history, mais sans aucune notion de temps synchronisé). La dérive des horloges ne compte plus : la proposition note que tolérer 5 % de dérive revient seulement à allonger les délais de 5 %.
Le reliquat exact est écrit dans SIMD-0384 (sa page du dépôt la montrait encore comme en cours de revue le 8 novembre 2026, donc à lire comme la spécification, pas comme un audit du code). Dès que les blocs Alpenglow ont commencé, le producteur de ticks a été mis en mode basse consommation à un hachage par tick, la hauteur de tick de la banque est fixée juste sous son maximum avant la fin de chaque bloc, et un dernier tick clôt chaque bloc pour que le logiciel qui assemble les transactions et diffuse les shreds sache que le bloc est terminé. La vérification des ticks a été désactivée. SIMD-0525 ajoute que les hachages par tick ne doivent pas être abaissés tant qu’Alpenglow tourne, son chemin basse consommation étant « currently expected to be one hash per tick » (actuellement attendu à un hachage par tick).
Un slot de 200 millisecondes qui portait 2 millions de hachages séquentiels à la mi-octobre se termine donc aujourd’hui par un seul hachage qui ne prouve rien sur le temps. Les noms de fonctions survivent dans le code ; l’horloge, non. Les leaders sont toujours désignés à l’avance selon la mise, par fenêtres de quatre slots, comme le montre l’échantillon RPC ; la graine utilisée par le calendrier depuis le basculement n’est pas indiquée dans la documentation publique d’Anza.
Des objectifs qui restent des objectifs
Deux chiffres phares demandent de la prudence. L’annonce d’Anza de mai 2025 situait la finalité médiane d’Alpenglow autour de 150 millisecondes, parfois 100, d’après des simulations sur la répartition de mise de l’époque. Aucune mesure indépendante de la finalité du mainnet depuis le 21 octobre n’avait été publiée au 8 novembre 2026 : les 150 millisecondes sont donc la cible de conception, pas un résultat observé. Rotor, qui selon Anza remplacera l’arbre multicouche de Turbine par un unique saut de relais, figure parmi les prochaines étapes.
| Tower BFT (jusqu’au 21 octobre 2026) | Alpenglow Votor (depuis) | |
|---|---|---|
| Votes | transactions dans la chaîne, avec verrouillages | envoyés directement entre validateurs, agrégés en certificats BLS |
| Final quand | 32 votes de profondeur (racine) ; confirmé à deux tiers de la mise | 80 % notarisent en un tour, ou 60 % en deux tours |
| Durée typique | environ 12,8 s avec des slots de 400 ms | environ 150 ms en médiane, objectif de conception |
| Modèle de fautes | moins d’un tiers de mise byzantine | 20 % byzantins plus 20 % hors ligne |
| Mesure du temps | chaîne de hachages PoH, 64 ticks par slot | délais locaux ; un tick de clôture d’un seul hachage |
| Coût du vote | environ 1 SOL par jour en frais | ticket d’admission d’environ 0,8 SOL par jour, brûlé |
| Plafond de validateurs | aucun | les 2 000 mieux dotés en mise |
| Diffusion des blocs | Turbine | Turbine (Rotor prévu) |
Pannes de Solana : pourquoi elles ont pesé plus que l’horloge
Le problème de réputation de Solana n’a jamais été la vitesse de son horloge, mais l’arrêt du réseau. Six arrêts complets entre septembre 2021 et février 2024 ont duré d’environ quatre heures et demie à environ 20 heures chacun, et ils aident à comprendre pourquoi les validateurs ont accepté à la fois un second client et le remplacement complet du consensus.
| Date (UTC) | Durée approximative | Ce qui s’est passé |
|---|---|---|
| 14-15 septembre 2021 | environ 17 heures | des transactions de robots inondant la vente de jetons Grape Protocol sur Raydium ont épuisé la mémoire des validateurs ; redémarrage coordonné par les opérateurs |
| 30 avril-1er mai 2022 | environ 7 heures | des robots en concurrence pour frapper des NFT via la Candy Machine de Metaplex ont saturé les leaders ; mémoire épuisée ; redémarrage achevé vers 03:00 UTC |
| 1er juin 2022 | environ 4,5 heures | un bogue dans le traitement des transactions à nonce durable a divisé les validateurs ; arrêt vers 16:30 UTC, redémarrage à 21:00 UTC |
| 30 septembre-1er octobre 2022 | environ 8 heures | un nœud de secours mal configuré a produit des blocs en double et un bogue de choix de branche a stoppé la production ; arrêt à 22:41 UTC, redémarrage vers 07:00 UTC |
| 25-26 février 2023 | près de 20 heures (estimations de presse) | finalisation dégradée pendant la mise à niveau de la version 1.13 vers la 1.14 ; redémarrage sur la 1.13.6, première tentative abandonnée |
| 6 février 2024 | environ 5 heures | boucle de recompilation infinie dans le cache de programmes de la v1.17 ; finalisation arrêtée à 09:53 UTC, reprise à 14:55 UTC |
6 février 2024, le dernier arrêt complet
Le rapport d’Anza sur la panne de février 2024 l’attribue au cache qui stocke les programmes compilés à la volée. Un programme utilisant un ancien chargeur, déployé dans une séquence particulière, a plongé les validateurs dans une boucle de recompilation sans fin. Plus de 95 % de la mise faisaient tourner la même version v1.17, si bien que presque tous les validateurs ont calé sur le même bloc, personne n’a voté, et la finalisation s’est arrêtée à 09:53 UTC. Les ingénieurs ont livré la v1.17.20 avec un correctif ciblé vers 12:34 UTC, et le consensus a repris à 14:55 UTC après un redémarrage coordonné. Un bogue semblable avait touché le devnet une semaine plus tôt.
L’arrêt de 2021 était d’une autre nature. Le bilan initial de la Solana Foundation décrivait des robots inondant une vente de jetons jusqu’à ce que les validateurs manquent de mémoire, et il a fallu environ 14 heures aux ingénieurs pour écrire un correctif et coordonner un redémarrage. La charge, et non un chemin de code précis, était le déclencheur. Le même schéma est revenu le 30 avril 2022, quand des robots de frappe de NFT ont submergé le réseau pendant environ sept heures, et les évolutions ultérieures de la manière dont les leaders acceptent les transactions, les changements QUIC et pondérés par la mise décrits plus haut, visaient cette faiblesse.
1 000 jours sans arrêt, et un client de trop
Aucun arrêt complet n’a été signalé depuis. Crypto Briefing a compté 1 000 jours consécutifs sans arrêt du réseau vers le 2 novembre 2026 (article en anglais), et écrit que la page d’état de Solana affichait 100 % de disponibilité les mois précédents. La page d’état elle-même ne listait aucun incident sur le mainnet pendant les deux semaines jusqu’au 8 novembre. L’épisode de février 2024 montre le risque qui demeure : quand presque toute la mise fait tourner la même base de code, un seul bogue arrête tout le monde en même temps. Alpenglow continue de finaliser avec jusqu’à 40 % de la mise en panne, d’après sa spécification, et pas davantage ; des logiciels identiques ont tendance à tomber ensemble.
C’est l’argument en faveur de Firedancer, un client de validation indépendant écrit de zéro par une équipe de Jump Crypto. Sa page de versions sur GitHub liste la v26.10.6 comme version prête pour le mainnet le 5 novembre 2026 ; la prise en charge d’Alpenglow a atteint une version prête pour le mainnet pour la première fois avec la v26.10.2, le 14 octobre. Aucun suivi neutre et publié des parts de clients n’était disponible au 8 novembre 2026. La lecture par Coindaro de la liste publique des nœuds ce jour-là a relevé 92 nœuds votants détenant environ 15,6 % de la mise active sur des versions commençant par « 26. », ce qui correspond à la numérotation année-mois de Firedancer, tandis que les nœuds en versions « 4. », la lignée Agave et ses dérivés comme le client de Jito, en détenaient environ 83,5 %. Six autres faisaient tourner des versions « 0. », la numérotation de Frankendancer, un hybride qui associe le réseau de Firedancer à l’exécution d’Agave, pour environ 0,6 %. Ce partage est une inférence de Coindaro à partir des numéros de version, pas un chiffre publié par les développeurs.
Qui fait tourner Solana au 8 novembre 2026
Les seuils d’Alpenglow rendent la concentration de la mise facile à lire : 20 % est le budget malveillant de son modèle de fautes, 40 % le budget de pannes, 80 % la voie rapide. Le tableau compte les comptes de vote, du plus gros vers le plus petit, qu’il faut pour atteindre chaque seuil.
| Mesure (RPC public, 8 novembre 2026, vers 10:00 UTC) | Valeur |
|---|---|
| Comptes de vote avec mise active | 697 (662 votants, 35 en retard) |
| Mise active | environ 434,8 millions de SOL |
| Plus gros comptes de vote détenant 20 % de la mise | 8 |
| Détenant un tiers | 18 |
| Détenant la moitié | 40 |
| Détenant deux tiers | 78 |
| Nécessaires pour 80 % (finalisation rapide) | 141 |
| Part des 10 plus gros | 24,6 % |
| Nœuds visibles dans le gossip (RPC et nœuds non votants inclus) | 3 843 |
Un compte de vote n’est pas une entreprise. Un même opérateur peut en exploiter plusieurs, et la mise déléguée via des plateformes d’échange et des services de staking peut dépendre de moins de mains que le tableau ne le suggère : la concentration réelle ne peut donc être que plus élevée que ces chiffres. Avec cette réserve, huit comptes de vote détiennent déjà les 20 % que le modèle d’Alpenglow traite comme son maximum malveillant, et la voie rapide demande 141 comptes pour répondre dans le même tour. Chainspect, qui publie des coefficients de Nakamoto pour de nombreuses chaînes, affichait 17 pour Solana sur 664 validateurs le même jour, proche des 18 comptes de vote du tableau. Pour voir comment la délégation façonne ces chiffres sur d’autres réseaux, consultez notre leçon sur la preuve d’enjeu déléguée.
Ce que le proof of history laisse derrière lui
Le proof of history de Solana a fait un travail à la perfection : transformer une fonction de hachage en métronome que chaque validateur pouvait contrôler, et laisser les leaders se relayer sans demander la permission. Il n’a jamais décidé quels blocs étaient finaux, et depuis le 21 octobre 2026 il ne garde même plus le temps. Des minuteurs locaux s’en chargent, et les votes voyagent hors de la chaîne sous forme de certificats.
Deux choses restent à venir. Rotor doit remplacer Turbine par sa propre proposition, et l’objectif de finalité de 150 millisecondes attend encore une mesure indépendante sur le mainnet. La prochaine leçon de ce parcours, consensus comparés, place le proof of history, Alpenglow et les autres familles côte à côte dans un seul tableau.
