Actualités du développement Safe 🇫🇷 6 janvier 2022

Ceci est une traduction automatique. L’original en anglais est ici: Update 06 January, 2022

Bonne année à tous ! Nous sommes de retour en selle :cowboy_hat_face: et impatients de partir.

Un grand merci à @josh pour la mise en place du récent testnet communautaire, et à tous ceux qui y ont participé. Certaines des anomalies signalées que nous avons vues se reflètent dans nos propres résultats de test, et il y a aussi eu quelques surprises, notamment les pics de processeur maximum que nous examinons actuellement. Acclamations gars!

Juste un rapide cette semaine pour vous faire savoir sur quoi nous travaillons en ce moment. Heureux de dire que nous avons déjà réglé quelques détails et que nous sommes tout à fait prêts à rouler.

Progrès général

Au fil du temps, nous avons envisagé différentes manières de calculer l’espace libre sur le réseau. Récemment, nous avons parcouru les quelques répertoires db et ajouté des tailles de répertoire pour calculer l’espace utilisé. Dirigé par @anselme, nous avons maintenant simplifié le stockage des données en supprimant la base de données avancée pour la remplacer par un processus plus simple directement sur le disque avec une structure de répertoires arborescente binaire. Cela nous a obligés à remplacer le processus de traversée de répertoires par un processus qui compte chaque octet au fur et à mesure qu’il est écrit et garde une trace de l’espace total utilisé, ce qui est beaucoup plus rapide et plus évolutif maintenant que nous aurons une arborescence profonde de répertoires au lieu d’un ou deux. Cela simplifiera également considérablement le processus consistant à faire rejoindre le réseau par un nœud avec des morceaux, car nous n’avons pas besoin de le mesurer à chaque fois, tout en simplifiant les divisions de section.

Anselme étudie également comment l’espace de stockage libéré lors de la suppression des registres privés (données modifiables) peut être facilement calculé.

En parlant de données modifiables, nous avons réfléchi au type de frais qui devrait être attaché au type de données de registre. Pay-per-change serait très maladroit, nous voulons séparer les modifications du processus DBC. Actuellement, nous envisageons de facturer un multiple du prix d’un morceau immuable (blob) PUT pour un registre PUT, et de permettre des modifications infinies par le propriétaire des données (et les parties avec lesquelles il choisit de partager) par la suite.

@bochaco a continué à affiner le processus d’adhésion, c’est-à-dire comment nous maintenons le nombre correct d’anciens dans une section et comment nous ajoutons de nouveaux nœuds adultes à la section si nécessaire. Lorsqu’un nouveau nœud demande à le rejoindre, il lance un processus qui inclut les messages AE et le test de preuve de ressource, et une fois que les anciens acceptent de l’accepter, un message est renvoyé au nœud qui rejoint. Ce flux est désormais intégré à la caisse sn_membership - au moins pour les adultes promus au rang d’anciens et les anciens partant. Cependant, ce processus d’« adhésion sn » suppose actuellement que tous les nœuds impliqués sont des membres votants (c’est-à-dire des anciens), de sorte qu’il exclut la promotion d’un adulte au rang d’aîné. @bochaco et @davidrusu travaillent actuellement sur celui-ci. Nous vous expliquerons plus dans une future mise à jour.

Pendant ce temps, @lionel.faber a cherché à accélérer le processus CI/CD avec les coureurs GitHub auto-hébergés sur AWS. Les machines virtuelles natives dans GitHub Actions peuvent être plutôt lentes - en particulier pour Windows - ce qui s’est avéré être un goulot d’étranglement lors des tests. En hébergeant nous-mêmes le service sur AWS, nous pouvons utiliser des machines virtuelles plus puissantes pour terminer nos flux de travail plus rapidement. Lionel documente également le processus de génération de clé distribuée (DKG) que nous utilisons pour l’accord.

Restons un instant sur les tests, parfois les tests peuvent être trop rigoureux. Comment? Les tests de puits sont conçus pour détecter chaque erreur lorsqu’elle se produit, alors qu’un réseau tolérant aux pannes avec des CRDT peut être en mesure de contourner ces problèmes, en arrivant finalement à un état cohérent garanti. Il peut donc être inutile de créer des tests qui capteront tout - mais c’est un exercice d’équilibre délicat !

Un exemple concret est une erreur de données manquantes, comme celle que vous avez peut-être vue sur le testnet. Les données manquent-elles vraiment ou ne sont-elles tout simplement pas encore arrivées ? Peut-être qu’il apparaîtra plus tard, ou peut-être qu’il est là mais qu’il y a eu une autre erreur.

Dans ce scénario, la messagerie entre les acteurs est également nuancée, et c’est un autre sujet de discussion. Lorsqu’un morceau a été PUT réussi, le client doit être (éventuellement) informé qu’il a été stocké, et grâce aux CRDT, cela devrait être sûr à 100%, mais s’il a apparemment «échoué», ce n’est pas certain à 100% à cause de l’asynchronicité et d’autres facteurs, de sorte que le client a besoin d’options sur la façon de procéder.

@Qi_ma a examiné les journaux pour retrouver l’erreur de données manquantes, et @yogesh cherche la raison des flots de messages AE qui submergent parfois les communications entre les nœuds. Sont-ils liés ? On devrait le savoir bientôt. Pendant ce temps, @joshuef a examiné un bogue qui pourrait causer des problèmes dans les nœuds martelés par les clients, provoquant une augmentation de la mémoire du nœud et les faisant parfois planter. Pour le moment, nous plafonnons cela à une limite arbitraire de messages clients simultanés, mais nous chercherons à rendre cela dynamique en fonction de la charge du nœud au fur et à mesure de notre progression.

Chaque pas est un autrer approchez-vous.


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