Actualités du développement Safe 🇫🇷 25 février 2021

Dimitar · Février 26, 2021, 1:21

Ceci est une traduction automatique. L’original en anglais est ici: Safe Network Dev Update - February 25, 2021

Résumé

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

Il y aura une réunion virtuelle Community Safe Chat le vendredi 26 février (demain) à 21h00 GMT. Détails complets ici.
L’identification et l’élimination des bogues se poursuivent, ainsi que plusieurs améliorations d’efficacité alors que nous faisons des progrès significatifs cette semaine sur la voie d’un réseau de test public.
Il y a eu quelques PR importants de sn_routing fusionnés cette semaine, en particulier PR # 2323, PR # 2328 et PR # 2336. Détails complets ci-dessous.
Deux autres PR importants sn_routing, # 2335 et # 2336, tous deux critiques pour un réseau de test stable, sont maintenant levés et devraient être revus et fusionnés dans les prochains jours.
@scorch a soumis un PR pour (enfin!) résoudre « ce problème » où les versions de la CLI elle-même et les binaires externes tels que sn_node ou sn_authd sont confus.
Découvrez l’excellente recherche et analyse de @bzee ici alors qu’il cherche à améliorer et mettre à jour le liaisons à Node.js.

Community Safe Chat: vendredi 26 février, 21h00 GMT

Les efforts de marketing axés sur la communauté se poursuivent grâce au travail de @sotros25, @m3data, @piluso et d’autres. Des efforts inlassables, il faut le dire!

Il y a eu des discussions et des stratégies sur le forum, et en petites réunions de zoom sur ces dernières semaines, dont celle-ci où nous discutons de certaines études de marché de @sotros25 sur des projets adjacents.

Nous sommes ravis d’avoir un autre hang-out virtuel ce vendredi, avec une invitation ouverte à tous les membres de la communauté à participer.

Les 45 premières minutes de la conversation porteront sur la stratégie de marketing communautaire. Après cela, nous ouvrirons la parole à une discussion plus large sur le réseau sécurisé. L’objectif est d’aider à définir la stratégie marketing et d’utiliser également le contenu de ces discussions sous forme de vidéo pour renforcer la sensibilisation et l’engagement.

Veuillez noter que cet appel sera enregistré, diffusé et rediffusé, de sorte que ceux dont les horaires ou les fuseaux horaires ne fonctionnent pas tout à fait ne manqueront pas.

Tous les détails et le lien pour adhérer seront disponibles ici.

Safe Client, Nodes et qp2p

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

