Actualités du développement Safe 🇫🇷 30 mars 2023

Dimitar · Avril 15, 2023, 6:31

Ceci est une traduction automatique. L’original en anglais est ici: Update 30 March, 2023

Parfois, lorsque vous travaillez avec une technologie de pointe, tout ce que vous pouvez faire est d’attendre que des développements se produisent ailleurs. Ces avancées peuvent être extrêmement longues à venir, mais cette semaine, nous sommes heureux d’annoncer une percée significative sur le front de la mise en réseau. Nous réalisons également des progrès significatifs sur les DBC, les frais de transmission et la manière dont ils sont gérés par les aînés. @oetyng explique plus.

Progrès général

Beaucoup de points positifs à raconter cette semaine. Tout d’abord, un travail de détective magistral par @qi_ma a mis au jour la cause profonde d’un problème de longue date que nous rencontrons avec le réseau démarrage, ce qui provoquait des échecs de CI. Heureux de dire que le mal de tête n’est plus.

Passons maintenant à quelque chose décrit par @dirvine à la fois comme « un changeur de jeu » et aussi, un peu mystérieusement, comme « très relaxant ». Alors c’est quoi? Eh bien cette semaine, Protocol Labs, l’équipe derrière IPFS et Filecoin, a mis à jour sa bibliothèque libp2p. Libp2p s’est avéré assez efficace pour le multiplexage et la perforation, mais jusqu’à présent, il n’a fonctionné que sur TCP. Cela a maintenant changé et la bibliothèque fonctionne avec UDP et QUIC, ce que Safe utilise pour gérer les connexions entre les nœuds. Libp2p est utilisé par Filecoin, Eth et Avalanche et a plein d’excellents ingénieurs qui travaillent pour lui.

Encore mieux, nous obtenons gratuitement la perforation, la découverte de nœuds locaux, les protections DoS et plus encore. Il semble que libp2p soit maintenant ce qu’il devait être et ce que nous essayions de créer avec qp2p : une bibliothèque solide axée sur le p2p. Avec l’inclusion récente de QUIC, nous pouvons voir que l’équipe libp2p a réalisé qu’une grande partie du travail qu’elle a effectué (multiplexage de flux, bruit pour la sécurité, etc.) est couverte par QUIC.

Quoi qu’il en soit, de bonnes nouvelles à tous points de vue. Cela devrait signifier que nous avons enfin une grande stabilité dans la couche réseau et que la couche réseau fonctionne comme nous le souhaitons. Alors chapeau bas les gens de libp2p Avec un peu de peaufinage et quelques relations publiques, nous devrions enfin pouvoir remplacer Quinn et qp2p sur Safe. Les limites de ces bibliothèques ont empêché David de dormir la nuit pendant de nombreux mois. Enfin, il peut se détendre. :Parasol:

@bzee a déjà réussi à obtenir un prototype de réseau Kademlia spécifié avec libp2p et avec un peu plus de travail qui devrait être opérationnel en tant que test. @Roland fouille également dans la documentation pour voir si nous pourrions en tirer parti.

@bochaco a ajouté des commandes CLI au nœud RPC pour permettre des choses comme les vérifications du niveau de stockage, les requêtes de récompense et les mutations de portefeuille.

Et @oetyng a été en devoir de paiement. Plus d’informations à ce sujet ci-dessous.

Mise à jour sur le réseau de paiement

Nous avons couvert quelques étapes vers un réseau de paiement.

Tout d’abord, comme certains l’ont déjà constaté lors de l’exploitation d’un réseau local, nous avons demandé aux clients d’interroger les aînés moyennant des frais (une valeur codée en dur de 1 nano) et d’étendre leur transfert pour contenir également un DBC chacun pour les aînés. Cela signifiait que lors de l’envoi de jetons, chaque entrée DBC que vous dépensez coûterait 7 nanos payés aux Anciens.

Mais le paiement était essentiellement une brûlure. Parce que l’aîné ne pouvait ni voir qu’il y avait un paiement pour eux, ni y accéder.

Vérification du montant des frais

