Actualités du développement Safe 🇫🇷 3 décembre 2020

Développement
1

Ceci est une traduction automatique. L’original en anglais est ici: Safe Network Dev Update - December 3, 2020

Sommaire

Voici quelques-unes des principales choses à souligner depuis la dernière mise à jour du développement:

1
1830×430 218 KB

Safe Client, Nodes et qp2p

Plan de projet des transferts sécurisés sur le réseau
Plan de projet Safe Client
Plan de projet du nœud de réseau sécurisé

Cette semaine a été un peu marquante pour sn_node avec la première release et publish de cette caisse sous son nouveau nom, et la première depuis juillet. Il y a eu beaucoup de changements dans les mois qui ont suivi, comme le changelog ainsi met clairement en évidence, et comme nous avons essayé de vous tenir informé de ces mises à jour. Ces versions ne signifient pas que le développement est terminé dans sn_node, mais que nous l’avons considéré comme suffisamment stable pour maintenant fusionner le Continuous Delivery pipeline PR précédemment créé. Le développement se poursuit au rythme, et maintenant chaque PR fusionné se traduira par une nouvelle version générée automatiquement.

Nous avons fusionné le travail avec amélioration de la gestion des erreurs dans sn_node, qui dégage le chemin de la progression. Après suppression de la mise en cache des séquences la semaine dernière, nous avons exposé cette semaine le client à des conditions réseau plus normales, ce qui a abouti à plusieurs échecs de tests. Avec quelques ajustements aux tests clients pour en tenir compte, ils sont à nouveau stables. En plus de cela, nous avons examiné le démarrage de section, qui fonctionnait bien localement, mais CI a eu un peu de mal avec. Nous avons établi que certains de ces problèmes sont dus à la lenteur des machines CI, et l’augmentation des délais entre les nœuds à partir de là nous a permis d’obtenir des résultats plus fiables. Il y a encore quelques bugs à corriger ici.

Nous avons encore progressé avec certains des tests qui ont échoué lors des tests de bout en bout du réseau, en particulier en ce qui concerne le stockage des données à l’aide du type de données Blob. Nous avons identifié certains problèmes qui se sont glissés au cours de certains des refactors, et avec ceux corrigés, nous voyons maintenant les tests passer de manière cohérente. Nous passons maintenant à la réactivation du système de réplication de blocs lorsque les nœuds quittent le réseau. Une fois cela fait, tous les flux Blob seront réactivés dans l’implémentation refactorisée de sn_node.

Une autre fonctionnalité sur laquelle nous avons travaillé cette semaine est la régulation du stockage dans une section, et finalement dans le réseau, via PR # 1153. À partir de ce PR, les nœuds de stockage de données surveillent leur stockage à chaque écriture qu’ils exécutent, avertissant leurs anciens de section s’ils atteignent leur capacité maximale. Les anciens maintiennent alors un registre de ces nœuds remplis et lorsqu’ils atteignent un seuil de nœuds remplis dans la même section, ils votent pour accepter de nouveaux nœuds pour rejoindre leur section, fermant les portes une fois l’offre / demande satisfaite, maintenant ainsi l’équilibre dans le réseau. Nous réitérerons avec divers ajustements aux métriques dans les prochains jours.

Un PR for Rust-CRDT a été soulevé pour mettre LSeq en ligne avec d’autres types CRDT en ayant besoin d’appeler apply avant modifier le type de données lui-même. Nous l’utilisons dans notre type de données Sequence pour nous assurer que toutes les opérations sont signées.

Les modifications apportées à sn_api et CLI se sont poursuivies la semaine dernière, s’adaptant aux nouvelles API sn_client et, comme mentionné la semaine dernière, essayant également de migrer vers de nouvelles terminologies UX. Nous avons la plupart des tests sn_api qui passent maintenant en utilisant une section locale, et nous essayons maintenant de finaliser ces changements ainsi que de résoudre les tests qui ont échoué, ce qui devrait, espérons-le, signifier que les commandes CLI et les tests E2E seront à nouveau opérationnels.

Et enfin, afin de permettre une couverture test accrue des transferts, des paiements,Des modules de récompenses, une restructuration de ce code et des changements pour accéder à la granularité ont été lancés cette semaine.

BRB - Diffusion fiable byzantine

Les travaux se poursuivent sur l’approche de l’horloge de génération pour l’adhésion dynamique. Le code prototype fonctionnel est attendu pour la fin de la semaine.

Sur une piste parallèle, la caisse bft-crdts est divisée en caisses séparées dans un effort de modularisation. L’idée est de définir 3 traits: un pour l’implémentation BRB, un pour les types de données à transmettre et sécuriser, et un pour la couche réseau.

De cette manière, les implémentations des trois traits peuvent être mélangées et mises en correspondance. Par exemple, nous pouvons utiliser une utilisation réseau en mémoire pour les cas de test, une implémentation qp2p pour le routage dans Safe Network, et une tierce partie peut utiliser une implémentation de sockets TCP / IP pour autre chose. Du côté des données, nous avons déjà une implémentation bancaire AT2 et une implémentation CRDT orswot.

Routage

Plan de projet

Comme mentionné ci-dessus, sn_node a été publié et publié pour la première fois sous sa forme actuelle cette semaine. Pour ne pas être en reste, l’équipe de routage a maintenant également publié et publié sn_routing, la première sortie en presque 2,5 ans! Voir le changelog pour un aperçu des modifications apportées. Comme pour sn_node, ces versions ne signifient pas que le développement est terminé dans sn_routing, juste que nous l’avons considéré comme suffisamment stable pour maintenant fusionner le Continuous Delivery pipeline PR précédemment créé. Le développement se poursuit au rythme, et maintenant chaque PR fusionné se traduira par une nouvelle version générée automatiquement.

Cette semaine, nous avons mis en œuvre une mesure de défense contre les attaques de vente de clés. Une attaque de vente clé se produit lorsqu’un nœud qui a bâti sa réputation vend sa clé secrète à une entité potentiellement malveillante qui peut alors assumer son rôle et faire des dégâts. Ce type d’attaque est très difficile à empêcher complètement, mais nous avons au moins rendu difficile l’accès à la clé secrète en s’assurant que la clé n’est pas exposée ou stockée sur le disque.

Nous avons également travaillé pour introduire le processus de réalisation de la vérification des ressources pendant le bootstrap, qui a été fusionné aujourd’hui. Cela met au défi tous les nouveaux nœuds de jonction potentiels pour s’assurer qu’ils sont suffisamment qualifiés pour partager la charge de travail du réseau. Une fois la vérification de la vérification des ressources en place, tous les nœuds nouvellement joints seront immédiatement considérés comme «adultes» - la gestion des nœuds «infant» n’est plus nécessaire.

Nous avons également travaillé mise à jour de la section de refactoring qui vise à simplifier la base de code de gestion de DKG. Les deux principaux changements proposés pour y parvenir sont:

  1. Les échecs de DKG ne seront plus signalés aux anciens de la section actuelle, mais il redémarre tout seul.
  2. L’accumulateur de résultats DKG séparé sera supprimé, à la place en utilisant l’accumulateur de votes ordinaire.

Cependant, après des discussions pendant le processus d’examen, d’autres problèmes ont été repérés que nous avons décidé de résoudre. Par conséquent, le PR a été changé en statut de projet et devrait être prêt pour une nouvelle révision, avec les ajouts, bientôt.

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