Pour établir la technologie blockchain, les casse-têtes complexes qui avaient jadis déconcerté le monde de la technologie ont été résolus. L’un de ces obstacles était le problème de tolérance aux pannes Byzantines (BFT). Pour mieux le comprendre, voyons de quoi il s'agit.
Toute technologie de registre distribué, ou technologie blockchain, repose sur l'hypothèse de base que le système doit être tolérant aux défaillances et doit continuer de fonctionner même lorsque les nœuds dévient de leur comportement normal. Cette déviation peut être non malveillante, comme une panne d’un nœud ou l’absence de réponse d’un nœud, ce qui peut arriver si le nœud n’a pas reçu le message en raison de défauts dans le protocole de communication ou si le nœud est hors ligne.
Donc, en termes de tolérance aux pannes, toute technologie de registre distribué peut être :
Système simple tolérant aux pannes ou tolérance aux pannes de plantage (CFT) : Ce type de mécanisme empêche le système de tomber en panne lorsque le(s) nœud(s) s’éteignent ou sont hors ligne. Il ne s'occupe pas des nœuds qui agissent de façon malveillante ou arbitraire. Un système simple tolérant aux pannes n’est pas très utile dans un environnement non contrôlé.
Système tolérant aux pannes Byzantines : Dans un système distribué décentralisé, comme la blockchain, les participants communiquent souvent entre eux dans un système ouvert, non contrôlé et sans permission. Leurs actions peuvent varier selon leurs intérêts individuels et peuvent être malveillantes. Un système conforme BFT assure qu’il continuera de fonctionner même si des nœuds défaillent ou sont malveillants.
Le problème Byzantin
Le problème Byzantin est défini dans un article publié par Leslie Lamport, Robert Shotak et Marshall Pease en 1982. L’article s’intitulait The Byzantine Generals Problem. Il présentait une allégorie pour illustrer les problèmes de consensus dans un système décentralisé.
L’allégorie est la suivante : « Avant la bataille, les généraux byzantins, qui commandent différents bataillons, essaient de décider s’ils doivent attaquer ou battre en retraite. Cela doit être réalisé en échangeant des messages par l’intermédiaire de messagers et en parvenant à un accord. Cependant, il y a un problème. Il est possible que certains généraux et/ou messagers soient des traîtres à la cause. Ces généraux et messagers traîtres peuvent modifier le message et transmettre une réponse malveillante, sabotant ainsi les plans des généraux loyaux. Donc, les généraux loyaux doivent trouver une façon d’atteindre un consensus en tenant compte de cette situation.
Dans le cas de la technologie blockchain ou d’un registre distribué, l’allégorie ci-dessus se traduit par un environnement où les généraux sont remplacés par des nœuds et les messagers par les connexions ou protocoles de messagerie.
Avec le temps, des tentatives ont été faites pour proposer une solution à ce problème centré sur les réseaux distribués ou la blockchain. Aujourd’hui, on dispose de nombreuses solutions pour les réseaux distribués qui donnent une réponse partielle sinon complète à cette question. Dans la blockchain, divers mécanismes de consensus (protocoles pour parvenir à un accord dans un système distribué) sont conçus pour traiter intrinsèquement le problème Byzantin.
Avant de discuter des solutions, comprenons comment la technologie blockchain ou les systèmes de registre distribué atteignent le consensus et les exigences similaires dans toute technologie distribuée.
Consensus dans un système distribué
Dans tout réseau distribué, en partant du même état de valeur initial, les nœuds doivent se mettre d’accord sur une valeur de sortie particulière lors d’une transition d'état. C’est ce qu’on appelle atteindre un consensus. Cela doit être réalisé même si les nœuds peuvent dévier et agir soit de façon non malveillante (plantage ou hors ligne), soit de façon malveillante (Byzantine).
Le processus arrive à un consensus si :
Les nœuds se décident sur une valeur de sortie
Cette approche déterministe confirme la terminaison, ou
La majorité des nœuds s’accorde sur la même valeur de sortie
Cela confirme l’accord.
Maintenant, ayant compris les bases du consensus, voyons comment les grands mécanismes de consensus blockchain s’y prennent pour y faire face. Les divers mécanismes de consensus déployés dans les solutions blockchain existantes traitent intrinsèquement du problème BFT, même si les probabilités de réussite varient.
La tolérance pratique aux pannes Byzantines (PBFT), la preuve de travail (PoW) et la preuve d’enjeu (PoS) sont certains des principaux algorithmes de consensus actuellement utilisés qui atteignent la BFT et sont utilisés dans les systèmes blockchain d'aujourd'hui. Jetons un bref coup d’œil sur PBFT et PoW sous l’angle du BFT.
PBFT (tolérance pratique aux pannes Byzantines)
Un article sur PBFT publié en 1999 par Miguel Castro et Barbara Liskov décrit un algorithme pratique pour la réplication de machine d’état qui tolère les pannes Byzantines. L’algorithme offre à la fois la vivacité (le client reçoit finalement les bonnes réponses à ses requêtes) et la sécurité, pourvu que :
- Au maximum « (n-1)/3 » nœuds soient défaillants sur « n » nœuds
- Le délai « t » ne croît pas plus vite qu’indéfiniment.
Ici, le délai est le temps entre le moment où le message est envoyé pour la première fois et le moment où il est reçu par la destination (en supposant que l’expéditeur continue de retransmettre le message jusqu’à réception).
Explication de 3f+1
Si « f » nœuds échouent de façon Byzantine, le système doit gérer deux types de problèmes. Le premier est de ne pas envoyer du tout le message, le second est d’envoyer malicieusement un message différent. Donc, le système doit fonctionner correctement après « (n-f) » nœuds. Cependant, il est possible que les « f » répliques qui n'ont pas répondu ne soient pas défaillantes et que les « f » répliques qui ont répondu soient défaillantes. Si l'on veut que les nœuds non défaillants soient plus nombreux que les défaillants, on a besoin d’au moins « (n-f)-f > f ». Donc, « n > 3f+1 » est optimal.
PBFT est actuellement utilisé dans Hyperledger Fabric avec le système d’ordonnancement Kafka. Kafka fournit la tolérance aux pannes de plantage et la finalité. Mais il est important de noter que, tandis que Kafka tolère les pannes de plantage, il n'est pas tolérant aux pannes Byzantines, ce qui empêche le système d’atteindre l’accord en cas de nœuds malveillants ou défaillants.
Preuve de travail (PoW)
Bitcoin intègre la BFT dans son protocole. Le PoW résout le problème des généraux Byzantins en obtenant un accord majoritaire sans autorité centrale, malgré la présence de parties inconnues/potentiellement peu fiables et même si le réseau n’est pas instantané.
Voyons comment Bitcoin fonctionne dans le contexte du problème des généraux Byzantins
Tous les généraux se sont entendus sur un protocole selon lequel un problème complexe doit être résolu afin d’ajouter le message d’attaque. L’énigme cryptographique est difficile pour le général proposant, mais facile à vérifier pour les autres généraux. Tous les généraux auront déjà la configuration structurelle essentielle que la solution doit avoir.
Supposons maintenant, sur le champ de bataille, qu’un général élabore un plan et veuille envoyer un message aux autres pour attaquer un jour et une heure spécifiques avec le plan. Les étapes seraient :
- Il ajoutera un nonce au plan original.
- Il hachera ensuite le plan avec le nonce et verra le résultat. Il continuera d’ajouter le nonce et de vérifier s’il obtient le hachage désiré. Autrement dit, le nombre de nonce ou la solution à l’énigme complexe.
- Il enverra ensuite les messagers aux autres généraux concernés. Même si les messagers sont interceptés, toute modification à leur message mènera à un hachage complètement différent, que les autres généraux pourront facilement repérer.
- Les autres vérifient finalement le plan et agissent en conséquence.
La tolérance aux pannes Byzantines est de 50 % en supposant une latence réseau nulle. Elle est d’environ 46 % (Ethereum) et 49,5 % (Bitcoin) avec des conditions observées en pratique, mais diminue à 33 % si la latence équivaut au temps de bloc et tend vers zéro quand la latence réseau approche l’infini.
La solution ne peut échouer que si la partie malveillante capture 50 % de la puissance du réseau.
Conclusion
Avec bitcoin, Satoshi Nakomoto a ouvert la voie permettant aux acteurs du système distribué de continuer de repousser les frontières de la recherche sur les protocoles de consensus. Bien que PoW, PBFT et PoS soient assurément les mécanismes de consensus les plus répandus, de nombreux autres mécanismes comme la preuve d’enjeu déléguée (DPOS), la preuve du temps écoulé (PoET) et les graphes acycliques dirigés (DAG), entre autres, émergent et abordent la question du BFT, même si le succès varie. Nous n'avons pas encore de mécanisme de consensus parfait, et s’il est peu probable que nous en ayons un, il sera intéressant d’examiner de nouveaux algorithmes de consensus à l’avenir.
À propos de la pratique des services blockchain chez HCLTech
Les services Blockchain de HCLTech constituent une pratique axée sur les solutions, fondée sur les valeurs fondamentales de HCLTech et soutenue par un réseau d’experts de l’industrie possédant une vaste expérience sectorielle. La plateforme CoTrustMC est un atout clé, offrant des solutions et des accélérateurs pour aider les entreprises à faire progresser leur parcours blockchain.
HCLTech fournit des services de conseil, d’accompagnement et des services infonuagiques pour la blockchain à l’aide de cadres éprouvés pour concevoir et mettre en œuvre des programmes blockchain, rationalisant les opérations dans des secteurs comme les services financiers, le transport maritime et la logistique. CoTrustMC réduit le temps, les coûts et les risques en offrant des capacités fondamentales et des cas d’usage réutilisables tels que la provenance, le suivi et le traçage, les paiements, la KYC décentralisée, la tokenisation et la gestion des essais cliniques.
HCLTech est le premier à lancer des solutions blockchain sur les places de marché infonuagiques. La plateforme CoTrustMC est offerte en mode SaaS pour divers secteurs d’activité et en version PaaS sur AWS et GCP pour une mise en œuvre rapide et évolutive de la blockchain.
