Ceci est une traduction automatique. L’original en anglais est ici: Safe Network Dev Update - February 4, 2021
Sommaire
Voici quelques-unes des principales choses à souligner depuis la dernière mise à jour du développement:
- La version testnet attendue aujourd’hui a dû être suspendue car nous ne pouvions pas obtenir de récompenses à temps, et désactiver ce que nous avions jusqu’à présent ne le réduisait toujours pas.
- Être capable de voir les fractionnements du réseau se produire ces derniers jours, avec les derniers développements en, nous a permis de trouver et d’écraser des problèmes multi-sections auparavant inconnus.
- Le travail de simplification de l’API crate
qp2ppour gérer les connexions et les flux en interne et soulager une partie de la pression sur le consommateur de l’API, est maintenant en cours d’examen par les pairs. - Un BRB PR pour corriger la perte de paquets aléatoire qui interférait avec les opérations BRB a été levé, testé et devrait être fusionné prochainement.
- Un merci spécial aux membres de la communauté @bzee, @mav et @scorch pour leurs efforts au cours de la semaine dernière avec la fusion de plusieurs PR communautaires.
Statut Testnet - en attente
Notre objectif au début de la semaine était d’inclure des récompenses dans un réseau de test public et de l’ouvrir à la communauté aujourd’hui, mais il restait encore plusieurs changements nécessaires pour le faire fonctionner, et nous n’avons pas été en mesure de terminer cela pour aujourd’hui.
À cause de cela, nous avons supprimé le flux de récompenses pour voir si nous pouvions obtenir un réseau suffisamment stable et avons fait des progrès avec cela, mais nous avons rencontré des difficultés en cours de route qui nous ont ralentis.
Notre statut actuel est que nous avons maintenant une dernière version d’un testnet en interne mais que nous n’avons pas eu de temps réel pour le tester. Nous prévoyons qu’il y aura probablement d’autres problèmes mineurs, nous aimerions donc avoir du temps pour tester cela en interne avant de le rendre public en toute confiance.
Nous n’avons pas encore complètement discuté et décidé si nous publierons un testnet avec les récompenses exclues, ou si les problèmes que nous rencontrons signifient que nous ferions mieux de continuer avec la mise en œuvre complète des récompenses, ce qui devrait prendre quelques jours de plus. (plus les tests). La stabilité du testnet que nous avons actuellement, avec les récompenses désactivées, devrait nous aider à décider, mais dans tous les cas, nous n’envisageons pas de mettre en place un testnet un vendredi, nous préférerions attendre la semaine prochaine pour nous permettre de soutenir pleinement il.
La grande majorité de notre temps cette semaine a été consacrée au testnet, mais voici un résumé de certains des travaux généraux que nous avons accomplis …
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, un PR de @bzee qui permet la configuration programmatique des nœuds a été fusionné avec master aujourd’hui. Bon travail! :mains levées:
Nous avons créé un nouveau trait Signing dans sn_data_types pour faire abstraction de la signature et de la vérification de nos différents flux dans les nœuds / transferts, et avons testé et corrigé des bogues certains flux centrés sur l’intégration des nouvelles requêtes d’infrastructure de routage. Cela a déplacé les opérations d’amorçage vers le routage lui-même, par opposition à l’intérieur des nœuds. Auparavant, nous étions limités à interroger uniquement les anciens (et les anciens de notre propre section) pour les informations d’amorçage du réseau. Déplacer ceci vers sn_routing signifie que nous pouvons interroger n’importe quel nœud et récupérer les informations de contact correctes … permettant essentiellement aux clients de fonctionner sur un réseau multi-sections.
Au-delà de cela, nous avons débogué divers problèmes avec les fractionnements de sections maintenant que nous avons pu le voir en action (bien que limité en raison des problèmes susmentionnés), et l’application Web node-logger de @ mav s’est avérée être un excellent outil. pour voir rapidement les flux entre nœuds et réduire la sortie du journal de notre réseau multi-sections en quelque chose d’un peu plus lisible par l’homme.
Nous travaillons également sur le flux de rattrapage des données qui est requis pour les Aînés nouvellement promus dans une section, qui auraient besoin de se mettre à jour avec toutes les données que les autres Aînés conservent. Étant donné que ces données seraient relativement volumineuses, nous voudrions idéalement diffuser les données afin que le nœud ne soit pas bloqué avec cette tâche, par conséquent, nous allons également bricoler un peu avec qp2p pour activer directement les données en continu. aux nœuds sur demande.
Au cours de la semaine dernière, nous avons fait quelques ajouts à la caisse qp2p pour gérer les connexions et les flux en interne afin de soulager une partie de la pression sur le consommateur d’API. Ce travail est terminé et en cours d’examen dans ce PR, la nouvelle API étant également intégrée au routage avec tous les tests réussis. Nous nous retenions pour qu’une itération publique de testnet soit publiée avant de les fusionner, mais avec le retard, nous pourrions décider de fusionner beforehand. Les tests ont montré que ce changement a rendu les choses considérablement plus simples et cela rendra le débogage de tout autre problème de réseau p2p beaucoup plus simple.
API et CLI
Plusieurs autres PR communautaires ont été soumis la semaine dernière, qui ont été fusionnés et font déjà partie d’une nouvelle version de CLI, qui vient d’être publiée aujourd’hui (v0.18.0).
Grâce à ce PR soumis par @mav, la validation NRS exclut désormais un plus grand jeu de caractères qui n’aurait jamais un but raisonnable étant inclus dans aucun URL. La limite de longueur totale des URL NRS de 255 octets, où chaque sous-nom ne peut pas dépasser 63 octets, est désormais appliquée avec cet autre PR .
Les commandes CLI safe auth donnent maintenant à l’argument --config la priorité sur l’utilisation des variables d’environnement, ceci est également maintenant en place dans la nouvelle version grâce à PR # 700, également soumis par @mav.
Du côté qjsonrpc PR # 698 soumis par @Scorch implémente un exemple d’application client / serveur de base utilisant l’API qjsonrpc. Un client qjsonrpc envoie un message ping à un serveur qjsonrpc, et le serveur répond avec un message ack. Cet exemple d’application montre simplement et clairement comment qjsonrpc peut être utilisé pour créer n’importe quelle application utilisant JSON-RPC sur QUIC. Il y a eu beaucoup plus d’activités et d’exploration faites par @Scorch avec plus d’idées autour de qjsonrpc - pour ceux qui sont intéressés par plus de détails et / ou à participer à cet effort, jetez un œil à son propre fil de développement où il a partagé tout it. :taper:
BRB - Diffusion fiable byzantine
Nous avons généré un PR dans brb_node_qp2p pour corriger les pertes de paquets aléatoires qui interféraient avec BRB opérations. Cela rend le nœud stable au cas où des membres de la communauté technique souhaiteraient interagir « de manière pratique » avec BRB dans un environnement CLI. Les instructions d’utilisation de base pour ce faire sont ici (Notez que vous devez créer le code vous-même, au moins pour l’instant).
Les discussions de conception pour l’intégration de BRB avec BLS Distributed Key Generation (DKG) se sont poursuivies avec plusieurs options présentées. L’accord semble se fondre autour de l’une des options. Des détails sur ces plans devraient être fournis dans les futures mises à jour au fur et à mesure que les travaux commenceront.
Routage
Nous avons fait un premier pas en déplaçant toutes les définitions de message de sn_routing dans la caisse sn_messaging, où non seulement les définitions de message résideront, mais aussi toute logique liée à leur sérialisation. L’itération initiale de ceci, avec un type de message unifié pour les clients et les nœuds se connectant à une section, est maintenant en place dans les dernières versions de sn_routing et sn_client. Notre prochaine étape à cet égard est de déplacer enfin toutes les définitions de types de messages dans la caisse sn_messaging, ce qui nous permet de découpler la logique sn_routing réelle de ce qui deviendrait l’API du réseau.
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é!