Ceci est une traduction automatique. L’original en anglais est ici: Update 13 April, 2023
Quelqu’un a-t-il envie d’une plongée plus profonde?
Il y a quelques semaines, @oetyng nous a fait le point sur les conceptions d’un réseau de paiement et sur la façon dont cela pourrait fonctionner seul.
Avec la pile technologique du réseau qui évolue maintenant à un rythme que nous ne pouvions pas prévoir il y a même quinze jours, nous nous sommes donné la latitude et la flexibilité nécessaires pour poursuivre diverses voies de lancement, qu’il s’agisse d’un réseau de paiement uniquement ou de la suppression pour le réseau de données complet dès le départ.
@oetyng revisite donc le monde des paiements pour expliquer comment il est intégré au stockage, aux portefeuilles et aux API client dans la nouvelle conception simplifiée.
Tout d’abord, un mot sur la façon dont le réseau prend forme alors que nous passons de la conception des sections à Kademlia. Kademlia exige que les nœuds se parlent sur tout le réseau, plutôt qu’à ceux de leur section. S’ils ne le faisaient pas, la table de routage deviendrait rapidement périmée et pleine de nœuds morts et le réseau mourrait d’un mauvais cas de mauvaise communication. Vérifier les parents DBC est un moyen de s’assurer en permanence que les nœuds sont actifs tout en remplissant une fonction vitale, afin que nous puissions y doubler.
Les transactions se produiront très rapidement sur le réseau, mais Safe n’est pas une base de données et n’est pas adapté aux mutations rapides des données. Ce type de travail est effectué côté client, les résultats étant ensuite stockés/répliqués sur Safe. Les CRDT signifient que les clients peuvent collaborer efficacement, en temps réel et sans conflit, et les résultats de ces collaborations peuvent être stockés publiquement ou en privé sur Safe pour la postérité. Le déménagement à Kademlia clarifie cette division du travail.
Un autre résultat du changement est qu’il est peu probable que les petits réseaux de test soient stables. La nouvelle conception nécessitera probablement 2 000 nœuds ou plus pour fonctionner correctement. Ce n’est pas du tout un problème, mais cela changera évidemment la façon dont nous gérons les testnets.
Progrès général
Alors que nous nous rapprochons de la possibilité de publier quelque chose pour la consommation publique, Jim travaille sur le positionnement, les feuilles de route et la messagerie. Jetez un œil à son fil What is launch si vous ne l’avez pas déjà fait.
Avec ce jour en vue, @bzee a creusé dans la traversée NAT et comment nous pouvons l’implémenter, et @bochaco prépare nos types de données pour l’intégration dans la nouvelle infrastructure réseau, y compris en travaillant sur les API pour permettre aux développeurs de se lancer sur les applications dès que possible comme nous avons quelque chose de stable. Bochaco examine également les messages d’erreur, en voyant où nous pouvons les rendre plus spécifiques et utiles.
L’autre gros travail consiste à trier les groupes proches. Étant donné le nom d’un bloc de données (identique à son adresse XOR), le client sait à quels nœuds k demander de le récupérer, mais devrions-nous commencer par 20, ou quelque chose comme 8 ? Plus signifie que plus de nœuds mettent à jour leurs tables de routage, mais c’est aussi plus de messages. Qu’en est-il du stockage des DBC ? C’est quelque chose dont @roland et @qi_ma s’occupent. @roland revisite également la réplication de données.
Bien sûr, nous devons être en mesure de voir ce qui se passe, et @Chriso a refactorisé l’implémentation d’OpenSearch dans le référentiel testnet pour faire place à la configuration de la surveillance.
Et @oetying commence à rassembler tout ça. Plus de lui ci-dessous!
DBC, virements et portefeuilles
Simplification du code DBC
Au cours des deux dernières semaines, le code DBC a subi une simplification nécessaire depuis longtemps. Il y avait à la fois plus de documentation et une petite refonte de la terminologie, alignant la dénomination et les concepts pour moins de charge cognitive.
Une autre chose que nous pourrions faire maintenant, puisque nous n’avons plus de sections et d’anciens, était de supprimer la signature réseau des DBC. Cela en soi est une simplification massive. Ce que nous avons maintenant, c’est qu’un transfert peut être construit complètement hors ligne, et tout ce que vous avez à faire est d’envoyer les parties du DBC, appelées * dépenses signées * (c’est-à-dire la clé correspondant à un identifiant DBC, signé la dépense de ce DBC - donc, l’expéditeur des jetons a signé la dépense). Lorsque suffisamment de pairs du réseau ont accepté ces dépenses signées, la transaction est terminée et valide.
Dépenses DBC dans le réseau (transferts ou paiements de données)
Alors, pour prendre un peu de recul.
Au lieu de demander aux aînés d’une section de valider et de signer une dépense (c’est-à-dire un transfert ou un paiement de données), comme cela se faisait auparavant, nous envoyons désormais les dépenses signées par le client au groupe proche de l’identifiant du DBC à dépenser. (Nous l’appelons l’adresse. Ainsi, les blocs ont une adresse, les registres ont une adresse et les dépenses DBC ont une adresse). Ce groupe proche a déjà été mentionné. Les pairs du groupe proche ne signent rien. Ils valident simplement les dépenses, chacun d’eux agissant de manière indépendante, et les stockent s’ils les jugent valables. Une partie pour le trouver valide consiste à rechercher les parents d’une telle dépense. Cela signifie rechercher les dépenses qui ont conduit à la création de ce DBC même actuellement dépensé.
Si ces dépenses des parents peuvent être récupérées à partir de leur groupe proche respectif, cela signifie qu’elles sont valides, car elles ont elles-mêmes subi tson processus de retour quand ils ont été dépensés.
Il y a bien sûr plus de validations, telles que les quantités en aveugle vérifiant les entrées et les sorties, que les clés des dbcs d’entrée ont tout signé correctement, et ainsi de suite.
Et lorsque tout cela a été confirmé comme valide, un pair stocke simplement ces dépenses signées. Et lorsqu’un client doit vérifier si le DBC qu’il a obtenu est valide, il demande simplement au réseau de retourner les dépenses signées qui ont conduit à la création de ce DBC. Si le nombre requis de pairs le renvoie, alors c’est un fait.
Fermer les groupes
Donc, un groupe serré. N’oubliez pas que ceux-ci sont trouvés par proximité de l’identifiant du DBC (ou du hachage des données). Ils peuvent être 4, 8, 16 pairs ou plus. Nous allons commencer par un nombre et ajuster au fur et à mesure que nous progressons. Mais il y a plus que cela. Nous pouvons ajouter des couches en hachant l’identifiant/le nom et obtenir une nouvelle adresse dérivée de manière déterministe de la première. Maintenant, nous pouvons également stocker le même élément dans ce groupe. Et ainsi, cela peut continuer, hacher cette adresse encore et encore, et à chaque fois, un autre groupe détient l’élément.
Ce sont quelques-uns des leviers qui ont été mentionnés précédemment. Nous allons commencer simplement avec un seul groupe, car nous voulons d’abord le mettre en place et le faire fonctionner dans un testnet.
Portefeuilles
Nous venons de terminer la première implémentation simple d’un portefeuille contenant des DBC et un historique des transactions. Comme pour les données, la première itération utilise le stockage en mémoire. Ensuite, il le stockera localement sur le lecteur, puis nous effectuerons un stockage réseau. La bonne chose est que nous implémentons le portefeuille pour avoir une interface simple qui peut être utilisée avec l’un des trois (ou tous) des supports de stockage mentionnés ci-dessus.
Ce qui a également été pris en considération cette fois-ci, c’est que tous les pairs devront avoir un portefeuille pour leurs récompenses. Mais nous n’en sommes pas encore là, une semaine ou deux de plus pour cela. (Et oui, maintenant c’est beaucoup plus simple de faire des estimations de temps.)
Frais de transfert
Ceux-ci ont été décrits très récemment dans une mise à jour, et peu de choses y ont changé. Les paiements vont aux nœuds et la file d’attente prioritaire (anciennement appelée mempool) est la même.
Ce que nous examinerons probablement un peu plus tôt, c’est comment le même modèle peut être appliqué pour les paiements de données.
Et c’est vous qui êtes au courant de la progression des transferts et du paiement pour l’instant.
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é!