Le travail ici cette semaine a consisté à stabiliser les réseaux. Nous avons commencé la semaine à enquêter sur un comportement étrange, vu uniquement avec certains journaux activés, ce qui nous a finalement conduits à un petit extrait de routage où nous maintenions un verrou 'pendant la durée d'un long appel asynchrone (envoi d'un message client), qui provoquait une impasse dans les réponses. C'était difficile à comprendre; mais une fois que nous avons réalisé que le verrou était appelé dans le cadre de l'instruction if`, nous devions simplement le déplacer et nous assurer que le verrou était supprimé une fois que nous avions ce dont nous avions besoin. Cela a fait revenir les réponses des clients.

Avec les modifications apportées à l’infrastructure de messagerie la semaine dernière, les nœuds n’incluent plus de logique d’agrégation des signatures, reposant entièrement sur la capacité du routage à le faire. Auparavant, nous n’avions que l’agrégation à la source, où le routage regroupait les signatures chez les anciens avant de les envoyer à la cible, ce qui entraînait l’envoi du message avec la signature agrégée à la destination plusieurs fois, les doublons étant filtrés au nœud cible. En déplaçant l’agrégation de signatures vers la destination, nous pouvons réduire une partie de la charge des anciens et réduire considérablement le nombre de messages échangés. Nous avons ajouté la prise en charge de l’accumulation de destination dans le routage et l’avons utilisée dans sn_node pour la communication entre une section et ses adultes porteurs de morceaux. Avec les deux correctifs ci-dessus, nous avons maintenant tous les tests clients qui passent par rapport à une seule section, avec un code de nœud massivement simplifié. Cependant, un PR de suivi est nécessaire pour couvrir un cas d’utilisation supplémentaire, qui concerne les communications entre les aînés d’une section et les aînés d’une autre section, une partie du flux de récompenses (car les fonds de la section sont gérés par une section, mais détenus / vérifiés dans une autre section). Ceci est couvert au moment où nous parlons, et devrait être fusionné avant la fin de la semaine.

Sur ce front, avec une petite mise à jour de certains événements de routage, nous obtenons maintenant notre frère de section PublicKey sur le fractionnement afin que nous sachions où envoyer des jetons pour remplir les portefeuilles de section enfant résultants. Après un certain débogage de flux, cela semble être en cours et nous débogageons maintenant une petite boucle de routage sur le fractionnement, où les informations de section ne sont pas détectées correctement, et nous transmettons à plusieurs reprises les mêmes (fausses) informations à un nouveau nœud. Nous refactorisons également le modèle de communication entre les clients, les nœuds et leurs sections, où les clés de section précédemment obsolètes provoquaient des bogues dans les flux de récompenses et de transfert. Par conséquent, nous allons maintenant appliquer la vérification et la mise à jour des connaissances de PublicKey avec chaque message qui serait envoyé sur le réseau, et par conséquent, tous les pairs seront à jour avec les dernières connaissances du réseau.

Pour commencer, la division des fonds de la section sera un transfert enchaîné après l’autre, car nous n’avons toujours pas de transferts `` un à plusieurs ‹ ›, et le chaînage était une tâche triviale, fonctionnant assez bien pour un testnet. Cependant, avec la refactorisation de TransferAgreementProof il y a quelques mois en un débit signé et un crédit signé, nous pouvons maintenant implémenter relativement facilement des transferts" un-à-plusieurs "en incluant un ensemble de crédits. Un goodie pour plus tard :).

En tant que tâche de moindre priorité, et parallèlement à ce qui précède, nous avons commencé à préparer la mise à niveau vers une nouvelle version de Quinn qui nous permet enfin de passer à la stable Tokio v1. Nous venons d’essayer et préparons les PR pour que cette migration se produise dès la publication de la version 0.7.0 de Quinn.

Une autre amélioration qui a été apportée cette semaine concerne la suppression des données privées. Avant les modifications nouvellement fusionnées dans self_encryption et sn_client, la suppression d’un objet blob privé signifiait la suppression uniquement de l’objet blob racine qui était la carte de données des données réelles auto-chiffrées et stockées sur le réseau. Notre dernier ajout à l’équipe, @kanav, a mis en œuvre une approche de suppression récursive qui supprime les morceaux individuels, ainsi que les morceaux qui stockent la (les) carte (s) de données, réalisant la suppression dans un vrai sens.

API et CLI

@scorch a soumis un PR pour supprimer l’option -V des sous-commandes CLI afin d’éviter toute confusion entre la version de la CLI elle-même et la version de binaires externes tels que sn_node ou sn_authd. Ce changement comprenait également l’ajout d’une sous-commande bin-version aux sous-commandes $ safe node et $ safe auth pour récupérer la version des binaires externes, afin que la sémantique soit claire, ainsi que la distinction entre la CLI version et les versions sn_node ou sn_authd.

Actuellement, la bibliothèque qjsonrpc est implémentée pour prendre en charge le standard JSON-RPC 2.0. Cela dit, certains codes d’erreur définis dans la spécification n’ont pas été exposés par la caisse. Cela signifie que les consommateurs doivent redéfinir eux-mêmes les mêmes constantes, ce qui n’est pas nécessaire puisqu’elles font en quelque sorte partie de la mise en œuvre. Pour cette raison, @scorch a également soumis un PR pour exposer ces codes d’erreur en tant que constantes de qjsonrpc.

Comme mentionné dans la section précédente, nous avons également essayé de nous préparer pour la mise à niveau vers Tokio v1, nous avons donc préparé les caisses CLI et authd pour une telle mise à niveau en effectuant quelques tests préliminaires.

CRDT

