Ceci est une traduction automatique. L’original en anglais est ici: Update 17 November, 2022
La tolérance aux pannes byzantines, basée sur le problème des généraux byzantins, est un must pour les réseaux décentralisés où les nœuds doivent s’entendre même si certains sont malveillants. @dirvine explique ce qu’est BFT et, surtout, ce qui lui manque.
Progrès général
@davidrusu a travaillé sur le découplage d’AE des messages de jointure et a fait de bons progrès là-bas, le code de jointure est un peu plus simple maintenant.
@joshuef envisage également de rejoindre des nœuds et a trouvé des anomalies. Lorsque plus d’un tiers des réponses des anciens ont été reçues, le nœud qui se joint demande à nouveau. Avec cinq anciens, ayant reçu deux réponses, le nœud réessaie et obtient deux autres réponses. Mais à ce stade, il reçoit une réponse pour le premier essai, ce qui provoque une situation de blocage/nœud fantôme.
Il a également réussi à supprimer davantage de verrous, ce qui signifie que les adultes peuvent désormais écrire directement sur le système de fichiers sans aucune étape intermédiaire. Une simplification importante.
Et dans un autre élément de rationalisation, @bzee a refactorisé une partie de qp2p dans une API plus proche de Quinn où aucune structure de données distincte n’est nécessaire pour les connexions ou les flux entrants.
Tolérance aux pannes byzantines
Problème des généraux byzantins en termes réels
Dans le problème des généraux byzantins, une armée a assiégé la ville de Byzance. Les généraux commandant ces forces doivent décider du moment de l’attaque. Si tous les généraux mènent leurs forces pour attaquer la ville en même temps, la victoire est assurée, mais s’ils attaquent à des moments différents, ils perdent. Les généraux n’ont pas de communication directe entre eux et les porteurs de messages peuvent être des espions ennemis, peuvent être tués par les forces en défense ou les messages eux-mêmes peuvent avoir été modifiés. De plus, bien sûr, certains des généraux eux-mêmes pourraient être des traîtres. Comment les généraux s’assurent-ils que leurs forces attaquent toutes en même temps ?
C’est le problème que les réseaux décentralisés doivent surmonter.
En appliquant l’analogie aux systèmes décentralisés, nous obtenons :
- Généraux fidèles ==> nœuds honnêtes
- Généraux traîtres ==> nœuds défectueux
- Enemy Army, nous envoyons des messages via ==> réseau asynchrone peu fiable qui peut abandonner et retarder les messages
Cette histoire est une couverture digeste pour des calculs assez lourds dans lesquels il s’avère que tant que pas plus d’un tiers des généraux sont traîtres, les généraux honnêtes peuvent coordonner leurs plans avec succès - Tolérance aux fautes byzantines (BFT).
Nous avons plusieurs nœuds, dont certains peuvent être malhonnêtes et certains peuvent subir des échecs de communication entre eux.
Le problème classique des généraux byzantins est celui de la synchronisation des états locaux * en dépit * des généraux traîtres qui tentent de faire diverger les états. Pour l’élargir un peu, ATTACK et RETREAT seraient des réponses correctes (valides)… tant que toutes les forces loyales font de même.
Pour nos besoins, le problème classique des généraux byzantins est une vision contrainte de BFT. Il se concentre uniquement sur le consensus et doit donc traiter davantage de types de défauts.
Il existe d’autres notions de BFT que nous pouvons examiner à la place pour gérer les problèmes d’adhésion.
Ici, le problème est que nous avons une fourchette. Lorsque les adultes et les aînés quittent ou rejoignent les nœuds, ils peuvent avoir des vues différentes de la section. Bien que ce fork finisse par être résolu, les décisions prises lors de la vue fractionnée, par ex. une dépense DBC, sont difficiles à gérer. Ainsi, nous essayons d’éviter cette vision partagée par le consensus.
Une option sur laquelle Mostafa et @Davidrusu travaillent est un protocole de diffusion appelé Verifiable Consistent Broadcast (VCBC).
Protocoles de diffusion BFT
Un protocole de diffusion tente de diffuser un message d’un nœud au réseau. La version BFT essaie de s’assurer que tous les nœuds sont d’accord sur le message que ce nœud a envoyé :
Sur la gauche, nous avons un nœud honnête 1 diffusant msg à 2,3,4,5. Sur la droite, nous avons un nœud défectueux 1 diffusant a vers 2,3 et b vers 4,5.
Un protocole de diffusion BFT protège contre le fork dans le second cas en s’assurant que tous les nœuds honnêtes acceptent le même message du « nœud 1 » ou qu’ils refusent tous d’accepter tout message du « nœud 1 ».
Cela se fait dans VCBC via un protocole en 3 phases :
- Le nœud 1 diffuse le message qu’il veut que tout le monde voie
- Tous les nœuds vérifient si c’est la première fois que le nœud 1 envoie un message, si c’est le cas, répond avec un partage de signature sur le message :
sigma_j(m) - Le nœud 1 attend jusqu’à ce qu’il reçoive > 2/3 des partages de signature pour les agréger en une signature complète, puis diffuse la signature complète sur le réseau pour convaincre tout le monde qu’ils ont tous le même message.
Regardons comment cet algorithme se décompose.
VCBC s’appuie de manière cruciale sur plus des 2/3 du réseau suivant fidèlement le protocole. Nous pouvons nous demander : « Quel dommage peut être causé si 1/3 ou plus des nœuds sont défectueux ? »
Si plus de 1/3 mais moins de 2/3 + 1 sont défectueux, alors le pire qu’ils puissent faire est de bloquer le filettravailler en refusant d’apporter des actions de signature.
Si plus de 2/3 sont défectueux, alors les nœuds défectueux peuvent faire des signatures sur n’importe quel message qu’ils aiment.
Cependant, ce fait n’est vrai que si les nœuds BFT s’entendent. c’est-à-dire que s’ils ne sont pas le même attaquant, ils n’ont pas autant d’importance. Ils ne créeront pas de fork.
Ainsi, un élément essentiel de l’évitement du BFT est le mot COLLUSION.
Une grande expérience mentale résout le problème BFT en ayant BEAUCOUP d’attaquants. De cette façon, l’attaquant unique en collusion est dilué par d’autres attaquants et des nœuds honnêtes.
Qu’est-ce que cela signifie dans la vraie vie ?
Si l’on considère l’esprit d’un attaquant. Que préférerait-il ?
- Le réseau fonctionne toujours
- Son ennemi a pris le contrôle du réseau
De toute évidence, la réponse est que le réseau fonctionne toujours honnêtement. Ainsi, à moins qu’un attaquant n’ait le contrôle majoritaire (2f + 1, où f = le nombre de nœuds malveillants en collusion), il ne peut pas prendre le contrôle du réseau.
Donc, si nous avons N==9 et des nœuds d’attaque==9 mais des nœuds de collusion==0, alors nous n’avons aucun problème ?
Donc, 100 % des nœuds étant des attaquants, c’est OK.
Ce n’est que lorsque nous avons des nœuds défectueux en collusion que nous avons des problèmes. Il y a deux façons/seuils en jeu ici. Si nous considérons un attaquant complice, les seuils sont :
- L’attaquant contrôle >=1/3 nœuds
- L’attaquant contrôle >=2f+1 nœuds.
1 Est une attaque de vandalisme où il peut bloquer les décisions et le réseau.
2 Est-ce une reprise de la section au moins.
La perspective compte donc ici. Plus nous avons d’attaquants, plus notre réseau est sécurisé ! Nous pouvons réduire l’influence d’un attaquant en ayant de nombreux attaquants et/ou de nombreux nœuds honnêtes.
Qu’est-ce donc que l’attaque BFT sur un protocole de diffusion
Lorsque nous parlons d’une attaque BFT, nous parlons d’un attaquant complice. Les attaquants individuels vont bien.
Nous pouvons tolérer moins d’1/3 de mauvais nœuds en collusion. Alors qu’il peut y avoir de nombreux nœuds défectueux, nous sommes protégés tant qu’aucun groupe de collusion ne dépasse 1/3 des décideurs (pour caler) ou 2f+1 pour créer un fork (prise de contrôle).
Liens utiles
- Site Web du réseau sécurisé
- Safe Network Primer
- Principes de base du réseau
- Feuille de route
- Glossaire
N’hésitez pas à répondre ci-dessous avec des liens vers les traductions de cette mise à jour de développement et les modérateurs les ajouteront ici.
En tant que projet open source, nous sommes toujours à la recherche de commentaires, de commentaires et de contributions de la communauté. Ne soyez donc pas timide, rejoignez-nous et créons ensemble le réseau sécurisé!