Actualités du développement Safe 🇫🇷 11 août 2022

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

Avec des activités en cours dans plusieurs domaines disparates, voire sans rapport, nous avons pensé que ce serait le bon moment pour un tour d’horizon de l’état général du projet couvrant les principaux volets du travail, où ils en sont et comment ils se connectent.

Progrès général

@yogesh a rationalisé la configuration du serveur ElasticSearch/Kibana pour nous permettre de surveiller plus facilement nos droplets, et finalise la documentation pour traceroute.

@joshuef a découvert un processus dans sn_node qui utilise environ 1/3 du temps CPU et qui est probablement inutile car nous avons implémenté cette fonctionnalité ailleurs, il voit donc ce qui se passe si nous le supprimons.

@oetyng et @davidrusu ont mené la charge sur la conceptualisation de la création et des paiements de Genesis DBC, que l’équipe a étoffés cette semaine (voir ci-dessous), tandis que @anselme est dans les dernières étapes de la refactorisation de DKG avec le multithreading supprimé pour plus de simplicité , ainsi que la suppression des délais d’attente (voir ci-dessous).

Répartition des activités

Adhésion, AE et consensus - joindre les points

L’adhésion et l’anti-entropie (AE) concernent la mise à jour du système, tandis que le consensus est utilisé pour décider des décisions qui modifient la composition d’une section et/ou les données qu’elle contient.

Chaque message système envoyé sur le réseau contient la clé de section. Le client envoie ce qu’il pense être la clé de section actuelle lorsqu’il communique pour la première fois avec la section, et si elle est obsolète, les anciens de la section lui envoient la clé actuelle dans le fournisseur d’autorité de section (SAP), qui contient également une liste des anciens de la section, afin qu’il puisse mettre à jour ses enregistrements avant de réessayer. C’est AE.

Nous envisageons également d’ajouter l’adhésion à cet échange d’informations, afin de combler l’écart entre ce que les nœuds comprennent et votent, et ce qui est partagé au sein du SAP. L’adhésion, vous vous en souvenez peut-être, est la façon dont les anciens gardent une trace des adultes et des autres anciens de leur section, afin qu’ils puissent gérer les nouvelles jointures, les scissions, le roulement et les promotions.

En particulier lorsque nous examinons les paiements à des adultes individuels, ce sera plus rapide si nous savons où ils se trouvent - les adultes se désintéressent plus rapidement que les aînés et peuvent avoir été transférés dans une autre section ou promus. De plus, les adultes ont un «âge de nœud», et leur paiement sera proportionnel à cela. Nous cherchons donc à inclure des informations sur la génération actuelle d’adultes de la Section dans les messages sur le stockage et les paiements.

Les adultes peuvent réclamer leurs paiements à tout moment, même s’ils ont déplacé des sections, etc., car le DBC est réémis sur leur clé publique et ils peuvent prouver qu’ils étaient dans la section à ce moment particulier, dans le cadre de cette génération particulière. Cette mesure vise donc davantage à réduire le nombre de messages circulant.

En plus d’intégrer les Membres dans le processus d’échange d’informations, nous avons également introduit un mécanisme de consensus dans son fonctionnement. L’adhésion utilise le consensus pour accepter et supprimer des membres dans une section de manière synchronisée. Il s’assure que tous les anciens ont la même vue sur l’ordre des jointures et des feuilles dans la section. Ceci afin d’éviter les incohérences dans l’ensemble de membres de chaque aîné, car le journal des modifications des membres est une chaîne d’ajout uniquement où un consensus avec une majorité qualifiée est requis pour ajouter un nouvel élément.

Temps d’appel sur les délais d’attente - augmentation de la certitude sur les rondes DGK

En général, DKG n’utilise pas le consensus, mais les participants de DKG s’assurent que personne ne triche en envoyant des messages signés et une fois qu’ils ont obtenu tous les messages des autres, ils envoient un ensemble avec les messages de tout le monde et s’assurent que tout le monde a signé le même ensemble. S’il y a une seule incohérence, ils arrêtent de participer à ce tour DKG, il est considéré comme un échec et nous n’atteignons jamais aucune forme de consensus sur ce tour. Cela garantit qu’un tour DKG avec des membres tricheurs n’atteindra jamais la fin, nous ne voulons pas de tricheurs comme anciens après tout.

