Actualités du développement Safe 🇫🇷 9 juin 2022

Ceci est une traduction automatique. L’original en anglais est ici: Update 09 June, 2022

Nous avions prévu d’approfondir les questions de gouvernance dont nous avons discuté la semaine dernière, mais nous n’avons malheureusement pas pu le faire en raison de quelques membres clés de l’équipe qui ont dû prendre des congés imprévus. Tout va bien, nous y reviendrons la semaine prochaine.

En attendant, veuillez lire le post de @jimcollinson sur nos objectifs stratégiques, et sachez que nos objectifs et notre vision n’ont pas changé d’un iota . Et n’oubliez pas de garder les discussions, aussi passionnées et passionnées soient-elles, toujours respectueuses. Nous avons un code de conduite du forum que tous les membres doivent respecter.

Cette semaine, nous examinerons les données sur le réseau et ce que cela signifie pour les fichiers d’être publics ou privés.

Progrès général

Yogesh a examiné les bases de données pour remplacer sled db, qui est bogué et ne semble pas être activement maintenu. Jusqu’à présent, les principaux candidats semblent être Persy, une base de données transactionnelle qui optimise la cohérence, et Cacache qui selon @yogesh « semble offrir la meilleure vitesse hors du lot avec la création et la gestion de métadonnées intégrées ». Ni l’un ni l’autre ne sont parfaits, mais les deux feraient probablement l’affaire. Les tests se poursuivent.

Merci à @josh d’avoir organisé le comnet DBC la semaine dernière. Comme @Chriso l’a mentionné, le dépôt de DBC possédés ne fonctionne pas encore, mais c’est ce sur quoi il a travaillé cette semaine, et @Qi_ma étudie un bogue de réédition DBC et travaille également sur l’intégration des livres dépensés.

Pendant ce temps, @davidrusu continue de travailler sur la transmission des informations d’adhésion aux adultes afin de s’assurer que les connaissances sur l’adhésion et le réseau (via le fournisseur d’autorité de section signé) sont synchronisées dans toute la section.

Données publiques et privées sur le Safe Network

Qu’est-ce qu’un fichier sur Safe Network ? Question assez simple mais la réponse est un peu plus compliquée. La réponse de base est « contenu + métadonnées + datamap » - mais qu’est-ce que cela signifie ?

Contenu

Le contenu est la matière première du fichier, l’information binaire de base. Une fois que cela atteint plus de 1 Mo, il est automatiquement crypté pour produire des morceaux et une carte de données. En raison du fonctionnement de l’auto-cryptage, c’est déterministe, c’est-à-dire qu’auto-cryptez le même contenu un certain nombre de fois et vous obtiendrez les mêmes morceaux. Sa sécurité est largement indépendante de l’algorithme de chiffrement (nous utilisons AES256), ce qui signifie que si l’algorithme est fissuré, les morceaux sont toujours sécurisés.

OK alors qu’est-ce qu’un morceau? À moins que vous n’ayez le datamap, un morceau est un blob de bits sans signification, généralement d’une taille d’environ 1 Mo avec un nom qui est également son hachage. Cela signifie que nous pouvons vérifier s’il est valide - le nom correspond-il au hachage - mais nous ne pouvons rien dire d’autre à ce sujet. Nous pouvons le voir mais nous ne pouvons pas le lire, ni savoir d’où il vient.

Carte de données

Bon, alors qu’est-ce qu’un datamap? Le datamap est un simple fichier qui contient le nom non chiffré du contenu et les noms de tous les morceaux chiffrés qui le composent, on sait donc où les trouver (nom du morceau == adresse Xor). S’il est stocké non crypté sur le réseau, n’importe qui peut l’utiliser pour recréer le contenu. S’il est crypté ou stocké sur notre client privé, nous seuls pouvons le faire. Nous reviendrons sur le chiffrement du datamap dans une seconde.

Métadonnées

Et la dernière chose que nous devons mentionner, ce sont les métadonnées, les informations sur le contenu. Cela inclut éventuellement sa taille, son nom, le type de fichier et potentiellement la date de création, d’accès, etc. Mais attendez une seconde, Safe ne fait pas le temps ! C’est vrai, mais cela ne doit pas être une limitation.

La raison pour laquelle nous n’incluons pas de métadonnées avec le contenu est que cela ruinerait la déduplication. Disons que quelqu’un a téléchargé la chanson GodSaveTheQueen.mp3 des Sex Pistols, et que quelqu’un d’autre a téléchargé exactement le même MP3 mais l’a appelé GSTQ.mp3. Si le nom faisait partie du contenu, les morceaux seraient complètement différents, il n’y aurait donc pas de déduplication. Cela signifie que nous stockons les métadonnées séparément des morceaux. Nous pouvons le stocker dans une carte de données sur le réseau ou sur notre client, ce qui nous permet d’organiser ces blobs apparemment sans signification à notre guise, de les nommer et de les étiqueter comme nous le souhaitons - y compris le temps créé et le temps d’accès - et de les organiser dans notre propre structures de répertoires.

Les répertoires peuvent également être du contenu, cryptés, fragmentés et stockés sous forme de fichiers avec leur propre carte de données (c’est pourquoi les petits fichiers qui ne passent pas par l’auto-cryptage sont illisibles - tout le contenu est stocké dans un répertoire, mais c’est un pour un autre jour ).

Données publiques et privées

La façon dont fonctionne Safe est que les données valides doivent être stockées. Cela signifie que nous ne pouvons pas supprimer de morceaux. Mais rappelez-vous que les fichiers sont du contenu plus un datamap.

Le contenu n’est que des blobs sans signification sans datamap, et ces blobs sont aussi sécurisés et inconnaissables que possible avec la technologie actuelle. Pour rendre GodSaveTheQueen.mp3 accessible au public, nous le téléchargeons, publions sa carte de données sur le réseau non cryptée et lions-y. Il y a de fortes chances qu’avec une chanson bien connue comme celle-ci, les morceaux soient déjà là, mais le téléchargeur d’origine,qui l’a nommé GSTQ.mp3 a choisi de crypter le datamap ou de le garder sur son client et donc privé.

Voilà donc la différence fondamentale entre les données publiques et privées.

Si nous chiffrons la carte de données avec une clé BLS, cela nous permet également de créer des partages de clés que nous pouvons ensuite envoyer à d’autres personnes, ce qui signifie que nous avons partagé des données privées. BLS nous offre cette magie gratuitement. Cela signifie que les données publiques/privées et partagées sont toutes des actions côté client. Le réseau stocke les données pour toujours et les clients utilisent la carte de données (racine) et le cryptage pour rendre les données publiques, privées ou privées partagées.


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