Aller au contenu
Financial Context Wiki

Mécanismes de consensus : validité, choix de branche et finalité

Un mécanisme de consensus coordonne les répliques sur des historiques compatibles sous des hypothèses explicites de panne et de réseau. Il faut analyser séparément décision, participants et poids, validité, proposition, choix de branche, finalité, sûreté, vivacité et déploiement.

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

Un mécanisme de consensus est le protocole par lequel des répliques non défaillantes convergent vers des décisions compatibles sur un journal ordonné ou un état malgré les retards, la concurrence et les pannes couvertes par son modèle. Dans une blockchain, le mécanisme complet peut inclure sélection du proposant, validation des blocs et transitions d’état, votes ou preuves, choix de branche, engagement ou finalité, reprise et règles d’adhésion. Ce n’est pas seulement « plusieurs ordinateurs enregistrent le même fichier », un seuil de vote, le minage, le staking ou un barème d’incitations.

Trois propriétés doivent être énoncées séparément. safety (sûreté) empêche les participants non défaillants de prendre des décisions incompatibles ; liveness (vivacité) indique qu’un travail valide peut finir par progresser sous certaines conditions ; validity (validité) contraint ce qui peut être décidé. Un protocole peut s’arrêter tout en préservant la sûreté ou continuer sous des hypothèses autorisant une réorganisation ultérieure. Le mot « consensus » n’indique pas seul quelle garantie vaut, quand elle vaut ni à quelle preuve un client doit se fier.

La validité d’une transaction et la sélection canonique sont distinctes. Un nœud complet rejette indépendamment une transition qui enfreint les règles courantes. Si deux transactions individuellement valides dépensent la même entrée, l’ordre ou le choix de branche détermine laquelle entre dans l’historique canonique ; une majorité de ressources ne rend pas les deux valides. De même, un accord sur des octets ne prouve pas la vérité d’un fait d’oracle, d’une affirmation de pont, d’un calcul applicatif ou d’une assertion juridique.

Proof of Work et Proof of Stake fournissent généralement résistance aux attaques Sybil, influence sur les propositions ou poids de vote attribuable, mais leur nom ne spécifie pas un protocole complet. Bitcoin combine preuve de travail, validation et sélection selon le travail cumulé. Gasper d’Ethereum combine attestations pondérées par enjeu, choix LMD-GHOST et finalité des points de contrôle Casper FFG. Un BFT à tours comme CometBFT possède d’autres messages, seuils, hypothèses temporelles et finalité. Leurs pourcentages ne sont pas interchangeables.

Méthode d’analyse

  1. Nommer la décision et le périmètre. Préciser si les répliques décident une valeur, un journal ordonné, un bloc par hauteur, un point de contrôle ou un état applicatif ; identifier chaîne, réseau, couche, version et point de départ fiable.
  2. Définir participants et influence. Distinguer proposants, votants, validateurs complets, clients légers et observateurs. Noter l’entrée et la sortie des identités, si l’influence suit puissance de hachage, enjeu, adhésion égale ou autre poids, et la défense contre les identités dupliquées bon marché.
  3. Séparer les étapes. Documenter validité de transaction et d’état, construction et diffusion de proposition, vote ou preuve, choix de branche, engagement, finalité et reprise. Un bloc valide peut perdre le choix et une tête canonique ne pas être encore finalisée.
  4. Énoncer le modèle système. Définir canaux authentifiés, synchronie ou synchronie partielle, délais et expirations, pannes par arrêt et byzantines, équivoque, omission, corruption adaptative, vol de clé, partitions et nombre ou poids maximal défaillant f.
  5. Retracer une décision. Suivre domaines de messages, hauteurs, tours, parents, verrous, certificats et état local de la proposition à la décision. Montrer le traitement d’un message tardif, d’un proposant équivoque, d’un tour expiré ou de deux branches valides.
  6. Vérifier séparément sûreté et vivacité. Dériver intersection de quorum, croissance de chaîne ou autres conditions avec l’ensemble et l’instantané exacts des poids. Tester ensuite s’il reste assez de connectivité et de participation honnêtes ; ne pas déduire la vivacité d’un seuil de sûreté.
  7. Relier la preuve au déploiement. Vérifier versions des clients, changements de paramètres, concentration des membres et enjeux, garde des clés, diversité des pairs, rôles de builder ou séquenceur, points de contrôle, règles de subjectivité faible, réorganisations et politique de confirmation applicative.

FLP ne dit pas que le consensus déployé est impossible. Dans un modèle de messages entièrement asynchrone, même une seule panne par arrêt laisse une exécution admissible où un protocole déterministe ne termine pas. Les protocoles réels obtiennent des garanties utiles en ajoutant synchronie ou synchronie partielle, aléa, détecteurs de pannes, hypothèses économiques ou promesses de terminaison plus faibles. Ces ajouts doivent être nommés et non cachés derrière une étiquette.

Exemples détaillés

1. La validité n’est pas l’ordre canonique

Une sortie non dépensée U vaut 1 BTC. La transaction T_B la dépense vers Bob et T_C dépense la même sortie vers Carol. Par rapport au même état parent, chacune peut avoir signature et format corrects, mais un historique valide ne peut consommer U deux fois.

Si deux blocs valides concurrents contiennent chacun une transaction, la validation conserve localement les deux branches candidates et le choix de branche en sélectionne une canonique. Quand T_B entre dans l’historique retenu, T_C entre en conflit avec l’état résultant. Le consensus a choisi un ordre ; il n’a pas corrigé une mauvaise signature ni décidé qui méritait moralement le paiement.

2. Travail cumulé, pas nombre de nœuds

