Qu’est-ce que la tolérance aux pannes byzantines (BFT) ?

La tolérance aux pannes byzantines (BFT) est, en bref, la capacité d’un réseau informatique à continuer de fonctionner correctement lorsqu’une partie des participants tombe en panne, commet des erreurs ou diffuse volontairement de fausses informations.

Cela est particulièrement important pour les blockchains. Une blockchain ne dispose pas d’un administrateur central qui décide quelles transactions et quels blocs sont valides. À la place, des ordinateurs répartis, également appelés nœuds ou validateurs, doivent parvenir ensemble à un accord sur une seule version de la blockchain.

Un validateur peut rencontrer différents types de défaillances, à savoir une défaillance ordinaire ou une Byzantine Fault. Dans le cas d’une défaillance ordinaire, il est clair pour le réseau que le validateur ne fonctionne pas correctement. Le validateur, par exemple, tombe en panne, perd la connexion Internet ou n’envoie pas un message à temps. Il ne fournit alors aucune information exploitable. La blockchain peut généralement gérer cela assez facilement. Les autres validateurs n’attendent pas indéfiniment, mais poursuivent après un certain délai sans le validateur hors service. Tant qu’il reste suffisamment d’autres validateurs actifs, le réseau continue de traiter de nouveaux blocs.

En cas de Byzantine fault, un validateur ne se comporte pas seulement de manière défectueuse, mais de façon imprévisible. Il peut encore envoyer des messages, mais transmettre des informations erronées ou contradictoires. Ainsi, il peut dire à un validateur que le bloc A est valide et à un autre validateur que le bloc B est valide.

La différence est donc la suivante :

• En cas de défaillance ordinaire, l’information d’un validateur est absente.
• En cas de Byzantine fault, il y a bien une information, mais il n’est pas clair si elle est correcte.

Une Byzantine fault est donc plus difficile à résoudre. Le réseau doit non seulement pouvoir continuer sans un validateur hors service, mais aussi empêcher que des messages erronés ou contradictoires conduisent à une décision incorrecte.

La tolérance aux pannes byzantines décrit comment un réseau peut malgré tout prendre une décision commune, malgré ce type de problèmes. Le protocole utilise notamment des contrôles, des signatures numériques, plusieurs tours de vote et un seuil de vote élevé.

De nombreux protocoles BFT exigent que plus de deux tiers du poids de vote total soutiennent la même proposition avant qu’un bloc ne devienne définitif. Ainsi, un petit groupe de validateurs défaillants ou malveillants ne peut pas déterminer seul quelle version de la blockchain est valide.

La BFT n’est pas un mécanisme de consensus distinct. Il s’agit d’une propriété d’un réseau ou d’un protocole de consensus. Des protocoles tels que PBFT, Tendermint et HotStuff utilisent chacun leurs propres règles pour tolérer les pannes byzantines.

À retenir

• La tolérance aux pannes byzantines aide une blockchain à gérer des validateurs défectueux ou non fiables.
• Une Byzantine fault peut résulter d’une panne technique, d’une erreur logicielle ou d’une attaque délibérée.
• Les validateurs contrôlent les propositions et votent sur de nouveaux blocs.
• De nombreux protocoles BFT exigent le soutien de plus de deux tiers du poids de vote total.
• La BFT aide à éviter que plusieurs versions de la blockchain deviennent définitives en même temps.
• PBFT, Tendermint et HotStuff sont des exemples de protocoles BFT.

Que résout la tolérance aux pannes byzantines ?

La tolérance aux pannes byzantines empêche qu’un petit groupe de validateurs défectueux ou malveillants puisse déterminer seul quelle version de la blockchain est valide. Elle aide le réseau à conserver un historique unique des transactions, même lorsque certains participants tombent en panne, ne répondent pas ou diffusent de fausses informations.

Un validateur non fiable peut, par exemple, envoyer des blocs différents à différents participants, voter pour deux blocs en conflit, ou tenter de faire approuver un bloc invalide. Un validateur peut également refuser de coopérer et ainsi ralentir l’obtention du consensus.

