Actualités du développement Safe 🇫🇷 19 mai 2022

Ceci est une traduction automatique. L’original en anglais est ici: Update 19 May 2022

Un réseau sain est composé de nœuds sains, d’appareils qui font ce qu’on attend d’eux comme prévu, dans une plage de performances acceptée. C’est le travail des anciens de s’assurer que les adultes de leur section sont à la hauteur et d’agir en votant s’ils repèrent quelque chose qui cloche. Le suivi des dysfonctionnements est une grande partie de ce sur quoi l’équipe travaille actuellement.

Progrès général

Cette semaine, nous avons réalisé que nous perdions potentiellement des nœuds lors de rotations et de fractionnements élevés, avec le nœud pensant qu’il avait rejoint, mais avec la rotation, la clé de section valide avait évolué. Le nœud, pensant que tout allait bien, n’essaierait pas de se reconnecter. Donc @anselme a travaillé sur la vérification de notre connaissance du réseau et après l’avoir mise à jour, a réessayé le processus de jointure pour ces nœuds perdus.

Le travail DBC se poursuit, avec les premières étapes de stockage du SpentBook en place.

En exécutant des réseaux de test pour déboguer l’instabilité des données, nous avons découvert une paire de blocages potentiels. Dans un cas, nous avons vu des lectures DataStorage suspendues pendant la réplication. Nous avons donc commencé à créer des benchmarks pour tester ChunkStorage, et avec cela nous avons découvert un blocage dans le code de stockage sous-jacent.

Un autre verrou (non confirmé) s’est produit pendant le processus de nettoyage de PeerLink. Il est difficile de dire si cela se produisait vraiment, mais nous avions vu des nœuds bloqués et notre code de nettoyage avait été appelé fréquemment autour des blocages. En creusant, il y avait beaucoup de potentiel de simplification, donc nous avons fait exactement cela.

Un autre verrou potentiel se produisait en cas de dysfonctionnement, la structure de données imbriquée étant lue de manière incorrecte sans verrou mut. :open_mouth: :man_facepalming:

Il est difficile de dire si tout cela se produisait avec certitude (nécessitant des conditions spécifiques pour se produire), mais ces changements devraient certainement être des pas dans la bonne direction !

Avec tout cela, nous avons enfin intégré le DKG-Handover avec le travail de génération (qui était beaucoup plus stable au-dessus d’autres changements récents). Nous réduisons la stabilité, avec plus de tests/benchmarks à venir pour DataStorage, et quelques autres ajustements aux flux de réplication de données en cours de test (nous devons étendre le pool de nœuds auxquels nous demandons des données, comme avec un taux de désabonnement important, les chances de frapper une autre augmentation de nœud fraîchement rejoint et il semble que nous commençons à perdre la rétention de données !).

Suivi des dysfonctionnements

Le suivi des dysfonctionnements est un processus continu. Il y a toujours de nouveaux comportements à tester et à modéliser, et c’est donc un processus itératif, permettant d’améliorer les performances et la stabilité à mesure que nous avançons.

Le suivi des dysfonctionnements est différent de la gestion de la malveillance. La malveillance est une mauvaise action objectivement prouvable, telle que la signature d’un message réseau invalide, et c’est le travail de tous les nœuds d’identifier ces nœuds et de les punir. Le dysfonctionnement, d’un autre côté, signifie un «comportement inférieur aux normes» et il est du devoir des aînés de déterminer ce que cela signifie.

Un nœud peut être sous-performant en raison de facteurs environnementaux tels qu’une lenteur temporaire de l’Internet local ou de conditions qui s’accumulent au fil du temps, telles qu’un stockage ou une mémoire insuffisants. Ou le dysfonctionnement peut être soudain, comme une panne de courant ou un redémarrage forcé.

Le dysfonctionnement couvre également des facteurs opérationnels, notamment la qualité et le nombre de messages, ainsi que le stockage et la diffusion de données sur demande.

Certains types de dysfonctionnement (perte de données, perte de connectivité étendue) sont plus graves que d’autres et doivent donc être traités différemment.

Nous pouvons tester les performances d’un nœud par rapport aux autres nœuds de la section, mais que se passe-t-il si toute la section est inférieure aux normes par rapport aux autres sections ? Quoi alors ?

Comme vous pouvez le constater, le suivi des dysfonctionnements est un problème complexe comportant de nombreuses variables.

Objectifs du suivi des dysfonctionnements

