Actualités du développement Safe 🇫🇷 9 novembre 2023

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

Pour le prochain testnet, nous espérons mettre fin aux problèmes de mémoire qui ont fait couler le dernier, c’est donc notre objectif cette semaine.

La branche pay-one-node semble bonne et, avec un peu plus de tests, elle sera prête à fusionner. Cela devrait réduire l’utilisation de la mémoire par rapport à l’approche précédente consistant à payer tous les nœuds qui stockent un morceau. Comme nous l’avons mentionné la semaine dernière, à terme, nous devrions être en mesure de proposer des options de compromis en matière de vitesse de téléchargement et d’assurance dans le client.

Payer un seul nœud simplifie également le paiement des redevances. La compensation de cinq nœuds signifie que cinq messages de redevances distincts sont diffusés pour le même morceau, qui doivent ensuite être dédupliqués par les nœuds de réception. Ceci est compliqué par le fait que ces « CashNoteRedemptions » sont cryptées. L’utilisation d’un seul nœud simplifie beaucoup cela. De plus, ces messages bavardés n’ont plus besoin d’être chiffrés (sans perte de sécurité), c’est pourquoi nous l’intégrons maintenant.

L’impact exact sur l’utilisation de la mémoire pour les paiements de redevances doit être testé davantage sur un réseau de test plus large, mais il semble que d’autres optimisations simples soient également possibles. Par exemple, configurer chaque nœud pour qu’il s’abonne uniquement aux messages pertinents, et non à tous les messages, a entraîné une forte réduction de la mémoire, et nous cherchons également à arrêter les rediffusions inutiles.

Sur GossipSub lui-même, nous avons rendu la vérification plus stricte à des fins de test. Plutôt que d’attendre un nombre minimum de messages, nous vérifions désormais le montant exact.

Le PR de @southside pour améliorer les sorties de journalisation est désormais dans la base de code. Et merci aussi à @loziniak pour un PR pour cloner ClientRegister. :palms_up_together:

Nous allons maintenant laisser la parole à @anselme pour nous expliquer comment fonctionnent les paiements.

Paiements sur le réseau sécurisé

Ceci est un résumé de la façon dont nous payons les données sur le Safe Network ainsi qu’une introduction aux transferts d’argent en général.

Transferts

Avant d’aborder les paiements de données, comprenons d’abord comment fonctionnent les transferts de base. Tout le monde sur le réseau sécurisé, les clients (applications de portefeuille, Safe CLI, etc.) et les nœuds (stockage de données) disposent d’une paire de clés publique/privée. La clé publique (alias « MainPublicKey ») est utilisée pour recevoir des jetons. C’est l’équivalent des adresses Bitcoin ou Ethereum. La clé privée (alias « MainSecretKey ») est utilisée pour signer des transactions et prouver la propriété de l’argent.

Voici à quoi ressemble une MainPublicKey :

‹ 93d01b3c6c0d41c4e50c855c753f906ba478f97a838415e6d74615a4b037a7101e724f935727bbf23d17293ab74a3027 ›

Vous pouvez obtenir le vôtre avec la commande : adresse du portefeuille sécurisé

L’argent dans un portefeuille est stocké sous forme de « CashNotes ». C’est comme un contrôle pour une valeur donnée. Ils contiennent toutes les informations nécessaires pour que le propriétaire puisse y dépenser la valeur, mais n’ont pas de valeur en eux-mêmes car ils sont inutiles sans la clé privée.

Lorsque quelqu’un souhaite envoyer de l’argent, il crée une transaction dans laquelle il dépense ses propres « CashNotes » en échange de nouveaux « CashNotes » appartenant au destinataire. Comme ces « CashNotes » contiennent des secrets qui pourraient affecter la confidentialité de l’expéditeur et du destinataire (la « MainPublicKey »), ils ne sont jamais envoyés ou stockés sur le réseau.

Au lieu de cela, l’expéditeur crée de très petits « CashNoteRedemptions » qui contiennent le minimum d’informations nécessaires dont le destinataire a besoin pour vérifier la transaction et recréer son propre « CashNote » de son côté.

Ces « CashNoteRedemptions » sont cryptés et regroupés dans un transfert qui est envoyé directement au destinataire. Le destinataire du transfert peut ensuite le déchiffrer à l’aide de sa « MainSecretKey », vérifier et reconstruire les « CashNotes », avant de les ajouter à son portefeuille. À ce stade, le transfert est terminé !

Vous pouvez envoyer un transfert avec : safe wallet send <amount> <to>

Exemple : portefeuille sécurisé envoyer 42 93d01b3c6c0d41c4e50c855c753f906ba478f97a838415e6d74615a4b037a7101e724f935727bbf23d17293ab74a3027

Cela imprimera le transfert crypté qui pourra être publié ou envoyé directement au destinataire.

Ils peuvent le recevoir avec : safe wallet recevoir <transfer>

Paiements de données

Les données sur le Safe Network sont payées en utilisant ces mêmes transferts.

Avant que les données ne soient stockées sur le Réseau, elles sont préparées localement par l’utilisateur : découpées en morceaux et cryptées. Chacun de ces morceaux a une valeur de hachage unique à partir de laquelle nous dérivons leur « NetworkAddress ».

Les nœuds du réseau ont également une « NetworkAddress ». Les données sont stockées sur les nœuds qui ont la « NetworkAddress » la plus proche des données elles-mêmes. C’est pourquoi nous disons que les données sont adressables par le contenu.

En interrogeant le réseau, un client peut obtenir les nœuds les plus proches d’une « NetworkAddress ». Une fois que nous les connaissons, nous effectuons d’abord une requête « StoreCost » pour demander le prix de conservation des données à cet emplacement. Le prix dépend de la capacité de stockage des nœuds, qui dépend en fin de compte de la demande.

Une fois que nous connaissons le « StoreCost », nous pouvons envoyer les données en toute sécurité avec le transfert payant. Dès réception des données, les nœuds vérifient le transfert, acceptent le paiement, vérifient les données elles-mêmes et les stockent.

Parallèlement à ce transfert, un autre petit transfert est envoyé : NetworkRoyalties, ceux-ci sont envoyés à un pool et aident à maintenir le réseau en vie. Lors de la réception de paiements de données, les nœuds s’assurent que ces « NetworkRoyalties » sont également valides avant de stocker les données.

Tout cela se fait automatiquement lorsque vous téléchargez des données à l’aide de la CLI :

les fichiers sécurisés téléchargent un_fichier

Progrès général

@chriso a terminé son travail sur une extension prometteuse du gestionnaire de services WinSW pour faciliter la gestion des nœuds pour Windows et a soumis un PR pour cela.

@roland a soumis un PR pour reprendre les téléchargements CLI sur plusieurs exécutions. Cela stocke les morceaux localement et les déplace/supprime une fois payés/vérifiés. Il a également refactorisé la base de code pour publier le client RPC sous forme binaire afin de corriger certaines erreurs de déploiement testnet.

Plusieurs membres de l’équipe ont étudié le mécanisme de paiement de redevances aux nœuds de la Fondation, comme décrit ci-dessus, notamment @bochaco, @bzee et @qi_ma.

@qi_ma a également créé un PR pour éviter les travaux de hachage en double, tirant le meilleur parti des dernières modifications apportées à libp2p.

@jimcollinson a examiné ce qui est nécessaire pour un lancement MVP, en mettant l’accent sur les rampes d’accès et de sortie pour un lancement en douceur.

Et @joshuef a dressé une liste prioritaire du travail technique restant avant d’entrer en version bêta.


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