Ainsi, l’étape suivante consistait à introduire le « aveuglement » du montant des frais, afin que l’Ancien puisse vérifier que A. il y avait un paiement pour eux, et B. que c’était un montant suffisant . Parce que rappelez-vous, un étranger ne peut pas voir quel montant contient un DBC, ni à qui il est destiné. Nous devons avoir un moyen de dire ces choses aux Aînés.

Ainsi, les clients envoient une paire de chiffres - des informations cryptées - avec leur demande de dépenses. Lorsque l’Ancien le reçoit, il peut le déchiffrer et obtenir ce qui suit :

Indice de dérivation

L’« indice de dérivation » est utilisé pour dériver la clé publique (essentiellement l’identifiant unique) du nouveau DBC contenant le paiement des frais. Le client obtient cet identifiant à partir de la clé publique statique que l’aîné envoie, ainsi que le montant des frais actuellement requis pour interroger l’aîné.

L’Aîné utilise ce même indice de dérivation pour dériver la clé secrète correspondante, avec laquelle il peut déverrouiller la valeur dans le DBC contenant le montant des frais pour lui.

Comme cet index de dérivation est envoyé crypté à l’Aîné, personne ne peut dire qu’il y a un paiement à cet Aîné, et il n’y a aucun moyen de voir à combien il s’élève.

Facteur aveuglant + montant

De plus, le client envoie le «facteur aveugle» et le montant cryptés.

Avec le « facteur aveugle », l’aîné peut aveugler le montant et le comparer avec le montant de la transaction DBC. En effet, si le même « facteur d’aveuglement » et la même quantité sont utilisés, cela produit exactement le même brouillage inintelligible. C’est pourquoi le « facteur aveuglant » est également crypté. Seuls le Client et l’Aîné connaîtront le montant.

Pour plus de détails sur le flux ci-dessus, vous pouvez lire la section des commentaires en haut de ce fichier : safe_network/mod.rs at main · maidsafe/safe_network · GitHub

Enfin gfixer les frais

Lorsqu’une super majorité d’anciens ont signé les dépenses, ils envoient chacun un « SpentProofShare » aux détenteurs de données du réseau. Lors de l’interrogation de ces partages, le SpentProof peut être agrégé à partir de ces signatures, et les DBC correspondant à chacune des sorties de la transaction peuvent être créés. Un ancien peut ainsi interroger le réseau pour ceux-ci, puis construire le DBC qui contient le paiement des frais.

Des frais codés en dur aux frais dynamiques

Un nano par frais ne va pas beaucoup aider, nous avons donc creusé le calcul des jetons requis pour stocker certaines données que nous avions déjà dans nos archives.

L’implémentation calcule les jetons requis pour les opérations d’écriture, en tant que nombre de jetons à payer pour un certain nombre d’octets, en fonction du préfixe de section actuel, du nombre de nœuds dans la section et du pourcentage de remplissage. Cela peut également être utilisé pour calculer les frais d’un transfert, car nous l’alimentons simplement avec un nombre fixe d’octets.

Compte tenu des paramètres d’entrée et de la conception de la courbe, il y a un effet sur le prix basé sur l’offre et la demande, mais avec une certaine inertie. La valeur calculée est plus élevée lorsqu’il y a moins de nœuds dans la section, lorsqu’il y a moins d’espace disponible et plus tôt dans le réseau. Plus tôt dans le réseau ? vous pourriez demander. Oui, on suppose qu’un réseau plus grand signifie que le jeton a une plus grande valeur puisque plus de personnes partagent un nombre constant de jetons. Par conséquent, le nombre requis de jetons par opération est également inférieur à mesure que le réseau se développe. En d’autres termes, le prix reflète le caractère déflationniste du SNT.

Une autre propriété de la courbe est qu’elle est très plate à un niveau bas jusqu’à ce qu’il reste environ 1/3 d’espace, après quoi elle commence à se raidir rapidement. La raison est que les frais restent aussi bas que possible aussi longtemps que possible.

Mais cela ne remplace pas un véritable marché. Même si nous avons un certain contrôle sur l’offre et la demande, celle-ci est assez lente, et le montant des frais basé sur cela est donc assez rigide. Il est donc difficile pour le réseau de refléter les changements réels de la valeur fiat du jeton, et cela peut entraîner de grands déséquilibres - ce qui n’est jamais une bonne chose. De tels déséquilibres pourraient être beaucoup trop de demandes ou beaucoup trop peu, car la valeur réelle n’est pas synchronisée avec la valeur calculée à partir des paramètres du réseau.

