Ceci est une traduction automatique. L’original en anglais est ici: Update 26 January, 2023
Cette semaine, nous réexaminons l’âge des nœuds et examinons quelques ajustements pour en tirer parti pour davantage d’opérations réseau. Pour éviter les gémissements et les grincements de dents, ne vous inquiétez pas, ce n’est pas le genre de refonte architecturale qui va prendre des mois. Il s’appuie sur ce qui existe déjà en termes de nouveaux nœuds devant faire leurs preuves et se déplacer sur le réseau, mais il supprime les tâches critiques de traitement des données de ces jeunes nœuds et les limite à ceux qui ont déjà fait leurs preuves.
Progrès général
Après des discussions communautaires longues et parfois animées, @JimCollinson et @andrew ont de nouveau sorti les feuilles de calcul et ont travaillé sur les différentes options de distribution de jetons. Nous espérons sincèrement que cela fournit la base pour aller de l’avant maintenant.
@joshuef a expérimenté des réseaux de test avec des machines virtuelles encore plus petites et de petits nœuds. Cela s’est plutôt bien passé, mais il y a eu quelques bugs qui semblent être autour du processus DKG (vote des anciens) où parfois les votes ne sont pas reçus. Dans le même ordre d’idées, @anselme, @maqi et @davidrusu examinent de près DKG, ce qui le déclenche exactement, notamment en examinant la génération SAP ( un nouveau record d’anciens qui est créé à chaque fois qu’il y a du désabonnement) et exactement où cela déclenche un tour DKG.
@oetyng a simplifié le processus de jointure en le déplaçant dans les flux de messages réguliers. Après cela, le flux de relocalisation a été simplifié en en faisant également une jointure, mais vers une autre section et en incluant une preuve de relocalisation. @davidrusu a trouvé un besoin potentiel d’affirmer qu’un événement de désabonnement valide a été utilisé, ce travail est à venir.
@bochaco a débogué et finalisé sn_comms, le module de communication, qu’il continue de refactoriser.
Et Mostafa a fini de tester l’algorithme de consensus et l’a ajouté au dépôt principal.
Merci à @southside d’avoir suggéré l’initiative de commentaire de code ChatGTP. Quiconque souhaite apporter son aide (aucune compétence technique requise) doit consulter ce post.
Âge et données du nœud
Les responsabilités dans le réseau sont basées sur la notion de node age.
L’âge du nœud n’augmente pas de manière linéaire, mais exponentielle, ce qui signifie que chaque augmentation de l’âge est basée sur 2x de ce sur quoi l’incrément précédent était basé.
Le temps dans le réseau est mesuré en nombre d’événements, et la mesure est approximative car nous effectuons une évaluation probabiliste.
Ainsi, l’âge A survient après ~n événements, et l’âge A+1 survient après ~2n événements.
La raison pour laquelle l’âge des nœuds est mesuré de cette manière vient de l’observation empirique selon laquelle les nœuds qui sont restés en ligne x fois sont susceptibles de rester en ligne pendant au moins x fois. Donc, si vous avez passé du temps t dans le réseau, il est probable que votre temps total dans le réseau sera finalement d’au moins 2t.
Cela signifie simplement que plus le nœud est jeune, plus il est susceptible de se déconnecter, et plus il est ancien, plus il est susceptible de rester en ligne.
Avoir des nœuds très stables et très instables stockant des données en direct, comme nous le faisons maintenant, est difficile à gérer lorsqu’il y a beaucoup de désabonnement. Si un nœud se déconnecte, ses données doivent être transférées au prochain candidat XOR le plus proche, ce qui prend du temps. Les nouveaux nœuds ne sont pas fiables et peuvent se déconnecter rapidement, ce qui signifie beaucoup de mouvement de données et un casse-tête pour les anciens qui doivent le gérer.
Stockage primaire et secondaire
Nous examinons des concepts autour d’un « ensemble stable » de nœuds (plus d’informations à ce sujet plus tard). Mais une idée que cela nous donne est de séparer les nœuds en deux niveaux de stockage en fonction de l’âge et (par conséquent) de la probabilité de barattage, et de leur donner ainsi des tâches différentes.
Par exemple, nous voudrions que les nœuds les plus stables (par exemple, âgés de 10 ans et plus) soient responsables du stockage des données principales. Ces nœuds s’occupent des données et les transmettent à un client sur demande. Ils ne sont pas susceptibles de se désagréger de sitôt.
Les nœuds en dehors d’un tel ensemble stable, ceux qui travaillent encore à augmenter l’âge de leur nœud, contiennent des copies supplémentaires de données (stockage secondaire). Ce faisant, ils fournissent une redondance pour prendre en charge l’ensemble stable.
Leur comportement dans le traitement de ces données est également utilisé pour évaluer leur qualité de la manière habituelle. Mais comme ils ne contiennent que des copies supplémentaires, ils n’ont pas besoin d’être suivis de si près par les anciens et peuvent échouer sans causer de problèmes sérieux au réseau ou nécessiter une migration massive des données.
Cela nous permettrait d’avoir un nombre accru de réplications pour les données, tout en testant les nœuds entrants de manière plus approfondie, sans sacrifier la stabilité des données pour ce faire. Tout cela en tirant parti de notre système d’âge de nœud existant. 
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é!