Ceci est une traduction automatique. L’original en anglais est ici: Update 15 June, 2023
La première chose à dire est que nous sommes * massivement * satisfaits de la façon dont ReplicationNet s’est déroulé. C’était un peu un pari de jeter autant de nœuds - notre plus grand testnet à ce jour avec une certaine marge - et nous nous attendions à des oscillations majeures, mais il a fallu tout ce que nous pouvions lui lancer dans sa foulée et sans se plaindre, jusqu’à ce que les nœuds complets arrêtent de jouer. . Le plus encourageant de tous, c’est que cette stabilité s’est produite malgré quelques erreurs de messagerie autour de la réplication des données qui auraient pu la faire tomber. Au lieu de cela, il les a repoussés comme une mouche. Un grand merci encore une fois à tous ceux qui ont participé 
, et une mention spéciale à @shu pour son fantastique travail sur le tableau de bord 
.
ReplicationNet - résultats et actions
Ainsi, après avoir parcouru les journaux, à la fois ceux gentiment partagés par la communauté et les nôtres, nous pouvons signaler ce qui suit.
-
Le problème de mémoire qui augmente lentement est presque certainement dû au fait que les nœuds atteignent leur capacité. Nous ne voyons pas ce comportement jusqu’à ce qu’un certain nombre de nœuds soient pleins (1024 morceaux dans ce cas). Une fois que le réseau est opérationnel, nous ne devrions pas voir cela car de nouveaux nœuds seront incités à se joindre.
-
Les problèmes de mémoire insuffisante semblent être causés par trop de données stockées dans le cache lorsque le nœud approche de sa capacité. (Et pour ce cas, nous avons trop de nœuds sur une machine trop petite, semble-t-il). Ce n’est pas un bogue en soi, libp2p devrait disperser ce cache et les données seraient stockées au fur et à mesure que de nouveaux nœuds se joindraient.
-
Nous avons identifié et écrasé un bogue par lequel la réplication des données provoquait des fermetures de connexion, et par conséquent de nombreux messages abandonnés concernant la réplication. C’est quelque chose qui risque de sonner le glas, et c’est un témoignage de la stabilité sous-jacente du réseau qu’il a eu si peu d’impact.
-
Une autre correction de bogue concernait les erreurs « Outbound Failure ».
-
La distribution des données entre les nœuds est assez uniforme. Encore une fois, une excellente nouvelle car nous pouvons utiliser le pourcentage d’espace utilisé comme déclencheur pour la tarification des récompenses comme prévu. Le problème de certains nœuds qui ne se remplissent pas est un bogue, probablement lié au fait que les nouveaux nœuds ne se promeuvent pas suffisamment dans les tables de routage des autres.
-
Il y a quelques anomalies dans les journaux où les requêtes put et les métriques stockées ne semblent pas correspondre. Nous devons travailler à les clarifier.
-
Pour donner aux utilisateurs ayant une bande passante plus faible plus de contrôle, nous avons ajouté la possibilité pour le client de définir la durée d’expiration des demandes et des réponses à partir du réseau . Nous avons également augmenté la durée de temporisation par défaut de 10 à 30 secondes.
-
Nous réfléchissons maintenant aux flux de paiement et aux récompenses pour les différents scénarios : nouvelles données, réplication de données et republication de données (lorsque des données valides ont été perdues pour une raison quelconque)
Le prochain testnet nous aidera à tester ces suppositions et correctifs, ainsi qu’à valider certains travaux autour de l’expérience utilisateur.
Progrès général
Tous les yeux sont désormais rivés sur les DBC, avec @bochaco et @Anselme travaillant sur la sécurisation du vérification du processus de paiement pour le stockage des morceaux, y compris la vérification des parents du paiement DBC sont dépensés et s’assurent que leur hachage « raison » correspond aux informations de preuve de paiement fournies pour chaque bloc. Anselme a corrigé un défaut dans lequel le robinet et le portefeuille ne marquaient pas les DBC comme dépensés. Il s’est avéré que cela avait à voir avec l’activité synchrone des nœuds de vérification provoquant un verrou en lecture-écriture, alors que nous avons besoin qu’il soit asynchrone.
De même, @roland élimine un blocage dans les opérations PUT et GET pour s’assurer qu’elles peuvent être exécutées - et payées - simultanément. La parallélisation est le nom du jeu. Il s’assure également que nos validations de données se produisent quel que soit le moment où les données arrivent dans un nœud, empêchant un certain « chargement latéral » de données via les protocoles libp2p/kad (qui auraient essentiellement permis des données gratuites).
@bzee est toujours en train de bricoler les entrailles de libp2p, peaufinant actuellement la numérotation initiale des pairs d’amorçage.
@Joshuef et @qi_ma ont principalement travaillé sur les résultats du dernier testnet et les ont corrigés au fur et à mesure.
@chriso a travaillé dur pour mettre à jour safeup, plus d’informations à ce sujet bientôt.
Et @aed900 a participé à un outil de lancement de testnet pour automatiser la création de testnets sur AWS et Digital Ocean.
À partir de!
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é!