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

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

Cette semaine, nous examinons un peu plus en profondeur les émissions de SNT. C’est ainsi qu’après la distribution initiale de jetons à la création du réseau, les 70 % restants des l’offre totale sera créée et distribuée en toute sécurité grâce au téléchargement de données sur le long terme. Nous avons réfléchi un peu plus à la manière dont cela devrait fonctionner pour qu’il soit aussi simple et sécurisé que possible, et nous avons supprimé quelques étapes de notre conception d’origine.

Bravo à @southside pour tester les dernières versions et fournir des journaux :pray:. Examinons maintenant ces pics et ces défaillances de nœuds.

Progrès général

@Davidrusu a rationalisé les journaux afin que chacun soit une seule ligne pour faciliter leur analyse et éliminer les informations superflues. Malheureusement, dans le processus, nous aurons bousillé le Vdash de @ happybeing - mais j’espère que ce n’est pas trop difficile à déboucher à nouveau.

Une grande partie du reste du travail consiste à tester des tests des tests. Suite à une suggestion de @Chriso, nous apportons quelques modifications à la façon dont les tests affectent la construction nocturne, en introduisant une branche de mise en scène et en priorisant la correction des échecs de test qui empêchent une publication là-bas, afin que le code soit toujours prêt à être publié ou proche de celui-ci.

Et @anselme a corrigé un problème dans l’étape de diffusion de la clé éphémère BLS dans DKG. La diffusion de la clé BLS et les votes DKG fonctionnent correctement maintenant et tous les membres reçoivent tous les votes, une étape importante.

Émissions SNT

Lorsque les utilisateurs téléchargent des données sur le réseau, ils paient. Nous ne voulons pas que chaque paiement entraîne des émissions de SNT, juste une partie d’entre elles, et nous voulons que cette proportion varie en fonction des besoins du réseau. Si le réseau nécessite plus d’espace de stockage, la proportion de téléchargements entraînant une émission SNT augmente pour attirer plus de nœuds de stockage, lorsqu’il y a beaucoup d’espace, elle diminue. Le mécanisme exact pour cela est encore en discussion, mais nous espérons vous apporter plus de détails sous peu.

Un paiement qui entraîne la création d’un nouveau (Genesis) DBC est appelé (pour l’instant) un Genesis event. L’événement Genesis nécessite un GenesisProof qui est un fichier qui encode les informations sur la valeur du DBC et ses destinataires.

La valeur de la Genesis DBC est assez simple - c’est une partie fixe de la valeur de la transaction de stockage (par exemple, 90% du paiement initial peut être récompensé).

La partie destinataires est celle où les choses sont un peu plus complexes. L’« événement Genesis » d’une transaction se produit dans une seule section, et tous les anciens et les nœuds de stockage sont payés proportionnellement à l’âge de leur nœud. Mais l’adhésion à une section est en constante évolution, alors comment savoir quels nœuds payer ?

Les informations sur les anciens de section sont conservées dans le fournisseur d’autorité de section (SAP), mais elles ne sont peut-être pas à jour, et pendant qu’elles sont mises à jour via AE, les membres peuvent changer à nouveau.

Donc, une meilleure façon serait d’utiliser les destinataires du paiement « Evénement Genesis ». Le client est informé sur la demande du magasin (devis) qui payer, y compris le SAP (anciens) et les nœuds de stockage. L’âge des nœuds au moment du devis peut être calculé à partir de leur ID. De cette façon, n’importe lequel des destinataires peut réémettre le DBC à lui-même et aux autres destinataires à tout moment, et le paiement sera garanti pour lui parvenir même s’il n’est plus dans la section, le processus est déterministe.

Cependant, notre premier port d’escale pour la réémission sera toujours le client (le payeur), car cela soulage un peu le réseau. Nous discutons si l’un des destinataires de la récompense DBC pourrait être le client lui-même, ce qui inciterait le client à effectuer la réémission, mais si cela échoue, l’un des nœuds de réseau mentionnés dans le « GenesisProof » peut le faire à la place.

Ne payer que pour stocker des adultes, plutôt que tous les adultes d’une section (un autre scénario possible), fonctionne bien car cela signifie moins de DBC et moins de messages. Au fil du temps, les paiements sont effectués de manière aléatoire sur la section/le réseau car les nœuds de stockage sont déterminés par l’adresse XOR des blocs de données.

C’est donc vers cela que nous travaillons maintenant. Nous devons encore déterminer comment définir le coût du magasin, comment rendre l’extraction de SNT non rentable pour les sections malveillantes et où stocker les « GenesisProofs ».

Nous tenons également à supprimer le surnom de « Genesis » pour les nouveaux DBC, car cela prête à confusion. Une suggestion est RootDBC - qu’en pensez-vous, oh communauté ?


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