Sans règles solides, différents groupes de validateurs pourraient alors chacun suivre une version différente de la blockchain. Le réseau ne pourrait plus déterminer avec certitude quelles transactions et quels blocs sont valides.

La BFT évite cela en ne confirmant un bloc que lorsque suffisamment de validateurs ont contrôlé et soutenu la même proposition. Ainsi, un groupe limité de participants non fiables ne peut pas induire seul le réseau en erreur.

Les participants n’ont pas besoin de se faire confiance personnellement. Ils se fient aux règles fixes du protocole de consensus, telles que les signatures numériques, les tours de vote et un seuil de vote élevé.

La BFT permet ainsi de maintenir une version partagée et cohérente de la blockchain, sans administrateur central.

Comment fonctionne la tolérance aux pannes byzantines ?

Pour bien comprendre la tolérance aux pannes byzantines, il est important de connaître d’abord la différence avec un mécanisme de consensus.

Un mécanisme de consensus est l’ensemble des règles par lesquelles les participants d’une blockchain parviennent à un accord sur de nouveaux blocs et sur l’historique valide du réseau. Il détermine, par exemple, qui peut proposer un bloc, comment les validateurs votent à ce sujet, et quand un bloc est confirmé ou devient définitif.

La tolérance aux pannes byzantines est la propriété qui garantit que ce processus continue de fonctionner lorsque certains validateurs tombent en panne, commettent des erreurs ou envoient de fausses informations.

La BFT n’est donc généralement pas un système séparé, en plus du mécanisme de consensus. Elle se compose des règles au sein du processus de consensus qui empêchent des validateurs non fiables d’induire la blockchain en erreur. Il peut s’agir, par exemple, d’un seuil de vote élevé, de signatures numériques, de plusieurs tours de vote, et du remplacement d’un validateur qui ne propose pas de bloc valide.

Le fonctionnement exact varie selon la blockchain, mais, dans de nombreux protocoles BFT, le processus se déroule à peu près de la même manière.

Un validateur est temporairement désigné pour proposer un nouveau bloc. Ce validateur est souvent appelé le proposer ou le leader. Le bloc contient de nouvelles transactions et une référence au bloc précédent. Le proposer signe numériquement la proposition, afin que les autres validateurs puissent vérifier de qui elle provient.

Les autres validateurs vérifient ensuite si le bloc est valide. Ils contrôlent, par exemple, si les transactions respectent les règles, si les utilisateurs disposent d’un solde suffisant et si les mêmes tokens ne sont pas dépensés deux fois. Ils vérifient également si le bloc s’ajoute à la bonne version de la blockchain.

Lorsqu’un validateur juge le bloc valide, il émet un vote numérique. Grâce à cette signature, le réseau peut voir qui a voté, pour quel bloc le vote a été émis, et si un validateur a également voté pour un bloc en conflit.

C’est ici que la tolérance aux pannes byzantines intervient. Le réseau ne se fie pas à la décision d’un seul validateur. Dans de nombreux protocoles BFT, plus de deux tiers du poids de vote total doivent soutenir le même bloc pour qu’il puisse devenir définitif.

Ce seuil de vote élevé garantit qu’un petit groupe de validateurs défectueux ou malveillants ne peut pas décider seul quel bloc est valide. Lorsque certains validateurs envoient de fausses informations ou ne répondent pas, les autres validateurs peuvent néanmoins parvenir ensemble à une décision unique.

Exemple : Ethereum utilise le Proof of Stake et des règles proches de la BFT pour rendre les blocs définitifs. Les validateurs immobilisent de l’ETH et votent ensuite sur des points de contrôle dans la blockchain. Au moins deux tiers de l’ETH total staké doivent soutenir le même point de contrôle pour qu’il devienne définitif. Lorsqu’une petite partie des validateurs tombe en panne ou vote incorrectement, Ethereum peut malgré tout atteindre la finalité. Si environ un tiers du poids de vote total ne participe pas correctement, la finalité peut s’arrêter temporairement. Ethereum dispose pour cela d’une inactivity leak : les validateurs qui ne participent pas pendant une longue période perdent progressivement une partie de leur stake. Ainsi, les validateurs actifs peuvent, à terme, représenter à nouveau suffisamment de poids de vote pour atteindre la finalité.