Nous avons itéré sur le CRDT sous-jacent au type de séquence dans sn_data_types. Auparavant, Sequence était implémenté avec LSeq. Nous avons essayé une [List] plus simple(https://github.com/rust-crdt/rust-crdt/blob/master/src/list.rs) pour résoudre certaines paniques avec des insertions profondes, puis nous sommes passés à GList pour prendre en charge le cas d’utilisation de croissance uniquement. À l’analyse, tous ces CRDT ne font pas le versionnage de modèle comme nous le souhaiterions. Ils essaient de linéariser l’ordre des documents, alors qu’en réalité, un historique de document forme un DAG. Nous avons une conception pour un registre CRDT Merkle-DAG qui nous permettrait de modéliser fidèlement l’historique des documents et de lire les versions les plus récentes.

Nous avons également commencé à supprimer la mutabilité des politiques de nos types de données mutables, c’est-à-dire de nos types de données CRDT comme Sequence. Dans notre implémentation actuelle, nous avons essayé de résoudre tous les types de conflits que des mutations de politique simultanées peuvent créer sur des données CRDT. Cela s’est avéré rendre les choses assez compliquées sans même couvrir tous les scénarios possibles de résolution des conflits. Par conséquent, nous avons décidé de commencer à adopter une approche différente où les politiques deviennent immuables une fois qu’ellese été défini lors de la création d’un contenu. Changer une politique signifiera alors le clonage du contenu sur une nouvelle adresse avec la nouvelle politique, et un mécanisme pour relier ces différentes instances peut éventuellement être créé et utilisé uniquement au cas par cas par les applications.

BRB - Diffusion fiable byzantine

Notre tentative d’intégrer le prototype de système de fichiers sn_fs avec BRB a mis à nu quelques aspérités. La raison en est que sn_fs reçoit les opérations du noyau du système d’exploitation plus rapidement qu’elles ne peuvent être appliquées par BRB. À cette fin, nous avons proposé quelques solutions connexes: 1) contourner la couche réseau lors de l’envoi d’une opération à soi-même, et 2) suivre le moment où les pairs ont reçu ProofOfAgreement afin que nous puissions éviter d’envoyer l’opération suivante jusqu’à 2 / 3 des pairs ont appliqué l’op en cours. Cela est nécessaire pour répondre à l’exigence de commande à la source de BRB. L’ordre des sources signifie que les opérations provenant de la même source (acteur) doivent être ordonnées séquentiellement, mais les opérations de nombreux acteurs différents peuvent être traitées simultanément.

Également dans le cadre de l’intégration sn_fs, nous avons modifié la caisse brb_dt_tree pour prendre en charge l’envoi de plusieurs opérations d’arborescence dans une seule opération BRB. Cela nous donne effectivement une propriété de transaction atomique pour appliquer des opérations CRDT liées logiquement de manière tout ou rien. Nous avons l’intention d’utiliser ce même modèle dans d’autres types de données BRB.

Routage

Plan de projet

Cette semaine, nous avons fusionné un PR en changeant la façon dont les messages clients sont traités, et ils peuvent maintenant être acheminés à travers le réseau de la même manière que les messages des nœuds. Cela signifie qu’un client peut envoyer une demande en dehors de sa section et recevoir une réponse même lorsque le client n’est pas directement connectable par le (s) destinataire (s) de la demande en raison de NAT restrictif ou de problèmes similaires.

Comme détaillé dans la section Nodes ci-dessus, nous avons également implémenté accumulation de signature de message à destination, ce qui signifie que les utilisateurs du routage n’ont plus à implémenter ce flux manuellement , résultant en un code plus simple.

Enfin, la fork resolution PR est maintenant en cours de révision. Au cours du travail sur ce PR, nous avons découvert quelques bogues supplémentaires qui n’étaient pas liés à la manipulation des fourches. Tout au long de la semaine, nous avons été occupés à les déboguer et à partir d’aujourd’hui, il semble que nous les ayons presque tous résolus. Les résultats des tests de résistance internes semblent très prometteurs, et nous avons réussi à exécuter un réseau localhost avec ** 111 (!) Nœuds ** sur une seule machine et tout s’est bien passé. Un PR avec ces correctifs est actuellement en état de * brouillon *, et devrait être prêt pour examen 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é. Alors ne soyez pas timide, rejoignez-nous et créons ensemble le réseau sécurisé!