Cela nous amène à la possibilité pour un client de * prioriser * ses dépenses, et ce que cela nous ouvre.

File d’attente prioritaire des dépenses

Une « priorité » attachée à une dépense est un grand pas en avant vers un véritable marché, où les propriétés offre/demande du système sont agiles et réactives.

Cela est fait par les Aînés qui gardent une * file d’attente prioritaire *, classée par la valeur des frais qui leur sont payés pour signer la dépense.

Les avantages de la mise en place d’une file d’attente prioritaire sont les suivants :

Les clients peuvent obtenir un prix inférieur pour leur stockage si la demande est faible.
Les aînés peuvent obtenir une récompense plus élevée pour leurs services si la demande est élevée.
Les incitations pour les opérateurs de nœuds à exécuter des nœuds supplémentaires augmentent lorsque la demande augmente.
Le réseau devient plus réactif et peut se développer plus rapidement (attirer plus de nœuds d’exécution) lorsque la demande augmente.
Le fonctionnement continu des nœuds est mieux protégé contre la surcharge des dépenses des clients.
La charge sur le réseau est étalée dans le temps, car les gens reportent leurs dépenses en période de charge élevée et les déplacent vers des périodes de charge plus faible.
Il est possible que les aînés accèdent à leurs récompenses plus rapidement, car ils peuvent les rassembler et les réémettre dans un DBC plus grand lorsque les frais sont bas.
…et plus…

Le premier exemple utilise quelques étapes « prioritaires » discrètes pour un client, à utiliser à partir de l’interface utilisateur du portefeuille lors d’un paiement. Cela supprime tout besoin de définir manuellement les montants des frais.

La priorité est traduite en frais basés sur les frais actuels dans la file d’attente. Une priorité élevée signifierait que vous payez une valeur similaire à ceux plus élevés dans la file d’attente, et vice versa pour une priorité faible. Vous pouvez également le définir sur * au-dessus * de la valeur la plus élevée, ou * en dessous * de la plus basse, et c’est là que la pression sur les prix peut commencer, en fonction de l’offre et de la demande, et des besoins des clients et des opérateurs de nœuds pour trouver un équilibre.

Par le choix de la priorité, le Client décide essentiellement à quelle vitesse il souhaite que cela soit traité. Ils peuvent le faire traiter plus ou moins instantanément, ou fixer les frais à un niveau inférieur pour le faire traiter à un moment où la demande et les frais sont moins élevés.

Notez qu’il y a toujours une limite au niveau auquel le client peut fixer les frais. En dessous, il serait supprimé et une erreur renvoyée au client.

Il devrait également être possible pour un client de mettre à jour une dépense en attente, afin qu’elle ne soit pas bloquée si les frais et la demande restent à un niveau plus élevé.

Résumé

Donc, pour résumer, l’idée de base est que dépenser un DBC peut entraîner de nombreux DBC de sortie. Lorsque nous envoyons une demande aux Aînés pour dépenser un DBC, nous joignons également ces résultats.

Les aînés vérifient ensuite le montant et procèdent au traitement des dépenses.

Le lecteur observateur aurait noté que les honoraires payés à un aîné sont dans un DBC, et quand l’aîné veut dépenser ce DBC, alors il prendrait des honoraires pour le dépenser, et si l’aînédeux sont pareils… alors vous n’avez… rien ?
C’est exactement comme ça. Et donc, si l’on se souvient que l’algorithme de prix renvoie des valeurs d’autant plus faibles que le réseau est grand, on peut voir qu’il y a une sorte d’effet lock-in + early bird. Au fur et à mesure que la valeur nominale d’une redevance diminue, les redevances précédemment payées deviendront de plus en plus « accessibles ».

C’est également là que la file d’attente prioritaire aide. Les frais perçus lors de charges élevées pourraient être perçus et réémis lorsque les frais sont inférieurs. Un autre facteur qui contribue à égaliser la charge.

J’espère que cela vous donne à tous un bon aperçu de ce qui se prépare.

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