Supposons deux branches valides de type Bitcoin dont les scores de travail cumulé sont W_A=240 et W_B=235 dans la même unité arbitraire. Un nœud validateur choisit A selon le travail cumulé même s’il a d’abord entendu B de davantage de pairs. Le nombre de pairs n’est pas un poids de consensus.

Si B ajoute ensuite 10 unités et A aucune, on obtient W_B=245 contre W_A=240 ; après validation, le nœud peut se réorganiser vers B. Cette arithmétique simplifiée montre pourquoi la confirmation PoW est probabiliste : remplacer un historique profond devient progressivement plus coûteux, pas logiquement impossible après un nombre fixe de blocs.

3. Quorum BFT pondéré et arrêt de la vivacité

Soit un poids validateur total 100 et un engagement de type CometBFT exigeant des préengagements >2/3 pour le même bloc, à la même hauteur et au même tour. Le poids entier 67 suffit. Deux quorums de poids 67 se recoupent sur au moins 34, car 67 + 67 - 100 = 34. Si le poids byzantin est inférieur à un tiers, l’intersection comprend du poids honnête qui ne doit pas signer d’engagements contradictoires.

Le même seuil révèle une limite de vivacité. Si 34 de poids est hors ligne, il ne reste que 66 et aucun engagement ne peut se former, même si tous les validateurs en ligne sont honnêtes. Le protocole peut s’arrêter en préservant la sûreté ; un vote de gouvernance ou le nombre d’opérateurs ne remplace pas le poids absent.

4. Choix de branche et finalité des points de contrôle sont distincts

Dans une trace Gasper simplifiée, prenons pour points de contrôle C_0, C_1 et son enfant direct C_2. Des votes représentant 67/100 du solde effectif actif peuvent créer un lien de supermajorité de C_0 à C_1, justifiant C_1. Un lien qualifiant ultérieur de C_1 à C_2 peut finaliser le point antérieur selon la règle FFG applicable.

Entre les points de contrôle, LMD-GHOST utilise les attestations les plus récentes pour choisir la tête parmi les descendants viables du point justifié, tandis que les contraintes du point finalisé filtrent les branches incompatibles. Choix de tête, justification et finalisation sont donc des transitions liées mais différentes ; « 67 % ont voté pour ce bloc » n’en décrit aucune complètement.

Risques et erreurs d’examen

Modèle et garanties

  • Dire « le réseau atteint le consensus » sans définir décision, sûreté, vivacité, validité et terminaison.
  • Prendre Proof of Work, Proof of Stake, minage, staking ou un pourcentage de vote pour une spécification complète.
  • Appliquer 51%, 2/3 ou n=3f+1 universellement à des modèles différents de panne, temps, poids et finalité.
  • Confondre arrêt, comportement byzantin, vol de clés, canaux défaillants, logiciels corrélés et capture de gouvernance.
  • Invoquer FLP comme interdiction du consensus pratique plutôt que dans sa portée déterministe, entièrement asynchrone et à terminaison garantie.
  • Compter nœuds ou clés sans mesurer opérateurs indépendants, poids, clients, nuages et garde.
  • Supposer que canonique, safe, justifié, engagé et finalisé sont des états interchangeables.
  • Déduire vérité externe, ordre équitable, confidentialité, décentralisation ou valeur de l’accord répliqué.

Protocole et implémentation

  • Accepter blocs ou votes sans les lier à chaîne, version, hauteur, tour, parent, charge, expéditeur et époque d’adhésion.
  • Laisser les implémentations diverger sur transition, sérialisation, domaine de signature, choix, départage ou arrondi.
  • Vérifier un certificat sans reconstruire l’instantané de poids admissible et le traitement des signataires dupliqués.
  • Rejouer votes, travail ou certificats entre branches, réseaux, tours, mises à niveau ou changements de validateurs.
  • Mal mettre à jour verrous, points justifiés ou certificats les plus hauts lors d’expiration, changement de vue ou reprise.
  • Prendre une tête locale ou l’étiquette d’un seul RPC pour une preuve indépendante de finalité du réseau.
  • Tester seulement le cas nominal, sans délai, partition, équivoque, proposition invalide, réorganisation et reprise.

Déploiement et application

  • Concentrer hachage, enjeu, clients, relais, builders, séquenceurs, nuages ou signature derrière des identités nominalement séparées.
  • Régler expirations ou intervalles sous les temps réels de propagation et validation, nuisant à la vivacité ou augmentant les forks.
  • Créditer dépôts, créer des actifs de pont ou exécuter des actions irréversibles avant la finalité requise de la source et de l’application.
  • Supposer que pénalités, récompenses ou prix du jeton créent toujours un budget de sécurité suffisant et liquide.
  • Employer reprise sociale ou gouvernance sans reconnaître qui coordonne, quelle chaîne les clients installent et quelle garantie antérieure change.

Idées reçues

  • Consensus et validation sont identiques. La validation rejette les données contraires aux règles ; le consensus choisit des décisions compatibles parmi des candidats peut-être valides localement.
  • Plus de nœuds signifie automatiquement plus de sécurité. Influence, indépendance, topologie, diversité logicielle et modèle de panne comptent plus que le nombre brut.
  • Un attaquant à 51 % peut falsifier toute signature. Une majorité de ressources peut permettre censure ou réorganisation dans un protocole, mais ne révèle pas les clés et n’autorise pas une dépense invalide.
  • Deux tiers signifient toujours finalité. Inégalité, message, tour, instantané de poids, règle de verrou et condition de finalité dépendent du protocole.
  • Des blocs rapides prouvent un consensus fort. Des intervalles courts peuvent augmenter courses de propagation et pression des ressources ; évaluer latence avec sûreté, vivacité et finalité.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...