Ceci est une traduction automatique. L’original en anglais est ici: Update 12 January, 2023
Tout d’abord, un grand merci à tous ceux qui ont participé à notre testnet la semaine dernière. Nous le considérons comme un succès car tous nos changements récents ont fonctionné comme prévu et le réseau est resté stable jusqu’à ce qu’il soit plein. Bon produit. 
Certains d’entre vous ont remarqué que nous avions besoin de 7 anciens pour répondre au client plutôt que de 5. C’est parce que nous étions intentionnellement sévères en testant les connexions et en nous assurant que tout fonctionne correctement. Nous sommes occupés à déployer d’autres améliorations et nous vous enverrons un autre testnet une fois qu’elles seront en place. Mais les exigences « tous les anciens doivent répondre » et les exigences similaires en « mode strict » resteront encore en place pendant un certain temps.
En arrière-plan, l’équipe a travaillé sur les détails les plus fins de la distribution de jetons. @JimCollinson nous explique où nous en sommes.
Progrès général
@qi_ma et @roland continuent de simplifier le flux de relocalisation. C’est l’un des domaines les plus complexes à maîtriser. D’abord, les anciens doivent remarquer qu’un nœud a disparu et voter sur ce fait. Ils doivent ensuite voter sur le changement d’adhésion, notifier un candidat pour remplacer le nœud manquant, puis échanger des messages afin que le nouveau nœud dispose de toutes les informations dont il a besoin avant que les données ne lui soient transférées. Donc, beaucoup de pièces mobiles et plus nous pouvons le rendre simple, mieux c’est.
Pour surveiller ces événements complexes, nous avons besoin d’un système d’observabilité de surveillance solide, sur lequel @chriso travaille. Actuellement, il travaille à faire fonctionner OpenSearch et OpenTelemetry avec Amazon ECS.
@Roland affine également une interface graphique à utiliser avec safe pour supprimer le besoin d’utiliser la ligne de commande redoutée. Devrait être démontable bientôt.
@Joshuef continue de réduire le nombre de communications que nous traitons entre les nœuds. Il semble que nous contactons des nœuds qui sont en dehors de la section et que nous attendons ensuite des réponses qui ne viennent jamais, provoquant des erreurs.
@bochaco a fini de supprimer le flux d’envoi de Cmd :: SendMsg, en introduisant une nouvelle commande pour séparer les flux censés être exclusivement sur les flux.
Et @anselme tourne son attention vers certains refactors DBC. Plus à ce sujet à une date ultérieure.
Mises à jour des plans pour la distribution sécurisée de jetons réseau
Salut les gens. Une petite mise à jour pour le Token Distribution RFC alors que nous tournons autour de certaines solutions.
Il y a beaucoup de pièces mobiles; des capacités techniques, des propositions de conception, des considérations opérationnelles aux commentaires juridiques. Beaucoup de choses vont dans des ajustements qui peuvent sembler petits à première vue, nous vous remercions donc pour tout le soutien, la patience et vos commentaires et commentaires approfondis dans le dernier fil de discussion RFC 0061.
Émission de jetons et fourniture Genesis
Le plus grand changement ici est une réponse à la question de savoir si nous monnayons l’offre totale lors du lancement du réseau, et comment et quand les 70 % des jetons restants sont créés puis distribués.
Pour frapper l’offre totale au lancement, il a fallu que la Fondation ou le réseau lui-même détienne puis distribue ces jetons au fil du temps, qui présentent tous deux des défis importants que nous voulons éviter, au premier rang desquels la sécurité, mais aussi la répartition équitable d’une part considérable du puissance économique.
Un rappel que les objectifs étaient A. la libération progressive des jetons restants, tout en B. faisant en sorte que les jetons soient sous la garde du réseau.
La solution ici n’est pas du tout de les faire créer à l’avance, mais plutôt que le réseau les émette au fil du temps - en les créant au fur et à mesure que le réseau se développe - et en les versant aux opérateurs de nœuds en tant que récompenses d’approvisionnement en ressources.
Bien qu’il s’agisse encore d’un gros travail qui ne sera probablement pas terminé sans retarder la création du réseau, nous sommes convaincus qu’il s’agit d’une solution de conception raisonnable à portée de main et qui peut être mise en œuvre via une mise à niveau du réseau après le lancement.
Ainsi, l’offre Genesis, circulant au lancement, représentera donc 30% de l’offre maximale, et le reste ne commencera à voir le jour qu’après qu’une solution satisfaisante, sécurisée et robuste aura pu être présentée et déployée ; puis ces jetons s’écouleront vers les contributeurs du réseau sur une période prolongée, probablement des décennies.
Autres modifications mineures
Vous remarquerez également quelques autres modifications mineures, telles que le langage décrivant l’éligibilité aux redevances de réseau en tant que développeur d’applications ; plus de précision sur l’attribution du SNT aux actionnaires ; et indiquant directement que eMaid sera échangeable 1: 1 contre des jetons de réseau sécurisé, tout comme la saveur originale MaidSafeCoin.
Approvisionnement maximal
Vous remarquerez le changement de terme de l’offre totale à l’offre maximale, afin de mieux articuler les changements autour des émissions symboliques et l’offre de genèse proposée.
Une chose que nous proposons reste de la RFC, c’est le changement du plafond original de Safecoin de 2 ^ 32 à l’offre maximale de 4 525 524 120. Il s’agit de résoudre la bizarrerie de la crowdsale originale qui a vu une overmint de MAIDE.
Mais il est important de noter que :
- Aucun investisseur, participant au crowdfund ni détenteur de MAID ne perd.
- L’échange similaire 1: 1 Maid à SNT tant vanté reste; qui est facile à décrire et à comprendre, et très utile à maintenir pour la convivialité lors de la montée en puissance sur le réseau avec MAID.
- En raison de changements techniques fondamentaux, les jetons ne sont plus liés aux adresses réseau. Cela permet des choses comme la divisibilité, mais nous donne également la liberté de spécifier une offre maximale appropriée.
- L’offre maximale de MAID est connue et annoncée depuis près d’une décennie maintenant, affichée sur toutes les applications d’échange et de blockchain, ainsi que les conditions de rachat 1: 1, ce n’est donc pas une surprise.
- C’est une solution plus propre et nous pensons qu’il est plus facile d’expliquer les allocations de 5/10/15 % accordées aux pools de distribution initiaux, et leur part dans l’économie globale, que d’examiner à plusieurs reprises pourquoi le MAID est maintenant de 10,37 %.
Nous savons que c’est un choix que certains d’entre vous n’aimeront pas, mais c’est un choix entre deux options esthétiques/ergonomiques, qui arrivent toutes deux au même résultat, nous avons donc choisi ce que nous pensons être le chemin de moindre résistance.
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é!