Actualités du développement Safe 🇫🇷 20 janvier 2022

Ceci est une traduction automatique. L’original en anglais est ici: Update 20 January, 2022

Un domaine d’intérêt clé pour le moment est l’adhésion, la façon dont les anciens suivent les adultes et les autres anciens de leur section, afin qu’ils puissent gérer les nouvelles jointures, les scissions, le roulement et les promotions. Cette fonctionnalité est gérée par la caisse sn_membership. Les algorithmes de cette caisse subissent actuellement des tests rigoureux avant d’être intégrés au réseau. Ce n’est pas une nouvelle fonctionnalité en tant que telle, mais plutôt un resserrement médico-légal de la maison de transition que nous avons eue jusqu’à présent et une formalisation des algorithmes. La plupart des membres de l’équipe travaillent actuellement sur certains aspects de l’adhésion.

Progrès général

La caisse sn_membership est gérée par @davidrusu. Presque tous les tests passent maintenant, donc c’est surtout du rangement.

@bochaco examine les flux au sein des membres : quel est l’ordre des événements lorsqu’un nouveau nœud rejoint ou que l’adulte le plus âgé est promu ?

Un aspect couvert par la gestion des adhésions est le transfert des anciens, en s’assurant que les anciens nouvellement promus disposent de toutes les bonnes informations, clés, etc. @anselme l’a bien placé maintenant et c’est à peu près prêt à partir.

Loin de l’adhésion, @chriso a travaillé sur des problèmes avec des tests nocturnes et, après avoir terminé la documentation CLI, rédige maintenant NRS.

Sur le front des données, @yogesh se concentre sur les tests de réplication des données, et @joshuef a mis à jour qp2p vers la dernière version de quinn.

Pendant ce temps, @danda se branche sur les DBC. L’intégration de Ring CT est à peu près terminée, et les menthes sont la prochaine étape, bien que davantage de travail soit nécessaire pour que les menthes fonctionnent correctement avec Ring CTs.

@happybeing a fait un joli petit PR mise à jour de la journalisation des nœuds. Cela devrait aider à économiser de l’espace sur tous les nœuds démarrés et faciliter le suivi des journaux avec des commandes telles que tail -f.

Adhésion

Les opérations d’adhésion couvrent les nouveaux nœuds rejoignant la section, la gestion de la capacité, l’éjection des nœuds qui se comportent mal ou la réduction de l’âge de leur nœud, la promotion des adultes au rang d’anciens et la garantie que les nouveaux anciens sont correctement équipés.

Pour rappel, les sections comptent sept anciens et (sauf si de futurs tests indiquent le contraire) 60 à 100 adultes. Les adultes tournent fréquemment, avec des abandons, de nouveaux entrants et des nœuds plus anciens qui arrivent lorsqu’ils sont déplacés d’autres sections. Les anciens doivent garder une trace de l’adhésion à la section afin qu’ils sachent quand autoriser de nouveaux adultes à se joindre, et aussi quand les anciens partent et qu’un adulte est promu. Ils conservent une liste de tous les adultes et aînés actuels de leur section.

L’appartenance à la section est limitée par la taille maximale de la section. Lorsque nous avons de telles contraintes dans un système distribué, nous devons souvent recourir au consensus pour décider entre des options concurrentes. Dans notre cas d’adhésion, les anciens doivent décider lequel des (nombreux) nœuds en attente de rejoindre une section doit être autorisé à entrer.

Nous n’utilisions pas d’algorithme de consensus jusqu’à présent, les processus actuels de gestion des membres se déclenchent parfois lorsque des événements inattendus se produisent.

La nouvelle caisse sn_membership fournit un algorithme de consensus BFT sans leader offrant de bonnes performances dans un modèle de réseau éventuellement synchrone. Après un régime de tests sans merci, il est maintenant prêt à être intégré au réseau.

sn_membership fonctionne avec l’anti-entropie (AE) et la génération de clé distribuée (DKG) pour gérer l’appartenance à la section. Voici quelques flux.

Rejoindre un nœud

Un nœud entrant interagit avec un ancien, échangeant des messages « JoinRequests » jusqu’à ce qu’il soit provisoirement accepté et reçoive le défi de preuve de ressource et le renvoie à l’ancien.

