Aller au contenu
Financial Context Wiki

Tolérance aux fautes byzantines : sûreté, vivacité et quorums

La tolérance aux fautes byzantines décrit quand un protocole distribué reste sûr et vivant malgré des fautes arbitraires. Protocole, modèle réseau, borne de fautes, quorum, poids, finalité et reprise doivent être évalués ensemble.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

La tolérance aux fautes byzantines (BFT) est une propriété d’un protocole distribué précis sous des modèles de faute et de réseau précis : il continue de respecter ses garanties même si certains participants tombent en panne, retiennent des messages, envoient des messages incompatibles à différents pairs ou se comportent arbitrairement. BFT n’est pas un algorithme unique et ne signifie pas que tous les services restent disponibles durant toute partition.

Les garanties doivent être séparées. safety (sûreté) empêche les participants honnêtes de décider des valeurs incompatibles ; liveness (vivacité) permet à des entrées admissibles d’aboutir finalement à une décision ; validity (validité) limite les valeurs décidables. Un protocole peut s’arrêter pour préserver la sûreté lorsque la communication ou le pouvoir de vote honnête manque. Un consensus correct ne prouve pas non plus la correction du code applicatif, des règles de validité, des ponts, des clés ou de la gouvernance.

Dans une classe courante de protocoles BFT authentifiés et partiellement synchrones, n=3f+1 répliques tolèrent au plus f répliques byzantines et un certificat de validation utilise q=2f+1 votes. Les formules « moins d’un tiers fautif » et « quorum supérieur aux deux tiers » viennent de ce modèle. Les protocoles synchrones, asynchrones aléatoires, tolérant les pannes franches, les chaînes à preuve de travail et d’autres constructions BFT peuvent employer d’autres hypothèses et seuils.

Dans les systèmes pondérés par la mise, les seuils portent sur le pouvoir de vote défini par le protocole, pas nécessairement sur le nombre de validateurs, d’adresses, de personnes ou d’opérateurs indépendants. Avant d’appliquer une fraction, il faut préciser version, instantané des poids, type de décision, hypothèse réseau, comparaison du quorum (> ou >=) et comportement fautif.

En dessous du seuil
25%
Part contradictoire
25%
Marge jusqu'au seuil
8,4%

Les résultats sont des approximations pédagogiques. Ils excluent les règles du site, les taxes, la latence, le comportement d'Oracle et d'autres paramètres spécifiques au protocole, sauf indication contraire.

Fonctionnement

  1. Définir la décision. Déterminer si les nœuds ordonnent des transactions, valident un bloc, finalisent un point de contrôle, élisent un chef, acceptent une transition d’état ou choisissent une branche. Ces décisions ne sont pas interchangeables.
  2. Énoncer les modèles du système et de l’adversaire. Consigner membres, authentification, changements de permission, poids, corruption adaptative, compromission de clés, équivoque, pannes, pertes de messages, censure, déni de service et corrélation possible des fautes.
  3. Énoncer le modèle réseau. Distinguer synchronie, synchronie partielle et asynchronie. En synchronie partielle, préciser ce qui n’est garanti qu’après un temps mondial de stabilisation inconnu et comment les délais s’adaptent.
  4. Dériver la règle de quorum. Employer le seuil et les règles exactes de verrouillage ou de vote. Dans le cas classique n=3f+1, deux quorums 2f+1 se croisent sur au moins f+1 répliques ; avec au plus f byzantines, l’intersection en contient une honnête.
  5. Suivre chaque phase et certificat. Vérifier proposition, vote, verrou, changement de vue ou de tour, validation, choix de branche et reprise. Une supermajorité signée n’a de sens que si hauteur, tour, valeur, parent, domaine, époque des membres et certificat antérieur sont validés.
  6. Séparer les preuves de sûreté et de vivacité. Prouver quelles décisions incompatibles sont toujours exclues, puis vérifier que le progrès reprend lorsque les hypothèses de communication et de participation honnête sont réunies. Un délai est un outil d’ordonnancement, pas une preuve de malveillance.
  7. Vérifier mise en œuvre et exploitation. Comparer au modèle la diversité des clients, la garde des clés, la relève des signataires, l’antirejeu, la synchronisation d’état, le traitement des preuves, les changements de membres, la surveillance, la politique de confirmation et la reprise.

Le résultat FLP établit qu’un protocole de consensus déterministe ne peut garantir la terminaison dans un modèle entièrement asynchrone, même avec une seule panne franche possible. Il ne dit pas que la sûreté est impossible ni que le consensus distribué ne fonctionne jamais. Synchronie partielle, aléa, détecteurs de panne, hypothèses économiques ou garanties plus faibles modifient chacun différemment les conditions précises de l’impossibilité.

Exemples calculés

1. Quatre répliques de même poids

Soient n=4, f=1 et q=3. Deux ensembles de trois votes se croisent sur au moins 3+3-4=2 répliques. Avec au plus une byzantine, au moins une réplique de l’intersection est honnête. Si les règles honnêtes interdisent de voter pour des valeurs incompatibles dans l’historique de hauteur et de tour concerné, deux certificats incompatibles ne peuvent pas se former.

Si deux répliques sont hors ligne, seuls 2 votes restent et aucun certificat q=3 ne se forme. C’est une perte de vivacité, pas automatiquement de sûreté : un protocole sûr attend au lieu d’abaisser localement le seuil.

2. Sept répliques de même poids