De nombreux rounds DKG peuvent se dérouler simultanément, et c’est une course entre eux pour atteindre la fin (ou s’éteindre). Lorsque nous avons un DKG terminé, le consensus de transfert peut commencer et décider des prochains anciens. Étant donné que le transfert utilise le consensus, il garantit qu’un seul résultat DKG est sélectionné, de sorte que nous pouvons avoir plusieurs achèvements DKG simultanés, mais un seul d’entre eux sera sélectionné pour le transfert.

La génération de clé distribuée (DKG) est la manière dont les anciens créent la clé de section de manière sécurisée, chaque ancien ne connaissant que son propre partage de clé. Lors des tests, nous avons trouvé quelques cas où DKG échouait et réessayait de manière incohérente en raison de l’utilisation de délais d’attente lors de l’attente de messages.

Nous réorganisons notre DKG avec une implémentation plus propre et sans minuterie. Par exemple, si les sept nœuds les plus anciens d’une section ne sont pas les anciens actuels, ils tenteront une exécution DKG pour créer une nouvelle clé de section. Si tous les candidats les plus âgés ne participent pas, nous permettons à ce DKG de ne pas se terminer, et c’est bien parce que nous ne voulons pas que les nœuds inactifs deviennent des anciens. Nous pouvons attendre qu’un autre roulement d’adhésion se reproduise et déclencher un autre DKG. Nous acceptons d’avoir cles DKG actuels se précipitent pour devenir les nouveaux anciens. Le consensus de transfert décidera qui l’emporte en fin de compte.

@anselme a passé beaucoup de temps à nettoyer DKG, à supprimer les types de messages inutiles du code DKG et à intégrer le nouveau DKG. Il a l’air beaucoup mieux maintenant et nous pourrons bientôt le tester.

Changements de nœud

Nous avons apporté quelques modifications à notre binaire sn_node. Vous devez maintenant transmettre le chemin du fichier de contacts à chaque nœud qui rejoint un réseau (--network-contacts-file). Plutôt que le nœud s’attend à trouver des contacts quelque part, d’autres outils sont chargés de s’assurer que le chemin est fourni au nœud.

Nous avons mis à jour notre sn_launch_tool pour ce faire, donc si vous l’utilisez (ou la CLI qui l’utilise), l’outil fournit désormais à chaque nœud de jonction le chemin vers --network-contacts-file.

--network-contacts-file est simplement un fichier qui donne à un nœud de connexion ou à un client d’amorçage les informations dont il a besoin pour rejoindre le réseau. Ces informations se trouvent dans le SAP et dans la partie SAP de PrefixMap.

Pour les nouveaux nœuds, nous utilisons le fichier PrefixMap du nœud Genesis pour fournir ces informations (il se trouve dans ~/.safe/node/local-test-network/sn-node-genesis/prefix_map), mais l’outil le copie également fichier à l’emplacement où les clients/CLI le trouveront par défaut (~/.safe/prefix_maps/default).

Nous pouvons utiliser le même PrefixMap pour permettre à la fois à un nœud de rejoindre un réseau et à un client de s’amorcer sur le réseau, car il contient les SAP auxquels ils peuvent se connecter. De leur point de vue, c’est la même chose qu’une liste de contacts réseau.

À l’avenir, les clients et les nœuds pourront prendre en charge d’autres types de fichiers et de formats. Quels que soient les changements, ils auront toujours besoin d’une liste de contacts réseau pour démarrer/se connecter à un réseau.

Comme décrit dans une mise à jour récente, PrefixMap a récemment évolué à partir d’un simple fichier qui mappe les préfixes de section aux SAP actuels, à un structure plus complexe qui inclut la clé de section complète DAG/tree - donc ce fichier sera probablement renommé bientôt.

Finalisation du paiement par le réseau des 70 % de récompenses

70 % des SNT seront finalement créés par le réseau lors du processus de téléchargement des données par les clients.

