Ceci est une traduction automatique. L’original en anglais est ici: Update 05 January, 2023
Bonne année à tous 
C’est super d’être de retour - nous sommes déterminés à faire en sorte que celui-ci compte vraiment 
L’équipe a réussi à prendre un bon moment de repos et est impatiente de partir. Pendant la pause, nous avons également corrigé quelques problèmes et réfléchi à certaines améliorations possibles, notamment la taille optimale des nœuds et des sections et modifications de l’âge et de la relocalisation des nœuds. Pour le premier d’entre eux, nous avons exécuté des réseaux de test internes avec des nœuds plus petits et des sections plus grandes. Celles-ci se sont plutôt bien déroulées et ont révélé un ou deux autres problèmes liés aux communications et au transfert sur lesquels nous avons travaillé. La seconde est une optimisation de la conception qui traitera les nœuds plus jeunes différemment des nœuds plus anciens. Plus de détails à ce sujet dans les prochaines semaines.
Progrès général
Une pause dans la routine peut être un bon moment pour réfléchir à ce qui peut être amélioré et résoudre les problèmes. Voici un résumé de ce que l’équipe a fait depuis la dernière mise à jour.
Diviser la messagerie fourre-tout NodeMsg::Propose en quatre variantes distinctes pour plus de clarté.
RequestHandover : lorsque les nœuds terminent DKG et demandent un transfert aux anciens actuels (nœud-> aîné)
SectionHandoverPromotion : lorsque les aînés disent à ces nœuds qu’ils sont promus en tant qu’aînés (aîné-> nœud)
SectionSplitPromotion : lorsque les aînés disent à ces nœuds qu’ils sont promus en tant qu’aînés de chaque côté d’une scission (aîné-> nœud)
ProposeSectionState : lorsque les aînés décident de lancer des nœuds ou d’accepter de nouveaux nœuds dans une section (aîné-> aîné)
Cette distinction rend explicite qui signe et qui reçoit/agrège les signatures.
** Couper les messages inutiles **
Nous fixed un problème coûteux où les messages AE vérifiaient à plusieurs reprises le SectionTree pour chaque message, même s’il avait déjà été vérifié.
Optimisation AE
Nous avons expérimenté le ralentissement du sondage AE autour des fractionnements pour réduire le nombre de messages circulant, et avons également refactorisé les connaissances de la section du réseau mondial pour cibler un aléatoire aîné dans trois sections aléatoires toutes les cinq minutes. Auparavant, la valeur par défaut était tous les anciens dans trois sections toutes les 30 secondes. Cela a entraîné une utilisation considérablement réduite du processeur et de la mémoire autour des fractionnements, et le temps plus long devrait être suffisant pour nos besoins : les fractionnements ne se produisent pas toutes les 30 secondes après tout.
** Utilisation élevée de la mémoire en attente de rejoindre **
Nous avons essayé un bogue qui entraînait une utilisation élevée de la mémoire dans les nœuds en attendant de se joindre, comme on l’a vu dans les récents testnets. Nous serons prêts à mettre cela à l’épreuve sur un réseau de test communautaire sous peu. Nous avons également empêché la mise en cache des sessions de connexion pour les nœuds non joints.
** Refactorisation des communications **
Un vilain verrou dans le code pour send-streams dans sn_node a été refactorisé. De plus, nous testons des communications « happy path » grâce auxquelles les clients peuvent envoyer un message à un seul aîné plutôt qu’à tous.
Nous avons également supprimé le code de suivi des nœuds et les verrous associés qui étaient des points de défaillance potentiels. Nous voyions de nombreux messages à la suite d’un échec des changements de niveau d’envoi/de stockage qui bloquaient les nœuds.
Modifications des paramètres de stockage
Une marge a été ajoutée à la capacité de stockage, dans laquelle nous attendons une quantité minimale de stockage, mais les nœuds peuvent stocker davantage. Cela devrait aider à atténuer les erreurs «Impossible de stocker» avant de diviser. Nous avons également mis en place des anciens pour stocker des données (ils ne l’étaient pas auparavant) et utiliser leur capacité de stockage minimale locale comme indicateur du moment de la séparation, comme discuté sur le forum.
Avec cela, nous avons maintenant le flux suivant :
- Les nœuds reçoivent des données.
- Chaque fois que nous dépassons un certain niveau de stockage utilisé (pour la première fois), nous permettons à de nouveaux nœuds de se joindre.
2.1 Lorsqu’un nœud demande à rejoindre, nous voyons que les jointures sont autorisées, et les anciens lancent un vote pour ajouter le nœud. - Lorsqu’un nouveau nœud rejoint, les jointures sont désactivées, nous vérifions si nous avons atteint
min_capacity
3.1. Nous n’avons pas atteintmin_capacity, continuez normalement.
3.2. Nous avons atteintmin_capacity, nettoyez l’espace de stockage excédentaire.
3.3 Si nous sommes toujours à ou au-dessus demin_capacity, déclenchez le fail-safeallow_joins_until_split.
3.4. Lorsqu’un nœud demande à rejoindre, nous voyons que les jointures sont autorisées, et les anciens lancent un vote pour ajouter le nœud. - Le nœud de jonction soulage la charge de stockage.
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é!