Ceci est une traduction automatique. L’original en anglais est ici: Safe Network Dev Update - January 7, 2021
Sommaire
Voici quelques-unes des principales choses à souligner depuis la dernière mise à jour du développement:
- Bonne année!
- Nous sommes ravis d’annoncer que le travail d’adhésion dynamique est terminé et nous avons publié aujourd’hui plusieurs caisses Byzantine Reliable Broadcast (BRB) sur GitHub
. Tous sont liés depuis le brb crate central. - Nous avons travaillé dur, même pendant les vacances, pour améliorer notre couche d’erreurs et de communications, y compris la création d’une nouvelle caisse
sn_messaging. - Nous sommes en train de préparer quelques correctifs mineurs pour une nouvelle version de correctif de la CLI.
- Nous sommes également sur le point d’avoir la CLI et
authdconstruits avec musl, ce qui signifie une compatibilité avec une plus large gamme de plates-formes. - Nous avons un nouvel outil de test de stress pour le routage avec le PR en cours de révision. Ce nouvel outil est conçu pour découvrir les limites du routage en termes de gestion des changements d’appartenance (churn) et a déjà porté certains problèmes à notre attention.
Mise à jour Testnet
Merci à tous ceux qui ont pris le temps d’essayer le code testnet publié avant Noël. Avec toute l’équipe MaidSafe maintenant de retour à leur bureau, nous continuons à travailler sur certains problèmes que nous avons identifiés avant la publication, et d’autres que vous avez mis en évidence pour nous. Une fois que nous serons satisfaits de la résolution de ces problèmes, nous annoncerons une autre itération, avec l’intention d’héberger un réseau de test public auquel tous ceux qui le peuvent peuvent se connecter.
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é
Nous avons travaillé pour améliorer notre histoire d’erreur tout au long de nos bibliothèques, et sommes passés à l’utilisation de thiserror à travers node / data_types / client / transferts pour fournir une meilleure chaîne d’erreur et une plus grande encapsulation des fonctionnalités. Auparavant, nous utilisions beaucoup d’erreurs mixtes, tirant beaucoup de sn_data_types vers d’autres bibliothèques. Maintenant, nous avons des erreurs spécifiques dans chaque bibliothèque, pour cette bibliothèque, et ne propagons les erreurs des bibliothèques inférieures que comme une autre version des erreurs de la bibliothèque actuelle.
En plus de cela, nous avons extrait sn_messaging de sn_data_types dans sa propre caisse afin de séparer notre couche de communication, ainsi que les erreurs que nous enverra vers / depuis d’autres nœuds et clients. Il s’agit d’un petit pas vers une définition plus claire d’une «API» de réseau de messages et d’erreurs et il fournit une séparation plus claire des erreurs des bibliothèques internes vers le client.
Dans le cadre de cet effort, nous explorons différents types de sérialisation, dans le but final d’en avoir un qui soit indépendant du langage de programmation. Nous nous concentrons pour le moment sur une simple sérialisation JSON (par opposition au bincode actuellement utilisé), mais nous jouons également avec Msgpack.
Le résultat de tout cela a été un code plus propre et des flux d’erreur beaucoup plus clairs dans toutes les bibliothèques impliquées, ce qui est excellent.
En tandem, nous avons supprimé les «défis» clients du flux d’amorçage nœud / client. Celles-ci étaient auparavant utilisées pour vérifier qu’un client détenait des clés, afin d’éviter les attaques de relecture de messages. Mais avec idempotency provenant des types de données AT2 et CRDT, cela sera traité ici. Encore plus de simplification pour le client et le nœud, et clarifie davantage les opérations réseau en tant que messages signés uniquement.
Auparavant, pour empêcher les attaques de vente de clés sur le réseau, nous supprimions toutes les API d’exposant SecretKey de sn_routing et les contenait uniquement dans leur caisse. Cependant, nous avons constaté qu’il y avait de multiples complications dans l’arborescence des dépendances causées par cette suppression, et avons donc convenu de ramener ces API pour nous permettre d’avancer rapidement avec le testnet pendant les vacances. Nous avons décidé de nous attaquer directement à ce problème et avons commencé à refactoriser les caisses sn_transfers et sn_node, où nous détenons et utilisons ces SecretKeys en dehors de sn_routing.
Le travail d’agrégation de signature effectué par sn_node pendant l’échange de messages entre KeySection et DataSection est peut-être dupliqué avec le travail d’accumulation de consensus du routage, car les deux sont en fait entrepris par des nœuds plus anciens. Nous étudions et effectuons un travail de refactoring en essayant de supprimer cette partie de la caisse sn_node, et de faire confiance aux messages de consensus de sn_routing.
Et un tout petit peu de travail est en cours pour supprimer la gestion des flux des nœuds. Cela a été mis enplace pour maintenir les communications avec les clients, mais avec les récents changements de qp2p, nous pouvons compter sur le pool de connexions pour gérer cela pour nous, et ainsi éliminer beaucoup de complexité de la gestion des clients du nœud. Nous sommes également en train de refactoriser les exemples qp2p en parties séparées pour démontrer clairement et distinctement les systèmes echo_service et de messagerie. Nous faisons des essais avec ces exemples avec une redirection de port manuelle pour potentiellement prendre en charge des routeurs non compatibles avec IGD dans d’autres réseaux de test.
API et CLI
Nous nous sommes concentrés sur les changements et les améliorations côté réseau, cependant, nous avons toujours travaillé pour résoudre certains bogues mineurs qui ont été signalés par la communauté lors de l’utilisation de testnet et sont donc en train de préparer quelques correctifs mineurs pour une nouvelle version de correctif de la CLI.
De plus, nous essayons de construire notre prochaine version de CLI et de authd avec musl, ce qui, comme nous le savons, nous permettra d’exécuter ces applications sur de nombreuses autres plates-formes utilisant les mêmes artefacts publiés. Nous avons déjà pu les construire manuellement (merci beaucoup à @mav et @tfa pour leur contribution et leurs contributions à cela), donc nous cherchons maintenant à intégrer cela dans notre CI dans les prochains jours.
BRB - Diffusion fiable byzantine
Nous sommes ravis d’annoncer que le travail d’adhésion dynamique est terminé et nous avons publié aujourd’hui plusieurs caisses Byzantine Reliable Broadcast (BRB) sur GitHub :tada :. Tous sont liés depuis la crate brb centrale.
Le système BRB comprend:
1. Le protocole de diffusion BRB de base pour les membres d’un quorum afin de répliquer les données à la manière BFT.
2. Le protocole d’appartenance dynamique permettant aux nœuds de se joindre dynamiquement et de quitter un quorum actif.
3. Des wrappers de type de données qui encapsulent des types de données compatibles (par exemple CRDT) pour le transfert via BRB.
4. Tests complets pour vérifier l’exactitude.
5. brb_node_qp2p: un exemple d’application / nœud CLI pour appeler manuellement la fonctionnalité BRB.
Pour ceux qui souhaitent approfondir les détails, des slides sont disponibles et fournissent des informations supplémentaires sur le système et les protocoles.
Routage
Comme nous le savons tous, la délocalisation est bonne pour le réseau, facilitant entre autres le vieillissement des nœuds. Cependant, nous avons observé que dans certaines situations, nous étions en train de déménager excessivement. Par exemple, nous déménagions même lorsque nous n’avions pas assez d’anciens en raison de l’attrition, et nous déplaçions également les nœuds lorsqu’ils venaient de rejoindre. Pour résoudre, nous avons mis en place des critères pour éviter la relocalisation visant à maintenir le réseau stable pendant certains scénarios.
Un changement d’API a également été entrepris pour renvoyer les informations de section pour le nom de cible spécifié. Ceci est principalement destiné à l’utilisation de sn_node pour les travaux de refactorisation à venir.
Nous avons mis en place un test de résistance pour le routage (PR en cours d’examen). C’est un petit outil conçu pour découvrir les limites du routage en termes de gestion des changements d’appartenance (churn). Il génère un taux de désabonnement aléatoire selon un calendrier configurable. Il produit ensuite périodiquement diverses informations utiles sur le réseau et mesure la santé du réseau. Cet outil sera très utile pour les prochains travaux d’intégration de la nouvelle solution d’adhésion dynamique. En l’exécutant sur la version actuelle du routage, il a déjà découvert certains problèmes que nous avons autour des délocalisations et des scissions, que nous examinerons bientôt. C’est en fait une bonne chose, car la première étape pour résoudre un problème est de connaître le problème: smile: Voici une petite capture d’écran de la sortie de l’outil:
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é. Alors ne soyez pas timide, rejoignez-nous et créons ensemble le réseau sécurisé!