Table des matières
ToggleVous souvenez-vous de la scène de mariage typique entre la protagoniste et son homme principal dans un feuilleton ou un film, où, sortant de nulle part, le public dit « Je m’oppose » et le cours de l’histoire change alors complètement ? Les failles byzantines fonctionnent de manière très similaire.
Même si, bien sûr, dans ces cas-là, le protagoniste décidait avec qui rester, malgré les défauts de chacun, pour finalement parvenir à un accord avec les deux parties pour aboutir à une fin typique d’une production cinématographique Disney. C’est à ce stade, que nous allons nous concentrer et commencer à parler de la tolérance aux fautes byzantines, un système informatique qui, bien qu’il ne soit pas aussi romantique et fantastique qu’un film d’amour, est une solution idéale et largement utilisée dans la technologie blockchain des crypto-monnaies.
Nous pouvons la définir comme la capacité d’un système informatique distribué à atteindre un consensus suffisant et à fonctionner correctement, malgré des composants malveillants ou des bogues (nœuds) dans le système qui tombent en panne et diffusent des informations incorrectes. En d’autres termes, il s’agit d’un protocole de consensus approprié pour éviter une défaillance catastrophique du système. Un exemple pratique serait d’éviter de croire les ouï-dire de ses voisins et d’essayer de garder un point de vue objectif sur les informations de telle ou telle personne.
Actuellement, nous pouvons trouver différents projets qui utilisent la pratique de la tolérance aux pannes byzantine: Hyperledger Fabric de la Fondation Linux et Zilliqa, un projet asiatique connu pour sa crypto ZIL.
En effet, les expressions « défaillance byzantine » et « tolérance de défaillance byzantine » dérivent du problème des généraux byzantins qui, dans le domaine de la technologie et de l’informatique, est un dilemme complexe et bien documenté, malgré son histoire facile à comprendre.
Pendant la guerre, les généraux doivent décider s’ils doivent attaquer ou battre en retraite devant l’ennemi. Dans une telle situation, il ne manque pas de généraux qui préfèrent attaquer et donner leur cœur jusqu’au bout, tandis que d’autres préfèrent battre en retraite. L’important est évidemment de parvenir à un accord commun, car une attaque désorganisée se solde par une défaite.
Le problème réside dans la présence d’espions ou de traîtres, comme dans Among Us, qui veilleront à leurs propres intérêts. Pour le comprendre, imaginons que nous soyons dans cette situation : nous sommes neuf généraux des forces armées espagnoles et l’inquiétude de nos ennemis est de plus en plus latente, nous décidons donc d’organiser une réunion pour voter sur ce que nous allons faire: attaquer ou nous défendre.
Sur les neuf d’entre nous, quatre acceptent de se retirer et quatre acceptent d’attaquer. La décision revient à ce neuvième général, qui est peut-être un traître. C’est là que se situe le problème, car il a la décision absolue: on attaque ou on se retire.
Maintenant, à cela nous pouvons ajouter un autre problème de communication et c’est que nous pensons que physiquement nous n’étions pas ensemble, mais nous avons décidé d’envoyer des lettres avec notre décision, qui peuvent être falsifiées ou non délivrées par les messagers. C’est dans ces circonstances, comme solution possible, que la tolérance aux pannes byzantine entre en jeu. Mais nous allons développer ce point dans le point suivant.
Pour en revenir à l’exemple ci-dessus, face au problème des traîtres et des messagers qui peuvent retenir ou déformer l’information (en d’autres termes, une faute byzantine), la tolérance aux fautes byzantine établirait un système avec des mécanismes de consensus qui garantissent que les traîtres ne peuvent pas conduire à une faute.
Il garantit ainsi l’accord de la majorité des généraux loyaux et évite, dans le cas du mariage oscarisé, que la protagoniste et son beau prétendant ne soient séparés. Bien entendu, pour cela, des règles doivent être définies par le système.
Faisons connaissance avec les règles les plus courantes de la tolérance aux pannes byzantine. Imaginons que nous sommes dans un processus de minage et que nous voulons effectuer une transaction sur une blockchain, en utilisant une méthode de tolérance aux pannes byzantine. Dans cette circonstance, nous observerons quatre phases:
En commençant par ses avantages, pBFT n’a pas besoin de confirmations multiples, ni de période d’attente pour s’assurer qu’une transaction est sécurisée ou valide après son inclusion dans un bloc, puisque cela se fait rapidement.
En outre, il peut atteindre un consensus sans nécessiter une utilisation excessive d’énergie pour les mineurs, assure une communication efficace au sein du réseau et réduit la variation des récompenses pour les mineurs.
Cependant, elle présente certains inconvénients. Parmi elles, nous pouvons constater qu’elles sont vulnérables aux attaques Sybil, qui sont exécutées par la même entité contrôlant les entités du réseau et corrompant le système. En outre, il n’évolue pas correctement, car il y a une surcharge de communication interne et il faut beaucoup de temps pour répondre à une demande.
Il ne fait aucun doute que, dans le contexte des cryptomonnaies, il est essentiel de disposer d’un système sûr, efficace et rapide pour l’exécution des transactions et autres procédures caractéristiques d’une blockchain.
Par conséquent, la tolérance aux pannes byzantine s’est imposée comme une bonne option et une proposition convaincante par rapport à d’autres algorithmes tels que le consensus PoS (proof of stake), PoW (Proof of Work) et Pol (Proof of Importance).
Félicitations pour être allé jusqu’au bout!
De la part de l’équipe de Bitnovo, nous souhaitons « récompenser » votre intérêt pour cet article. Ainsi, en guise de cadeau symbolique, vous aurez accès au dernier blog Bitnovo, entièrement gratuit et sans date d’expiration, afin de continuer à être informé des dernières nouvelles sur les cryptos par les meilleurs auteurs en la matière.
Dans le lien souligné, vous pouvez consulter l’ensemble de notre contenu !
Pour l’instant, rendez-vous dans un prochain article.