Actualités du développement Safe 🇫🇷 26 octobre 2023

Dimitar · Octobre 28, 2023, 10:21

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

Au cours des dernières années, nous avons souvent sympathisé avec Sisyphe dans la légende grecque. Sisyphe a dû pousser un rocher sur une colline pendant l’éternité pour que celui-ci redescende dès qu’il s’approchait du sommet.

Nous ne souhaitons pas tenter les dieux grecs notoirement vengeurs, mais nous sommes de plus en plus certains que cette fois nous avons enfin réussi, et nous sommes plutôt assis sur le plateau. Pourquoi cette confiance, oh vous qui êtes restés avec nous à travers vents et marées, oh vous qui ressentez peut-être un léger sentiment de déjà-vu ?

Et bien parce que les bugs diminuent et que nous les corrigeons plus rapidement. Parce que toute l’équipe corrige les bugs ensemble, plutôt que chacun ait une spécialisation. Parce que les testnets durent plus longtemps et donnent des résultats que nous pouvons comprendre et gérer. Parce que nous pouvons itérer à la volée avec des améliorations tangibles. Parce que nous collaborons avec des personnes partageant les mêmes idées. Et parce que la communauté apporte ses propres solutions. Nous sommes passés du théorique au pratique, et ça fait du bien.

De nombreux PR sont arrivés cette semaine, de l’équipe à l’équipe et à quelques autres projets. En résumé:

Un correctif pour retourner une majorité de nœuds plutôt que tous.
Un PR pour seulement payer un nœud plutôt que tous, tout en continuant à se répliquer vers le groupe proche.
Un autre sur réplication, celui-ci pour utiliser tokio::Interval pour la réplication forcée au lieu d’Instant, pour gérer les pics de trafic qui provoquaient des blocages .
Une modification apportée au client pour vérifier uniquement les morceaux qui atteignent la majorité pour la réplication.
Un correctif pour un homologue problème de duplication lors du déclenchement de la réplication.
Et un autre qui expérimente l’extension de la plage de réplication.
Ensuite, il y en a un qui supprime la journalisation lente de content_hash pour les enregistrements volumineux - une fuite de mémoire probable.
Encore une fois, concernant la journalisation, il y en a un qui ajoute la journalisation SwarmCmd pour le profilage des performances, un autre qui ajoute la journalisation de la KBucketKey du nœud et un autre qui corrige les journaux de synchronisation.
De plus, il y a le PR de @bzee à libp2p pour adresser un magasin vecteur d’adresse en constante croissance - un autre candidat à une fuite de mémoire.
Ensuite, il existe un correctif pour les échecs des tests de récompense en émettant NetworkEvent sur les publications GossipSub
De plus, plusieurs autres attendent d’atterrir depuis les succursales individuelles de l’équipe.

Merci à @southside pour ses RP utiles pour une simple amélioration du résultat et à shuoer86 pour quelques corrections de fautes de frappe. Tout le monde, ne soyez pas timide. Si vous repérez quelque chose qui pourrait être modifié ou amélioré, déposez un PR ou faites-le nous savoir sur le forum.

Progrès général

@joshuef a étudié les variations des coûts des magasins et la façon dont les clients se tournent inutilement vers l’augmentation des prix et paient pour des données déjà stockées. (PR 887/888). Nous renforçons le système de paiement en vérifiant qui détient la part et en les remboursant si nécessaire, et non en remboursant la totalité. En retour, cela réduit le stress sur le processus de vérification, ce qui signifie moins d’activités inutiles et des performances améliorées.

Les améliorations associées incluent l’élimination du hachage de contenu redondant et la vérification uniquement des morceaux dans la majorité du groupe proche plutôt que dans la totalité d’entre eux pour éviter un travail inutile.

@bochaco a travaillé sur les modifications de la documentation pour les nouvelles commandes cli/rpc-client et a testé testnet-deploy pour vérifier que CashNotes peut être téléchargé et déposé sur un portefeuille local. Il a également finalisé le processus de paiement des nœuds de la Fondation et préparé le dernier testnet pour le mettre à l’épreuve.

@bzee envisage de payer un seul nœud pour le stockage des données. Comme discuté la semaine dernière, cela pourrait être une bonne option bon marché et sale pour le stockage sans redondance, à condition qu’elle s’avère suffisamment fiable. Il a également, espérons-le, corrigé une autre fuite de données autour d’un magasin en constante croissance dans libp2p qui contient les identités des nœuds connus. L’équipe libp2p est actuellement sur ce point.

Pendant ce temps, @anselme a réorganisé les paiements stockés avec CashNotes et Transfers.

@roland a porté son attention sur la réplication, la retardant d’un instant à vérification toutes les 10 secondes pour éviter les blocages indésirables autrementici. De plus, Roland a optimisé la façon dont les nœuds enregistrent et stockent leurs homologues proches pour éviter la duplication.

La réplication des registres constitue un autre problème persistant. Si un registre change pendant le processus de réplication, différents nœuds peuvent finir par contenir des versions différentes, avec des problèmes survenant du fait que la convergence CRDT ne se produit pas à temps. @Qi_ma a mis en place un correctif pour cela maintenant, c’est donc un autre coché.

Et @chriso continue d’améliorer le processus d’automatisation de testnet, y compris une commande d’installation pour le gestionnaire de nœuds.

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