Actualités du développement Safe 🇫🇷 22 juin 2023

Dimitar · Juin 25, 2023, 7:13

Ceci est une traduction automatique. L’original en anglais est ici: Update 22 June, 2023

À l’heure où nous parlons, InstallNet fonctionne toujours bien, et nous en avons déjà tiré quelques leçons utiles, testé certaines hypothèses et fait des plans d’amélioration. L’itération actuelle consiste vraiment à tester le processus safeup que @ChrisO a mis en place pour automatiser l’installation du client safe, safenode et testnet sur macOS, Windows, Linux et, finalement, sur d’autres plates-formes également.

L’inspiration, comme vous le savez peut-être, est « Rustup » qui fait la même chose pour l’écosystème du langage Rust. Je suis sûr que vous conviendrez que même s’il y a quelques bizarreries à régler, cela fait déjà une meilleure UX.

Merci comme toujours à tous ceux qui se sont mêlés. Nous ne pouvons pas faire cela sans vous.

InstallNet - résultats et actions

Certains des problèmes rencontrés par les testeurs de la communauté sont dus à l’incompatibilité des nouvelles versions de « safe » et de « safenode » avec les anciennes. Les mises à jour sont nombreuses et rapides, et parfois elles contiennent changements de rupture. À l’avenir, les réseaux de test devront être liés à des versions spécifiques ici (jusqu’à ce que les mises à niveau fonctionnent correctement).
L’une de ces modifications majeures est que nous ajoutons désormais un « RecordHeader » à chaque élément de données. Cela nous permet de faire la distinction entre un morceau, DBC et un registre, puisque Kademlia stocke tout sous forme d’enregistrement dans le réseau. Les nœuds plus anciens ne peuvent pas gérer ces en-têtes.
L’installation de safeup en tant que root/sudo (Linux) place les fichiers binaires à différents endroits, dont nous devrons garder une trace.
La journalisation/traçage doit être nettoyée et standardisée - nous sommes en train d’examiner nos options ici.
Les binaires Safe et safenode étaient bogués sur iMac High Sierra 10.13.6, Arm v7. Un correctif est déjà disponible pour cela, mais continuez à recevoir les rapports et nous ferons de notre mieux pour les prendre en charge.
L’emplacement de stockage de bloc par défaut doit être divisé en sous-répertoires, un par nœud sur cette machine.
Cela fonctionne sur Android !
Nous devons affiner les instructions pour les utilisateurs de Windows.
Nous n’avons pas encore résolu le problème où les nœuds mettent beaucoup de temps à recevoir des morceaux. Il se peut qu’à mesure que les buckets Kademila (groupes proches) se remplissent, de nouveaux nœuds « fermés » soient promus uniquement lorsqu’un autre pair ne répond plus, suggérant que nous avons un regroupement de nœuds au démarrage, peut-être en raison de la façon dont nous ne fournissons qu’un sous-ensemble limité de nœuds pour le contact initial. Nous creusons ici.

Progrès général

@Joshuef et @qi_ma se sont penchés sur le problème des nœuds inactifs, ce qui entraîne de nombreuses boucles de connectivité lorsque les nœuds tentent de trouver (les mêmes) pairs et d’être acceptés (ce qui, à son tour, peut provoquer des pics de mémoire). Cela implique une plongée profonde dans le fonctionnement de Kad, des réflexions sur ce dont un nœud a besoin pour se faire remarquer dans un petit réseau et des solutions de contournement possibles telles que de nouvelles tentatives avec de nouveaux PeerIds.

Qi a également examiné certains pics de mémoire et problèmes de vitesse notés dans le dernier testnet (vous pouvez voir qu’il y a eu des progrès dans les nouveaux tableaux de référence )

@ChrisO a compilé une liste de problèmes à partir du dernier testnet et travaille sur des améliorations de la « sécurité » et du processus de publication.

Pendant ce temps, @anselme a terminé son travail sur les dépenses, a vérifié que les doubles dépenses sont évitées comme prévu, et a commencé à stocker les registres dans notre Kad RecordStore , travaillant sur un prototype d’API barebones pour imiter ce qui existe pour les gros morceaux et les dépenses.

@Bzee continue d’examiner les subtilités des connexions libp2p pour déterminer combien d’E / S nous pouvons contrôler au niveau du nœud et @bochaco travaille sur la vérification des entrées de paiements de stockage.

Et quelques nouvelles provisoires mais très positives de @aed900. Il a testé le support de libp2p pour la perforation via QUIC, qui est un travail en cours de l’équipe libp2p. Il rapporte que jusqu’à présent, tout semble fonctionner comme prévu - mais d’autres tests sont nécessaires avant de casser le champagne.

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