Actualités du développement Safe 🇫🇷 25 mars 2021

Dimitar · Mars 26, 2021, 4:03

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

Résumé

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

L’appel pour les membres bénévoles du comité du Fonds BambooGarden est maintenant terminé! Nous avons 8 membres respectés et expérimentés de la communauté en place.
Avec la confirmation du comité du Fonds BambooGarden, nous allons passer à la mise en place de canaux de communication et pouvoir inviter les premières demandes de fonds.
Nous avons apporté plusieurs modifications relativement petites à la base de code client au cours de la semaine dernière, ce qui nous a permis de voir maintenant la majorité des tests clients passer de manière cohérente dans un réseau multi-sections.
Avec la stabilisation du client, nous avons été en mesure de réactiver les paiements de récompense, et nous travaillons maintenant sur des problèmes et des optimisations.
La mise en œuvre de la messagerie paresseuse se poursuit dans tous les domaines.
D’autres questions sont envoyées à l’AMA, et une autre réponse aussi voir la dernière vidéo de @jimcollinson ici
Nous avons publié un résumé des fonctionnalités pour le prochain testnet plus tôt dans la semaine.
Surveillez régulièrement le fil de discussion Like This Tweet sur le forum pour obtenir d’excellents conseils sur la manière de promouvoir le réseau sécurisé, et composants environnants, avec un simple clic de bouton!

Mise à jour du fonds BambooGarden

Un grand merci à chacun des bénévoles du comité du Fonds BambooGarden. Nous avons eu 8 bénévoles qui ont offert leur temps et nous pensons donc que c’est un bon point pour fermer le comité, pour l’instant, et le maintenir à un nombre gérable.

Nous avions initialement l’intention d’avoir 3 membres du comité communautaire à un moment donné, mais nous avons décidé de changer cela pour que ces 8 bénévoles fassent partie du comité. Ce changement présente plusieurs avantages, comme nous permettre de tirer le meilleur parti de l’expérience et de l’expertise variées qu’ils offrent. Il est également inévitable qu’il y aura des moments où certains membres du comité auront d’autres engagements, donc ce nombre plus élevé signifie que nous pouvons continuer sans heurts quoi qu’il en soit. Les députés pourront s’abstenir lorsqu’ils ne pourront pas le faire, ou même s’ils ne pensent pas être qualifiés pour juger une demande, sans avoir à craindre de laisser le comité court.

Le personnel de MaidSafe sera toujours composé d’environ 3 membres du comité. Nous avons également ajouté une condition selon laquelle MaidSafe aura le droit à un « veto » sur toute demande de financement, c’est-à-dire le droit de rejeter des propositions qui, selon nous, ne répondent pas aux objectifs, aux principes fondamentaux et aux valeurs de MaidSafe, ou qui ne le sont pas. t répondre au but et aux objectifs initiaux pour lesquels ce fonds a été créé et dont MaidSafe a été invité à se porter garant. Notez que le droit de veto sert uniquement à rejeter les candidatures et non à les forcer lorsque le comité au sens large les a rejetées.

Tout cela a été communiqué aux bénévoles du comité au cours des derniers jours, ainsi que d’autres décisions importantes. Par exemple, le comité sera tous membres d’un forum de discussion distinct, où nous pourrons discuter et voter sur les candidatures. MaidSafe a également proposé des domaines immédiats que nous avons identifiés comme urgents en prenant des mesures pour atteindre l’objectif numéro un de ce fonds, qui est «d’accélérer le déploiement du Safe Network». Ces domaines sont:

Documentation formelle - nous pensons que le projet gagnerait énormément à ce que nos algorithmes soient officiellement documentés. Peut-être qu’un rédacteur technique ou autre qui a de l’expérience dans l’écriture d’algorithmes formels et d’articles serait en mesure d’offrir de la valeur ici. La mise en place de ces documents formels aide les développeurs intégrés qui s’impliquent, tout en aidant les auditeurs externes à qui nous demanderions à un moment donné de vérifier notre code pour les failles de sécurité, les bogues, etc.
Expertise CRDT supplémentaire pour aider à pousser cela au niveau suivant.
Expertise consensuelle supplémentaire.
Expertise de réseautage supplémentaire.

