Introduction

Le problème des généraux byzantins, également connu sous le nom de problème des deux généraux, a été proposé dans l'article de Leslie Lambert sur la tolérance aux pannes de la communication en réseau distribué pair-à-pair en 1982. Dans la communication du système distribué, certains problèmes locaux peuvent provoquer l'envoi de messages d'erreur par l'ordinateur et détruire la cohérence du système. Par conséquent, le problème des généraux byzantins est essentiellement un problème de consensus dans la communication point à point.

Origine

Le problème des généraux byzantins trouve son origine au Moyen-Âge. En raison du vaste territoire de Byzance, la communication entre les armées ne peut compter que sur des messagers. Si un traître déforme délibérément les informations des chefs d'armée, cela entraînera des plans opérationnels incohérents, ce qui se traduira par les "échecs byzantins".

Pour résoudre ce problème, il existe deux solutions : la première est d'envoyer des messagers les uns aux autres par accord oral, et de parvenir à un consensus à la majorité simple, mais il est difficile de distinguer les traîtres potentiels ; la seconde est d'envoyer des messagers sous forme d'accords écrits pour délivrer des messages écrits avec des signatures exclusives, qui doivent être appuyées par chaque armée, mais si la transmission est trop lente, les signatures peuvent être perdues. Comme ces deux solutions ne peuvent résoudre qu'une partie du problème, et qu'il faut trop de temps et de ressources pour parvenir à un consensus, elles ne sont pas utiles.

Problème des généraux byzantins sur Internet

Le problème des généraux byzantins dans l'Internet signifie que dans le processus de transmission des canaux, il peut être difficile pour certains nœuds de réaliser la synchronisation des informations en raison d'une charge de travail excessive ou de certaines attaques malveillantes. En 1999, Miguel Castro et Barbara Liskov ont proposé la tolérance aux pannes byzantine (BFT). Ils pensaient que si deux tiers des nœuds du système fonctionnaient normalement, la cohérence et l'exactitude du système pouvaient être garanties. Plus tard, Satoshi Nakamoto a proposé le mécanisme de preuve de travail (PoW) et l'algorithme cryptographique asymétrique du Bitcoin, qui a fourni une nouvelle solution au problème des généraux byzantins.

Tolérance aux pannes byzantine

Supposons qu'il y ait n généraux et t traîtres. Disons que n=3, t=1, donc l'un de A, B et C est un traître. Si A donne l'ordre [d'attaquer], mais que le traître B dit à C de [se retirer], alors C ne peut pas prendre de décision ; si le traître B envoie l'ordre [d'attaquer] à A et l'ordre [de se retirer] à C, alors A et C ne peuvent pas parvenir à un accord. Par conséquent, lorsque le nombre de traîtres est supérieur ou égal à 1/3, le problème des généraux byzantins ne peut être résolu.

De même, en supposant que le nombre total de nœuds du réseau est N et que le nombre de nœuds malveillants est T, le problème ne peut être résolu que lorsque N>=3T+1, c'est-à-dire que le nombre de nœuds normaux du réseau est au moins (2/3) N, de manière à garantir la cohérence des informations. Dans une communication réseau fiable, la tolérance aux pannes byzantine peut résoudre le problème de la défaillance d'un nœud dans une certaine mesure, de sorte que le système puisse atteindre un consensus.

Mécanisme de preuve de travail (PoW)

Supposons que le général A donne d'abord l'ordre [d'attaque] et y appose sa signature. Après l'avoir reçu, si d'autres généraux prévoient également d'attaquer, ils suivront l'ordre [d'attaque] et sa signature après l'ordre du général A. Si A n'exécute pas l'ordre [attaque] après l'avoir envoyé, les autres généraux peuvent juger A comme un traître et l'utiliser pour distinguer les bonnes informations.

De même, plusieurs nœuds participants obtiendront un résultat par le biais d'une série de travaux, et le premier nœud qui obtient le résultat le diffusera à l'ensemble du réseau. Si le résultat est correct, les autres nœuds l'ajouteront à leur propre grand livre pour préparer le calcul afin de gagner le droit d'enregistrer les transactions sur la blockchain.

Un Hacker doit disposer de plus de 51% de puissance de calcul pour détruire la sécurité du réseau ou publier de faux blocs. Le coût est bien plus important que le rendement. Par conséquent, ce mécanisme peut réduire la possibilité de fausses informations et permettre au système d'atteindre un consensus plus rapidement.

Algorithmes à clé asymétrique

Le cryptage et le décryptage des algorithmes à clé asymétrique nécessitent deux clés secrètes distinctes - clé publique et clé privée, qui apparaissent généralement par paires. Si A veut envoyer un message à B, A a besoin de la clé publique de B pour crypter l'information, et B a besoin de sa propre clé privée pour décrypter l'information. Si B veut montrer son identité, il peut signer la clé privée, écrire un "texte de signature" et le diffuser. Les autres peuvent vérifier son identité en fonction de la clé publique de B.

L'identité et la signature ne pouvant être falsifiées, les algorithmes à clé asymétrique garantissent la confidentialité de la transmission et de la signature de confiance.