Dans les réseaux Proof-of-Stake, il ne s’agit donc généralement pas seulement du nombre de validateurs, mais surtout de leur poids de vote. Ce poids de vote dépend de la quantité de tokens qu’ils ont stakés.

Certains protocoles de consensus utilisent plusieurs tours de vote. Un exemple connu est Tendermint, aujourd’hui développé plus avant sous le nom de CometBFT et utilisé par de nombreuses blockchains au sein de l’écosystème Cosmos, dont Cosmos Hub. Les validateurs votent d’abord sur le bloc proposé, puis confirment lors d’un tour suivant qu’un nombre suffisant d’autres validateurs soutient la même proposition. Ainsi, le réseau ne contrôle pas seulement si le bloc est valide, mais aussi s’il existe un accord large à son sujet.

Il peut aussi arriver qu’il n’y ait pas suffisamment de soutien. Le proposer peut, par exemple, être hors ligne, proposer un bloc invalide ou diffuser des propositions contradictoires. Le mécanisme de consensus lance alors, après un certain temps d’attente, un nouveau tour avec un autre proposer.

Cela fait également partie de la tolérance aux pannes. Un validateur défectueux ou malveillant ne peut ainsi pas bloquer le réseau indéfiniment.

Le mécanisme de consensus détermine donc comment la blockchain prend des décisions collectives. La tolérance aux pannes byzantines garantit que cette prise de décision reste fiable lorsque tous les participants n’agissent pas correctement.

En bref : comment fonctionne la tolérance aux pannes byzantines ?

1. Le mécanisme de consensus détermine quel validateur peut proposer un bloc et comment les autres validateurs votent à ce sujet.
2. Les autres validateurs vérifient si le bloc proposé est valide.
3. La BFT garantit que le réseau ne se fie pas à un seul validateur, mais ne prend une décision que lorsqu’une large majorité soutient le même bloc.
4. Les signatures numériques rendent visible qui a voté pour quoi, et si un validateur a émis des votes contradictoires.
5. Dans de nombreux protocoles BFT, plus de deux tiers du poids de vote total sont nécessaires pour rendre un bloc définitif.
6. Lorsqu’un proposer tombe en panne, ment ou n’obtient pas de majorité valide, le protocole démarre un nouveau tour de vote avec un autre proposer.
7. Le rôle de la BFT est donc de maintenir la fiabilité du consensus lorsque certains validateurs tombent en panne, commettent des erreurs ou diffusent volontairement de fausses informations.

Que cherchent à protéger la safety et la liveness ?

La tolérance aux pannes byzantines doit garantir qu’une blockchain reste fiable lorsque certains validateurs tombent en panne, commettent des erreurs ou diffusent de fausses informations. Dans ce cadre, le réseau doit éviter deux problèmes.

Premièrement, les validateurs ne doivent pas aboutir à deux versions définitives différentes de la blockchain. Deuxièmement, le réseau doit, tant que cela est possible, continuer à traiter de nouveaux blocs et de nouvelles transactions.

Ces deux objectifs sont appelés, au sein de la BFT, safety et liveness.

Safety : pas deux versions différentes

La safety signifie que le réseau n’accepte pas comme définitifs deux blocs en conflit.

Supposons que deux groupes de validateurs reçoivent chacun un bloc différent. Sans règles claires, les deux groupes pourraient penser que leur propre version est valide. La blockchain pourrait alors avoir deux historiques de transactions différents.

