Ceci est une traduction automatique. L’original en anglais est ici: Update 06 October, 2022
La plupart de l’équipe est occupée à refactoriser Authority, le code qui nous dit quels acteurs peuvent faire quelles actions et quel niveau de l’autorisation dont ils ont besoin. Nous passons la main à un jeune type appelé @dirvine pour expliquer davantage.
Progrès général
D’autres correctifs sont également en cours.
@anselme a corrigé une erreur dans la caisse sn_sdkg qui impliquait de rendre la gestion des votes récursive. Avec cela, un nœud effectuant DKG seul atteindrait récursivement la terminaison lors de la gestion de son premier vote en un seul appel ! (Pas bon).
@bochaco continue de déboguer les communications entre les nœuds, avec @qi_ma, et corrige également les problèmes rencontrés avec les commandes à thread unique et les requêtes/requêtes dans le pipeline d’intégration continue (CI).
Pendant ce temps @bzee et @chriso continuent d’examiner le fonctionnement de Quinn, l’implémentation Rust du protocole Quic pour établir et maintenir des connexions entre pairs, en vue de refactoriser qp2p.
Autorité de refactorisation
Pour le moment, nous avons une autorité par message et cette autorité est répartie entre le nœud, le client, la section et la section_part. C’est à la fois déroutant et sujet aux bugs. Plus récemment, nous avons creusé dans « l’autorité », ce que cela signifie et ce qu’elle nous achète.
La première étape de ce nettoyage consiste à supprimer l’autorité des messages et à se concentrer sur les « opérations ». Nous entendons par là que l’opération dans le message est l’endroit où nous voulons vérifier l’autorité et également pouvoir l’appliquer directement aux données. Cette partie nous permet d’économiser, 1 : avoir l’autorité (signatures) deux fois et 2 : s’assurer que toute mutation de données (y compris le stockage) a l’« autorité » appropriée.
Pour casser un peu ça. Pour stocker des morceaux ou un conteneur (un registre), nous exigeons que les clients paient. Lorsqu’il a payé, chaque ancien retourne une partie de signature de section. Le client agrège ensuite la signature pour créer une signature de section. Cette signature de section reste avec les données et rend les données « NetworkValid ». Il n’y a donc aucun sens à signer tout le message, juste la partie qui dit « Store ABC », où ABC est le nom des données. Ainsi, chaque élément de données a maintenant SectionAuthority et nous ne nous soucions pas du message ou du format dans lequel nous recevons l’opération signée.
Alors quoi, certains peuvent demander. Essentiellement, ce que nous faisons maintenant est assez excitant à plusieurs points de vue :
- Encore moins de code
- Des types de données plus concrets
- Suppression de l’exigence de toute signature de message (mise en garde dans une minute).
- Et le grand … voir ci-dessous
L’astucieux peut à ce stade remarquer une grande victoire pour les réseaux décentralisés ici. Avec les éléments de données SectionSigned et le SectionTree à partir de quelques mises à jour, nous avons des données valides indépendantes du réseau. c’est-à-dire que tout réseau qui fait également confiance à notre SectionTree, même la majorité (dans le cas d’un méga hack) peut valider et faire confiance aux données NetworkValid. Cette fonctionnalité permet aux données de se déplacer vers d’autres réseaux, ou même Safe II, qui sait ?
Cependant, nous avons des messages de signature de nœuds, et nous considérons cela comme une « preuve ». Les nœuds envoient des messages entre eux et aux clients avec des données ou des suggestions (comme le nœud X est mort ou le nœud Y veut se joindre, etc.) et nous traitons leurs messages comme des commandes d’infrastructure (c’est-à-dire transitoires) ou des commandes de service client (donnez-moi des données). Comme ces messages entraînent des conséquences sur le réseau, nous exigeons que les nœuds se comportent. S’il s’avère qu’ils se conduisent mal, nous devons avoir une preuve irréfutable de leur mauvais comportement afin de pouvoir les punir. Le message signé nous donne une preuve irréfutable du comportement d’un nœud.
En tenant compte de tout cela, le refactor actuel est plutôt rapide, ce n’est que quelques jours, mais il nous achète une tonne de simplicité et en même temps nous donne plus de flexibilité dans le stockage/republication des données. Imaginez que vous trouviez d’anciennes données sur votre nœud, elles ne sont pas sur le réseau mais devraient l’être. Ensuite, vous ne devriez pas avoir à payer pour les stocker, vous devez simplement dire que voici les données SectionSigned, vous DEVEZ les stocker. C’est le contrat du réseau avec la planète.
Non seulement cela, les clients qui paient pour stocker, paient en fait pour obtenir SectionAuthority sur les données, ce qui en fait NetworkValid. Désormais, cela signifie qu’ils peuvent ajouter l’autorité de section à leurs données et choisir de la stocker à tout moment. Ils peuvent également le republier si le réseau leur a fait défaut.
Nous sommes 3 ou 4 à effectuer cette tâche cette semaine et déjà, nous constatons des améliorations dans la clarté et trouvons peut-être des bogues étranges lorsque nous supprimons l’ancien code de retour (la messagerie contient encore du code très ancien). C’est une refactorisation vraiment soignée qui rendra la chasse aux bogues tellement plus simple qu’elle simplifiera les opérations du réseau. Cela rend également le réseau plus simple à expliquer.
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é!