En surveillant les nœuds pendant qu’ils accomplissent leurs tâches, nous voulons étouffer tout problème dans l’œuf avant qu’il ne se développe. L’éjection d’un nœud devrait être un dernier recours, à la place, nous voulons agir - ou demander au propriétaire du nœud, l’agriculteur, d’agir - pour corriger le problème.

Ce processus de correction progressive du comportement des nœuds doit être automatisé et flexible, capable de réagir aux conditions changeantes plutôt que basé sur des paramètres arbitraires codés en dur.

Le suivi des dysfonctionnements concerne l’optimisation, mais il ne s’agit pas seulement d’optimiser les performances - cela conduirait à la centralisation. Les utilisateurs à domicile seraient incapables de rivaliser avec les instances des centres de données - ils seraient toujours relativement dysfonctionnels.

Où nous sommes

Actuellement, nous avons une version simplifiée du dysfonctionnement en place.

Liveness testing vérifie que les nœuds sont en ligne, permettant aux anciens de prendre des mesures s’ils ne le sont pas. Cela a été étendu pour pénaliser les nœuds non seulement pour avoir abandonné des morceaux, mais aussi pour avoir abandonné des connexions et être en retard en termes de connaissance du réseau.

Vivacité testing, une fois peaufiné pour s’assurer que nous ne sommes pas trop durs (comme nous l’avons été jusqu’à présent) ou trop doux sur les nœuds qui se comportent mal est une bonne première étape pour assurer un réseau stable, mais avec le suivi des dysfonctionnements, nous voulons aller plus loin et construire un modèle qui optimise également d’autres facteurs.

Pénaliser les nœuds signifie actuellement les supprimer, mais intégrera bientôt d’autres mesures comme la réduction de moitié de l’âge des nœuds. Les décisions sur la marche à suivre seront prises par les anciens par consensus.

Comme mentionné, un certain degré de «comportement dysfonctionnel» est inévitable, et en ce moment, nous expérimentons la classification des nœuds comme bon (95% + taux de réussite pour une opération donnée), médiocre (75%) ou mauvais (30%) donc nous peut traiter chaque classe différemment selon sa gravité, sans coder en dur les valeurs « attendues » (PR #1179). Nous voulons également savoir combien de nœuds de chaque classe se trouvent dans notre section.

La caisse sn_dysfunction est ici.

Où allons-nous

Nous voulons augmenter le nombre de tests que nous effectuons et les paramètres que nous vérifions afin de nous assurer que nous modélisons le réseau de manière significative.

Les idées incluent des sondages réguliers auprès d’adultes pour leur donner une petite preuve de travail qui pourrait également vérifier s’ils détiennent une version à jour de certaines données modifiables. Les données mutables sont un CRDT et finiront par converger, mais une connectivité intermittente peut signifier qu’un réplica renvoie une version obsolète. Son obsolescence aurait une incidence sur son score de dysfonctionnement, un décompte cumulatif accordé à chaque nœud. Si cela dépasse une valeur seuil, ce nœud peut être reclassé comme « médiocre » ou « mauvais » et être traité en conséquence. Sur quelle période de temps nous continuons à ajouter au score, il faudra tester.

Tous les problèmes ne peuvent pas être suivis en comparant les performances entre pairs (si tous les nœuds sont mauvais, cela signifie une mauvaise section ; si trop de sections sont mauvaises, cela signifie un mauvais réseau), nous allons donc examiner les paramètres globaux appropriés.

Nous devons également réfléchir à la manière dont nous pouvons utiliser le suivi des dysfonctionnements pour encourager la diversité des nœuds et éviter de conduire à la centralisation, afin qu’une instance AWS et un Raspberry Pi puissent jouer un rôle.

Et nous voulons considérer comment nous présentons les informations de dysfonctionnement à l’utilisateur final, l’agriculteur, éventuellement sous la forme d’un ensemble de paramètres par défaut qui sont modifiables via un fichier de configuration, et plus tard via une interface graphique.

En fin de compte, Safe est comme un ordinateur global, les anciens étant un processeur multithread et les adultes un disque dur géant. Nous voulons que ce disque dur soit auto-réparateur et que le processeur puisse s’adapter aux changements.

Tout cela nous emmène dans le domaine de l’ingénierie du chaos, tel qu’utilisé par Netflix et Google sur leurs plates-formes cloud, pour s’assurer que les pannes de serveur individuelles ne ne pas faire tomber tout le système.

Il y a probablement quelque chose que nous pouvons apprendre ici aussi alors que nous travaillons pour rendre le réseau sûr robuste et fiable.


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