Les protocoles BFT tentent d’éviter cela grâce à un seuil de vote élevé, plusieurs tours de vote et des votes signés numériquement. Des règles peuvent également exister pour empêcher les validateurs de voter simplement pour un autre bloc après avoir déjà soutenu une proposition précédente.

La safety garantit donc que les participants honnêtes continuent de suivre la même version définitive de la blockchain, même lorsque certains validateurs diffusent des informations contradictoires.

Liveness : le réseau continue d’avancer

La liveness signifie que le réseau peut continuer à prendre de nouvelles décisions.

Cela implique que de nouveaux blocs sont produits, que les transactions sont traitées, et qu’un proposer défectueux ou malveillant peut être remplacé lorsqu’il bloque le processus.

Les protocoles BFT utilisent pour cela, par exemple, des délais d’attente et de nouveaux tours de vote. Lorsqu’un proposer ne propose pas de bloc valide ou ne répond pas, un autre validateur prend son tour après un certain temps.

La safety et la liveness peuvent parfois entrer en conflit. Lorsque trop de validateurs sont hors ligne ou diffusent des informations différentes, le réseau peut ne pas être en mesure de réunir suffisamment de votes fiables.

Le protocole peut alors choisir de ne rendre aucun bloc définitif temporairement. La blockchain n’avance plus pendant un moment, mais évite qu’une version incorrecte ou contradictoire ne soit approuvée.

En cas d’incertitude importante, les protocoles BFT donnent donc généralement la priorité à la safety. Le réseau préfère s’arrêter temporairement plutôt que de rendre définitive une version potentiellement incorrecte ou conflictuelle de la blockchain.

Quelle est la différence entre la tolérance aux pannes byzantines et le Byzantine Generals Problem ?

Le Byzantine Generals Problem et la tolérance aux pannes byzantines sont liés, mais ne signifient pas la même chose.

Le Byzantine Generals Problem est une expérience de pensée qui montre pourquoi il est difficile de parvenir à un accord dans un réseau sans décideur central. Dans l’histoire, plusieurs généraux doivent décider ensemble s’ils attaquent ou s’ils se retirent. Ils ne communiquent que par messages, tandis que certains généraux peuvent mentir ou diffuser des informations contradictoires.

Dans une blockchain, il s’agit en pratique du même problème. Les validateurs doivent décider ensemble quelles transactions et quels blocs sont valides, tout en n’ayant pas la certitude que chaque participant soit honnête et fiable.

La tolérance aux pannes byzantines décrit ensuite la manière dont un réseau gère ce problème. Elle garantit que les validateurs peuvent tout de même parvenir à une décision commune, même lorsqu’une partie des participants tombe en panne, commet des erreurs ou envoie de fausses informations.

Le Byzantine Generals Problem décrit donc le problème. La tolérance aux pannes byzantines est la capacité d’un réseau à résoudre ce problème. Les règles concrètes qui permettent cela, telles que les tours de vote, les signatures numériques et un seuil de vote élevé, constituent ensemble le protocole BFT.

Comment les blockchains appliquent-elles la tolérance aux pannes byzantines ?

Les blockchains peuvent appliquer la tolérance aux pannes byzantines de différentes manières. Tous les réseaux n’utilisent pas le même protocole, mais l’objectif reste similaire : les validateurs doivent choisir ensemble une seule version valide de la blockchain, même si une partie d’entre eux tombe en panne ou diffuse de fausses informations.

Les différences portent surtout sur la manière dont un validateur est choisi pour proposer un bloc, sur le nombre de tours de vote nécessaires et sur le moment où un bloc devient définitif. Le comportement du protocole varie également selon la manière dont il gère les validateurs qui ne répondent pas ou qui émettent des votes contradictoires.

Practical Byzantine Fault Tolerance

Practical Byzantine Fault Tolerance, le plus souvent abrégé en PBFT, est l’un des protocoles BFT les plus connus. Il a été développé par Miguel Castro et Barbara Liskov afin de rendre la tolérance aux pannes byzantines utilisable dans des systèmes informatiques réels.