Soient n=7, f=2 et q=5. Deux quorums se croisent sur au moins 5+5-7=3=f+1 répliques. Puisque au plus 2 sont byzantines, une honnête appartient à l’intersection. Deux byzantines seules ne créent pas un certificat de cinq votes, mais trois absentes ou retenant leur vote ne laissent que 4 votes et peuvent bloquer le progrès.

L’arithmétique du seuil est nécessaire, mais insuffisante. Si des mises en œuvre honnêtes acceptent des votes d’une autre hauteur, réemploient les membres, violent un verrou ou signent avec des clés compromises, les hypothèses de la preuve ne décrivent plus le déploiement.

3. Pouvoir de vote pondéré

Supposons des poids 40, 30, 20 et 10, total 100, et un certificat exigeant strictement plus de 2/3, ici au moins 67. La coalition 40+30=70 peut certifier ; 30+20+10=60 ne le peut pas malgré trois validateurs sur quatre. Si le validateur de poids 40 est hors ligne, il ne reste que 60 et la finalité s’arrête.

Deux ensembles d’au moins 67 se croisent sur au moins 67+67-100=34. Des certificats incompatibles impliquent donc qu’au moins 34 de poids a participé aux deux ou qu’une autre hypothèse a échoué. Dans certains protocoles, un peu plus d’un tiers d’équivoque suffit à violer la sûreté ; « deux tiers pour attaquer » n’est pas un minimum universel.

4. Synchronie partielle et délais

Supposons des délais de tour de 1 s, 2 s, 4 s et 8 s. Avant l’instant inconnu de stabilisation, les messages peuvent arriver après chaque délai et provoquer des changements de tour sans décision. Si le retard passe ensuite sous 3 s, un tour de 4 s ou plus peut laisser assez de temps à un proposant honnête et au quorum, sous les autres hypothèses.

Ces nombres illustrent un progrès éventuel, pas une formule universelle. Des délais courts provoquent des changements inutiles ; des délais longs retardent la reprise. La sûreté ne doit pas dépendre d’une estimation correcte de la latence avant stabilisation.

Risques et erreurs de contrôle

Modèle et preuve

  • Dire « BFT » sans nommer protocole, version, décision, modèles de faute et de réseau, membres et seuil.
  • Appliquer n=3f+1 ou un tiers à tout registre distribué même lorsque sa preuve repose sur d’autres hypothèses.
  • Confondre sûreté, vivacité, validité, disponibilité, cohérence, finalité, choix de branche et correction des transactions.
  • Affirmer que FLP rend le consensus impossible sans conserver les conditions déterministe, entièrement asynchrone et de terminaison garantie.
  • Compter nœuds ou adresses quand le protocole compte mise, délégation, comités, époques ou une autre ressource.
  • Arrondir « deux tiers » de façon ambiguë ou ignorer >, >=, poids entiers et instantané du dénominateur.
  • Vérifier la taille du quorum sans intersection, verrous, certificats, changements de vue, reconfiguration et transfert d’état.
  • Supposer qu’une preuve couvre corruption adaptative, vol de clés, fautes corrélées, déni de service ou historique de longue portée.

Mise en œuvre et exploitation

  • Accepter des signatures non liées à la chaîne, au domaine, à la hauteur, au tour, à la valeur, au parent, à l’époque des membres et au type de message.
  • Rejouer d’anciens votes ou certificats entre tours, hauteurs, branches, réseaux, mises à niveau ou changements de validateurs.
  • Autoriser double signature, recul du verrou, relève dangereuse ou deux répliques actives partageant une identité de validateur.
  • Traiter l’expiration du délai comme preuve de malveillance et décider de la sûreté avec les seules horloges locales.
  • Ignorer les fautes corrélées dues à un client, nuage, lieu, réseau, matériel, gestionnaire de clés ou opérateur commun.
  • Supposer que la pénalité empêche les fautes, rétablit la vivacité, annule une action finalisée ou indemnise tout le monde.
  • Tester seulement le cas normal, pas les partitions, retards, réordonnancements, équivoques, pannes du proposant, redémarrages et changements de membres.

Application et gouvernance

  • Traiter une valeur validée comme état valable sans exécution déterministe ni validation de transition.
  • Créditer des dépôts, émettre des actifs sur un pont ou régler des opérations avant la condition exacte de finalité requise.
  • Assimiler finalité du protocole et irréversibilité sociale après compromission de clés, panne logicielle ou intervention de gouvernance.
  • Ignorer censure et délai d’inclusion parce que les blocs des autres utilisateurs continuent d’être finalisés.
  • Déduire décentralisation, sécurité des actifs, valeur du jeton ou force juridique de l’étiquette BFT ou du nombre annoncé de validateurs.

Idées reçues

  • BFT signifie que le réseau ne s’arrête jamais. Beaucoup de protocoles sacrifient volontairement la vivacité lors de fautes excessives ou de partitions afin de préserver la sûreté.
  • Plus de 51 % de participants honnêtes suffisent toujours. Le seuil dépend du protocole ; le BFT classique partiellement synchrone demande souvent plus des deux tiers du pouvoir pertinent pour progresser.
  • Un attaquant a toujours besoin des deux tiers pour briser la sûreté. Deux tiers peuvent certifier seuls, mais deux certificats incompatibles peuvent révéler à peine plus d’un tiers d’équivoque.
  • Davantage d’adresses de validateurs améliorent automatiquement la tolérance. Propriété commune, délégations, clients, infrastructure, clés et domaines de panne déterminent l’indépendance.
  • La pénalité constitue la preuve BFT. C’est une réponse économique de certains systèmes PoS ; la sûreté vient des règles et hypothèses, et la sanction n’annule pas les conséquences externes.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...