Ceci est une traduction automatique. L’original en anglais est ici: Update 28 September, 2023
Cette semaine, nous avons examiné les résultats du testnet et travaillé sur des correctifs de bugs. La première chose à noter est que, pour faciliter le débogage, le testnet était délibérément impitoyable, un morceau devant être répliqué sur les huit nœuds du groupe proche pour être considéré comme valide. Cela dit, il a mis au jour une certaine étrangeté autour des morceaux manquants sur lesquels @qi_ma et @joshuef ont creusé.
Le téléchargement de fichiers volumineux échouait parfois en raison de l’absence d’un ou plusieurs morceaux dans le téléchargement. Merci à tous ceux qui ont signalé cela. L’une des raisons que nous soupçonnons est liée à la mise en cache. Lorsque nous récupérons un enregistrement depuis Kademlia, nous avons plusieurs choix. « Quorum :: One » signifie que nous prenons la première réponse que nous obtenons, « Quorum :: All » signifie que nous attendons que toutes les réponses arrivent et vérifions qu’elles correspondent. Étant donné que les morceaux sont auto-vérifiables (contenu adressé), une seule réponse devrait suffire car nous pouvons vérifier sa validité sur place.
Cependant, il semble que la mise en cache Kademlia, qui devrait mettre en cache des morceaux sur des nœuds plus proches lors de l’utilisation de « Quorum::One », ne fonctionne pas tout à fait comme nous le pensions… Elle semble garantir qu’un seul nœud contient les données, uniquement (comme au lieu de toujours garantir qu’elles soient transmises à tous les détenteurs de données, même si nous n’exigeons qu’une seule copie). Nous désactivons donc cela pour le moment et revenons à « Quorum :: All » pour voir comment nous nous en sortons.
Des coûts de magasin incorrects sont une autre raison possible pour laquelle des morceaux sont manquants. Parfois, le client demande de stocker les coûts à partir de nœuds différents de ceux qui finissent par stocker les morceaux. Cela a pour conséquence que les nœuds de stockage ne sont pas payés. Nous constatons également des échecs de réplication, c’est pourquoi nous les examinons également. (Cela pourrait bien être lié au travail de « Quorum » / mise en cache ci-dessus !)
Pour vous faciliter la vie, nous avons fait en sorte que si le téléchargement d’un morceau échoue, l’ensemble du processus s’arrête avec un message d’erreur « MissingChunk », plutôt que d’attendre la fin. Nous améliorons également la journalisation pour déboguer chaque lot de chargements et de téléchargements. Et comme les journaux fournissent des informations de débogage précieuses, nous enregistrons désormais les sorties des clients et des nœuds par défaut. Les journaux sont assez détaillés, alors sachez que les petites instances se rempliront probablement plus rapidement.
Et nous avons ajouté des pairs d’amorçage codés en dur dans le code du nœud et du client, donc plus besoin de définir la variable SN_PEERS.
La « taille du lot » et la « concurrence » semblent avoir un certain effet, avec des tailles de lots plus grandes accélérant considérablement les téléchargements et des paramètres de concurrence plus importants, jusqu’à environ 40, faisant de même. Nous expérimentons actuellement les effets sur les performances de la réduction de la taille du groupe fermé de 8 à 5, ce qui devrait accélérer les téléchargements et réduire l’utilisation de la mémoire.
Merci, comme d’habitude, à tous ceux qui se sont impliqués et ont mis le projet à l’épreuve. En récompense, vous avez pu profiter du plaisir de vivre dans un environnement hyper-inflationniste, et une ou deux personnes sont devenues extrêmement riches en SNT. Ne dépensez pas tout d’un coup, les gars.
CashNotes
CashNotes est le nouveau nom des DBC qui reflète mieux la manière dont les paiements sont réellement effectués. Le code sous-jacent n’a pas changé ici.
Il s’agit essentiellement d’une représentation locale de jetons dans un portefeuille. Ils peuvent être dépensés sur le réseau en échange de nouveaux de même valeur (valeur totale d’entrée/sortie d’émission) par les destinataires.
Les CashNotes sont créés dans les transactions et attribués à des clés publiques dérivées. Les clés dérivées sont créées à partir de la clé publique du destinataire plus un index aléatoire. Une clé dérivée différente est utilisée pour chaque transaction, rendant chaque CashNote unique et impossible à associer à la clé publique d’origine du propriétaire.
Le destinataire a besoin de l’index aléatoire secret ainsi que des informations de transaction parent pour générer la clé privée dérivée correspondante afin d’échanger le CashNote pour recevoir des paiements.
Progrès général
@joshuef et @qi_ma ont été les principaux membres de l’équipe impliqués dans l’examen des coûts de magasin incorrects, des échecs de réplication et des morceaux manquants. Josh a soulevé un PR à fail fast dès que des morceaux sont manquants pendant le téléchargement, et temporairement suppression de la mise en cache Kademlia et je suis revenu à Quorum::All pour résoudre le problème des morceaux manquants.
En plus d’aider au débogage, Qi continue de rechercher la mise en cache libp2p pour mieux la comprendre, et a étudié l’implémentation pub/sub GossipSub sur laquelle @bochaco travaille également. Cela en est maintenant au stade de test, et ils retracent la façon dont les messages se propagent entre les nœuds. Il reste encore un peu de chemin à parcourir là-dessus. @bochaco a également travaillé sur les notifications de récompenses dans le nœud.
@Anselme nettoyé le code inutilisé dans la caisse sn_transfers, minimisé les risques de sécurité en rendant les modules privés et réécrit les benchmarks à l’aide d’API de transfert de haut niveau pour gérer cela changement.
@bzee travaille sur la réutilisation des transferts lorsque les coûts des nœuds changent. Quand le magasining node augmente son prix entre le moment où le client demande un magasin et le moment où il effectue le paiement, ce paiement est insuffisant. Plutôt que de devoir recommencer, nous souhaitons réessayer avec le CashNote d’origine, puis si cela échoue à nouveau, rechargez-le avec un CashNote supplémentaire, ce qui est plus rapide.
@Chriso Ajout de prise en charge des binaires versionnés dans l’outil de déploiement automatisé de testnet et a travaillé sur son fonctionnement, ainsi que quelques améliorations intéressantes pour l’ux « sûr ».
@roland a également travaillé sur des correctifs en réponse aux résultats du testnet, et @dirvine a réduit la taille du groupe fermé de 8 à 5 pour améliorer les performances. David a également approfondi sa réflexion sur un mécanisme de mise à niveau sécurisé pour Safe.
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é!