Ceci est une traduction automatique. L’original en anglais est ici: Update 27 July, 2023
Comme vous l’aurez remarqué, un nouveau testnet est parmi nous. Il est temps de monter à bord si vous ne l’avez pas déjà fait ! Téléchargez en toute sécurité et téléchargez certains fichiers, et voyez comment le paiement pour chaque téléchargement est automatiquement soustrait de votre portefeuille. Tout l’argent du Monopoly pour le moment, bien sûr, mais c’est super de le voir en action. Faites-nous part des erreurs que vous pourriez voir dans le fil.
Le paiement des données est un grand pas en avant, rendu possible par le fait que le réseau est maintenant assez bien comporté et stable (touche du bois). La mémoire par nœud tourne autour de la plage de 50 à 60 Mo, alors qu’elle se situait auparavant dans les centaines de Mo. Mais il reste encore des choses à régler. Merci pour les commentaires jusqu’à présent, et continuez. La prochaine étape consistera à tester le flux de paiement de base vers les nœuds et une sorte de mécanisme de tarification simple.
Malheureusement, il n’y a pas encore de traversée NAT solide, mais ceux qui ont des nœuds cloud ou qui sont satisfaits de la redirection de port peuvent essayer d’exécuter un nœud ou deux. Tiens nous au courant de comment ça se passe.
Maintenant que nous sommes dans un endroit stable, nous allons également commencer à décortiquer le fonctionnement du réseau. Cette semaine @roland va vous expliquer ce qui se passe lors de la réplication des données.
Progrès général
@Chriso travaille sur la journalisation centralisée pour faciliter l’analyse des erreurs agrégées après les tests. En fin de compte, nous espérons permettre aux membres de la communauté de le faire en temps réel, mais nous gardons les choses simples pour le moment.
Thomas Eizinger et Max Inden de l’équipe rust-libp2p ont fusionné un correctif de @bzee, qui voyait de nouveaux nœuds continuer à composer (message ) d’autres nœuds même après leur connexion au réseau. @bzee est en contact régulier avec cette équipe, qui dit qu’AutoNAT et la perforation devraient fonctionner « bientôt ». L’un des responsables a une solution provisoire qui résoudrait le problème de la réutilisation des ports - AutoNAT n’a pas besoin de réutiliser les ports sur les sondes sortantes. Je croise les doigts pour des progrès rapides à ce sujet.
@aed900 cherche à améliorer l’expérience utilisateur autour des nœuds non connectés gestion des délais d’attente.
@bochaco propose une fonctionnalité pour récupérer simultanément toutes les dépenses pour une preuve de paiement pour accélérer le processus de vérification DBC, ainsi qu’une approche pour faire des registres adressable par le contenu.
@qi_ma a corrigé un bogue subtil avec les DBC. Lorsqu’un client souhaite dépenser un DBC pour télécharger des données, les nœuds vérifient s’il existe une preuve de dépense existante à l’adresse concernée (pour éviter les doubles dépenses). Le nœud détenant cette adresse répondra également activement aux requêtes GET, ce qui peut retarder sa réponse aux nœuds demandeurs, leur faisant croire qu’il n’y a pas de preuve dépensée. C’est un événement extrêmement rare mais nous l’avons vu dans la nature et cela permettrait une double dépense. Nous le corrigeons en exigeant que 5 nœuds voient un GET avant qu’il ne soit utilisé.
Et @joshuef examine les paiements et la tarification dynamiques, y compris le client demandant aux nœuds à proximité du lieu de paiement quel est leur coût de stockage, et avec cela la mise à jour du paiement pour les téléchargements. Et aussi un calcul du coût du magasin basé sur la capacité du magasin de disques.
Réplication des données
La réplication de données est un mécanisme qui permet aux nœuds de distribuer des données à de nouveaux pairs lorsqu’ils rejoignent et transfèrent des données d’un « pair mort » vers les autres nœuds. Cela garantit que les données restent disponibles dans le réseau, même lorsque les nœuds rejoignent ou quittent. Cependant, l’approche utilisée par Libp2p reposait sur un nœud inondant périodiquement le réseau avec toutes ses données. Cela s’est accompagné de certains inconvénients, notamment un trafic réseau important et une utilisation élevée de la mémoire entre les nœuds. De plus, les nouveaux nœuds n’ont pas reçu les données dont ils étaient responsables et les données détenues par les nœuds morts n’ont pas été répliquées à temps. Pour résoudre ces problèmes, nous avons implémenté un processus de réplication personnalisé qui est déclenché chaque fois qu’il y a un changement dans le groupe fermé d’un nœud.
Avant de nous plonger dans le processus de réplication, discutons brièvement de la manière dont les données sont stockées sur le réseau. Le réseau fonctionne comme une table de hachage distribuée (DHT), permettant la récupération de données à l’aide de clés uniques. Lorsqu’une personne souhaite stocker un fichier sur le réseau, elle utilise d’abord son DBC pour payer le fichier, puis télécharge le fichier sur le réseau. Ces données (DBC, Chunk ou Register) sont transformées en une série de 0 et de 1 et placées à l’intérieur de quelque chose appelé Record. Bien que les enregistrements puissent être infiniment volumineux, les nœuds sont limités à la gestion d’enregistrements de taille 1 Mo. Chaque Record a sa propre Key, qui est le XorName des données qu’il stocke.
Pour stocker le Record contenant à la fois les données et la clé dans le réseau, le client calcule la distance Xor entre la Record Key et ses nœuds dans son RT (Routing Table), triant les pairs en fonction de leur proximité avec la Key. Par la suite, le client demande à ces nœuds de « calculer et partager les pairs qu’ils pensent être les plus proches de la ‹ clé › ». Le client trie ensuite les réponses et identifie les nœuds encore plus proches de la « clé ». Ce processus se poursuit jusqu’à ce que les huit nœuds responsables de l’enregistrement soient trouvés et que l’enregistrement soit stocké avec eux. Libp2p fait abstraction de ce processus complexe, nous permettant de construire notre réseau par-dessus.
Une fois qu’un Record a été stocké parmi les pairs les plus proches du réseau, nous souhaitons conserver au moins huit copies de l’enregistrement, même si les nœuds qui les détiennent se déconnectent. Notre processus de réplication actuel fonctionne comme suit : chaque nœud garde une trace des pairs qui lui sont proches, c’est-à-dire son groupe proche. Chaque fois qu’un pair est ajouté ou supprimé du RT, nous vérifions si cela affecte notre groupe proche. S’il y a un changement, nous envoyons les « Record Keys » à nos pairs proches du groupe qui, selon nous, devraient détenir ce record. Lors de la réception de la liste de clés, si un pair n’a pas l’enregistrement correspondant, il le demande au nœud qui a initialement envoyé la « clé ». Au cas où il ne pourrait pas recevoir l’enregistrement du nœud qui a initialement envoyé la clé, il demande les données au réseau.
Bien que d’autres optimisations soient possibles, l’approche de réplication actuelle est nettement moins gourmande en ressources que celle « Libp2p » et empêche efficacement la perte de données.
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é!