Si vous avez des idées de demandes de fonds dans ces domaines, ne les envoyez pas pour le moment, mais vous pouvez commencer à y réfléchir un peu plus en vue de l’ouverture du processus de demande.

Nous proposons également que, une fois que le réseau de test est en ligne, nous demandons des applications pour augmenter la taille de notre équipe d’ingénierie afin que nous puissions avancer à un rythme plus rapide. La raison pour laquelle nous disons ici après testnet est que l’intégration préalable de nouveaux ingénieurs serait une distraction du travail de testnet.

Au cours des prochains jours, les bénévoles du comité seront tous invités à se joindre à un forum de discussion distinct où nous formaliserons ensemble certaines des lignes directrices du comité. Nous annoncerons ensuite que nous sommes prêts à accepter nos premières demandes de financement, avec tous les détails des domaines initiaux spécifiques, tels que ceux outlici-dessus, auquel nous voulons limiter le premier lot d’applications. Nous fournirons également tous les détails sur la manière de soumettre des candidatures et ce que nous attendons des candidatures.

Safe Client, nœuds, routage 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é
Plan de projet de routage sécurisé

Améliorations du code client

Après avoir fusionné les nouvelles modifications de la division du portefeuille de section dans les dépôts au début de la semaine, nous avons apporté diverses améliorations au code client. Il y a eu quelques petits refactors pour simplifier les choses, ainsi que des mises à jour pour permettre plus de flexibilité avec les nombres d’Aînés (car ils augmentent avec les changements de supermajorité), mais aussi pour utiliser ce même calcul de supermajorité pour la gestion des réponses (c’est-à-dire obtenons-nous le même réponse à une requête de X Elders et peut donc lui faire confiance). Nous avons également ajouté quelques correctifs pour les problèmes qui empêchaient le client de démarrer dans la bonne section dans un réseau multi-sections. Avec cela en place, nous avons pu voir la majorité des tests clients passer de manière cohérente dans un réseau multi-sections.

Récompenses

Après les fusions mentionnées ci-dessus, nous avons réactivé les paiements de récompense et avons inspecté le comportement au cours de plusieurs fractionnements. Quelques petits problèmes ont été trouvés et résolus, et quelques autres sont encore en cours de traitement sur les cas où il y a une consommation excessive de CPU et de mémoire après quelques fractionnements.

Même si les paiements de récompense fonctionnent maintenant, il semble que nous pourrions les simplifier encore plus, et nous essaierons donc de supprimer un gros morceau de logique gérant le paiement lors de la relocalisation des nœuds, et d’inclure à la place les paiements de récompense au portefeuille de la section. diviser.

Messagerie paresseuse

Parallèlement à cela, nous avons mis à jour les implémentations de messagerie paresseuse dans les bibliothèques et avons adapté sn_node au code de messagerie mis à jour. La mise à jour de sn_routing pour ces changements a été une grande tâche car chaque message de routage nécessitera désormais un en-tête propre qui fournit les détails de la destination, qui seront vérifiés par le destinataire pour l’exactitude et utilisé pour mettre à jour l’expéditeur ou le destinataire avec le courant État du réseau, s’ils sont à la traîne. Les implémentations de base sont en place et nous mettons à jour les derniers tests là-bas. Une fois que nous aurons cela, nous serons libres de créer le modèle de messagerie paresseux dans sn_node pour permettre une gestion facile de la mise à niveau des nœuds.

Routage des voisins

