Mise à jour du développement du réseau Safe 🇫🇷 19 novembre 2020

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

Sommaire

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

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é

Tout d’abord, cette semaine dans qp2p, nous avons mis en place le pool de connexions. Cela signifie que si un nœud veut se connecter à un pair et que la connexion a déjà été ouverte (et est toujours ouverte), nous réutiliserons la connexion existante au lieu d’en établir une nouvelle. Cela améliore les performances car l’établissement d’une connexion est coûteux (cela implique une prise de contact TLS, entre autres). Cela améliore également l’ergonomie car les utilisateurs de qp2p n’ont plus à se soucier de la mise en cache des connexions. Nous avons également mis en œuvre la déduplication de connexion, ce qui signifie que plusieurs tentatives de connexion simultanées vers le même homologue se résoudront toutes à la même connexion au lieu d’ouvrir une connexion distincte chacune. Cela améliore à nouveau les performances.

Nous revenons à la réplication par blocs de données Blob à sn_node. En commençant par un facteur de réplication 4x, les adultes du réseau seront principalement responsables de leur stockage. Nous portons l’ancienne implémentation des coffres pré-asynchrones vers la nouvelle base de code, en l’adaptant aux derniers changements de stockage, d’interrogation, etc. Nous avons également effectué un peu de maintenance dans tous les domaines cette semaine en traquant sournois s, expects et panic`s de notre code de production et de nos tests, stabilisant essentiellement notre base de code et capturant toutes les exceptions. C’est la meilleure pratique et quelque chose que nous remettons à plus tard depuis trop longtemps. Recherchez des contrôles CI supplémentaires ajoutés dans les prochains jours dans nos caisses pour vous assurer qu’ils ne se faufilent pas dans notre code.

Nous avons investi un peu de temps dans la recherche et la réflexion sur la manière dont les API devront éventuellement évoluer pour prendre en charge les demandes de signature du client en utilisant plusieurs paires de clés plutôt qu’une seule. Par exemple, un client peut souhaiter stocker un fichier qui appartiendrait à une clé publique tandis que le paiement d’une telle opération serait effectué à l’aide d’une deuxième clé publique qui possède les fonds, et peut-être qu’une troisième paire de clés pourrait être utilisée par le client pour crypter le contenu du fichier. Ce n’est pas quelque chose que nous considérons comme hautement prioritaire pour le moment, mais plutôt un PoC pour nous aider à identifier les défis et à comprendre comment éventuellement faire évoluer les API de nos clients.

CRDT

Le travail se poursuit sur l’adhésion dynamique à DSB et cette semaine, notre consultant a écrit un cas de test qui démontre un problème de concurrence avec les opérations de données pendant qu’un membre quitte le groupe. Une implémentation correcte de l’appartenance dynamique doit toujours réussir le test alors que notre implémentation naïve actuelle échoue, nous avons donc maintenant quelque chose de concret à mesurer.

À cette fin, nous sommes enthousiasmés par un article académique récent des auteurs d’AT2 intitulé Dynamic Byzantine Reliable Broadcast. Il fournit la citation: « la première spécification d’une primitive de diffusion fiable byzantine dynamique (dbrb) qui se prête à une implémentation asynchrone ». En d’autres termes, cet article fournit une solution officiellement éprouvée pour exactement notre problème.

Notre consultant examine actuellement ce document ainsi qu’une autre solution possible utilisant quelque chose appelé Generation Clock qui pourrait ne pas nécessiter autant communication réseau.

Routage

Plan de projet

Comme mentionné dans la mise à jour de la semaine dernière, le travail pour permettre à un nœud de se rejoindre avec le même nom a été approuvé et fusionné cette semaine. Cela signifie que tout nœud qui rejoint serait immédiatement déplacé avec la moitié de son âge, tant que l’âge réduit de moitié est supérieur à «MIN_AGE» (actuellement «4»). Ceci est conçu pour décourager les redémarrages malveillants.

Nous avions observé lors des tests internes que le nœud de genèse était parfois rétrogradé trop rapidement, cela était dû à un changement récent où nous faisons maintenant des nœuds avec un aléatoire gamme d’âge pendant la phase de démarrage. Pour résoudre ce problème, nous avons décidé de Démarrer le premier nœud avec un âge plus élevé, actuellement défini sur 32. Cela a maintenant été fusionné avec master. Cela garantit que le nœud genesis reste stable en tant qu’ancien pendant une période suffisamment longue, ce qui facilite beaucoup de choses pour les tests et la configuration de testnet.

Le travail en cours pour améliorer la détection des pairs perdus progresse bien. Nous avons déjà profité de la nouvelle fonctionnalité de pooling de connexions dans qp2p, qui nous a permis de simplifier le code. Certains tests d’intégration initiaux montrent que la refactorisation fonctionne bien. Ce PR est actuellement en cours d’examen et de tests finaux et, espérons-le, sera bientôt fusionné.

Pour nous assurer que lorsque les ressources d’un nœud sont sur le point d’être utilisées, de nouveaux nœuds affluent pour partager la charge de travail, nous allons [permettre aux nœuds de dire au routage d’accepter ou non de nouveaux nœuds](https://github.com / maidsafe / sn_routing / pull / 2234). Cette restriction sur le moment où le réseau accepte de nouveaux nœuds aidera également à prévenir les attaques sybil en ne permettant pas aux attaquants potentiels d’ajouter un nombre illimité de nœuds à volonté.

En plus de cela, nous cherchons également à apporter des modifications pour nous aider à nous informer de l’état exact du routage pendant le démarrage du réseau et au-delà, nous avons deux PR en cours [Indication pour le démarrage de la section et le déclenchement de l’événement PromotedToAdult] (https: / /github.com/maidsafe/sn_routing/pull/2233) et notifier lorsque la clé est modifiée pendant le déplacement. Ces changements en cours nous aideront à nous assurer que le routage se comporte comme prévu et devrait être achevé prochainement, une fois que les conceptions d’API seront convenues entre les nœuds et le routage.

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