PBFT fonctionne avec un leader temporaire qui envoie une proposition aux autres participants. Ceux-ci vérifient la proposition et partagent ensuite entre eux s’ils la jugent valide. Ils confirment ensuite qu’un nombre suffisant de participants soutient la même proposition.

Grâce à ces différents cycles de communication, le réseau peut vérifier qu’il existe réellement un accord large. PBFT fonctionne surtout bien avec un groupe relativement restreint de participants connus. Lorsque le groupe grandit, il faut échanger de plus en plus de messages. Le protocole devient donc moins efficace pour des blockchains avec un très grand nombre de validateurs.

Tendermint BFT

Tendermint BFT est utilisé par de nombreuses blockchains de l’écosystème Cosmos. Avec Tendermint, un validateur propose d’abord un bloc. Ensuite, deux tours de vote suivent, durant lesquels les validateurs indiquent s’ils soutiennent le bloc.

Un bloc ne devient définitif que lorsque plus de deux tiers du poids de vote y consentent. Tendermint utilise également un mécanisme de verrouillage (locking). Lorsqu’un validateur constate qu’un bloc bénéficie d’un soutien suffisant, il est, en quelque sorte, verrouillé sur ce bloc.

Le validateur ne peut ensuite pas voter librement pour un bloc en conflit. Cela aide à éviter que, lors de tours différents, deux blocs contradictoires soient approuvés.

HotStuff

HotStuff est un protocole BFT plus moderne qui cherche à appliquer la même idée de base de manière plus efficace. Ici aussi, un leader temporaire propose des blocs et un nombre suffisant de validateurs doit les soutenir.

HotStuff peut résumer le soutien des validateurs dans un quorum certificate. Il s’agit d’une preuve cryptographique qu’un nombre suffisant de validateurs a soutenu la même proposition. Les validateurs doivent toujours envoyer leurs votes, mais le quorum certificate permet de transmettre de manière compacte la preuve de ce soutien large. HotStuff est également conçu pour rendre plus efficaces la communication et la rotation du leader.

Ainsi, il n’est pas nécessaire de traiter systématiquement tous les votes séparés. Le protocole est en outre conçu pour permettre un changement de leader plus rapide lorsque le leader actuel ne fonctionne pas correctement.

Plusieurs protocoles blockchain modernes sont totalement ou partiellement inspirés de HotStuff.

Ethereum

Ethereum n’utilise pas une forme classique de PBFT, Tendermint ou HotStuff. Le réseau utilise le Proof of Stake, où les validateurs votent avec l’ETH qu’ils ont staké. Néanmoins, on retrouve clairement des principes BFT dans la manière dont Ethereum atteint la finalité.

Les validateurs votent sur des points de contrôle dans la blockchain. Un point de contrôle ne devient définitif que lorsque au moins deux tiers de l’ETH total staké le soutiennent.

Lorsque plus d’un tiers du poids de vote ne coopère pas, la finalité peut s’arrêter temporairement. Le réseau choisit alors d’attendre suffisamment de votes fiables, plutôt que de rendre définitives deux versions différentes.

Les validateurs qui votent de manière démontrable pour des versions contradictoires peuvent être sanctionnés. Cela s’appelle le slashing. La sanction économique soutient ici les règles BFT : les validateurs peuvent diffuser de fausses informations, mais ce comportement est visible et peut avoir des conséquences.

Bitcoin

Bitcoin aborde le même problème de base différemment. Le réseau doit également parvenir à un accord alors que les participants ne se font pas entièrement confiance, mais il n’utilise pas pour cela un protocole BFT classique fondé sur le vote.

Bitcoin utilise le Proof of Work. Les mineurs utilisent de la puissance de calcul pour produire de nouveaux blocs, puis les nœuds vérifient si ces blocs sont valides. Les mineurs poursuivent la construction sur la blockchain valide dans laquelle le plus grand cumul de travail de calcul a été investi.

