Consensus distribué et tolérance aux pannes byzantines
Consensus distribué et tolérance aux pannes byzantines
Section intitulée « Consensus distribué et tolérance aux pannes byzantines »Le consensus distribué permet à plusieurs nœuds de retenir le même ordre d’opérations sans autorité centrale unique. La tolérance aux pannes byzantines ajoute l’hypothèse pénible mais réaliste qu’un nœud peut mentir, signer des messages contradictoires ou disparaître au pire moment.
→ Lire l’explication complète de la marmotte
Consensus distribué : sûreté, vivacité et hypothèses
Section intitulée « Consensus distribué : sûreté, vivacité et hypothèses »Un protocole de consensus doit fournir deux propriétés distinctes. La sûreté interdit de décider deux valeurs incompatibles, par exemple appliquer deux fois un virement ou élire deux responsables pour le même mandat. La vivacité garantit qu’une décision finit par être prise. Réunir les deux n’est pas automatique : un système peut préserver la sûreté en refusant éternellement de progresser. C’est frustrant, mais moins ruineux qu’une double validation.
Le théorème de Fischer, Lynch et Paterson (FLP) établit qu’avec un réseau entièrement asynchrone et au moins une panne par arrêt, aucun protocole déterministe ne garantit simultanément sûreté et terminaison. Un réseau entièrement asynchrone ne fournit aucune borne fiable sur les délais de transmission ou d’exécution. Un message peut être perdu, retardé ou simplement coincé derrière un pare-feu qui fait semblant d’être vivant.
La production contourne ce résultat avec la synchronie partielle. Avant une date inconnue, les délais peuvent être arbitraires. Après cette date, ils redeviennent bornés par une valeur inconnue du protocole. Les temporisations déclenchent alors les changements de tour ou d’élection. Elles ne prouvent jamais qu’un pair est hostile : elles signalent seulement qu’il n’a pas répondu assez vite. Confondre absence et malveillance conduit à expulser les nœuds chargés pendant un incident, méthode appréciée des systèmes qui veulent transformer une dégradation en catastrophe.
Les protocoles comme Paxos et Raft supposent généralement des pannes par arrêt : un nœud répond correctement ou ne répond plus. Ils conviennent à un domaine d’administration homogène, avec identité des pairs contrôlée et stockage local fiable. Ils ne résistent pas à un pair compromis qui forge des réponses valides selon le protocole. Cette distinction doit être écrite dans la menace, pas cachée dans un diagramme à six hexagones.
Pour replacer ces mécanismes dans les choix d’architecture, voir les fondations des systèmes de sécurité et les arbitrages d’architecture cybersécurité.
Tolérance aux pannes byzantines et seuils de quorum
Section intitulée « Tolérance aux pannes byzantines et seuils de quorum »La tolérance aux pannes byzantines (BFT, Byzantine Fault Tolerance) suppose qu’un participant peut adopter un comportement arbitraire : envoyer des votes différents à des destinataires différents, rejouer un ancien message, refuser de répondre ou coopérer avec un attaquant. Un protocole BFT classique tolère au plus f nœuds byzantins avec au moins 3f + 1 validateurs.
Ce seuil n’est pas décoratif. Avec 3f + 1 nœuds, un quorum de décision contient au moins 2f + 1 voix. Deux quorums de cette taille se recouvrent sur au moins f + 1 nœuds. Puisqu’il existe au maximum f nœuds malveillants, l’intersection contient au moins un nœud correct. Ce nœud correct ne doit jamais voter pour deux décisions concurrentes au même tour. Toute la sûreté repose sur cette règle et sur une preuve vérifiable de chaque vote.
Un ensemble de quatre validateurs tolère donc une compromission, sept en tolèrent deux, dix en tolèrent trois. Ajouter des nœuds sans redéfinir le seuil ne crée pas magiquement de la résilience. Cela crée parfois un groupe de discussion plus grand, ce qui est une autre discipline, avec moins de signatures.
Le compromis central est net : la BFT gagne une sûreté face aux comportements arbitraires, mais paie en latence, en trafic de votes, en gestion des identités et en disponibilité lors d’une perte de quorum. Pour un contrôle interne sous une même autorité, Raft ou Paxos reste généralement le bon choix. La BFT se justifie lorsque plusieurs domaines de confiance doivent partager un registre, une décision de contrôle ou une racine d’autorisation sans accepter qu’un seul opérateur puisse la falsifier.
La BFT ne rend pas les données vraies. Elle garantit qu’un groupe a décidé selon des règles, pas que l’événement soumis au groupe correspond au monde réel. Un oracle applicatif compromis, une source de temps erronée ou une autorisation métier abusive sera répliqué avec une discipline exemplaire. La cohérence d’un mensonge reste de la cohérence.
Authentification des votes et identité des validateurs
Section intitulée « Authentification des votes et identité des validateurs »Un vote BFT doit être lié cryptographiquement à son émetteur, à l’instance de consensus, au tour et à la proposition. Signer seulement une charge utile laisse la porte ouverte au rejeu dans une autre instance. Le domaine de signature doit inclure au minimum l’identifiant de réseau, la hauteur ou séquence, le numéro de tour, le type de message et le condensat de la proposition.
La clé privée d’un validateur est un actif de gouvernance, pas un paramètre de conteneur. La placer dans une variable d’environnement, un volume partagé ou un fichier de configuration de pipeline revient à transformer un seuil BFT en concours de récupération de secrets. Une clé par validateur doit être générée, stockée et utilisée dans un HSM (Hardware Security Module) ou un mécanisme équivalent qui interdit l’export de la matière privée.
La rotation est délicate : retirer une clé ne retire pas les signatures déjà émises, et ajouter un validateur modifie la composition du quorum. Une transition d’ensemble de validateurs doit elle-même être décidée par l’ancien quorum, puis activée selon une hauteur déterministe. Accepter une modification locale de la liste des pairs casse l’accord global avec une efficacité presque artistique.
La révocation dépend de l’application et du protocole. Un certificat révoqué peut encore être présenté par une session établie, et une signature historique reste mathématiquement valide. Le système doit donc distinguer validité cryptographique, autorisation courante et validité à une hauteur donnée. Les sujets de clés, certificats et ancres de confiance relèvent aussi de la cryptographie appliquée et de la PKI et TLS.
Quorum BFT : exemple de contrôle reproductible
Section intitulée « Quorum BFT : exemple de contrôle reproductible »Le calcul suivant vérifie si un ensemble de signatures atteint le quorum BFT. Il ne remplace pas la vérification cryptographique des signatures : il contrôle la règle de cardinalité après cette vérification. Exécuter avec Python 3, sans dépendance externe.
# Chaque identifiant représente un validateur dont la signature a déjà été vérifiée.validateurs = {"a", "b", "c", "d", "e", "f", "g"} # 3f + 1 = 7, donc f = 2signataires = {"a", "b", "c", "d", "e"} # 2f + 1 = 5 signatures requises
n = len(validateurs)assert (n - 1) % 3 == 0, "L'ensemble doit respecter 3f + 1"f = (n - 1) // 3quorum = 2 * f + 1
assert signataires <= validateurs, "Signataire hors ensemble de validateurs"print(f"f={f}, quorum={quorum}, signatures={len(signataires)}")print("DECISION ACCEPTEE" if len(signataires) >= quorum else "DECISION REFUSEE")python3 quorum_bft.py# f=2, quorum=5, signatures=5# DECISION ACCEPTEEEn production, conserver avec chaque décision les signatures, la liste exacte des validateurs et son identifiant de version. Sans ces éléments, une décision peut être appliquée, mais elle ne peut plus être auditée ni rejouée de façon déterministe. Un journal append-only répliqué n’est pas une preuve si ses entrées ne permettent pas de recalculer le quorum.
Surface d’attaque des protocoles BFT
Section intitulée « Surface d’attaque des protocoles BFT »L’attaque la plus directe vise l’équivoque : un validateur signe deux propositions incompatibles pour le même tour. Les messages doivent donc être signés individuellement, archivés, et leur domaine de signature doit empêcher le rejeu. Les preuves d’équivoque doivent déclencher une exclusion protocolaire ou une suspension gouvernée, jamais une suppression discrète de logs. Effacer la preuve pour rendre le tableau de bord plus vert est une tactique de camouflage, pas de disponibilité.
L’attaque par partition réseau tente de séparer les validateurs en groupes incapables de communiquer. Si aucun groupe n’atteint 2f + 1, la vivacité s’arrête mais la sûreté demeure. C’est le comportement attendu. Réduire le quorum à chaud pour « relancer le service » autorise deux partitions à décider séparément. Le protocole n’a alors plus de bug : l’exploitation vient de créer un autre protocole.
Le déni de service cible souvent les leaders ou propose des blocs coûteux à vérifier. Limiter la taille des messages, le coût de validation, les connexions entrantes et le nombre de propositions par tour protège les ressources. Séparer le réseau de consensus du trafic applicatif réduit l’exposition, avec filtrage réseau, authentification mutuelle et supervision des latences. Les mécanismes réseau restent détaillés dans la section réseaux et proxy.
La compromission de f + 1 clés peut suffire à perturber durablement le système, même sans atteindre le seuil de falsification. La compromission de 2f + 1 clés permet de produire des décisions valides selon le protocole. La BFT n’est donc pas une alternative à la sécurité des postes d’administration, à la segmentation réseau ou au contrôle d’accès privilégié. Elle suppose ces contrôles, puis répartit le risque résiduel.
Exploitation : sauvegarde, reprise et observabilité
Section intitulée « Exploitation : sauvegarde, reprise et observabilité »Sauvegarder les clés privées sans précaution annule la séparation entre validateurs. Une sauvegarde chiffrée doit être protégée par des contrôles d’accès distincts, testée en restauration et journalisée. Un export de clé depuis un HSM pour « simplifier le plan de reprise » simplifie surtout la compromission future.
Le stockage persistant doit retenir le dernier tour voté et les décisions verrouillées avant tout accusé de réception. Restaurer un validateur depuis un instantané ancien peut le pousser à signer à nouveau une proposition incompatible. Ce risque de double signature impose soit un stockage anti-retour, soit une procédure de restauration qui retire le validateur jusqu’à resynchronisation complète.
Superviser quatre signaux : taille et version de l’ensemble des validateurs, hauteur décidée, retard de réplication, taux d’échec des signatures et des propositions. Ajouter les changements de tour, les preuves d’équivoque et l’âge des certificats. Une alerte sur la perte de quorum doit déclencher un diagnostic réseau et cryptographique, pas un redémarrage en boucle. Redémarrer trois fois un protocole qui refuse de décider ne produit pas un quatrième quorum.
🐝 Ce qui arrive si on s’en passe
Section intitulée « 🐝 Ce qui arrive si on s’en passe »Sans consensus tolérant aux pannes byzantines, un registre partagé entre plusieurs domaines de confiance repose sur la bonne foi de la réplique qui répond. Un client ne reçoit aucun certificat de quorum signé à vérifier : une seule réplique compromise peut lui servir un état forgé, tronqué ou ancien, et un autre client peut recevoir une version différente sans que l’écart soit détectable de l’extérieur. Un leader Raft ou Paxos compromis peut aussi réordonner ou réécrire des entrées que les suiveurs répliquent sans contrôle cryptographique. Après incident, aucun vote signé ne permet d’attribuer une entrée litigieuse à un opérateur précis : la contestation entre domaines ne peut plus s’appuyer sur une preuve, seulement sur des journaux que chaque partie contrôle elle-même.
🦫 Explication de la marmotte 🍫
Section intitulée « 🦫 Explication de la marmotte 🍫 »Un système distribué répartit une même décision entre plusieurs machines. Chaque machine reçoit une proposition, vérifie qu’elle respecte les règles, puis envoie un vote signé. Une signature prouve quelle machine a émis le vote et empêche une autre machine de le modifier sans être détectée.
Le système attend un nombre minimal de votes avant de considérer une décision comme acceptée. Ce nombre est choisi pour que deux décisions opposées ne puissent pas chacune être acceptées sans qu’au moins une machine honnête doive voter deux fois. Les machines honnêtes refusent ce double vote. Si certaines machines sont en panne ou mentent, les autres peuvent donc empêcher une contradiction.
Quand le réseau est coupé en plusieurs parties, une partie trop petite ne peut plus atteindre le nombre de votes demandé. Elle doit attendre. Le service ralentit ou s’arrête, mais il ne doit pas inventer une décision différente. Quand la communication revient, les machines échangent les décisions signées et reprennent à partir de la dernière décision reconnue.
Le système dépend toutefois de clés privées protégées, de machines non compromises en trop grand nombre, d’un stockage qui conserve les votes déjà envoyés et d’une liste de participants contrôlée. Si assez de clés sont volées, les fausses décisions auront des signatures valides. Le mécanisme garantit l’accord selon ses règles, pas la vérité des informations fournies.
À lire aussi
- Méthodes formelles TLA+ et Coq (Rocq), où elles valent leur coûtCe que prouvent réellement TLA+ et Coq (Rocq Prover), ce qu'ils ne prouvent pas, et sur quelles parties d'un système les méthodes formelles remboursent leur coût.
- Partager un secret et distribuer la confiancePrésenter les mécanismes qui évitent de concentrer un secret ou une décision dans une seule machine: partage, seuil, conférence et calcul distribué.
Pages voisines
La citent
- Méthodes formelles TLA+ et Coq (Rocq), où elles valent leur coût
- Chaîne d'alimentation et refroidissement d'un datacenter
- Chaînes de blocs, wallets et cryptographie économique
- Partager un secret et distribuer la confiance
Consensus distribué et tolérance aux pannes byzantines
Elle cite