Ceci est une traduction automatique. L’original en anglais est ici: Safe Network Dev Update - December 10, 2020
Sommaire
Voici quelques-unes des principales choses à souligner depuis la dernière mise à jour du développeur:
sn_clientv0.44.0 a été publié cette semaine, la première version du client depuis juillet.- Nous avons terminé et fusionné l’implémentation de la duplication des blocs Blob lorsqu’un adulte quitte le réseau - maintenant disponible dans sn_node v0.25.9.
- Notre consultant a mis au point un algorithme codé, testé et fonctionnel pour l’adhésion dynamique.
Mise à jour générale
Une rapide mise à jour générale de nos progrès vers le prochain testnet.
Nous sommes tous tête baissée en rassemblant toutes les pièces pour le prochain testnet. Comme prévu, il y a une chasse aux bogues et des ajouts de dernière minute. Une chose que nous n’aurons pas le temps d’inclure dans ce réseau de test est la nouvelle adhésion à BRB (Byzantine Reliable Broadcast). L’adhésion à la BRB est une étape vraiment importante, mais pour l’instant, nous cherchons à tester tellement d’autres pièces mobiles que nous avons convenu que l’accent devrait être mis sur le lancement de cette phase I dès que possible, nous pourrons alors nous concentrer pleinement sur BRB.
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 vu la première release et publish de sn_client depuis juillet. Ce référentiel se composait auparavant de plusieurs caisses sous la bannière Safe Client Libs, mais comme les lecteurs réguliers ici le savent sans doute, nous avons fortement remanié ce qui nous a conduit à supprimer plusieurs milliers de lignes de code que nous estimions inefficaces, boguées. ou inutile. Il s’agit maintenant d’une seule caisse sn_client, publiée sous ce nom pour la première fois. Cela rejoint sn_node et sn_routing dans les nouvelles versions importantes de crate au cours des 2 dernières semaines, et nous espérons donc démontrer les progrès que nous faisons alors que les principaux éléments commencent à se mettre en place. Cette version ne signifie pas que nous en avons terminé avec sn_client, cela signifie simplement que nous la considérons suffisamment stable pour introduire un pipeline de livraison continue. 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 essayé de localiser la source d’un problème de débordement de pile qui est apparu danssn_node. Il semble au départ qu’il n’y ait pas de source spécifique, mais que l’utilisation de la pile a simplement augmenté au fil du temps. Cela ne se produisait à l’origine que sur Windows, où nous avons découvert que la taille de la pile par défaut est de 1 mégaoctet, ce qui est faible par rapport à Ubuntu, qui a 8 Mo. Réduire la taille de la pile sur Ubuntu nous permet de répliquer cela, ce qui est bien. Donc, avec cela, nous avons étudié cela plus en détail et les options pour éviter que cela ne se produise.
Nous avons terminé l’implémentation de la duplication des blocs Blob lorsqu’un adulte quitte le réseau. Cette fonctionnalité, qui a été temporairement désactivée pendant certains des refactors dans le repo sn_node pour apporter de l’agriculture et des récompenses, est désormais compatible avec la nouvelle structure du code, testée et fusionnée. Cette mise en œuvre jette également les bases des prochaines tâches sur nos cartes - distribution de données sur le désabonnement des aînés, les événements de promotion et les divisions du réseau. Nous avons déjà quelques idées en tête et commencerons bientôt la mise en œuvre.
BRB - Diffusion fiable byzantine
Bonnes nouvelles! Notre consultant a mis au point un algorithme de travail pour l’adhésion dynamique. Il s’agit d’une œuvre originale qui utilise une horloge de génération avec une opération de jointure ou de sortie autorisée par acteur, par génération. Cet algorithme a déjà été codé avec une suite de tests, et tous les tests réussissent.
La prochaine étape consistera à l’intégrer à la mise en œuvre DSB existante. Nous aurons donc à la fin un protocole de négociation d’appartenance dynamique distinct mais complémentaire du protocole DSB pour la transmission BFT des opérations / données régulières.
Routage
Cette semaine, pour renforcer notre journalisation et faciliter le débogage, nous avons décidé de changer de routage pour utiliser tracing, au lieu de la caisse log . Cela nous permet d’utiliser une journalisation et des étendues structurées. Le PR pour ce commutateur a maintenant été fusionné. Notre intention est de passer à l’utilisation du «traçage» dans d’autres caisses au cours des prochaines semaines.
Après une discussion plus approfondie sur la façon et le moment où la vérification des ressources est utilisée, nous avons décidé que les nœuds déplacés devraient être approuvés et qu’il ne serait donc pas nécessaire qu’ils subissent la resouprocédure d’épreuvage à nouveau. Le PR Ne pas exiger de preuve de ressources des nœuds déplacés a maintenant été fusionné pour refactoriser ce comportement. Dans le même PR, nous avons également corrigé quelques bogues et échecs de test que nous avons repérés grâce à la journalisation améliorée fournie par la caisse de traçage susmentionnée.
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é. Alors ne soyez pas timide, rejoignez-nous et créons ensemble le réseau sécurisé!