Un bloc n’est alors pas immédiatement définitif. La probabilité qu’il soit annulé diminue à mesure que davantage de blocs sont ajoutés au-dessus. Cela s’appelle la finalité probabiliste.

Bitcoin cherche donc à résoudre le même problème général que les protocoles BFT : comment un réseau conserve-t-il un historique fiable lorsque tous les participants ne sont pas dignes de confiance ? La différence est que Bitcoin utilise la puissance de calcul et des coûts économiques, tandis que les protocoles BFT classiques fonctionnent surtout avec des tours de vote explicites et un seuil de vote élevé.

Que se passe-t-il lorsque les validateurs ne coopèrent pas ?

Ce qui se passe lorsque des validateurs tombent en panne ou agissent incorrectement dépend du poids de vote qu’ils représentent ensemble.

Lorsqu’un petit groupe de validateurs seulement ne coopère pas, les autres validateurs peuvent généralement encore rassembler suffisamment de soutien pour confirmer de nouveaux blocs. Le réseau continue alors de fonctionner normalement, même si tous les validateurs ne sont pas actifs ou fiables.

La situation change lorsque plus d’un tiers du poids de vote total ne participe pas. Dans de nombreux protocoles BFT, le réseau ne peut alors plus réunir le soutien requis de plus de deux tiers. Les nouveaux blocs ne peuvent donc pas être rendus définitifs temporairement. Ce groupe peut ainsi bloquer la progression, mais ne peut généralement pas, à lui seul, faire approuver une version conflictuelle de la blockchain.

Lorsqu’un groupe contrôle plus de deux tiers du poids de vote et coopère, il peut, à lui seul, constituer un soutien suffisant pour confirmer des blocs. Un tel groupe peut donc décider quels blocs valides atteignent la finalité et peut censurer des transactions en ne les incluant pas. Pour rendre définitives deux versions conflictuelles, les validateurs doivent toutefois enfreindre de manière démontrable les règles de consensus, ce qui, dans de nombreux réseaux Proof-of-Stake, peut mener à du slashing.

C’est pourquoi ce n’est pas seulement le nombre de validateurs qui compte, mais surtout la répartition du poids de vote. Une blockchain peut avoir des milliers de validateurs et rester relativement concentrée si un petit nombre d’acteurs détient une grande partie des tokens stakés.

Comment les validateurs malveillants sont-ils sanctionnés ?

Les blockchains Proof-of-Stake peuvent sanctionner les validateurs lorsqu’ils enfreignent de manière démontrable les règles de consensus. Cela s’appelle le slashing.

Un validateur peut, par exemple, être sanctionné s’il vote pour deux blocs en conflit ou s’il tente de soutenir deux versions différentes de la blockchain. Comme chaque vote est signé numériquement, le réseau peut vérifier quel validateur a commis l’infraction.

La sanction diffère selon la blockchain. Un validateur peut perdre des récompenses de staking, perdre une partie de ses tokens stakés, ou être temporairement retiré de l’ensemble des validateurs. En cas d’infractions graves, l’exclusion peut durer plus longtemps ou être permanente.

Le slashing ne rend pas la triche impossible, mais augmente les conséquences financières. Un validateur qui enfreint les règles de consensus risque ainsi de perdre une partie de la valeur qu’il a lui-même engagée.

Quels sont les avantages de la tolérance aux pannes byzantines ?

La tolérance aux pannes byzantines présente plusieurs avantages :

1. Le réseau peut continuer de fonctionner en cas de pannes : tous les validateurs n’ont pas besoin d’être en permanence en ligne ou sans erreur. Tant qu’un nombre suffisant de validateurs continue de fonctionner correctement, le réseau peut traiter de nouveaux blocs.
2. La blockchain conserve un historique partagé unique : la BFT aide à éviter que différents groupes de validateurs rendent définitifs des blocs en conflit. Ainsi, les participants honnêtes continuent de suivre la même version de la blockchain.
3. Les blocs peuvent devenir définitifs rapidement : de nombreux protocoles BFT rendent un bloc définitif dès qu’un nombre suffisant de validateurs le soutient. Les utilisateurs n’ont donc souvent pas besoin d’attendre de nombreux blocs supplémentaires.
4. Le comportement des validateurs est vérifiable : les votes sont signés numériquement. Le réseau peut ainsi voir quel validateur a voté pour quel bloc et si quelqu’un a émis des votes contradictoires.
5. Il n’y a pas besoin de décideur central : les validateurs peuvent déterminer ensemble quels blocs sont valides, sans qu’une seule partie centrale ne prenne toutes les décisions.

