Ceci est une traduction automatique. L’original en anglais est ici: Update 08 June, 2023
Partout dans le monde, des milliers de nœuds continuent de fredonner, stockant et reproduisant soigneusement et sans poser de questions les photos de coq de la communauté et les choix musicaux insondables pour toujours, et toujours, et toujours. Ne vous inquiétez pas, nous allons retirer ce testnet en temps voulu. Nous n’en sommes pas encore là, mais au fil du temps, le réseau devient sensiblement plus stable, prévisible et évolutif - ce qui est extrêmement gratifiant. Veuillez continuer à télécharger et à partager, et publiez vos journaux si vous voyez quelque chose de fâcheux.
Sous la capuche
Certains résultats de tests concluants nous ont convaincus de faire passer notre modèle de réplication de données du push au pull. Dans le modèle push que nous avons utilisé jusqu’à présent, lorsqu’il y a un désabonnement (un nœud se déconnecte), les nœuds avec des copies des données détenues par le nœud mort les poussent vers le nœud le plus proche. Certains de ces nœuds réussiront à pousser leurs morceaux, d’autres non, mais il devrait y avoir suffisamment de tolérance dans le système (comme contrôlé par le choix de k-value) pour s’assurer qu’aucune donnée n’est perdue.
La méthode pull est similaire, sauf que le nouveau nœud, réalisant qu’il est l’héritier du nœud mort, demande des morceaux à son groupe proche. Encore une fois, certaines demandes peuvent réussir, d’autres non, mais à la fin, tous les morceaux devraient être reçus.
Quelle est donc la différence ? C’est dans le nombre de messages envoyés et le nombre de copies supplémentaires qui sont nécessaires pour faire fonctionner le modèle push. @Qi_ma a effectué des tests dans des conditions de désabonnement extrêmes et a découvert que l’attraction est supérieure sur chaque métrique - messages, CPU, mémoire et taux de réussite. Par conséquent, le changement était une évidence. Pour l’instant, nous utilisons le modèle pull.
C’est beaucoup mieux, mais nous voyons encore des messages abandonnés occasionnels, c’est pourquoi le succès n’est pas encore à 100 %.
Ailleurs, les DBC sont maintenant reproduits, jetant les bases du paiement des données, qui fera l’objet d’un futur testnet. @bochaco a créé une illustration des DAG Merkle et comment ils construisent un arbre pour le chunks qui nous permet d’utiliser la racine de l’arbre comme preuve de paiement du stockage, que nous reproduirons ici.
Les preuves de paiement de stockage sont générées à l'aide d'un arbre Merkle binaire :
Un arbre de Merkle, également connu sous le nom d'arbre de hachage, est une structure de données utilisée pour la vérification des données
et synchronisation. C'est une structure de données arborescente où chaque nœud non-feuille est un hachage de
ses nœuds enfants. Tous les nœuds feuilles sont à la même profondeur et sont aussi loin à gauche que
possible. Il maintient l'intégrité des données et utilise des fonctions de hachage à cette fin.
Dans Safe, afin de payer le réseau pour le stockage des données, tous les fichiers sont d'abord auto-cryptés
obtenir tous les morceaux que l'utilisateur doit payer avant de les télécharger. Un Merkle binaire
l'arbre est créé en utilisant les adresses/Xornames de tous ces morceaux, chaque feuille de l'arbre de Merkle
contient la valeur obtenue à partir du hachage de chacun des Xorname/address du Chunk.
L'arborescence suivante montre comment deux fichiers A et B, avec deux morceaux chacun, seraient utilisés
pour construire l'arbre de Merkle :
[ Root ]
hash(Node0 + Node1)
^
|
*-------------------------------------------*
| |
[ Node0 ] [ Node1 ]
hash(Leaf0 + Leaf1) hash(Leaf2 + Leaf3)
^ ^
| |
*----------------------* *----------------------*
| | | |
[ Leaf0 ] [ Leaf1 ] [ Leaf2 ] [ Leaf3 ]
hash(ChunkA_0.addr) hash(ChunkA_1.addr) hash(ChunkB_0.addr) hash(ChunkB_1.addr)
^ ^ ^ ^
^ ^ ^ ^
| | | |
[ ChunkA_0 ] [ ChunkA_1 ] [ ChunkB_0 ] [ ChunkB_1 ]
^ ^ ^ ^
| | | |
*----------------------* *----------------------*
| |
self-encryption self-encryption
| |
[ FileA ] [ FileB ]
L'utilisateur relie le paiement effectué aux nœuds de stockage en définissant la valeur racine de l'arbre Merkle
comme valeur 'Dbc::reason_hash'. Grâce aux propriétés de l'arbre de Merkle, l'utilisateur peut
puis fournissez la sortie DBC et la piste d'audit pour chacun des Chunks payés avec le même
DBC et arbre, aux nœuds de stockage lors du téléchargement des Chunks pour les stocker sur le réseau.
@Anselme a travaillé sur quelques bogues dans le robinet et le portefeuille, qui ne marquent actuellement pas les DBC comme dépensés sur le réseau. Il a également résolu certains problèmes de journalisation.
@Roland a émis un PR pour collecter des métriques système, réseau et processus. Ceci est derrière une porte de fonctionnalité, ce qui signifie qu’il peut être activé et désactivé en fonction de nos besoins. Cela devrait être utile lors des testnets pour collecter des métriques auprès de la communauté. Plus tard, nous activerons les métriques OpenSearch, mais c’est une solution simple pour l’instant.
@ChrisO a un processus de publication automatisé de testnet qui fonctionne expérimentalement. Devrait être prêt pour l’action en direct très bientôt. Lui et @aed900 ont également travaillé sur d’autres aspects des testnets, notamment la gestion des secrets sur Digital Ocean. Angus a également examiné un problème où les nœuds privés (derrière NAT) sont écrits dans la table de routage, ce qui n’est pas ce que nous voulons.
Heureusement @bzee, qui a creusé dans libp2p, pense qu’une prochaine version devrait résoudre ce problème pour nous.
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é!