Lors du routage, nous avons supprimé le concept de voisins. Pour rappel, les nœuds doivent conserver des informations sur les autres sections du réseau afin de savoir (entre autres) comment leur envoyer des messages, et ainsi de suite. Nous avions l’habitude de ne conserver que les sections qui étaient « voisines » de notre section. Cela a été défini arbitrairement comme les sections dont le préfixe diffère de notre préfixe d’exactement un bit. Cela signifiait que si nous voulions envoyer un message à une section qui n’était pas notre voisine, nous devions le relayer via nos voisins. Nous avons réalisé il y a longtemps que c’était une complexité inutile et nous avons décidé de la supprimer et cette semaine nous y sommes finalement parvenus. Alors maintenant, les nœuds conservent des informations sur toutes les sections du réseau, ce qui signifie qu’il n’est pas nécessaire de relayer quoi que ce soit car ils connaissent toujours les destinataires finaux. Cela simplifie la conception et améliore les performances. On peut se demander si cela nécessite une énorme quantité de mémoire, mais il s’avère que ce n’est pas le cas. Nous avons calculé que nous pouvons prendre en charge plusieurs centaines de milliers de sections avant que la mémoire ne devienne un problème. Nous réglerons ce problème une fois sur place. Dans le cadre de ce changement, nous avons également remanié la logique de messagerie paresseuse et l’avons extraite dans un module séparé, ce qui nous a permis d’y ajouter plus de tests unitaires, augmentant ainsi la confiance dans le code.

API et CLI

Après avoir finalisé les modifications requises pour le nouveau type de données CRDT Register dans les caisses sn_node et sn_client, nous avons commencé à adapter la base de code sn_api et son API pour la supporter.

L’aspect principal de ces changements est lié au fait que nous exposerions désormais à l’utilisateur de l’API la possibilité de rencontrer des branches dans les données. Ces branches pourraient avoir été causées involontairement par l’application lorsque plusieurs instances écrivent simultanément des valeurs dans le même Register, mais elles pourraient très bien être créées intentionnellement par l’application, par exemple une application blockchain où les fourchettes se produisent simplement et sont également résolues.

Nous avons également commencé par adapter toutes nos abstractions (NRS, FilesContainers et Wallets) pour utiliser ce type de données. C’est là que nous voyons un plus grand défi en termes d’UX, étant donné que la lecture d’un FilesContainer pourrait entraîner l’affichage de plus d’un état, comme expliqué ci-dessus. Ainsi, nous recherchons maintenant la meilleure façon d’exposer cela dans notre API afin que l’utilisateur et / ou le développeur d’un application peut décider quoi faire dans ces situations. Par exemple, l’utilisateur final peut être invité à décider non seulement quelle branche lire, mais aussi peut-être comment les fusionner à nouveau en une seule branche. Comme vous pouvez déjà le voir, il peut y avoir plusieurs façons pour l’utilisateur ou le développeur de résoudre l’occurrence de branches dans les données, et c’est maintenant le principal moteur de la nouvelle conception de ces API.

En ce qui concerne la CLI sécurisée, nous devrons prendre des décisions sur les options à offrir à l’utilisateur final pour résoudre les branches de données. Un exemple ici étant lors de la récupération d’un FilesContainer avec deux états non résolus, la CLI peut probablement présenter des informations détaillées à leur sujet et laisser l’utilisateur décider lequel rechercher.

CRDT

Nous avons poursuivi nos recherches sur le travail des compteurs délimités, et cette semaine, nous avons travaillé pour les rendre tolérants aux pannes byzantines et pour mettre en œuvre un PoC. Espérons que dans la semaine prochaine, nous aurons quelque chose de concret à partager sur ce front.

Nous avons également développé la conception d’un nouveau CRDT MultiMap basé sur MerkleReg. Ce sera probablement la base des types de données de sous-domaine NRS, ainsi qu’une structure flexible pour d’autres applications qui ont besoin d’une carte comme le type de données.

Communauté et marketing

D’autres questions se posent à l’AMA, et une autre réponse trop. Cette fois, @jimcollinson en aborde un de @dimitar: _Est-il trop tard pour la confidentialité en ligne? N’ont-ils pas déjà toutes nos informations? _

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