Un général en chef envoie un ordre, attaquer à l’aube, à trois lieutenants installés autour d’une ville. L’ordre voyage par messager. Parmi les quatre hommes se cache un traître, et personne ne sait lequel. Si le traître est le chef lui-même, 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 peut dire à deux lieutenants d’attaquer et au troisième de battre en retraite. Les officiers loyaux peuvent-ils malgré tout finir par faire la même chose ? Cette énigme est le problème des généraux byzantins. En 1982, Leslie Lamport, Robert Shostak et Marshall Pease ont montré que la réponse est oui avec quatre généraux et un traître, et non avec trois.
Vingt-six ans plus tard, le 13 novembre 2008, un développeur inconnu qui signait Satoshi Nakamoto a expliqué à une liste de diffusion de cryptographie que sa nouvelle conception répondait à la même énigme, mais entre inconnus sur internet, où chacun peut entrer et où personne ne tient la liste de qui est qui. Entre les deux dates, on croise des ordinateurs d’avion, un article rebaptisé et un serveur de fichiers du MIT. Le chemin s’achève sur deux nombres qui décident encore de la façon dont les blockchains tombent en panne : un tiers et une moitié.
Les citations de ce cours viennent de sources en anglais : elles sont traduites par nos soins, et chaque lien mène au texte original.
Le problème des généraux byzantins en mots simples
Des ordinateurs qui travaillent ensemble tombent en panne de deux grandes manières. Certains s’arrêtent tout simplement : un serveur plante, un câble est coupé. D’autres continuent de tourner et donnent de mauvaises réponses, et les pires envoient des réponses fausses différentes à des destinataires différents. L’histoire des généraux sert à obliger les ingénieurs à prendre au sérieux cette seconde catégorie. Un traître est n’importe quel élément qui se comporte de façon arbitraire : un capteur défaillant, un processeur corrompu ou, sur une blockchain publique, un participant qui ment exprès.
Le cours précédent, ce qu’un mécanisme de consensus décide, et pourquoi sûreté et vivacité tirent dans des sens opposés, posait la question générale. L’article de 1982 la rend exacte. Il ramène toute l’armée à un commandant et à ses lieutenants, et demande deux choses. Premièrement, tous les lieutenants loyaux obéissent au même ordre. Deuxièmement, si le commandant est loyal, chaque lieutenant loyal obéit à l’ordre que le commandant a réellement envoyé. L’article appelle ces exigences les conditions de cohérence interactive, IC1 et IC2.
Les deux comptent. Sans la première, le camp loyal se scinde. Sans la seconde, l’armée pourrait s’accorder sur n’importe quoi, par exemple toujours reculer, ce qui ne sert à rien quand le commandant loyal dit d’attaquer.
L’argent donne à cette énigme une forme familière. Une double dépense, c’est un traître qui raconte deux histoires différentes à deux interlocuteurs au sujet de la même pièce, comme l’a montré, attaques réelles à l’appui, le cours sur le problème de la double dépense. Un registre partagé par de nombreux ordinateurs n’est utile que si chaque copie honnête raconte la même histoire, même quand certaines copies sont tenues par des menteurs.
Pourquoi trois généraux ne suffisent pas quand l’un d’eux ment
L’article fixe d’abord les règles pour ce qu’il appelle les messages oraux, c’est-à-dire des messages qu’un traître peut inventer librement en les relayant. Trois hypothèses tiennent : tout message envoyé est remis correctement, le destinataire sait qui l’a envoyé, et l’absence d’un message se détecte. Les messagers sont donc fiables. Tout le problème réside dans les généraux.
Le piège à trois généraux
Prenons un commandant et deux lieutenants, dont l’un peut être un traître. Le lieutenant 1 reçoit « attaquer » du commandant. Le lieutenant 2 lui dit alors : le commandant m’a dit de battre en retraite. Deux scénarios collent exactement à ces faits. Dans le premier, le commandant est loyal et le lieutenant 2 ment ; IC2 oblige alors le lieutenant 1 à attaquer. Dans le second, le commandant est le traître : il a envoyé « attaquer » à l’un et « retraite » à l’autre, tandis que le lieutenant 2 rapporte honnêtement ce qu’il a reçu.
Le lieutenant 1 voit les mêmes messages dans les deux mondes, donc toute règle qui le fait attaquer dans le premier le fait attaquer dans le second. Par symétrie, le lieutenant 2 doit dans le second monde suivre l’ordre qu’il a reçu, la retraite. Les deux lieutenants loyaux sont alors en désaccord, et IC1 est violée. Les auteurs préviennent eux-mêmes leurs lecteurs : il faut, écrivent-ils, se méfier beaucoup d’un raisonnement aussi peu rigoureux. Leur preuve complète est plus soignée que cette esquisse et aboutit à la même conclusion.
Quatre généraux, un traître : le vote qui sauve la situation
Ajoutons un lieutenant loyal et le piège s’ouvre. L’algorithme que l’article nomme OM(1) comporte deux tours. Au premier, le commandant envoie son ordre à chaque lieutenant. Au second, chaque lieutenant relaie l’ordre reçu aux deux autres. Chacun prend ensuite la valeur majoritaire parmi les trois qu’il détient. Si un commandant traître n’envoie rien du tout, l’article fixe un ordre par défaut, la retraite, pour que le silence ne puisse pas paralyser l’armée.
Le tableau ci-dessous est notre propre illustration du pire cas, celui où le traître est le commandant et cherche à diviser le camp.
| Lieutenant (tous loyaux) | Ordre reçu du commandant | Ordres relayés par les deux autres | Majorité, donc décision |
|---|---|---|---|
| Lieutenant 1 | attaquer | attaquer (de L2), retraite (de L3) | attaquer |
| Lieutenant 2 | attaquer | attaquer (de L1), retraite (de L3) | attaquer |
| Lieutenant 3 | retraite | attaquer (de L1), attaquer (de L2) | attaquer |
Chaque lieutenant loyal se retrouve avec les trois mêmes valeurs, dans un ordre différent, si bien que la majorité donne à chacun la même réponse : IC1 est respectée. Inversons maintenant le cas : le commandant est loyal et dit « attaquer », et le lieutenant 3 est le traître qui relaie « retraite ». Les lieutenants 1 et 2 détiennent chacun attaquer, attaquer et retraite : ils attaquent tous deux, ce que leur commandant loyal avait ordonné. IC2 est respectée aussi. Le mensonge du traître est noyé, car il n’a qu’une voix sur trois.
La règle générale : plus des deux tiers des généraux doivent être loyaux
L’article de 1982 généralise le résultat dans les deux sens. Son résumé affirme qu’avec des messages oraux seulement, le problème est soluble « si et seulement si plus des deux tiers des généraux sont loyaux ». En chiffres : pour faire face à m traîtres, il faut au moins 3m + 1 généraux. Un traître exige quatre généraux, deux traîtres en exigent sept, dix traîtres en exigent trente et un. L’algorithme OM(m) fonctionne pour toute armée de cette taille en répétant le tour de relais m + 1 fois, chaque général transmettant ce que chacun des autres affirme avoir entendu.
Cette répétition coûte cher. Le nombre de messages croît très vite avec m, et la conclusion de l’article reconnaît qu’une solution « semble intrinsèquement coûteuse ». Un travail de Fischer et Lynch, que les auteurs citent, montre que m + 1 tours sont incompressibles. La seule façon de réduire le coût, écrivent-ils, est de faire une hypothèse sur les pannes possibles, et les quarante années suivantes ont largement consisté à chercher des hypothèses à la fois bon marché et réalistes.
Les messages signés changent les calculs
Le second algorithme de l’article, SM(m), ajoute une hypothèse. La signature d’un général loyal ne peut pas être falsifiée, toute modification d’un message signé se détecte, et chacun peut vérifier de qui est la signature. Les traîtres peuvent toujours s’entendre et signer l’un pour l’autre. Avec ce seul changement, dit le résumé, « le problème est soluble pour un nombre quelconque de généraux et de traîtres possibles ».
La raison est qu’un traître ne peut plus mettre des mots dans la bouche d’un général loyal. Dans le piège à trois généraux, le lieutenant 2 pouvait prétendre que le commandant avait dit « retraite ». Avec des signatures, il devrait produire l’ordre signé du commandant, et si le commandant a vraiment signé deux ordres différents, les deux lieutenants détiennent la preuve de sa trahison et se rabattent sur le même ordre par défaut. L’accord ne dépend plus de la possibilité de submerger les menteurs en nombre, seulement de relayer des ordres signés pendant assez de tours.
Deux réserves empêchent d’y voir de la magie. D’abord, l’accord de SM(m) porte sur l’exécution de l’ordre d’un seul commandant. Quand il s’agit de s’accorder sur des valeurs correctes venues de nombreuses machines, comme des mesures de capteurs, une majorité des entrées doit encore être correcte : la note de Lamport sur l’article de 1980 chiffre le besoin à 2n+1 processeurs pour tolérer n pannes quand on utilise des signatures, contre 3n+1 sans elles. Ensuite, les signatures de l’article n’étaient pas de la vraie cryptographie. Lamport les qualifie de « métaphore » : elles devaient seulement résister à des pannes aléatoires, pas à un adversaire intelligent, et étaient donc bien plus faciles à réaliser que de véritables signatures numériques. Les blockchains utilisent la vraie chose, celle qu’explique notre cours sur les clés privées et publiques, ce qui rend le cas signé si important en pratique.
D’où vient le problème : ordinateurs d’avion et article rebaptisé
Les généraux sont nés dans l’aéronautique. Dans les années 1970, la NASA a financé à SRI International des recherches sur la façon de rendre des ordinateurs assez fiables pour piloter des avions de ligne. Le projet s’appelait SIFT, et son article de présentation, signé John Wensley et ses collègues, est paru dans les Proceedings of the IEEE en octobre 1978. Lamport, qui travaillait à SRI, dit que le projet fut peut-être surtout remarquable pour avoir produit le problème des généraux byzantins et ses solutions. L’article de 1982 cite la NASA parmi ses financeurs, avec le Ballistic Missile Defense Systems Command et l’Army Research Office.
L’inquiétude des ingénieurs était précise. Un ordinateur de bord est sécurisé en faisant tourner plusieurs copies et en prenant un vote majoritaire. Cela ne marche que si chaque copie lit la même entrée. Un capteur défectueux, ou un site radar dans un réseau de défense antimissile, peut envoyer une valeur à un processeur et une autre au suivant. Même une horloge honnête peut provoquer cela : deux processeurs qui lisent l’heure au moment où elle change peuvent obtenir l’ancienne valeur pour l’un et la nouvelle pour l’autre. Le vote majoritaire entre processeurs n’a alors plus rien de cohérent à départager.
Les résultats sont plus anciens que le nom. Un article de 1980 de Pease, Shostak et Lamport, « Reaching Agreement in the Presence of Faults », dans le Journal of the ACM, prouvait déjà qu’il faut 3n+1 processeurs pour n pannes et donnait le cas des signatures. Lamport attribue à Shostak la solution à quatre processeurs et la preuve d’impossibilité, à Pease la solution générale à 3n+1 ; l’algorithme à messages signés était le sien. Il écrit aussi : « On m’attribue souvent à tort l’invention du problème de l’accord byzantin. » Le problème, dit-il, avait été formulé par les gens qui travaillaient sur SIFT avant son arrivée à SRI. L’article de 1980 a reçu le prix Dijkstra de l’informatique distribuée en 2005.
Ce qu’a ajouté l’article de 1982, c’est le récit. Lamport trouvait que les philosophes de Dijkstra, un conte sur des philosophes attablés, avaient attiré plus d’attention que des problèmes plus concrets, et il voulait la même force d’attraction pour celui-ci. Il cherchait une nationalité qui ne froisserait aucun lecteur. L’Albanie était alors une société complètement fermée, et son premier titre fut donc The Albanian Generals Problem. Son collègue de SRI Jack Goldberg lui fit remarquer qu’il y avait des Albanais hors d’Albanie, et, selon les mots de Lamport, « les Byzantins, manifestement plus appropriés, me sont alors venus à l’esprit ».
Lamport dit lui-même que la raison principale du nouvel article était de donner son nouveau nom au problème. La référence est « The Byzantine Generals Problem », ACM Transactions on Programming Languages and Systems, volume 4, numéro 3, juillet 1982, pages 382 à 401, et une copie libre est sur le site de Lamport : vingt pages, lisibles par quiconque est à l’aise avec un peu de récurrence.
Le problème des deux généraux : quand les messagers se perdent
Les généraux eux-mêmes ont été empruntés. Lamport dit les avoir pris à une énigme plus ancienne sur deux armées qui doivent s’accorder sur une attaque, énigme qu’il note être parfois appelée le problème des généraux chinois. Ce casse-tête est différent, et les deux sont souvent confondus.
Sa première forme publiée est un article de 1975 de E. A. Akkoyunlu, K. Ekanadham et R. V. Huber, « Some Constraints and Tradeoffs in the Design of Network Communications », présenté au cinquième symposium de l’ACM sur les principes des systèmes d’exploitation (SOSP 1975, pages 67 à 74). Leur annexe n’emploie pas de généraux du tout. Elle raconte l’histoire de deux bandes de gangsters qui préparent un coup et ne peuvent se coordonner que par des messages susceptibles de se perdre en route.
Le raisonnement est le suivant. Le groupe A envoie une heure. Il ne peut agir avant de savoir que le message est arrivé, donc B doit répondre. Mais B ne peut agir avant de savoir que sa réponse est arrivée, donc A doit confirmer, et ainsi de suite. Prenons un échange fini censé fonctionner et regardons son dernier message : l’expéditeur ne peut pas savoir s’il est arrivé, le plan ne peut donc pas en dépendre, et un échange plus court devrait fonctionner aussi. Répétons le raisonnement et il ne reste rien. Les auteurs notent que la chaîne de confirmations est infinie même quand aucun message n’est réellement perdu.
Le contraste est simple à retenir. Dans le problème des deux généraux, tout le monde est honnête et les messagers sont peu fiables. Dans le problème des généraux byzantins, les messagers sont fiables et certains généraux mentent. Les vrais réseaux cumulent les deux ennuis, et les ingénieurs se contentent donc de nouvelles tentatives, de délais d’attente et d’un petit doute résiduel.
FLP : pourquoi aucun algorithme ne peut être certain sur un réseau sans horloge
Les solutions de 1982 reposent sur une hypothèse discrète : un message manquant peut être détecté. En pratique, cela suppose un délai maximal de remise connu et des horloges qui s’accordent à une erreur fixe près, comme l’explique la section de l’article consacrée à la mise en œuvre. Retirez ces garanties et tout devient bien plus difficile.
En 1985, Michael Fischer, Nancy Lynch et Michael Paterson ont publié « Impossibility of Distributed Consensus with One Faulty Process » dans le Journal of the ACM. Leur résultat porte sur un système entièrement asynchrone, où les messages arrivent toujours mais peuvent prendre un temps quelconque : « aucun protocole de consensus complètement asynchrone ne peut tolérer ne serait-ce qu’une seule mort de processus non annoncée ». Le résultat FLP, du nom de ses auteurs, n’a même pas besoin de traîtres. Il suppose des processus honnêtes et un réseau qui ne perd jamais un message. Un seul processus qui s’arrête en silence suffit, car les autres ne peuvent jamais savoir s’il est mort ou simplement lent.
FLP ne dit pas que le consensus est impossible en pratique. Il dit qu’aucun protocole déterministe ne peut garantir à la fois qu’il reste toujours correct et qu’il se termine toujours, sans une hypothèse sur le temps. Tout protocole réel choisit donc une porte de sortie : une hypothèse de temps, du hasard, ou les deux.
La sortie qui l’a emporté date de 1988. Cynthia Dwork, Nancy Lynch et Larry Stockmeyer, dans « Consensus in the Presence of Partial Synchrony » (Journal of the ACM, volume 35), ont supposé que le réseau se comporte mal pendant un temps mais finit par remettre les messages dans une limite que personne ne connaît à l’avance. Leurs protocoles ne rompent jamais la sûreté, même pendant la mauvaise période, et progressent dès que le réseau se calme. Quand l’article a reçu le prix Dijkstra 2007, la citation du prix a décrit cette approche de synchronie finale comme la principale voie pour contourner le résultat FLP. PBFT, Tendermint et HotStuff vivent tous dans ce monde partiellement synchrone.
PBFT, 1999 : la tolérance aux fautes byzantines devient praticable
Pendant dix-sept ans après que les généraux ont reçu leur nom, la tolérance aux fautes byzantines est restée surtout dans les articles et dans quelques systèmes critiques, parce que les algorithmes connus étaient trop lents pour des services ordinaires. Miguel Castro et Barbara Liskov, du MIT, ont changé cela avec « Practical Byzantine Fault Tolerance », présenté à la conférence OSDI à La Nouvelle-Orléans en février 1999.
PBFT fait tourner un service sur un groupe fixe de réplicas, dont l’un joue le rôle de primaire et ordonne les requêtes des clients. Chaque requête passe par trois phases, pre-prepare, prepare et commit, pendant lesquelles les réplicas échangent des messages signés ou authentifiés jusqu’à ce qu’assez d’entre eux se portent garants du même ordre. Si le primaire semble défaillant ou se bloque, les autres lancent un changement de vue et le réplica suivant prend le relais. Avec 3f + 1 réplicas, le système tolère f réplicas défaillants, et l’article note que c’est le minimum. L’arithmétique est la suivante : deux groupes de 2f + 1 réplicas pris parmi 3f + 1 se recoupent sur au moins f + 1 machines, donc au moins une machine honnête figure dans les deux et empêche deux décisions contradictoires.
PBFT garde la sûreté même sur un réseau asynchrone comme internet et ne s’appuie sur une hypothèse de temps faible que pour la vivacité, ce qui, écrivent les auteurs, lui permet de contourner le résultat FLP. Le chiffre phare a fait écouter les ingénieurs : leur service de fichiers répliqué n’était « que 3 % plus lent qu’un NFS standard non répliqué ».
Une hypothèse demeurait, et elle compte quand il s’agit d’argent. PBFT exige une liste de membres connue et fixe. Le vote de chaque réplica compte parce que chaque réplica a une identité approuvée par quelqu’un. Sur un réseau ouvert à tous, un seul attaquant peut créer des milliers d’identités et l’emporter sur tout le monde, ce que les chercheurs appellent une attaque Sybil. Le livre blanc de Bitcoin formule la même objection en une ligne : si la majorité était décidée par « une adresse IP, une voix », elle « pourrait être renversée par quiconque est capable d’allouer de nombreuses IP ».
Comment Bitcoin résout le problème des généraux byzantins avec une chaîne de travail
Le livre blanc de Bitcoin n’emploie jamais le mot byzantin. Le lien s’est fait dans la discussion qui a suivi. Sur la liste de diffusion Cryptography, James A. Donald avait soutenu que faire en sorte que chacun sache que chacun connaît un fait était, comme dans le problème des généraux byzantins, le problème classique et difficile du traitement distribué des données. La réponse de Satoshi Nakamoto, datée du 13 novembre 2008 par les archives du Nakamoto Institute, s’ouvre sur une seule ligne : « La chaîne de preuve de travail est une solution au problème des généraux byzantins. »
Il a ensuite raconté l’histoire à sa façon. Un groupe de généraux veut s’introduire dans le wi-fi du roi en devinant ensemble le mot de passe, et l’attaque ne marche que si une majorité frappe au même moment. N’importe qui peut annoncer une heure, et la première que chaque général entend compte. Au lieu de voter, chacun lance une preuve de travail qui inclut cette heure. Si deux heures sont proposées en même temps, certains généraux travaillent sur l’une, d’autres sur l’autre, et dès qu’une branche s’allonge les autres basculent dessus, puisque la chaîne la plus longue contient plus de travail. Chaque bloc coûtant environ dix minutes de l’effort de tout le groupe, il écrivait qu’au bout de deux heures une heure d’attaque devrait être soutenue par une chaîne de 12 preuves de travail, et que chaque général peut vérifier qu’une majorité a forcément dû la produire.
L’astuce tient à ce qui remplace le vote. Le livre blanc le dit sans détour : « La preuve de travail, c’est en substance un processeur, une voix. » Une voix coûte du calcul et de l’électricité, pas une identité, et les faux membres n’y gagnent rien. La condition, énoncée dans le résumé : le système est sûr tant que les nœuds honnêtes contrôlent ensemble plus de puissance de calcul que n’importe quel groupe d’attaquants coopérants. Notre lecture du livre blanc de Bitcoin, section par section, couvre le reste de la conception, et le fonctionnement d’une blockchain rappelle comment les nœuds choisissent une chaîne quand deux blocs apparaissent.
L’échelle est l’autre changement. PBFT a été conçu pour un petit groupe de réplicas connus. Au 7 novembre 2026, vers 9 h 56 UTC, la chaîne de Bitcoin en était au bloc 974 916, et des mineurs qui ne s’inscrivent nulle part fournissaient un taux de hachage moyen sur trois jours d’environ 1 014 exahashs par seconde, d’après les données de mempool.space.
Un accord qui se renforce à chaque bloc
Le consensus de Nakamoto ne donne jamais le oui net de PBFT. Un bloc n’est acquis qu’avec une probabilité qui monte à mesure que le travail s’empile par-dessus. La section 11 du livre blanc montre qu’un attaquant qui détient moins de la moitié de la puissance de hachage prend du retard à un rythme exponentiel : sa chance de réécrire un bloc fond vite à chaque confirmation. Quand deux mineurs trouvent un bloc en même temps, le réseau détient brièvement deux branches puis se range à l’une ; les cours sur la finalité et les réorganisations et sur les soft forks et hard forks examinent ce qui se passe quand ce ralliement tourne mal ou quand les règles elles-mêmes changent.
Deux réserves accompagnent le chiffre de la majorité honnête. Ittay Eyal et Emin Gün Sirer ont montré en 2013 que le minage égoïste, où un pool retient des blocs pour gâcher le travail des autres, devient rentable pour des groupes qui s’entendent bien en dessous de la moitié ; la parade qu’ils proposaient ne protège que contre les pools sous un quart de la puissance de hachage. Ce débat relève d’un cours ultérieur sur les attaques de réseau. L’autre réserve est la concentration. Sur la semaine jusqu’au 7 novembre 2026, mempool.space attribuait 23,1 % des blocs à Foundry USA, 19,8 % à AntPool et 17,3 % à F2Pool : trois pools ont donc trouvé 60,1 % des blocs. Un pool coordonne de nombreux mineurs indépendants qui peuvent le quitter, ce n’est donc pas une propriété de la puissance de hachage, mais en pratique la majorité honnête dépend des choix d’une poignée de coordinateurs. Ce qu’un attaquant majoritaire pourrait ou non faire est exposé dans pourquoi une blockchain est difficile à réécrire.
Bitcoin est-il tolérant aux fautes byzantines ? Une étiquette contestée
De nombreux articles qualifient le consensus de Nakamoto de tolérance probabiliste aux fautes byzantines. L’étiquette est contestée. Satoshi a présenté la chaîne comme une solution au problème. Juan Garay, Aggelos Kiayias et Nikos Leonardos, dans leur analyse « The Bitcoin Backbone Protocol » (Eurocrypt 2015), ont prouvé que la chaîne offre deux garanties durables, qu’ils nomment préfixe commun et qualité de la chaîne, lorsque l’attaquant détient moins de la moitié de la puissance de hachage et que le réseau est rapide. Sur l’accord byzantin au sens strict, en revanche, ils écrivent que la suggestion de Nakamoto n’arrive pas à le résoudre. Ils décrivent une variante simple qui atteint l’accord si l’attaquant détient au plus un tiers de la puissance de hachage, et une variante plus élaborée qui fonctionne sous la moitié moyennant de fortes hypothèses sur le délai du réseau.
Leur résumé ajoute que la part de l’attaquant que le système peut supporter diminue à mesure que le réseau devient moins synchrone. Rafael Pass, Lior Seeman et abhi shelat, dans une analyse de 2016, ont dessiné un tableau semblable : la chaîne reste cohérente et vivante quand les délais de message ont une borne connue, et une attaque simple fonctionne dans un réseau entièrement asynchrone, si bien que la difficulté du puzzle doit être réglée en fonction du délai maximal. Un résumé honnête : Bitcoin atteint un accord qui devient pratiquement certain avec le temps, entre participants anonymes, sous des hypothèses sur la puissance de hachage et le délai du réseau. Que cela mérite le nom d’accord byzantin dépend de la définition dont on part, et la littérature ne tranche pas.
Les blockchains BFT d’aujourd’hui : voter, finaliser ou s’arrêter
De nombreuses chaînes à preuve d’enjeu sont revenues à la voie du vote, avec cette fois la mise en jeu à la place de l’identité : la voix d’un validateur pèse autant que les jetons qu’il a bloqués, ce qui rend de nouveau les fausses identités inutiles. Les bases de ce modèle figurent dans notre entrée de glossaire sur la preuve d’enjeu ; un cours complet sur la preuve d’enjeu viendra plus loin dans ce parcours.
Tendermint, décrit par Ethan Buchman, Jae Kwon et Zarko Milosevic dans un article de 2018, ajoute à l’idée de PBFT une messagerie par propagation de proche en proche. Son moteur actuel est CometBFT, un fork de Tendermint Core utilisé par de nombreuses chaînes construites avec les outils de Cosmos. La spécification de CometBFT suppose que moins d’un tiers du pouvoir de vote est byzantin, exige plus des deux tiers des votes de précommit pour valider un bloc, et dit sans détour que « toute coalition de plus d’un tiers des validateurs peut arrêter la blockchain en ne diffusant pas ses votes ». Si un fork se produisait malgré tout, la spécification montre que plus d’un tiers des validateurs auraient signé deux blocs contradictoires, ce qui est démontrable et sanctionnable.
C’est l’arbitrage central du BFT classique : quand trop de votants manquent ou mentent, la chaîne s’arrête au lieu de se scinder. Terra en a donné un exemple public, quoique singulier, le 12 mai 2022. Pendant l’effondrement de LUNA et d’UST, ses validateurs ont arrêté la chaîne au bloc 7 603 700 pour empêcher des attaques de gouvernance, l’effondrement des prix ayant fortement réduit leur coût, a rapporté Cointelegraph ce jour-là. Le réseau devait redémarrer quand deux tiers du pouvoir de vote seraient de nouveau en ligne, les nouvelles délégations étant désactivées. C’était une décision délibérée des validateurs, non un arrêt automatique, mais elle reposait sur la même règle des deux tiers.
HotStuff, de Maofan Yin, Dahlia Malkhi, Michael Reiter, Guy Golan Gueta et Ittai Abraham (2018, publié à PODC 2019), est un protocole à leader, partiellement synchrone, dont la communication ne croît que linéairement avec le nombre de réplicas, y compris lors d’un changement de leader, là où le changement de vue de PBFT était bien plus lourd. Plusieurs chaînes récentes ont bâti leur consensus sur des idées de cette famille ; Tendermint et HotStuff auront leur propre cours plus loin dans ce parcours.
Ethereum mêle les deux mondes. Sa règle de choix de fork, LMD-GHOST, fait avancer la chaîne bloc après bloc, un peu comme une règle de la chaîne la plus lourde. Par-dessus, le vote de finalité Casper-FFG marque des points de contrôle comme définitifs quand des validateurs détenant au moins deux tiers de l’ETH total mis en jeu s’accordent, et, selon la documentation de preuve d’enjeu d’ethereum.org, annuler un bloc finalisé coûterait à un attaquant au moins un tiers de tout l’ETH mis en jeu. Au 7 novembre 2026, vers 9 h 56 UTC, un nœud balise public affichait l’époque finalisée deux époques derrière la tête (487 553 contre une tête à l’époque 487 555), ce qui est le rythme normal quand le vote fonctionne.
Un tiers ou une moitié : les nombres à retenir
Chaque ligne du tableau ci-dessous a ses propres hypothèses : lisez la deuxième colonne avant de comparer les nombres.
| Système | Modèle de fautes et de réseau | Tolère | Ce qu’il exige |
|---|---|---|---|
| Généraux byzantins, messages oraux (1982) | menteurs arbitraires, réseau synchrone | m traîtres | au moins 3m + 1 généraux (4 pour 1 traître) |
| Généraux byzantins, messages signés (1982) | les menteurs ne peuvent pas falsifier les signatures loyales | un nombre quelconque de traîtres, pour l’ordre d’un commandant | des signatures et de la synchronie |
| FLP (1985) | une panne silencieuse, pas d’horloges | aucune, si l’on exige la certitude | une hypothèse de temps ou du hasard |
| PBFT (1999) | réplicas byzantins, sûr même en asynchronie | f défaillants sur 3f + 1 | un groupe de réplicas fixe et connu |
| Tendermint / CometBFT | validateurs byzantins pondérés par la mise | moins d’1/3 du pouvoir de vote | plus de 2/3 des précommits ; 1/3 ou plus peut bloquer |
| Finalité d’Ethereum (Casper-FFG) | stakers byzantins | moins d’1/3 de la mise pour la sûreté de la finalité | au moins 2/3 de l’ETH mis en jeu pour finaliser |
| Bitcoin (consensus de Nakamoto) | attaquant en puissance de hachage, délais bornés | moins de 1/2 de la puissance de hachage, avec accord probabiliste | le plus de travail cumulé ; le minage égoïste abaisse le seuil |
Lisez ce tableau comme un choix entre deux styles de panne. Une chaîne BFT à vote des deux tiers est définitive à la seconde où le vote se clôt, mais un tiers des votants peut l’arrêter. Une chaîne de Nakamoto continue à produire des blocs quoi qu’il arrive, mais tout bloc récent reste en principe réversible, et l’accord est affaire de profondeur.
Pour un utilisateur, la différence est concrète. Sur une chaîne à finalité BFT, un paiement définitif ne sera pas annulé sans une sanction lourde et démontrable des validateurs. Sur Bitcoin, c’est le destinataire qui choisit combien de blocs attendre, et les plateformes d’échange fixent leur propre nombre de confirmations pour les dépôts.
Chaînes permissionnées et chaînes publiques : le point de vue du NIST
Pour comprendre ces choix, la description officielle la plus claire vient de l’Institut national américain des normes et de la technologie (NIST), avec son rapport NIST IR 8202, « Blockchain Technology Overview » (octobre 2018, en anglais). Il décrit le vote en plusieurs tours entre stakers, parfois appelé preuve d’enjeu à tolérance aux fautes byzantines, et la production de blocs à tour de rôle utilisée par certains réseaux blockchain permissionnés, où les membres sont connus et approuvés.
Cette séparation explique bien des projets d’entreprise. Un consortium de banques ou de fournisseurs connaît déjà ses membres : le problème Sybil ne se pose pas, et un vote de type PBFT donne un accord rapide et définitif. Un réseau public comme Bitcoin n’a pas de portier, et paie donc sa sécurité en travail. Le rapport du NIST est une synthèse technique, pas une règle.
Problème des généraux byzantins : l’essentiel
- Les parties honnêtes d’un système peuvent-elles s’accorder quand certaines parties mentent, et mentent différemment selon l’interlocuteur ? C’est la question des généraux byzantins.
- Avec des messages non signés, plus des deux tiers des participants doivent être honnêtes : 3m + 1 participants pour m menteurs. Des signatures infalsifiables lèvent cette limite pour l’exécution de l’ordre d’un seul chef.
- Celui des deux généraux (1975) porte sur des messages perdus entre parties honnêtes, pas sur des menteurs.
- FLP (1985) exclut un consensus garanti sans hypothèse de temps ; la synchronie partielle (1988) est devenue la voie standard pour le contourner, et PBFT (1999) a rendu le BFT rapide pour un groupe de membres connus.
- Bitcoin a remplacé la liste de membres par la preuve de travail et accepte un accord qui se raffermit bloc après bloc, sous la moitié de la puissance de hachage dans son modèle de base ; les chaînes BFT classiques tolèrent moins d’un tiers de pouvoir de vote défaillant et s’arrêtent plutôt que de se scinder.
Le prochain cours, la preuve de travail en détail, ouvre la boîte que Satoshi désignait : comment un mineur hache l’en-tête d’un bloc, comment la difficulté garde les blocs autour de dix minutes et ce que coûterait aujourd’hui une attaque contre le travail.
