Ceci est une traduction automatique. L’original en anglais est ici: Update 13 January, 2022
C’était fantastique et gratifiant de voir le dernier testnet de la communauté fonctionner si bien 
. Un grand merci à tous ceux qui ont participé 
. Maintenant que le réseau devient plus stable, il est temps de passer aux détails du stockage et de la récupération des données, et nos plans actuels sont décrits ci-dessous. Comme toujours, nous essayons de proposer des mécanismes de base légers et flexibles et qui peuvent être facilement étendus pour prendre en charge d’autres fonctions telles que les paiements et l’agriculture. Plus important encore, ils n’impliquent aucune hypothèse de synchronisation du réseau.
Progrès général
@yogesh a réussi à résoudre un problème logique lors de la promotion de nouveaux anciens, en réduisant le nombre de tours AE, et par conséquent les échanges de messages, de 150 à 15. C’est une optimisation 10X impressionnante, mais il est sûr qu’il y a encore plus à faire ici à un stade ultérieur. Lui et @anselme examinent maintenant les processus de traitement des données décrits dans la section principale ci-dessous, avec @qi_ma déboguant le processus de traitement des accusés de réception et des erreurs au niveau du client.
@Joshuef a introduit Bors, un système d’automatisation qui intègre plusieurs PR à la fois, donc c’est un vrai gain de temps quand ça marche - ce qui, après un peu de bricolage, est la plupart du temps le temps maintenant, heureusement. Lui et @oetyng ont également travaillé sur le déplacement des registres vers les adultes, la simplification des entrées de registre et l’assouplissement de l’exigence actuelle d’envoyer des demandes aux sept anciens (voir ci-dessous).
@bochaco envisage le consensus d’adhésion au flux de routage et les nœuds de gestion qui ont été mis hors ligne, et comment cela sera intégré au travail DKG que @davidrusu et @danda ont fait avancer.
@chriso a mis à jour et rangé la documentation CLI, et @lionel.faber a corrigé certains tests de bout en bout qui ne réussissaient pas, mettant à jour l’outil testnet dans le processus.
Le traitement des données
Le cœur du réseau Safe est sa capacité à stocker des données de manière sécurisée, fiable et permanente. Voici un aperçu de notre réflexion actuelle sur le traitement des données. Cela touche également à d’autres problèmes, tels que l’interface utilisateur / UX et les contrôles de vivacité pour les adultes afin de voir s’ils font ce qu’ils doivent faire, ainsi qu’un mécanisme permettant aux clients de payer pour le stockage.
Données valides
Les données stockées sur le réseau doivent être valides du point de vue du réseau. Une fois qu’une donnée est valide, elle peut potentiellement être stockée par n’importe qui.
Chaque donnée est composée d’un nom, du contenu, d’une signature et d’une clé de section.
Le nom doit être signé par n’importe quelle clé de section valide (ancienne ou actuelle), et la clé de section proviendra de la section où elle est stockée.
Pour rappel, une section est composée de sept anciens décideurs et de bien d’autres (60 à 100) adultes qui stockent les données et les restituent sur instruction des anciens.
Les données sont stockées par les quatre adultes les plus proches (en termes XOR) de son nom.
Capacité de stockage
En prenant un peu de recul, chaque adulte est en fait l’ordinateur de quelqu’un. Il peut s’agir d’une VM cloud, d’un PC domestique ou d’un Raspberry Pi - ou même d’un smartphone à condition qu’il dispose de suffisamment de stockage. Mais combien de stockage est suffisant ? C’est un peu délicat car les besoins augmenteront probablement avec le temps.
Si un adulte manque d’espace, il cessera de répondre correctement et sera pénalisé (perdre l’âge du nœud). Si la machine est également utilisée pour d’autres choses, telles que le travail, la musique, le stockage de photos, etc., le fait d’être plein de morceaux sûrs les affecterait également, donc pour les deux raisons, il est important que son propriétaire reçoive un avertissement suffisant lorsque la capacité s’épuise - et que le réseau est également au courant.
Il y a quelques options ici. Tout d’abord, nous n’avons fixé aucune limite pour le stockage sécurisé, mesurant simplement l’espace restant sur le disque et avertissant lorsqu’il est presque plein. Cela a l’avantage de la simplicité, mais comme le stockage est un processus d’arrière-plan, la pleine capacité pourrait se glisser sur l’utilisateur et lui donner une mauvaise surprise.
Une autre option serait de demander à l’utilisateur de choisir une valeur fixe pour le volume de stockage, avec des quantités suggérées basées sur l’espace disponible au moment du démarrage du nœud, poussant les gens vers une quantité utile pour le réseau, peut-être en mettant en évidence une valeur moyenne.
Cela donne à l’utilisateur plus de contrôle, mais l’inconvénient est que nous, et encore moins eux, ne savons pas vraiment quelle est la valeur idéale et comment elle pourrait changer avec le temps.
Il peut être possible de créer une partition extensible dédiée uniquement pour les données du réseau sécurisé, mais cela peut être complexe à faire, compte tenu de la gamme de plates-formes et de systèmes d’exploitation.
Donc, celui-ci est toujours en discussion.
Vérification du comportement des adultes
Lorsque le client veut obtenir des données, il fait une demande aux anciens dans la section la plus proche du nom des données. Chaque aîné calcule ensuite quels quatre adultes devraient tenir le morceau. Il conserve un enregistrement de l’ID d’opération que les adultes doivent remplir. Lorsque les aînés ont reçu une réponse d’un adulte avec un bloc de données, il dissocie l’ID d’opération du nom de cet adulte car il a maintenant été rempli.
À ce stade, les anciens vérifieront s’il y a des adultes qui ne répondent pas. Un adulte ne répond pas s’il a des performances nettement inférieures à celles de ses voisins (la tolérance exacte sera déterminée expérimentalement). Les adultes qui ne répondent pas verront leur âge ganglionnaire réduit de moitié et pourront être déplacés.
Mise en cache des aînés
Depuis quelque temps, nous réfléchissons à la meilleure façon de déployer la mise en cache. Pour de nombreuses opérations, nous pensons que la mise en cache sur les nœuds anciens aidera à améliorer les performances et à gérer les données lorsque les nœuds se déconnectent, à la fois comme mesure de sécurité contre la perte de données et comme moyen d’accélérer la redistribution des blocs.
Dans ce schéma, les anciens stockeront toutes les données mises ou récupérées de la section dans un cache LRU (le moins récemment utilisé). La capacité du cache sera plafonnée, les anciens laissant tomber les données moins récemment utilisées si nécessaire.
Que se passe-t-il lorsque nous faisons la promotion d’un nœud ?
Lorsque nous promouvons un adulte au rang d’aîné, l’adulte publie d’abord ses données à d’autres adultes et les aînés enregistrent les morceaux dans leur cache LRU, supprimant au hasard ceux qui dépassent leur taille limite si nécessaire.
Que se passe-t-il au redémarrage ?
Lorsqu’un adulte redémarre ou déménage, il envoie ses morceaux aux trois anciens les plus proches du nom du morceau et ils stockent autant que possible dans leur cache. Les anciens conservent à leur tour chaque morceau à quatre adultes.
Les aînés peuvent déposer des données de leur cache, mais les adultes ne peuvent pas déposer de données. Les adultes signalent en permanence leur niveau aux aînés, et une fois qu’ils sont remplis à 90 %, plus aucune donnée ne leur est envoyée.
Stockage des données en tant que client
Lorsqu’un client stocke des données, il les envoie à trois anciens pour qu’ils les signent. Pourquoi trois ? Parce qu’il est garanti qu’il y aura un nœud honnête parmi eux, puisque nous supposons qu’il n’y a pas plus de deux anciens défectueux dans une section de sept. Avec un aîné honnête, tant que les données sont valides, le client obtiendra éventuellement une majorité qualifiée d’actions de signature (5) des anciens de la section honnête, ce qui signifie qu’elles peuvent être stockées. Dès qu’un nœud a renvoyé un accusé de réception avec une signature réseau, ce morceau peut être considéré comme stocké.
Obtenir des données en tant que client
Étant donné que les blocs sont signés et se valident automatiquement, dans le cas de données immuables, le client n’a besoin que d’un seul bloc. Peu importe qu’il soit signé par le réseau ou non, car il est immuable.
Les données mutables (CRDT) sont un peu plus complexes. Dans ce cas, le conteneur est signé par section, mais le contenu n’est signé que par le client (le propriétaire des données). De cette façon, les données sont auto-validantes et difficiles à corrompre, mais un nœud malveillant ou défectueux pourrait refuser de livrer le contenu ou donner au client un ancien contenu.
Ainsi, le client veut s’assurer qu’il obtient autant de données que possible, ce qui signifie qu’il doit demander au moins une superminorité d’anciens (trois) pour les données. Plus il a de copies, plus vite il peut fusionner ces copies pour recréer la dernière version des données.
Payer pour le stockage
Ce modèle s’intègre bien dans l’utilisation des DBC pour payer le stockage à l’avance. Lorsqu’un client demande que 100 morceaux soient stockés, les anciens reviennent chacun avec un prix pour signer les noms de ces morceaux.
Les citations des anciens devraient être les mêmes. Toute citation d’aîné très différente suggérerait un aîné défectueux, et le client pourrait signaler ce fait à la section afin qu’il puisse être traité.
Le client paie alors le montant indiqué avant de stocker ses données.
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é!