Le 22 septembre 2026, le Cosmos Hub, une chaîne qui repose sur le consensus Tendermint, s’est arrêté. Le bloc 33 086 741 porte l’horodatage 11:18:23 UTC ; le bloc suivant, 33 086 742, indique 12:06:23 UTC le lendemain. Cet écart de 24 heures et 48 minutes se lit sur la chaîne elle-même, à la portée de n’importe qui. Aucun serveur n’était tombé et aucun bogue ne s’était déclenché. Les validateurs du Hub ont suspendu la production de blocs de leur plein gré, après qu’un attaquant, qui avait pris le contrôle d’applications de Neutron par un vote de gouvernance, a fait passer de la valeur volée sur le Hub sous forme d’ATOM, d’après Protos. Quand la chaîne a repris, son premier bloc tournait sur une version corrigée qui a déplacé 1 227 121,37 ATOM hors de l’adresse liée à l’attaquant.
Cet arrêt, c’était le vote BFT qui fonctionnait comme prévu. Un bloc du Hub est définitif dès que des validateurs détenant plus des deux tiers du pouvoir de vote l’ont signé, et quand assez d’entre eux refusent de signer, plus rien ne bouge. Cette leçon démonte ce vote : les tours et les verrous de Tendermint, ce que le protocole HotStuff a changé après 2018, les chaînes qui font tourner ses descendants, les conceptions en DAG qui ont supprimé le leader unique, et la raison pour laquelle toutes gardent un ensemble de validateurs réduit.
La théorie qui sous-tend tout cela figure dans notre leçon sur le problème des généraux byzantins. En bref : un groupe de n machines ne peut s’accorder malgré f menteurs que si n vaut au moins 3f + 1, les messages signés changent le calcul, PBFT a rendu l’idée praticable en 1999, et le résultat FLP établit qu’aucun protocole ne peut être à la fois toujours sûr et toujours vivant sur un réseau sans horloge fiable. Tendermint et HotStuff acceptent tous deux ce marché. Ils garantissent la sûreté quel que soit le délai du réseau et ne promettent d’avancer que lorsque le réseau se comporte bien.
La conséquence pour les utilisateurs est traitée dans notre leçon sur la finalité et les réorganisations : un bloc validé sur une chaîne CometBFT est définitif en un bloc, sans réorganisation à attendre, et quand trop de validateurs manquent, la chaîne s’arrête au lieu de se scinder. Bitcoin offre une finalité par la profondeur et Ethereum par des votes de point de contrôle tous les deux epochs. Ici, les deux leçons sont considérées comme acquises, et nous regardons l’intérieur de la machine qui produit cette finalité en un bloc.
La leçon précédente de ce parcours, sur la preuve d’enjeu déléguée, a montré comment les validateurs sont élus et combien peu d’opérateurs peuvent détenir un tiers de l’enjeu. Celle-ci traite de ce que font ces validateurs élus, message après message, toutes les quelques secondes.
De Tendermint à CometBFT : un même moteur, dix ans
Tendermint est né du livre blanc de Jae Kwon, « Tendermint: Consensus without blockchain and earns a reward, which makes rewriting history very expensive.">Mining », que le dépôt de CometBFT référence toujours. Ethan Buchman a développé l’algorithme dans son mémoire de master à l’université de Guelph, « Tendermint: Byzantine Fault Tolerance in the Age of Blockchains », que la bibliothèque universitaire date du 23 juin 2016. La version formelle est arrivée le 13 juillet 2018, quand Buchman, Kwon et Zarko Milosevic ont déposé sur arXiv « The latest gossip on BFT consensus », révisé une dernière fois en novembre 2019.
L’article part d’un contraste. La réplication classique de machines à états tournait dans des centres de données avec « trois à sept » réplicas gérés par une seule organisation. Une blockchain publique exige des centaines de validateurs répartis entre entreprises et pays, reliés seulement par l’internet ouvert. La réponse de Tendermint a été de garder le vote de type PBFT et de livrer chaque message par propagation de pair à pair (gossip), si bien qu’un validateur n’a besoin de parler qu’à ses voisins.
La deuxième idée est la séparation des tâches. Tendermint ordonne les transactions et laisse leur sens à une application branchée par une interface, ABCI. Le Cosmos SDK est l’un de ces cadres applicatifs, ce qui explique que « Cosmos » et « Tendermint » soient souvent confondus : le SDK décide de ce que fait une transaction, le moteur de consensus décide dans quel ordre les transactions deviennent définitives.
La scission est intervenue à la charnière de 2023. Le 5 janvier, Jae Kwon a figé les fonctionnalités de Tendermint Core à sa branche 0.34, celle que le Cosmos Hub exécutait alors, et a relevé dans le dépôt que l’équipe d’Informal Systems avait créé un fork nommé CometBFT. Informal Systems a annoncé ce fork le 1er février 2023 comme « un fork de Tendermint Core et son successeur », et sa première version, la v0.34.27, a suivi le 27 février. Le README du projet le dit sans détour aujourd’hui : « CometBFT est un fork de Tendermint Core et implémente l’algorithme de consensus Tendermint » (traduction). Le nom a changé, pas l’algorithme.
Le moteur reste maintenu. La version v0.40.0, publiée le 27 juillet 2026, a ajouté un type de clé de validateur post-quantique, mldsa65, fondé sur la norme de signature ML-DSA, et la v0.38.26 a rétroporté sa vérification le 13 août 2026. Les nœuds publics du Cosmos Hub interrogés le 8 novembre 2026 annonçaient CometBFT v0.38.25. Plusieurs chaînes de la famille, dont Celestia et dYdX, exploitent leurs propres forks du moteur : le numéro de version varie donc d’un réseau, et parfois d’un nœud, à l’autre.
Comment fonctionne le consensus Tendermint, un tour à la fois
Tendermint décide un bloc par hauteur. Chaque hauteur comporte un ou plusieurs tours, et chaque tour compte trois étapes : proposition, prévote, précommit. Si un tour échoue, le suivant commence avec un nouveau proposant et la même hauteur. Les règles ci-dessous suivent la spécification du consensus de CometBFT telle que publiée le 8 novembre 2026.
Proposer, prévoter, précommiter
Le proposant de chaque tour est désigné par un tourniquet déterministe que la spécification décrit comme pondéré par le pouvoir de vote : un validateur avec deux fois plus d’enjeu propose deux fois plus souvent. Chaque nœud peut calculer qui est le proposant, 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 n’y a donc aucun message d’élection. Le proposant construit un bloc et le diffuse.
À l’étape de prévote, chaque validateur signe une prévote pour ce bloc s’il l’a reçu à temps et le juge valide. Sinon, il prévote nil, un vote explicite pour rien. Les votes se comptent en pouvoir de vote, pas en têtes. La spécification note « +2/3 » pour plus des deux tiers du pouvoir de vote et « 1/3+ » pour un tiers ou plus.
Lorsqu’un validateur voit plus des deux tiers de prévotes pour un même bloc, il passe au précommit et signe un précommit pour ce bloc. Quand il voit ensuite plus des deux tiers de précommits pour lui, le bloc est validé et la hauteur est terminée. Sur le Cosmos Hub, où 180 validateurs figuraient dans l’ensemble actif le 8 novembre 2026, cela signifie des signatures représentant plus des deux tiers des ATOM délégués, quel que soit le nombre de validateurs derrière elles.
Il faut deux votes parce qu’un seul ne suffit pas à s’assurer que les autres ont vu la même chose. Un quorum de prévotes apprend à un validateur que le réseau s’est entendu, pour ce tour, sur un seul candidat. Un quorum de précommits lui apprend que plus des deux tiers du pouvoir le savent aussi, et se sont engagés à s’y tenir.
Pourquoi un validateur se verrouille sur un bloc
Cet engagement, c’est le verrou. Un ensemble de plus des deux tiers de prévotes pour un bloc au cours d’un tour s’appelle une preuve de changement de verrou, ou PoLC (proof-of-lock-change). Un validateur qui voit une PoLC pour le bloc B et précommite B est désormais verrouillé sur B. Aux tours suivants de la même hauteur, il prévote de nouveau B, quoi que propose le nouveau proposant, et il ne lâche son verrou que s’il voit une PoLC pour autre chose à un tour ultérieur.
L’argument de sûreté, tel que la spécification le donne, tient en quelques lignes. Supposons que moins d’un tiers du pouvoir de vote soit byzantin. Si un validateur a validé B au tour R, il a vu plus des deux tiers de précommits pour B à R. Retirez de ce groupe le tiers malhonnête et il reste plus d’un tiers du pouvoir qui est honnête et verrouillé sur B. Ces validateurs ne prévoteront rien d’autre, donc aucun autre bloc ne pourra jamais réunir les plus des deux tiers dont il a besoin. Deux validations contradictoires à une même hauteur exigeraient que plus d’un tiers des validateurs signent les deux, une preuve que la chaîne peut établir et sanctionner, comme l’explique notre leçon sur le slashing et les récompenses des validateurs.
Les verrous pourraient figer une chaîne si des validateurs honnêtes différents détenaient des verrous différents. L’article de 2018 règle ce point avec deux variables par validateur, la valeur verrouillée et la valeur valide : un proposant ultérieur re-propose le bloc qui a le plus récemment réuni une PoLC, et les validateurs verrouillés sur un tour plus ancien peuvent l’accepter. Le progrès reprend dès qu’un tour se passe bien.
Délais, tours supplémentaires et coût de l’attente
La spécification énumère quatre raisons pour qu’un tour échoue : le proposant est hors ligne, son bloc est invalide, le bloc ne s’est pas propagé à temps, ou les prévotes et précommits ne sont pas arrivés à temps. Chaque étape a donc un minuteur. Dans l’article de 2018, chaque délai croît avec le numéro du tour, comme une valeur initiale plus le numéro du tour multiplié par un incrément fixe, et se réinitialise à chaque nouvelle hauteur. Un réseau lent allonge les tours jusqu’à ce que les messages y tiennent.
Après une validation, les nœuds attendent aussi un délai fixe, timeoutCommit, pour recueillir les signatures tardives avant de démarrer la hauteur suivante. Ces attentes font partie du temps de bloc. Mesuré sur 1 000 blocs le 8 novembre 2026, entre 08:11:35 et 09:46:45 UTC, le Cosmos Hub a produit un bloc toutes les 5,71 secondes en moyenne. Osmosis, également sur CometBFT, a affiché 0,84 seconde sur un échantillon du même type : le vote est le même, les paramètres non.
L’attente est aussi la cible des critiques. Les auteurs de HotStuff soutiennent que la réactivité (responsiveness) « est exclue par des conceptions telles que Tendermint/Casper » (traduction). Leur argument : dans Tendermint, un nouveau proposant doit attendre le délai maximal connu du réseau pour être sûr d’avoir entendu parler du plus haut verrou détenu par un validateur honnête. Une chaîne ne peut pas aller plus vite que ce minuteur, même quand le réseau est rapide.
Le gossip plutôt qu’un collecteur central
Dans Tendermint, chaque validateur diffuse sa prévote et son précommit, et chaque autre validateur doit les recevoir et les vérifier. Avec n validateurs, cela représente environ n au carré vérifications de signature par étape sur l’ensemble du réseau. Le résumé de l’article indique que la conception simplifie le BFT classique en s’appuyant sur un protocole de gossip de pair à pair entre les nœuds. Le gossip maintient la circulation des messages quand certains liens tombent, au prix d’un trafic qui croît vite avec n.
Trois arrêts de chaînes Cosmos, trois causes différentes
Parce que Tendermint préfère la sûreté à la vivacité, ses défaillances se ressemblent vues de l’extérieur : les blocs s’arrêtent. Les causes de trois arrêts de chaînes Cosmos sont pourtant très différentes. (Les arrêts de Terra en mai 2022, pendant l’effondrement de LUNA, sont racontés dans la leçon sur les généraux byzantins.)
| Chaîne | Dates | Durée | Cause | Suites |
|---|---|---|---|---|
| Neutron (sécurisée par les validateurs du Cosmos Hub) | 1er août 2023 | Non indiquée dans les sources utilisées | Arrêt après une mise à jour logicielle ; deux validateurs ont signé deux fois en mettant à jour dans la précipitation | Proposition 818 du Hub visant à les sanctionner, rejetée le 24 août 2023 |
| Cosmos Hub | 5-6 juin 2024 | Environ 4 h 40 min (de 19:21 à 00:02 UTC) | Panique dans GetLastValidators : plus de 180 validateurs liés après une sortie de prison | Gaia v17.2.0, correctif du Cosmos SDK |
| Cosmos Hub | 22-23 septembre 2026 | 24 h 48 min entre les blocs 33 086 741 et 33 086 742 | Les validateurs ont cessé de signer après l’attaque de gouvernance sur Neutron | Gaia corrigé a déplacé 1 227 121,37 ATOM vers une adresse de récupération ; proposition 1056 rejetée avec veto |
Sources : Informal Systems (août 2023), propositions 818 et 1056 du Cosmos Hub lues sur la chaîne, post-mortem de Cosmos Hub v17.1 sur le forum Cosmos, temps de bloc lus sur le Cosmos Hub le 8 novembre 2026, Protos et CryptoSlate (septembre 2026).
Août 2023 : Neutron cale et deux validateurs signent deux fois
Neutron, une chaîne alors sécurisée par les validateurs du Cosmos Hub au titre de la sécurité répliquée du Hub, s’est arrêtée le 1er août 2023 après une mise à jour logicielle qui avait mal tourné. Dans la hâte de la mise à jour, deux validateurs ont supprimé le fichier qui empêche un nœud CometBFT de signer deux fois à la même hauteur, et ils ont signé des blocs contradictoires, d’après un post-mortem d’Informal Systems publié le 17 août 2023. La proposition 818 du Hub, intitulée « Punish Equivocation on Neutron by Pupmos and Citizen Cosmos », demandait aux détenteurs d’ATOM de les sanctionner par slashing. Elle a été rejetée le 24 août 2023 : environ 100,3 millions d’ATOM ont voté non, 23,8 millions oui, 16,2 millions se sont abstenus et 2,0 millions ont opposé leur veto, selon le décompte de la proposition sur la chaîne.
L’épisode montre une facette de la sûreté BFT que les preuves laissent de côté. Le moteur a enregistré la preuve de la double signature, que n’importe qui pouvait interroger depuis un nœud Neutron. La question de la sanction était politique, et les stakers ont répondu qu’un accident survenu en pleine urgence ne méritait pas de coupe.
Juin 2024 : une panique à 180 validateurs
Le 5 juin 2024, le Cosmos Hub est passé à la v17 entre 16:58 et 17:15 UTC. À 19:21 UTC, il s’est arrêté au bloc 20 740 970 et n’a produit le bloc 20 740 972 qu’à 00:02 UTC le 6 juin, environ 4 heures 40 minutes plus tard, selon le post-mortem publié sur le forum Cosmos.
La cause était une panique dans une fonction appelée GetLastValidators, exécutée à la fin de chaque bloc. Une transaction de sortie de prison a brièvement placé un validateur de trop dans l’ensemble lié, et le code a trouvé plus que le maximum de 180 validateurs liés. Tous les nœuds honnêtes ont rencontré la même panique à la même hauteur : la chaîne s’est donc arrêtée au lieu de diverger. Le correctif est sorti sous la forme de Gaia v17.2.0 avec un Cosmos SDK corrigé. Le chiffre de 180 est un choix de gouvernance, et il est aussi câblé dans la machine à états.
Septembre 2026 : s’arrêter exprès
L’arrêt de septembre 2026 a commencé sur Neutron. Une proposition de gouvernance intitulée « AI Agent Takeover » y a été adoptée et a donné à son auteur le contrôle de deux applications, Astroport et Drop, selon Protos, qui rapporte que l’attaquant a dépensé environ 20 199 dollars en jetons NTRN pour faire passer le vote. Les estimations de la perte divergent : Protos a avancé des pertes initiales de 9,5 millions de dollars, tandis qu’un contributeur de Neutron cité par CryptoSlate situait l’impact initial près de 4,4 millions. Une partie de la valeur est arrivée sur le Cosmos Hub sous forme d’ATOM.
Les validateurs du Hub ont alors cessé de signer, après le bloc 33 086 741. Pour qu’une chaîne Tendermint s’arrête, il suffit que des validateurs détenant plus d’un tiers du pouvoir de vote restent silencieux ; la presse n’a pas publié qui s’est arrêté le premier ni dans quel ordre. La chaîne a redémarré le 23 septembre 2026 vers 12:06 UTC sur une version corrigée de Gaia, et son premier nouveau bloc a déplacé 1 227 121,37 ATOM, environ 2,2 millions de dollars à l’époque selon CryptoSlate, vers une adresse de récupération contrôlée par un groupe de validateurs. Le correctif n’a pas pu tout rattraper : 168 990,9 ATOM remboursés par THORChain sont arrivés à l’adresse liée à l’attaquant sept blocs après le redémarrage, puis ont été transférés sur Osmosis et vendus pour environ 266 841 USDC, selon un analyste on-chain cité par CryptoSlate.
Une proposition du Hub, numérotée 1056, a ensuite demandé que la réserve communautaire verse 1 221 120 ATOM à l’adresse liée à l’attaquant, en décrivant le prélèvement comme un vol, plus une « prime de justice » de 500 000 ATOM pour ceux qui votaient oui. Le vote s’est clos le 30 septembre 2026 à 23:20 UTC et elle a été rejetée : environ 91,5 millions d’ATOM ont voté non avec veto, 6,0 millions non, 3,9 millions se sont abstenus et 0,6 million ont voté oui, soit près de 90 % de veto selon notre lecture du décompte sur la chaîne.
Ce qu’un arrêt montre et ne montre pas
Aucun de ces arrêts n’a brisé la sûreté. Jamais deux blocs contradictoires n’ont été définitifs à la même hauteur. Ce qu’ils révèlent, c’est où se situe le pouvoir. La règle qui permet à plus des deux tiers de finaliser un bloc permet aussi à un tiers de geler une chaîne, et à une supermajorité de la relancer avec un changement d’état qu’aucune transaction n’a signé. Certains qualifient septembre 2026 de sauvetage d’urgence, d’autres de précédent de censure. Le protocole n’a pas d’opinion : il compte des signatures.
HotStuff : un leader collecte les votes
Maofan Yin, Dahlia Malkhi, Michael Reiter, Guy Golan Gueta et Ittai Abraham ont déposé HotStuff sur arXiv le 13 mars 2018 ; une version courte a été présentée à la conférence PODC en 2019. Il conserve le modèle partiellement synchrone de PBFT et de Tendermint et s’attaque à deux coûts : le prix du remplacement d’un leader, et l’attente qui rend Tendermint plus lent que le réseau.
Le problème : des changements de leader coûteux
Dans PBFT, changer de leader (un changement de vue) oblige chaque réplica à envoyer ses preuves au nouveau leader, qui doit en retransmettre la preuve complète : d’après le décompte de l’article, O(n3) authentifiants. Avec quatre réplicas, ce n’est rien. Avec une centaine de validateurs ou plus dans le monde entier, un seul leader défaillant devient coûteux, et une chaîne change de leader à chaque bloc. Tendermint a évité le lourd changement de vue en attendant un délai fixe, ce qui est le problème de réactivité évoqué plus haut.
Certificats de quorum et trois phases
HotStuff envoie chaque vote au leader plutôt qu’à tout le monde. Le leader collecte les votes de n moins f réplicas et les combine, par une signature à seuil, en un seul certificat de quorum (QC) : une preuve compacte qu’un quorum s’est accordé. Le leader diffuse ensuite le QC. Le trafic par décision devient linéaire en n.
Une décision traverse des phases nommées prepare, pre-commit et commit, chacune se terminant par un QC. Un réplica se verrouille quand il voit le QC de pre-commit, et un bloc est décidé dès que son QC de commit existe. Un nouveau leader part du plus haut QC qu’il a reçu de n moins f réplicas et n’a pas à attendre le plus lent, ce que les auteurs appellent la réactivité optimiste : le protocole avance à la vitesse du réseau réel.
Chained HotStuff : un vote, trois rôles
La version pratique de l’article met les phases en pipeline. Chaque nouveau bloc porte le QC de son parent, et ce vote unique compte comme la phase prepare pour le bloc le plus récent, la phase pre-commit pour son parent et la phase commit pour son grand-parent. Quand un bloc reçoit un enfant porteur d’un QC, il forme une chaîne de un ; avec un petit-enfant, une chaîne de deux, et les réplicas se verrouillent alors sur lui ; avec un arrière-petit-enfant dans des vues consécutives, une chaîne de trois, et le plus ancien des trois est validé.
En régime établi, un nouveau bloc est proposé à chaque vue et un bloc plus ancien devient définitif au même rythme. Un seul schéma de messages, répété, fait tout le travail. Cette régularité explique en grande partie pourquoi HotStuff est devenu le modèle des chaînes construites après 2019.
Ce que paie HotStuff : une phase de plus
La troisième phase n’est pas décorative. L’article explique qu’un protocole à deux phases avec un changement de vue linéaire peut caler : un nouveau leader peut ignorer un verrou détenu par un réplica honnête, proposer autre chose et ne réunir aucun quorum, encore et encore. Tendermint règle cela en attendant ; HotStuff le règle en ajoutant une phase pour qu’un leader qui détient le plus haut QC suffise. Les auteurs parlent d’un « petit prix en latence » (traduction).
| Protocole | Leader correct | Leader remplacé | f leaders défaillants à la suite | Réactif |
|---|---|---|---|---|
| PBFT | O(n2) | O(n3) | O(f n3) | Oui |
| SBFT | O(n) | O(n2) | O(f n2) | Oui |
| Tendermint / Casper | O(n2) | O(n2) | O(f n2) | Non |
| Tendermint* / Casper* (avec signatures à seuil) | O(n) | O(n) | O(f n) | Non |
| HotStuff | O(n) | O(n) | O(f n) | Oui |
Authentifiants (signatures ou MAC) envoyés par décision une fois le réseau stabilisé, n validateurs, f défaillants. Source : tableau 1 de l’article HotStuff, arXiv 1803.05069, version du 23 juillet 2019. Les lignes marquées d’un astérisque sont l’estimation des auteurs pour une variante que les travaux d’origine ne décrivaient pas.
Ce tableau est la comparaison des auteurs de HotStuff eux-mêmes, pas un banc d’essai neutre. Leur ligne Tendermint* en note de bas de page compte : avec des signatures à seuil, que les travaux d’origine ne décrivaient pas, le nombre de messages de Tendermint serait lui aussi linéaire. La vraie différence tient à la réactivité, pas au nombre brut de messages.
Après HotStuff : héritiers et rivaux
LibraBFT et DiemBFT
Le premier grand utilisateur a été le projet Libra de Facebook, dont le rapport technique de 2019 dit clairement que son cœur de consensus « est fondé sur HotStuff » (traduction), avec ses propres ajouts comme un mécanisme de synchronisation des tours ; le protocole a ensuite été rebaptisé DiemBFT. Le projet a pris fin quand le Diem Group a cédé ses actifs technologiques à Silvergate, une opération annoncée le 31 janvier 2022 et valorisée à environ 182 millions de dollars en numéraire et en actions. Des ingénieurs qui avaient travaillé sur Diem et sur le portefeuille Novi de Meta ont ensuite fondé Aptos Labs et Mysten Labs, la société derrière Sui, d’après The Block en décembre 2021 et mars 2022.
Jolteon : retour à deux phases
En juin 2021, une équipe comprenant Rati Gelashvili, Lefteris Kokoris-Kogias et Alberto Sonnino a publié Jolteon, une variante de HotStuff en chaîne de deux. Elle valide après deux QC au lieu de trois et le paie par un changement de vue quadratique, le coût que HotStuff avait supprimé. Le pari est que les leaders défaillent rarement, si bien qu’un cas courant plus rapide vaut une reprise plus lourde. L’article rapporte, dans ses tests, une latence de validation inférieure de 200 à 300 millisecondes à celle de HotStuff.
Aptos : AptosBFT, Baby Raptr et blocs en un saut
Aptos ne documente son consensus que sous le nom d’AptosBFT, un protocole qui tolère jusqu’à un tiers de validateurs malveillants. Ses propositions d’amélioration montrent la direction. L’AIP-106, « Baby Raptr », au statut Final, permet au consensus de proposer des lots de transactions avant que leur preuve de stockage ne soit collectée, ce qui retire environ 180 millisecondes, soit deux sauts réseau, du chemin (mesuré sur le mainnet d’Aptos le 30 octobre 2024). L’AIP-131, également Final, permet aux leaders de proposer un bloc sans attendre le QC de son parent, de sorte que le temps de bloc passe de deux sauts réseau à un.
La chaîne est rapide, quel que soit le mélange de ces changements en service aujourd’hui. Entre les hauteurs de registre 1 169 571 873 et 1 169 581 873, lues vers 09:47 UTC le 8 novembre 2026, Aptos a produit 10 000 blocs en 375 secondes, soit un toutes les 37,5 millisecondes en moyenne, avec 83 validateurs actifs. C’est un espacement de blocs, blocs vides compris, pas un temps de finalité ni un débit de transactions.
MonadBFT : une conception rivale à finalité spéculative
Monad se place à côté de la famille plutôt qu’en son sein. Sa documentation ne présente pas MonadBFT comme une version de HotStuff ; elle le mesure aux « protocoles de consensus en pipeline de la famille HotStuff » (traduction) et à leurs points faibles. Les docs donnent à MonadBFT un temps de bloc minimal de 300 millisecondes, une finalité spéculative après un slot (300 ms) et une finalité complète après deux (600 ms). Il revendique une complexité linéaire en messages et en authentifiants dans le cas favorable, ainsi qu’une protection contre le tail-forking, où un leader malveillant écarte le bloc de son prédécesseur pour s’en approprier la valeur. D’après les docs, ces conceptions en pipeline antérieures perdent souvent deux slots à la fois quand un leader rate son tour, ce que MonadBFT est construit pour éviter.
HyperBFT derrière une plateforme d’échange
Hyperliquid, la plateforme de produits dérivés on-chain, décrit son consensus comme « une variante du consensus HotStuff » (traduction) dans sa documentation. Les chiffres qu’elle publie concernent le trading, pas les blocs : une latence de bout en bout médiane de 0,2 seconde et de 0,9 seconde au 99e centile, et environ 200 000 ordres par seconde sur le mainnet. Notre page de la pièce HYPE traite du jeton.
Le consensus en DAG : plusieurs proposants, pas de leader unique par bloc
Les protocoles à leader partagent un goulet d’étranglement : un validateur par tour doit recevoir, assembler et envoyer tout le bloc. Une seconde ligne de recherche, menée par plusieurs des mêmes personnes, répartit ce travail entre tous.
Narwhal : diffuser les données séparément de leur ordre
Narwhal et Tusk, déposés le 25 mai 2021 par George Danezis, Lefteris Kokoris-Kogias, Alberto Sonnino et Alexander Spiegelman, divisent le travail en deux. Dans Narwhal, chaque validateur publie des lots de transactions par tours, chaque lot renvoyant à des lots du tour précédent, ce qui construit un graphe orienté acyclique (DAG) de données certifiées. L’ordonnancement devient une étape distincte et légère. Dans les tests en réseau étendu de l’article, Narwhal associé à HotStuff a dépassé 130 000 transactions par seconde, et Tusk, une couche d’ordonnancement asynchrone, a atteint environ 160 000 pour une latence d’environ 3 secondes.
Bullshark, puis Mysticeti sur Sui
Bullshark, déposé le 14 janvier 2022, ordonne le même DAG avec une règle partiellement synchrone et a rapporté 125 000 transactions par seconde pour environ 2 secondes de latence avec 50 participants. Mysticeti, déposé le 23 octobre 2023, va plus loin : les blocs de son DAG ne sont pas certifiés un par un, ce qui supprime des tours de messages, et les blocs peuvent être validés directement à partir de la structure des références qui les recouvrent.
Sui a adopté Mysticeti sur son mainnet à l’été 2024. Sa documentation décrit Mysticeti comme un protocole de consensus fondé sur un graphe orienté acyclique, et ne mentionne pas HotStuff. Ce n’est pas un descendant de HotStuff : aucun leader unique ne collecte de votes dans une chaîne de QC, même si les deux familles partagent des auteurs et le même quorum des deux tiers. À l’epoch 1305, commencée le 8 novembre 2026, le réseau Sui comptait 125 validateurs actifs.
Les chiffres publiés demandent de la prudence. La documentation de Sui cite des résultats de bancs d’essai d’environ une demi-seconde pour valider et un débit très élevé, et précise qu’il ne s’agit pas de mesures de production. Les articles testent sur des réseaux contrôlés ; une chaîne réelle, aux validateurs inégaux et à la charge réelle, se comporte autrement.
Pourquoi les ensembles de validateurs restent petits
Tous les protocoles de cette leçon exigent les signatures de plus des deux tiers du pouvoir de vote pour chaque décision. C’est ce prix qui fixe la taille de l’ensemble de validateurs.
Compter les signatures
Prenons la conception par gossip. Avec 180 validateurs, chacun envoyant une prévote et un précommit que tous les autres vérifient, un tour représente environ 180 × 180 × 2, soit 64 800 vérifications de signature sur le réseau. Avec 1 000 validateurs, on atteint deux millions. Les signatures agrégées et un leader qui collecte les votes réduisent le trafic, mais chaque vote doit tout de même être produit, envoyé et vérifié dans un temps de bloc qui se mesure en secondes ou moins.
Le plafond est inscrit dans les chaînes. Le 8 novembre 2026, les paramètres de staking indiquaient Cosmos Hub 180, Celestia 100, Injective 45, Sei 40, Osmosis 30 et dYdX 21. Comme la panique de juin 2024 l’a montré, la limite du Hub est aussi une règle stricte de son code.
Un petit ensemble, c’est une courte liste de noms
Plus l’ensemble est petit, moins il faut d’opérateurs pour bloquer ou pour finaliser. D’après notre propre calcul à partir des données de la chaîne au 8 novembre 2026, sans fusionner les validateurs gérés par une même entité, les 4 plus gros validateurs du Cosmos Hub détenaient plus d’un tiers de l’enjeu lié, comme l’a aussi constaté la leçon sur la preuve d’enjeu déléguée. Sur Aptos, les 14 plus gros des 83 validateurs dépassaient un tiers du pouvoir de vote ; sur Sui, les 18 plus gros des 125. Ce sont les coalitions qui pourraient bloquer chaque chaîne en restant silencieuses.
La version d’Ethereum du problème
Ethereum illustre le choix inverse. Il compte environ un million d’entrées de validateurs et finalise par points de contrôle tous les deux epochs plutôt qu’à chaque bloc. Dans sa note sur les voies vers une finalité en un seul slot, écrite quand il y avait 445 064 validateurs actifs, Vitalik Buterin écrit « On ne peut pas vraiment prendre Tendermint ou un autre algorithme BFT existant tel quel » (traduction). Tendermint s’arrête quand plus d’un tiers des validateurs sont hors ligne, alors qu’Ethereum est conçu pour continuer à produire des blocs ; il lui faut donc une règle de choix de fourche et une fuite d’inactivité en plus de tout vote. Il ajoute que traiter des centaines de milliers de signatures par slot est possible, ce qui explique que les propositions associent une finalité plus rapide à des validateurs moins nombreux et plus gros. Notre leçon sur la preuve d’enjeu en profondeur explique comment les validateurs d’Ethereum votent aujourd’hui.
La recherche continue d’avancer. Minimmit, déposé le 14 août 2025 par Chou, Lewis-Pye et O’Grady, appartient à un groupe de protocoles qui finalisent après un seul tour de votes, deux tours en comptant la proposition, en acceptant une hypothèse plus stricte : n au moins égal à 5f + 1, de sorte que moins d’un cinquième des validateurs peuvent être défaillants au lieu d’un tiers. Dans une simulation de 50 processeurs répartis sur dix régions virtuelles, les auteurs ont mesuré une latence de vue inférieure de 23,1 % et une latence de transaction inférieure de 10,7 % à celles des protocoles comparés.
Les chaînes BFT côte à côte, au 8 novembre 2026
| Chaîne | Consensus | Famille | Validateurs actifs (plafond) | Temps de bloc ou finalité |
|---|---|---|---|---|
| Cosmos Hub | CometBFT v0.38 | Tendermint | 180 (plafond 180) | 5,71 s par bloc, définitif en un bloc (mesuré) |
| Celestia | Basé sur CometBFT | Tendermint | 100 (plafond 100) | 2,85 s par bloc (mesuré) |
| Injective | Basé sur CometBFT | Tendermint | 45 (plafond 45) | 0,60 s par bloc (mesuré) |
| dYdX Chain | Basé sur CometBFT | Tendermint | 21 (plafond 21) | 0,64 s par bloc (mesuré) |
| Osmosis | CometBFT | Tendermint | 30 (plafond 30) | 0,84 s par bloc (mesuré) |
| Sei | Fork Tendermint propre à Sei (les nœuds annoncent v0.35) | Tendermint | 40 (plafond 40) | 0,47 s par bloc (mesuré) |
| Aptos | AptosBFT | Lignée HotStuff (héritage Diem ; Baby Raptr et propositions optimistes d’après ses AIP) | 83 | 37,5 ms d’espacement des blocs (mesuré, blocs vides compris) |
| Monad | MonadBFT | Pipeline, comparé par ses docs aux protocoles de la famille HotStuff | Non publié dans les sources utilisées | 300 ms spéculative, 600 ms finalité complète (docs) |
| Hyperliquid | HyperBFT | « Une variante de HotStuff » (docs) | Non relevé | 0,2 s de latence médiane d’ordre (docs, pas la finalité) |
| Sui | Mysticeti | DAG (lignée Narwhal et Bullshark) | 125 (epoch 1305) | Non mesuré ; les docs donnent seulement des chiffres de bancs d’essai |
Chiffres mesurés : moyenne sur les 1 000 derniers blocs (10 000 sur Aptos), lue entre 09:45 et 09:55 UTC environ le 8 novembre 2026 sur l’API publique de chaque chaîne ; plafonds issus des paramètres de staking ; version du moteur du Cosmos Hub tirée des informations du nœud. « Basé sur CometBFT » couvre les chaînes qui exploitent CometBFT ou leur propre fork. Monad et Hyperliquid : leur documentation, lue le 8 novembre 2026.
Ce tableau se lit avec ses limites. L’espacement des blocs sur une chaîne CometBFT égale son temps de finalité, puisqu’un bloc validé est définitif. Sur Aptos, l’espacement inclut les blocs vides et ne dit rien du temps d’attente d’une transaction. Les chiffres de Monad et d’Hyperliquid viennent de leur propre documentation, pas de nos mesures.
Cinq questions à poser à n’importe quelle chaîne BFT
Quand une nouvelle chaîne vante une finalité rapide, cinq questions la situent sur la carte tracée par cette leçon. Quelle part du pouvoir de vote peut l’arrêter, et est-ce déjà arrivé ? Un bloc est-il définitif d’un coup, ou après deux slots ou plus ? Combien de validateurs compte l’ensemble, y a-t-il un plafond, et combien d’entre eux détiennent un tiers de l’enjeu ? Est-ce un leader par tour qui collecte les votes, ou un DAG avec de nombreux proposants ? Et à quoi ressemblait le dernier arrêt : un bogue, un décalage, ou une décision ?
Aucune de ces réponses ne classe une chaîne comme bonne ou mauvaise. Elles montrent où une conception a dépensé son budget : Tendermint attend pour que ses règles restent simples, tandis que Jolteon a accepté une reprise plus lourde pour gagner quelques centaines de millisecondes dans le cas courant. Plus de contexte sur les familles de consensus figure dans notre aperçu de ce qu’est le consensus, et les chaînes Cosmos du tableau ont leurs propres pages, comme Osmosis et Celestia.
La prochaine leçon de ce parcours se tourne vers Solana : la preuve d’historique, l’horloge que tiennent ses leaders de blocs, et Alpenglow, le système de vote que le réseau a activé en octobre 2026.
