Ceci est une traduction automatique. L’original en anglais est ici: Update 23 February, 2023
Plus que toute autre chose, ce qui rend difficile la mise en réseau décentralisée et distribuée fiable est l’asynchronicité : nous ne pouvons tout simplement pas garantir que le « message A » arrivera avant le « message B », ou même s’il arrivera. Avec quelques nœuds, c’est OK, mais dans une section avec des dizaines de nœuds, le nombre de combinaisons possibles d’événements et de messages est énorme, et un véritable défi à raisonner. Cette semaine, nous examinons Stateright, un outil très utile pour tester nos hypothèses algorithmiques car il essaie toutes les différentes possibilités.
Progrès général
@bochaco teste la réponse du réseau à différentes tailles de blocs, y compris la façon dont il gère les cartes de données. Les petits morceaux sont plus rapides à transmettre, mais ils créent des cartes de données beaucoup plus grandes, nous devons donc les chiffrer automatiquement de manière récursive jusqu’à ce qu’ils soient inférieurs à chunk_size. Il y a aussi d’autres compromis plutôt techniques, mais fondamentalement, nous recherchons une taille optimale pour nos morceaux.
@anselme et @dirvine examinent un champ « raison » pour DBC SpentProofs - la preuve d’une transaction. Il s’agit d’un nouveau champ qui contient la raison de la dépense. Il peut s’agir du hachage des morceaux payés ou d’un numéro de bon de commande, ou d’une autre sorte d’étiquette. L’important est que les anciens pourront dire si c’est valide ou non (par exemple, s’il s’agit d’un paiement pour un seul bloc, le Tx correspond-il au prix de stockage des données ?).
Pourquoi faire ceci? Simplification et sécurité. Cela pourrait signifier que nous pouvons éliminer la nécessité pour les aînés de signer les données. Ainsi, plus de risque d '«attaque par ancienne clé» où si un mauvais acteur met la main sur une clé précédente, il pourrait l’utiliser pour valider des données. Avec cette conception, les signatures des anciens anciens ne seront plus valides.
Le flux:
- Le client demande un devis pour stocker les données : 1 SNT s’il vous plaît
- Le client réédite un 1 SNT DBC pour les anciens avec une référence aux données comme raison DBC
- Le client dit aux anciens qu’il est dépensé en envoyant des entrées SpentBook pour ce DBC (les entrées contiennent la «raison»)
- Les aînés vérifient cette raison et mettent à jour leurs SpentBooks
- Le DBC est maintenant officiellement dépensé pour une raison
- Le client demande aux anciens actuels une copie signée de cette entrée SpentBook
- Une fois que le client obtient suffisamment de signatures, il peut stocker les données en fournissant une copie signée de la section actuelle de l’entrée SpentBook avec les données
- Les anciens vérifient si la section signée (ce qui signifie que la plupart des anciens voient la même raison) l’entrée SpentBook fait référence aux données et les stocke.
Nous continuons à supprimer les verrous de lecture/écriture dans le code pour de meilleures performances et une simplification (pas de multithreading sauf si absolument nécessaire). @joshuef travaille à supprimer le gros autour de l’état node lui-même.
Comme certains membres de la communauté aux yeux perçants l’ont déjà remarqué, @oetyng modélise une version simplifiée d’un réseau de paiement.
@chriso travaille à l’amélioration des aspects de la CLI, notamment en retravaillant la commande de mise à jour.
Et @davidrusu s’est retrouvé coincé dans Stateright.
Droit d’État
Stateright est une bibliothèque Rust qui promet d’être d’une grande aide pour tester les hypothèses. Fondamentalement, il s’agit d’un vérificateur de modèle qui parcourt toutes les combinaisons possibles d’événements pour vérifier si une hypothèse énoncée est valide.
Les réseaux décentralisés sont difficiles à modéliser pour diverses raisons : les nœuds peuvent mourir, les nœuds peuvent être byzantins, les messages peuvent être retardés, les messages peuvent arriver dans le désordre ou pas du tout, vous pouvez avoir des conditions de concurrence inattendues, etc., etc. Stateright aide nous travaillons à travers toutes ces possibilités.
Par exemple, nous pourrions vouloir savoir si la double dépense DBC est possible avec notre conception actuelle. Nous modélisons l’hypothèse « Doublespend is not possible » dans le code, l’ajoutons à notre base de code existante et définissons Stateright dessus. Stateright passera ensuite en revue chaque combinaison unique, comme le permet notre modèle d’algorithme. Cela retardera les messages, fera échouer deux aînés à la fois et enverra des événements dans le désordre. Une fois qu’il a épuisé toutes les possibilités sans pouvoir dépenser deux fois, nous obtenons une belle coche verte - notre hypothèse est valide. Chaque état trouvé était correct.
Si quelque chose échoue, il nous redirige éventuellement vers une interface graphique où nous pouvons parcourir les messages qui ont conduit à l’échec et déterminer quel était le problème.
Ce qui est génial, c’est qu’il essaie tout, pas seulement un sous-ensemble de combinaisons possibles. Sur les réseaux décentralisés, ce sont les cas extrêmes qui vous tuent, et avec Stateright, contrairement aux autres méthodes qui utilisent l’échantillonnage, vous pouvez être sûr qu’il les couvre tous. Il peut y avoir des millions de combinaisons à parcourir, mais tant que nous avons correctement écrit les hypothèses, c’est assez rapide.
L’autre chose est que c’est une grande aide pour corriger itérativement notre code. Ce sont quelques fonctions supplémentaires que nous pouvons mettre dans notre base de code de production pour vérifier les modèles. Nous allons très probablement l’utiliser pour écrire des morceaux spécifiques de code de production et le faire dans un modèle. Lorsque le modèle est satisfait, nous prenons ce code de production et le mettons dans Safe.
Vous pouvez en savoir plus surut Stateright dans les docs ou à partir de cette vidéo - qui même si c’est un l’intro est assez technique.
Mieux encore, voici un lien vers nos expériences en cours. Pour les curieux/intéressés/curieux, il suffit de cloner ce dépôt GitHub - maidsafe/stableset-experiments. Nous utilisons la branche master de Stateright, vous devrez donc également la cloner dans le même dossier où vous avez cloné le référentiel d’expériences.
Soyez conscient, cependant, qu’il s’agit de données expérimentales réelles de Safe Labs et qu’elles changent considérablement au jour le jour à mesure que nous augmentons la barre dans nos recherches de simplicité.
Si vous faites un cargo run --release puis ouvrez http://127.0.0.1:3000, vous verrez l’interface graphique. Vous pouvez ensuite cliquer manuellement sur les messages à envoyer ou bien cliquer sur « Exécuter jusqu’à la fin » et cela vous montrera où se trouvent les problèmes actuels. Sachez que nous avons presque toujours des problèmes là-bas car nous testons de manière itérative, alors ne vous découragez pas, c’est vraiment génial 
.
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é!