Ceci est une traduction automatique. L’original en anglais est ici: Update 10 August, 2023
Le prochain testnet, qui devrait être lancé d’un jour à l’autre, examinera les coûts variables des magasins. Pour rappel, lorsque les nœuds sont pleins, le prix du stockage des données augmente afin d’attirer plus de nœuds sur le réseau ; à l’inverse, lorsqu’il y a beaucoup d’espace sur le réseau, le coût du magasin diminue.
Avant de stocker un bloc de données, un client demande maintenant un prix à une sélection de nœuds dans la plage d’adresses (un groupe proche). Le prix offert par chaque nœud dépend de la quantité de données qu’un nœud gère actuellement. Comme nous l’avons vu lors des testnets, la capacité de réserve, et donc le prix, va baisser dans une distribution. Dans le dernier testnet, alors que quelques nœuds se remplissaient complètement, la plupart se situaient entre à moitié plein et plein.
En gardant à l’esprit que chaque morceau stocké sera répliqué sur un certain nombre de nœuds (8 actuellement), il est logique que le client ne sélectionne pas le prix le plus bas car cela pourrait conduire à un nombre insuffisant de nœuds conservant le paiement et empêchant la réplication, mais plutôt de sélectionner un coût du magasin vers le haut de la fourchette proposée, ce qui sera un prix acceptable pour la majorité des nœuds du groupe. En résumé, le client doit rechercher le prix le plus bas qui garantit toujours qu’une majorité du groupe fermé stockera le morceau.
Pour bien faire les choses, il faudra quelques itérations de testnet, mais nous sommes ravis de pouvoir enfin commencer.
Une autre chose que nous examinons est de savoir comment échanger des DBC sur le réseau. Pour le moment, les DBC doivent être échangés hors bande - par messagerie, e-mail ou similaire - mais @anselme et @dirvine travaillent sur un processus par lequel les DBC qui sont émis dans une transaction seront mis à disposition en toute sécurité sur le réseau, de sorte que le le destinataire peut les récupérer tant qu’il connaît l’adresse et qu’il a la bonne clé.
Ailleurs, nous travaillons sur quelques bogues du dernier testnet. Il y a encore quelques problèmes avec les connexions, avec quelques nœuds qui ne sont pas correctement ajoutés aux tables de routage des autres nœuds. Un autre problème est la vitesse de vérification des données qui est assez lente. Nous avons maintenant introduit une option CLI pour ne pas vérifier les PUT afin d’accélérer les téléchargements, mais cela peut causer des problèmes avec des fichiers plus volumineux. Attendre que 20 nœuds répondent avant qu’un client puisse se connecter au réseau était également assez lent, nous avons donc réduit ce nombre à 8 nœuds, ce qui rendra les choses un peu plus rapides.
Du côté positif, les paiements pour le stockage des données ont été traités assez rapidement, nous en sommes donc très satisfaits.
Progrès général
@joshuef a dirigé les efforts de coût du magasin et a mis en œuvre le prix du nœud majoritaire mentionné ci-dessus. Il a également soulevé un PR pour coûts du magasin de cache chez le client et l’utilise comme un moyen de s’assurer que les tables de routage du nœud sont mises à jour, plutôt que de cingler les nœuds chacun temps. Cela devrait accélérer les requêtes PUT.
Bugfinder general @Qi_Ma a corrigé une erreur dans la logique d’élagage ainsi que la recherche de la cause profonde de la vérification des doubles dépenses dont nous avons parlé la semaine dernière et est réparer ça aussi.
Pendant ce temps, @Chriso a introduit la possibilité de créer des branches personnalisées de safenode et de déployer pour les tests, nous pouvons donc maintenant tester le code non fusionné dans notre version moderne et rouillée de l’outil de déploiement testnet.
@ Aed900 continue de grignoter les « nœuds de la maison ». Il a construit un prototype de fonction de relais permettant aux nœuds qui reçoivent un statut autonat privé du réseau (ce qui signifie qu’ils sont derrière un routeur ou un pare-feu) de communiquer avec le réseau en utilisant un autre nœud comme relais.
Sur un territoire similaire, @bzee a enquêté sur un problème avec des nœuds non routables dans libp2p qui causait des problèmes. Cela peut être dû à un changement récent dans ` libp2p ’ mais plus de recherches sont nécessaires, et cela nécessitera des outils de débogage spéciaux dans la pile réseau, semble-t-il.
Et @roland a corrigé un bogue dans le code testnet où un pair d’amorçage n’était pas fourni lors du lancement du robinet.
Liens utiles
- Site Web du réseau sécurisé
- Safe Network Primer
- Principes de base du réseau
- Feuille de route
- Glossaire
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é!