Lorsque les clients téléchargent des données, ils doivent d’abord payer les sections où les données seront stockées. Ces paiements sont partagés entre les nœuds de chaque section (très probablement les aînés et les adultes stockant les données données, au prorata en fonction de l’âge.

Cependant, une certaine proportion (à déterminer) des paiements entraînera également la frappe de nouveaux SNT sous la forme d’un DBC. La valeur totale du nouveau DBC sera la même que le montant du paiement. Le nouveau DBC sera partagé entre tous les nœuds de la section.

Pour sélectionner les paiements qui donneront lieu à un nouveau SNT, un test est effectué, par exemple une sorte de correspondance impliquant un hachage du paiement et le préfixe de l’adresse de section. La probabilité de réussir le test dépendra du taux de création de SNT souhaité (auparavant le taux d’élevage).

Les aînés vérifient chaque paiement pour voir s’il réussit ce test. L’incitation à cette vérification (qui est rapide et nécessite un minimum de ressources) est la possibilité de gagner du SNT. La plupart des paiements ne passeront pas le test et se dérouleront normalement, mais lorsqu’il y a correspondance, les anciens utilisent ce paiement pour frapper un « Genesis DBC ». Ce « Genesis DBC » est tout nouveau et augmente le montant total de SNT disponible à dépenser. Son montant total est le même que le montant du paiement de téléchargement, et sa valeur est répartie entre tous les nœuds de la section, pondérée par « l’âge du nœud ».

Pour qu’un DBC soit dépensé, il doit être réémis sur les clés publiques du ou des nouveaux propriétaires. Pour cela, nous transmettons le Genesis DBC au client et lui demandons de réémettre de nouveaux DBC aux nœuds - plus un DBC à lui-même comme incitation. Le montant de cette incitation doit être déterminé.

Une fois les DBC réémis, les nœuds destinataires sont notifiés et peuvent désormais dépenser leur DBC comme et quand ils le souhaitent.

La création d’un nouveau SNT ne se produit qu’avec un nouveau stockage de données. Les transferts SNT n’entraînent pas la création d’un nouveau DBC.

Nous allons probablement changer le nom « Genesis DBC » car il existe de nombreux DBC de ce type, donc le mot « genesis » prête à confusion.

Finaliser l’agriculture/payer le stockage

Avec le concept d’émission de jetons qui se déroule bien, nous pouvons également voir comment nos plans de paiement de données s’intègrent et, heureusement, nous constatons qu’ils s’intègrent plutôt bien. C’est un flux dont nous avons parlé précédemment, avec des clients demandant des devis à la section pour un ensemble de données donné, puis effectuant les paiements appropriés pour cela. Ce qui est bien, c’est que cela est intrinsèquement groupé, donc un ensemble de rééditions DBC peut fonctionner pour n’importe quelle quantité de données.

Ce processus nous donne un reçu avec lequel nous pouvons valider qu’une donnée donnée a été payée, et que nous pouvons joindre aux données en la rendant effectivement « Network Valid », c’est-à-dire qu’elle peut être re-téléchargée sans avoir à payer pour ça, par exemple.

Ce reçu fera alors partie du processus de paiement du réseau, comme indiqué ci-dessus.

Utiliser les potins pour l’adhésion intra-section etmise à jour inter-sections de PrefixMap

Nous introduisons une approche de potins dans la création de nouveaux SAP pour garantir que le réseau est toujours accessible depuis toutes les sections. Ce mécanisme assure une diffusion logarithmique des informations (très rapide et efficace). Lorsqu’un ancien reçoit un nouveau SAP de n’importe quelle partie du réseau, il sélectionnera deux anciens au hasard de n’importe quelle section et leur transmettra le message. AE veillera à ce que les nœuds se mettent à jour dans les deux sens et mettra également fin à la ronde de potins. Il s’agit de « commérages inter-sections » et ne concernent que les anciens.

À l’intérieur de la section, nous avons des changements d’adhésion qui incluent les adultes. Ces changements suivront le même schéma pour s’assurer que tous les membres sont au courant de tout changement d’adhésion. Il s’agit de « commérages intra-section ».


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