Byzantine Fault Tolerance, ou BFT pour son acronyme en anglais, est l'un des concepts les plus importants de la blockchain et peut-être l'un des moins connus. Sans cela, la technologie blockchain telle que nous la connaissons ne serait pas possible.
El terme de faute byzantine, dérive de Problème des généraux byzantins (PGB). Ce problème logique suppose, en un mot, que les parties prenantes doivent s'entendre sur une stratégie concertée pour éviter une défaillance catastrophique du système. Mais il est possible que certains acteurs du système ne soient pas fiables. Compte tenu de ce fait, le système doit créer des mécanismes garantissant que ces acteurs malveillants ne peuvent conduire à l'échec sans aucun autre remède. La création de ces mécanismes est précisément ce qui donne la tolérance aux fautes byzantines.
Cela peut paraître simple, mais la réalité est très différente. Atteindre la tolérance aux pannes byzantine est l'un des défis les plus difficiles de l'informatique. Au point que la première conception à le résoudre de manière satisfaisante a été le Bitcoin, de Satoshi Nakamoto. Cela a marqué une étape importante, qui a accompagné la technologie blockchain jusqu'à présent.
La Tolérance aux pannes byzantines, est la capacité d'un système informatique distribué à résister aux défauts byzantins.
Ces défauts peuvent être:
- Échecs du consensus.
- Échecs de validation.
- Échecs de vérification des données.
- Échecs du protocole de réponse face aux situations réseau.
Cette tolérance est liée à la capacité que le réseau, dans son ensemble, peut créer un mécanisme de consentement. Le but est de donner une réponse cohérente à la défaillance du système.
Comment fonctionne la tolérance aux pannes byzantine?
Tolérance aux pannes byzantines fonctionne en définissant un ensemble de règles permettant de résoudre le problème des généraux byzantins d'une manière satisfaisante. La réalisation de cet objectif est complexe, car ce type de défaillance n'implique aucune restriction. Cette situation rend le problème plus complexe et difficile à traiter. Cependant, dans de nombreux systèmes informatiques, cette tolérance est une exigence. Par conséquent, pour atteindre cet objectif, un système byzantin tolérant aux pannes doit au moins remplir les conditions suivantes:
- Chaque processus doit être démarré avec un statut indécis (ni OUI, ni NON). À ce stade, le réseau propose une série de valeurs déterministes applicables au processus.
- Pour partager les valeurs, un moyen de communication doit être garanti. Ceci afin d'afficher les messages en toute sécurité. Le support servira également à communiquer et à identifier les parties sans équivoque.
- Arrivés à ce point, les nœuds calculent les valeurs et passent à un état décidé (OUI ou NON). Chaque nœud il doit générer son propre état, qui s'inscrit dans un processus purement déterministe.
- Une fois décidé, total et remporte l'État avec le plus grand nombre de décisions favorables.
Ces quatre points définissent le fonctionnement de base d'un algorithme byzantin tolérant aux pannes.
Une explication plus détaillée
Certes, le cas précédent peut être un peu complexe. Par conséquent, une explication plus simple appliquée à la blockchain serieuse:
Imaginons que Juan effectue une transaction Bitcoin.
Chaque nœud sur le réseau, il commence la compilation de la transaction dans un état indécis (TX non confirmé). La confirmation de cette transaction passe par un travail de minage (notre protocole de consensus). Le processus d'extraction vérifie que le hachage de la transaction est correcte et l'inclut dans un bloc.
Ce processus de vérification est intensif en calculs et n'est possible que par des moyens déterministes. A chaque nouvelle confirmation (statut décidé) de la transaction donnée par la majorité du réseau, Juan peut être sûr que la transaction a été considérée comme valide.
Cas d'utilisation de la tolérance aux pannes byzantine
Tolérance aux pannes byzantines a la capacité de résoudre divers problèmes. Parmi ceux-ci, nous parlerons de certains des plus pertinents pour comprendre un peu plus sa large utilité:
Cas n ° 1: utilisation dans des compilateurs de logiciels
Un compilateur Le code source est l'un des outils informatiques les plus complexes que l'on puisse connaître. Les compilateurs ont la capacité de convertir le code source d'un programme en un binaire capable d'être exécuté par l'ordinateur. Cela signifie qu'ils convertissent quelque chose de proche du langage humain (comme C / C ++ ou Go) en langage machine ou binaire.
Au milieu de tout cela, les compilateurs "Coquilles" sa capacité en plusieurs sous-programmes à pouvoir effectuer les actions suivantes:
- Traduire le code source vers l'architecture de processeur souhaitée. Par exemple, nous pouvons décider de compiler pour x86-32 (PC) ou ARM (mobile). Dans cet exemple, nous choisissons x86-32.
- Ajuste les paramètres aux capacités de la famille ou de la génération de processeurs cible. Un point à prendre en compte, car le code d'une génération supérieure peut ne pas être exécuté dans une précédente. À ce stade, nous avons décidé de coder pour les Core i3 de 2e génération.
- Il commence à compiler le code et tous les sous-programmes le transforment en code machine. En parallèle, les applets décident où optimiser et quelles optimisations appliquer au code. Le résultat final est notre programme déjà compilé et prêt à être exécuté.
Dans ce processus, la tolérance aux pannes byzantine est vitale, car elle garantit ce qui suit:
- Que les applets s'appliquent correctement les paramètres et optimisations pour l'architecture et la génération choisies. Le non-respect de cette consigne entraînera des erreurs et un échec du résultat final.
- Appliquer des optimisations doit s'assurer qu'ils ne signifient pas duplication des données. Mais la déduplication au niveau binaire ne devrait pas non plus affecter le fonctionnement des parties du binaire. À ce stade, une analyse des défauts byzantins est nécessaire et les compilateurs devraient pouvoir l'analyser.
Cas n ° 2: Systèmes de stockage de données
Un autre cas d'utilisation de la tolérance aux pannes byzantine, applique la Systèmes de stockage de données. De nombreux systèmes de bases de données et même des systèmes de fichiers l'implémentent pour améliorer la fiabilité des données stockées. Un exemple de ceci est le système de fichiers ZFS. Ce système d'archivage est capable de répliquer le hachage avancé, la réplication, la déduplication, la correction d'erreurs, la gestion et le stockage de grandes quantités de données.
Pour y parvenir, ZFS utilise des schémas de tolérance aux pannes byzantins pour garantir:
- La pas d'omission de processus élémentaires pour lui traitement des données stockées ou en étant stocké dans le système de fichiers. Par exemple, l'application de hachages aux données et métadonnées, la compression, la correction d'erreurs ou la déduplication de celles-ci.
- Qu'aucune mesure indésirable n'est prise dans le traitement des données. En tant que déduplication qui entraîne une perte de données dans le système. Ou un correctif de bogue qui endommage les informations.
- Les créer, lire et écrire des processus dans des structures ZFS imbriquées Ils utilisent ces types de techniques pour s'assurer qu'elles sont cohérentes à tout moment.
Grâce à tout cela, ZFS conserve les données stockées dans sa structure en toute sécurité. C'est pourquoi il est connu comme le système de fichiers le plus sécurisé et le plus avancé du monde informatique.
Cas n ° 3: Systèmes avioniques
C'est le cas du système de gestion de l'information aéronautique. Un système qui fonctionne en temps réel et est tolérant aux défauts byzantins.
Chacun des capteurs de l'avion communique avec les systèmes de commande et de contrôle, fournissant des informations en temps réel. La défaillance d'un capteur ne doit à aucun moment entraîner une défaillance catastrophique de l'aéronef. Pour y parvenir, on utilise la tolérance aux pannes byzantine. Ceci afin de compenser les données des capteurs ou les systèmes endommagés et assurer la sécurité de l'avion.
En fait, appliquer la tolérance aux pannes byzantine à ce stade est tout un défi. En raison du nombre de systèmes et des différents scénarios à gérer. L'avionique doit prendre en compte des cas tels que la reconfiguration, la duplication, la panne de systèmes entiers, et toujours offrir une résistance à ces types de pannes. Si une résistance à 100% est impossible, les ingénieurs et les programmeurs font un travail formidable à cet égard.
Cas n ° 4: protocoles de consensus blockchain
Protocoles de consensus dans la blockchain comme PoW ils tolèrent les fautes byzantines. Celles-ci permettent à un réseau distribué d'atteindre un consensus dans des conditions byzantines. Quand Satoshi Nakamoto a conçu Bitcoin, pris en compte ce type de tolérance. Pour ce faire, il a créé une série de règles et appliqué le protocole de consensus PoW pour créer un logiciel byzantin tolérant aux pannes. Cependant, cette tolérance n'est pas de 100%.
Malgré cela, PoW s'est avéré être l'une des implémentations les plus sûres et les plus fiables pour les réseaux blockchain. À cet égard, l'algorithme de consensus de preuve de travail, conçu par Satoshi Nakamoto, est considéré par beaucoup comme l'une des meilleures solutions aux fautes byzantines. PoS y DPoS pour leur part, ils ne tolèrent pas totalement les fautes byzantines, c'est pourquoi ils sont généralement complétés par d'autres mesures de sécurité.
Avantages et inconvénients
Avantages
- Capacité à garantir l'exactitude des données et des informations, dans des systèmes distribués. Ceci même dans des scénarios hostiles pour de telles tâches.
- Il résout le problème du traitement de l'information dans des environnements hétérogènes.
- Haute efficacité en termes de calcul et d'énergie.
- Il propose des implémentations qui ont un impact positif sur l'évolutivité si elles sont bien construites.
- Plus il y a de nœuds appliquant la tolérance aux pannes byzantine, plus le modèle est sécurisé.
Inconvénients
- La création de ces solutions est complexe. Cela peut verrouiller d'autres problèmes de sécurité dans votre implémentation.
- Garantir son bon fonctionnement nécessite que la distribution du système se développe. Plus il y a de nœuds appliquant le processus, plus il est sécurisé. Mais cela a également un impact négatif sur l'évolutivité et la bande passante du réseau.