Sous l’ancien système, une fois qu’il avait réussi le test, le nœud y serait, mais cela constituait un risque pour la sécurité et pouvait provoquer des blocages (voir ci-dessous). Maintenant, l’ancien envoie une proposition pour ajouter le nœud en utilisant le protocole « sn_membership » aux autres anciens de la section. sn_membership se termine une fois que nous avons Super-Majority over Super-Majority, c’est-à-dire qu’une super-majorité d’anciens voit qu’une super-majorité d’anciens a accepté cette proposition. Une fois que sn_membership a commencé, il est garanti qu’il se termine (tant que notre hypothèse de réseau éventuellement synchrone n’est pas violée).

Une fois que la proposition atteint un consensus parmi les aînés, l’aîné renvoie l’approbation au nœud qui rejoint.

Promotion des adultes et passation des anciens

Si un ancien remarque que les anciens actuels ne sont pas les sept nœuds les plus âgés, cela déclenche un vote sur la promotion du ou des adultes les plus âgés et la rétrogradation des anciens les plus jeunes pour faire place.

L’algorithme Elder Handover contrôlant ce processus, qui est maintenant prêt à être intégré dans la caisse sn_membership, se déroule comme suit.

Un ancien reçoit une majorité qualifiée d’actions DKG complétées pour vérifier que les anciens actuels sont les sept membres les plus âgés.

L’aîné propose un nouvel ensemble deaînés.

Les anciens suivent un consensus de style sn_membership pour décider d’un seul message NewElders. Cette étape est nécessaire lorsque nous avons une chaîne d’événements compliquée qui se termine par plusieurs groupes de nœuds en course pour terminer DKG et devenir les prochains anciens.

Une liste des membres actuels de la section est transmise au nouvel aîné, le fournisseur d’autorité de section (SAP) est mis à jour et un nouveau bloc est ajouté à la chaîne de section.

Le rôle du consensus

Alors pourquoi un consensus est-il nécessaire pour l’adhésion alors que d’autres parties du réseau comptent sur AE pour rester à jour ?

Voici un exemple. Disons qu’une section est presque pleine. La limite de taille de section est de 50 nœuds (juste par exemple) et il y a actuellement 49 membres. Un nouveau nœud envoie un JoinRequest à un ancien. Dans un système sans consensus, l’aîné vérifie la capacité et voit qu’il y a de la capacité, échange des messages AE, et à condition que le nouveau nœud réussisse le test de preuve de ressource, il est dedans.

Mais à ce stade, la section est prête à se scinder, ce qui, lorsque plusieurs nœuds tentent de se joindre, peut entraîner des conflits de priorités :

Disons, dans le cas extrême, que les sept aînés reçoivent simultanément des « JoinRequests » de sept nœuds différents. Les sept anciens voient que nous avons de la place pour un nœud de plus, et puisque chacun des sept nœuds a réussi ses tests de preuve de ressources, chaque ancien permettra à son nœud de rejoindre la section.

Mais, à la suite de commérages anti-entropie entre anciens, ils constatent que leurs collègues aînés n’accepteront pas les nouveaux nœuds de l’autre, car cela pousserait la capacité de la section au-delà de la limite. Les anciens se retrouvent dans une situation de cerveau divisé où chaque ancien a une vision différente de l’appartenance à la section.

Pour éviter que ce problème ne se produise, les anciens parviennent à un consensus sur les nœuds qui seront autorisés. Avec sn_consensus, chacun des sept anciens peut proposer jusqu’à un changement. Cela signifie que jusqu’à sept changements (rejoindre/quitter) peuvent être décidés en un seul tour.

Dans le cas ci-dessus, sn_membership signifiera un travail supplémentaire par rapport aux aînés agissant seuls, mais cette surcharge n’est visible que lorsque nous avons de nombreux choix concurrents. sn_membership se réduit gracieusement à Byzantine Reliable Broadcast (BRB) lorsque les anciens sont généralement d’accord sur les mesures à prendre, nous ne payons les frais généraux de consensus que lorsque les anciens commencent à avoir des désaccords. sn_membership est une méthode pacifique pour résoudre les désaccords :slight_smile:


Liens utiles

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é!