Ceci est une traduction automatique. L’original en anglais est ici: Update 24 November, 2022
Poursuivant nos progrès dans l’adaptation des protocoles de consensus de réseau décentralisé à nos fins, dans ce cas la gestion de l’adhésion à la section, Mostafa nous emmène cette semaine à travers ABBA et MVBA. ABBA est un protocole de retournement de pièces pour un accord binaire. Si une section a besoin d’un autre adulte, les anciens peuvent choisir un seul nœud pour empêcher l’adhésion massive, tandis que MVBA est utilisé pour décider entre des propositions concurrentes, telles que les nœuds qui devraient être les anciens dans la prochaine itération de la section.
Progrès général
@roland a travaillé dur sur un nouvel utilitaire TestNetwork qui facilitera la configuration de l’environnement pour les tests de nœuds. Nous pouvons dire au constructeur de générer un réseau avec un SAP spécifique dans un préfixe et il créera un réseau fonctionnel et configurable avec toutes les lacunes remplies. @oetyng refactorise maintenant pour permettre certains tests de bout en bout qui avaient été désactivé après le travail de flux bidirectionnel, qui était bloqué depuis un certain temps.
@chriso a actualisé notre configuration AWS et nous vérifions maintenant comment en tirer parti au mieux lors des relations publiques (pour obtenir plus de rapidité et de fiabilité pour certains tests).
@joshuef et @roland continuent de réduire le nombre de verrous en écriture que nous prenons sur l’état du nœud. Ce sont des messages à envoyer entre les anciens et les clients les contactant pour s’assurer que le client dispose d’informations à jour sur la section avant d’essayer de faire une demande. Ces verrous en écriture sont un autre endroit où nous pouvons bloquer l’exécution du code et ralentir un nœud. Ils sont également une complication inutile et une source potentielle de bogues. Nous ne verrouillons désormais que les messages AE qui réellement nous mettent à jour (auparavant, c’était tous les messages AE). Nous ne verrouillons plus non plus lors de la réplication des données ou du suivi des dysfonctionnements. Nous sommes donc beaucoup plus proches d’un état de « nœud » léger/sain, qui n’a besoin que d’un accès en « écriture » pour un petit sous-ensemble de tâches liées à la connaissance du réseau.
En plus de ce travail, @bochaco travaille également sur la messagerie AE et la suppression de la logique redondante dans la gestion AE du client.
ABBA et MVBA
Protocole ABBA
ABBA ou Asynchronous Binary Byzantine Agreement est un moyen de résoudre le problème du consensus dans les réseaux asynchrones. En particulier, ABBA peut être utilisé pour décider d’une question oui/non en groupe.
Dans ce protocole, chaque partie commence par diffuser sa préférence (oui/non). S’il n’y a pas de majorité pour les valeurs initialisées, les parties lancent un schéma de tirage au sort à seuil qui produira un résultat aléatoire sur lequel tous peuvent s’entendre. ABBA est un protocole non déterministe, sa sortie est un nombre aléatoire. Si nous rejouons les événements d’entrée, nous pourrions obtenir une sortie différente.
La cohérence est assurée par VCBC. Comme couvert la semaine dernière, VCBC est un protocole de diffusion qui tente de diffuser un message d’un nœud au réseau, tous les nœuds étant d’accord sur le message envoyé par le nœud. Le protocole VCBC peut être modifié afin de n’accepter que les propositions valides et correctes.
Nous utilisons VCBC pour nous assurer que les messages diffusés par les nœuds sont valides. VCBC est simplement un contrôle de validation. Ainsi, si un aîné diffuse une proposition selon laquelle un autre nœud devrait être admis dans la section, les autres nœuds peuvent s’assurer que l’aîné n’est pas corrompu ou défectueux et la proposition doit être prise au sérieux.
Après cela, nous pouvons utiliser des séries d’ABBA pour parvenir à un accord via un schéma de signature de seuil qui se poursuit jusqu’à ce que la majorité des anciens parviennent à un consensus. ABBA terminera toujours. Il produira toujours une valeur binaire aléatoire qui est utilisée pour prendre la décision. Si nous avons suffisamment de voix, nous pouvons nous engager sur la proposition.
L’ordre des anciens compte. Imaginez que les anciens soient ordonnés comme ceci : [3,5,7,2,1]
et 3 est hors ligne. Après VCBC, nous avons des propositions [-,P5,P7,P2,P1] La première proposition est P5. Nous exécutons ABBA pour P5. Nous savons que P5 est valide et que tous les anciens l’ont (diffusé de manière cohérente), donc cela devrait être décidé après un certain temps.
La notion de validité plus faible
Nous prenons ces algorithmes vanille et les modifions pour nos besoins. Étant donné que VCBC a déjà validé les messages pour nous, nous pouvons simplement exiger qu’une partie honnête ne puisse décider que d’une valeur pour laquelle elle dispose des données de validation qui l’accompagnent. Sinon, il est rejeté.
Cela nous permet de simplifier le protocole ABBA.
Protocole MVBA
Le protocole de l’accord byzantin multi-valeurs (MVBA) est utilisé lorsqu’il y a plus d’une proposition pour parvenir à un consensus .
Nous pouvons l’utiliser lorsque plusieurs anciens partent ou que plusieurs adultes deviennent éligibles à une promotion en même temps, il existe donc un certain nombre de versions possibles de la prochaine itération de la section.
Dans ce scénario, chaque partie diffuse systématiquement ses propositions via VCBC et après avoir reçu suffisamment de propositions de parties honnêtes (valides), le protocole commence à exécuter un accord binaire (en utilisant ABBA) par proposition. Lorsque la première proposition obtient ddécidé que le processus se termine.
Problème d’adhésion
Alors, qu’est-ce que tout cela essaie de résoudre? Il s’agit de la promotion et de la rétrogradation des anciens. Ce processus doit se produire avec l’accord d’une super-majorité des anciens honnêtes, et nous voulons éviter l’ordre total car cela nécessite beaucoup de calcul et non la façon dont la nature fait les choses. Nous devons également gérer des niveaux élevés de simultanéité (plusieurs entrants/sortants simultanés) sans avoir à attendre la commande, et être capable de gérer ou d’interdire les forks.
Notre approche consiste à résoudre ce problème en utilisant le protocole MVBA. Dans ce scénario, chaque ancien propose une liste de vue des anciens qui seront en charge de la section après le changement et la diffuse aux autres anciens. Cela continue jusqu’à ce que la majorité des anciens reçoivent des propositions suffisantes des autres parties. Après cela, les propositions sont votées en utilisant le protocole ABBA afin qu’une liste finale d’anciens soit choisie au hasard parmi celles proposées.
Nous examinons attentivement ce domaine, comme vous le savez, et il y a des compromis et des choix à faire. Une amélioration que nous pouvons apporter est d’utiliser des propositions validables. L’adhésion nous permet de le faire, réduisant ainsi le temps d’un accord. Un autre domaine est la concurrence. Alors que l’ordre strict ne permet pas la simultanéité, il existe des options, ce sont des options complexes à considérer, mais probablement beaucoup moins de code à nouveau. Dans tous les cas, il est bon d’avoir des options, mais adapter ces options au cas spécifique d’adhésion nous donne beaucoup de choix et nous pouvons alors envisager les compromis avec plus de certitude dans ce cas d’utilisation.
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é!