Quels sont les inconvénients de la tolérance aux pannes byzantines ?

La tolérance aux pannes byzantines présente également plusieurs inconvénients :

1. Le réseau peut s’arrêter temporairement : lorsque trop peu de validateurs participent, le quorum requis ne peut pas être formé. Le réseau peut alors éventuellement proposer des blocs, mais ne pas pouvoir les rendre définitifs. Les transactions restent ainsi incertaines plus longtemps, et les utilisateurs doivent attendre que suffisamment de validateurs participent à nouveau.
2. Les validateurs doivent échanger beaucoup d’informations : au cours du processus de consensus, les validateurs doivent partager entre eux des propositions, des votes et des confirmations. À mesure que le nombre de validateurs augmente, la quantité de communications augmente également. Cela peut ralentir le réseau et exiger davantage de bande passante et de puissance de calcul.
3. Les protocoles BFT sont techniquement complexes : ces protocoles reposent sur plusieurs tours de vote, des délais d’attente, des leaders temporaires et des règles qui déterminent quand un validateur peut changer de vote. Une erreur dans ces règles ou dans le logiciel peut faire en sorte que les validateurs se bloquent, traitent des informations différentes, ou n’atteignent pas de consensus temporairement.
4. Le poids de vote peut se concentrer : une blockchain peut compter de nombreux validateurs, tandis que quelques grands fournisseurs de staking ou organisations détiennent ensemble une grande partie du poids de vote. Si ces parties contrôlent plus d’un tiers du poids de vote, elles peuvent éventuellement bloquer la finalité. Avec plus de deux tiers, elles peuvent exercer une forte influence sur les blocs confirmés.
5. La BFT ne protège que la couche de consensus : la BFT aide les validateurs à parvenir à un accord sur la blockchain valide, mais ne protège pas tous les éléments du réseau. Par exemple, une transaction peut être confirmée correctement tandis que le smart contract utilisé contient une erreur. La BFT n’empêche pas non plus des wallets piratés, des bridges vulnérables, des informations de prix incorrectes provenant d’oracles, des problèmes sur des plateformes d’échange crypto, ou des pertes liées à des baisses de prix.

En résumé

La tolérance aux pannes byzantines permet à une blockchain de rester fiable lorsque certains validateurs tombent en panne, commettent des erreurs ou diffusent volontairement de fausses informations. Le réseau ne se fie pas à un seul participant, mais utilise notamment des signatures numériques, des tours de vote et un seuil de vote élevé pour parvenir à une décision commune.

La BFT n’est pas un mécanisme de consensus distinct, mais une propriété du processus de consensus. Elle aide à éviter que différentes versions de la blockchain deviennent définitives en même temps, et garantit que le réseau, tant qu’un nombre suffisant de validateurs participe, peut continuer à traiter de nouveaux blocs.

Les blockchains appliquent ces principes de différentes manières. Tendermint utilise plusieurs tours de vote et des règles de verrouillage, Ethereum utilise des règles proches de la BFT pour la finalité, et Bitcoin résout un problème comparable avec le Proof of Work et la finalité probabiliste.

La tolérance aux pannes byzantines ne rend pas une blockchain entièrement protégée contre toutes les erreurs et attaques. Elle constitue néanmoins une base importante pour des réseaux dans lesquels les participants n’ont pas besoin de se faire entièrement confiance, tout en pouvant maintenir ensemble un historique unique et valide des transactions.