Proposition d'un système de stockage libre intégré à la blockchain pour toutes les données des utilisateurs

Les utilisateurs ont des données: nom, commentaire de transactions, profil, messages privées, annonces, commentaires d’annonces, etc

L’architecture actuelle stocke une partie en blockhain, une partie sur des pod Cs+, une autre encore sur des pod gchange, etc

Cette architecture a le mérite d’exister, et mon propos ici n’est pas de critiquer ceux qui ont consacré énormément de temps à la mettre en place, ils ont fait ce qu’il pouvait pour répondre aux besoins présents.

Outre les problèmes de synchronisation des pod Cs+ ou gchange entre eux, le fonctionnement actuel est basé sur la bonne volonté de certains d’héberger un pod qui va stocker les données de tout les utilisateurs. Ce qui fonctionne, car on a encore peu de données, mais si on veut que la Ğ1 puisse monter en charge, je pense que l’on doit repenser entièrement la manière de stocker les données des utilisateurs.

Dès qu’il y a beaucoup d’utilisateurs (disons plusieurs millions), le stockage sécurisé des données (donc avec suffisamment de backup pour éviter les pertes) deviens nécessairement coûteux.
Et donc seuls les gros acteurs ont les moyens de stocker les données, ce qui induit une centralisation de fait.

Depuis quelque temps je réfléchis à un système de stockage qui :

  • Sois générique: permette de stocker tout type de donnée pour tout usage.
  • Soit décentralisé: participer au stockage des données doit être accessible avec des moyens raisonnables, même avec une quantité astronomique de données.
  • Soit bien synchronisé: tous les acteurs doivent se mettre d’accord sur la version des données
  • Sois vérifiable: l’authenticité d’une donnée fournie par un serveur doit être rapidement vérifiable.
  • Sois résistant aux acteurs malveillants: il ne faut pas qu’un acteur propose d’héberger des données des utilisateurs mais ne les héberge en fait pas, où ne fournissent jamais les données quand on lui demande.

J’ai une proposition qui me semble satisfaire tous ces points, je n’ai pas tous les détails, mais j’ai déjà une idée relativement précise, voici le concept général:

Il s’agit d’un système de stockage clé/valeur.

Chaque acteur qui souhaite stocker une partie des données des utilisateurs doit s’inscrire en blockchain, un hash aléatoire lui est attribué, qui déterminera le milieu de la plage des hash de clés qu’il devra stocker.

Format de la clé

La clé doit être d’une longueur comprise entre 4 et 223 octets, et elle doit être préfixée par l’identifiant d’un protocole, l’identifiant du protocole peut être toute suite d’octet d’au moins 4 octets, y compris un nom encodé en ascii.

Ce n’est pas la clé en elle-même qui permettra de retrouver la valeur mais son hash. Avant de hasher la clé, il faut la préfixer avec la clé publique du propriétaire (en représentation binaire). Ce qui donne:

key_hash = blake2b-256( <protocol_id> || <protocol_key_data> || <owner_pubkey>)

Le format de protocol_key_data doit être défini séparément pour chaque protocole de donnée. Duniter-v2s n’interprète pas ces données, il se contente de les hasher et de les publier tel quel dans un évènement, la seule contrainte est que le nombre d’octets totaux occupés par <protocol_id> || <protocol_key_data> soit inférieur ou égal à 223.

Ajout/Modification/Supression d’une entrée (=paire clé/valeur)

Lorsqu’un utilisateur souhaite ajouter/modification/supprimer une entrée, il fournit à un data-pod (via une mutation GraphQL exposée par l’instance hasura associée) deux éléments:

  1. Les octets de la nouvelle valeur ou null si c’est une supression
  2. Une payload signée SCALE encodée qui contient dans l’ordre:
  • le hash du genesis
  • le data nonce
  • la clé (min 4 octets, max 223 octets)
  • le hash Sha256d de la valeur ou le hash zeroed si c’est une suppression (32 octets)
  • la taille de la valeur (en octet)

Le data-pod va alors vérifier si l’utilisateur a le droit de stocker cette donnée (s’il a des quotas suffisant ou de quoi payer des frais), et si tout va bien, il va ajouter cette “écriture d’entrée” dans sa pool.
Dès qu’il peut, le data-pod va soumettre à la blockchain un extrinsic duniterData.bloc() qui contiendra l’entièreté des payload signées dans sa pool, ainsi que la merkle proof contenant tout les hash intermédiaires permettant de calculer le merkle root actuel et le nouveau.

La blockchain va alors vérifier, pour chaque payload signée, l’utilisateur a le droit de stocker cette donnée (s’il a des quotas suffisant ou de quoi payer des frais), et si tout va bien, elle va émettre un évènement EntryUpserted ou EntryRemoved si la nouvelle valeur est None.

Tout les data-pod actifs suive la blockchain bloc après bloc, ils vont donc voir passer cet extrinsic et savoir quels sont les changements de donnée, et par qui ils ont été soumis, ils savent donc quels data-pod contacter pour récupérer les données qu’ils doivent stocker. Les endpoint de tout les data-pod actifs étant en blockchain, ainsi que leur «position» dans la plage des clés, chaque data-pod sait qui contacter quand, donc pas besoin de découverte par le réseau, on profite ici à fond du consensus glabal apporté par la blockchain.

Les indexeurs voient également passer tout les extrinsics et évènements, ils peuvent donc savoir selon le protocole id (qui est dans le préfixe de la clé) s’il s’agit d’une donnée qu’ils doivent indexer pour de la recherche (y compris recherche full text). Et s’ils doivent l’indexer, ils vont requeter les data-pod qui sont censés stocker cette donnée pour la récupérée et l’indexée.

Recherche d’une entrée

Un utilisateur souhaite par exemple faire une recherche full text dans les profils des utilisateurs.
Il va requeter une API hasura, qui va lui fournir les résultats de la recherche.

Si l’application de l’utilisateur souhaite s’assurer de l’authenticité des profils, il lui suffit de:

  1. Demander la merkle proof de chaque profil dans le résultat de la recherche (un champ graphQL optionel)
  2. Demander via l’API RPC (à son light node local ou à un full node considéré de confiance) le merkle root
  3. Vérifier chaque merkle proof
  4. Pour chaque profil dont la merkle proof est valide, l’utilisateur à la garantie que le profil est authentique, et qu’il s’agit bien de la dernière version du profil, il n’a pas besoin de truster l’instance hasura requetée. Si certain profil ont une merkle proof invalide (root hash qui ne correspond pas), afficher une alerte dans L’UX du style «Attention: l’authenticité de ce profil n’a pas pu être vérifiée !».

Obtention directe d’une entrée dont la clé est connue

C’est comme la recherche d’une entrée, sauf que la requete GraphQl sera un peu différente, et que Hasura n’ira pas chercher l’indexeur derrière mais uniquement le data-pod auquel elle est liée.
La valeur peut être vérifiée de la même façon.

Frais

Ici il y a 4 choses différentes qui ont un «coût», et chacune peut être gérée différemment si besoin.

1. le coût l’exécution des extrinsics

Ce coût n’a rien de spécifique au système proposé ici, ces extrinsics doivent être étalonnés comme les autres, c’est un problème plus global à toute la blockchain traitée dans un autre sujet: Comment partager équitablement cette ressource commune qu'est la blockchain Ğ1?

2. Le coût du storage onchain

Le onchain storage stockera:

  • le merkle root d’un arbre dont les feuilles sont les hashs des entrées (32 octets)
  • Pour chaque utilisateur: son data nonce (4octets), la taille totale de ses données(4 octets), et son dépôt total (8 octets).

L’idée est d’avoir un dépôt minimal par utilisateur pour qu’il paye les 64 octets nécessaires dans le storage on-chain (48 octets de préfixe + 16 octets de données).

3. Le coût du stockage par les full nodes inscrits

La blockchain sait exactement à tout bloc quelle quantité précise de donnée (en nombre d’octets) chaque acteur inscrit est censé stocker.
Il est donc possible de mettre en place un mécanisme de rémunération en fonction de la quantité de données stockées et de la durée de stockage.
Cette rémunération peut être financée par une trésorerie commune, ou par des frais payés directement par l’utilisateur, ou tout autre mécanisme de financement à imaginer.

4. Le coût du stockage par les indexeurs

Les indexeurs ne devrait stocker que les données nécessaires et suffisantes pour réaliser des recherches. Par exemple, les indexeur ne devrait pas stocker des avatars, mais seulement la clé, la valeur pouvant être demandées au data-pod.

Pour les indexeur il est également possible d’envisager un système d’inscription en blockchain, et donc une rémunération de ces derniers.

Refus de fournir une donnée

Si un data-pod refuse de fournir une donnée qu’il est censé fournir, il nous faut un mécanisme de rapport en blockchain, a minima pour stopper sa rémunération, et attribuer sa plage de hashs à d’autre.
Il y a juste à définir le seuil de déclenchement (en nombre ou proportion de membre certifiés), et la durée de vie d’un rapport (on ne va peut-être pas comptabiliser un rapport qui date de 3 ans).

Où peut également envisager un mécanisme de rapport (ou de vote), pour les indexeurs, mais il est plus délicat de montrer qu’un indexeur ne nous fournit pas les résultats qu’il est censé nous fournir, sauf à comparer avec un autre indexeur identique.

Pour ces questions de rapport ou de vote on a plus de temps pour y réfléchir et choisir les mécanismes, tant que les acteurs devant stocker les données sont inscrits en blockchain, ça permet de mettre en place plus tard des mécanismes de rémunération et de sanction.

Preuve de stockage d’une donnée

J’ai fait des recherches sur les preuves zk-SNARK, et j’ai expérimenté avec une implémentation en Rust.
Il est possible de demander au data-pod inscrits de publier régulièrement une preuve en blockchain qu’il stocke bien tel ou tel entrée (choisi aléatoirement pas la blockchain).
Ça forcerait les data-pod à bien stocker ce qu’ils sont censé stocker, mais ça ne les force pas à fournir ces données aux utilisateurs, donc il faut quand même un système de rapport ou de vote pour les full nodes inscrits.
Bref, juste pour signaler que c’est un mécanisme possible si on en a besoin un jour, mais on en aura peut-être jamais besoin.

Liste potentielle de protocoles

  • username
  • profile
  • avatar
  • private_message
  • advert
  • advert_comment

Autant qu’on veut en fait.

Exemple pour un message privé

Le protocole private_message peut spécifier:

Format de clé: twox128("private_message") || blake2-128(receiver_pubkey) || timestamp || issuer_pubkey.

Ainsi, lorsque l’application finale de l’utilisateur veut récupérer ces nouveaux messages reçus, elle peut le faire via un indexeur, qui aura pu indexer les messages graçe aux metadata darns la clé publiée en blockchain.

Exemple pour un profil une annonce de vente d’un bien ou service

Le protocole advert peut spécifier:

Format de clé: twox128("advert") || blake2-128(issuer_pubkey) || twox64(category) || timestamp).

Je fais une recherche full text auprès d’une instance hasura, qui me retourne alors un highlight pour chaque annonce qui match ma recherche.
Si j’ai demandé également le champ merkle_proof, je peux vérifier en tache de fond chaque preuve.
En termes d’UX ça permet d’afficher quand même tous les résultats de suite, mais avec une icône indiquant que l’annonce est en cours de vérification.

Si l’utilisateur clique sur l’une des annonces pour en voir le détail, alors là je peux recalculer le hash de l’annonce et vérifier définitivement son authenticité. Ce qui permet d’ajouter une icône check vert.
Si jamais l’authenticité de l’annonce n’est pas vérifiée, il faut afficher un warning à l’utilisateur du genre “Erreur lors de la vérification de l’annonce , le serveur distant est désynchronisé ou malveillant”.

À noter que le champ merkle_proof, peut valoir null, ce sera le cas lorsqu’une modification récente n’a pas encore pu être enregistrée définitivement en blockchain. L’application pourra préciser dans sa recherche si elle veut uniquement les données définitivement validées, ou si elle veut les données les plus récentes (avec l’inconvénient de ne pas pouvoir les vérifier).

Conclusion

Il s’agit d’un système de stockage ambitieux mais dont l’effort de développement me semble valoir le coût, car il permet de potentiellement tout vérifier (mais ce n’est pas obligatoire), et de traiter avec le même code tout type de donnée.

6 Likes

Cette semaine j’ai principalement avancé sur la conception et une 1ère implémentation de ce système de stockage libre.

J’aimerais avancer au moins jusqu’à avoir de quoi permettre l’indexation dans duniter-squid, pour vous faire une demo de ce que ça pourrait donner très concrètement, possiblement dans quelques semaines si tout va bien :slight_smile:

2 Likes

@elois où en est ce stockage libre ? Sera-il dispo au lancement de la gdev ?
Je suppose que non bien sûr, j’imagine le boulo que c’est, mais peux-tu nous dire si c’est toujours d’actualité ?

@kimamila Es-tu sûr de vouloir continuer sur les pod Cs+ pour v2s ?
Tu évoquais l’année dernière l’envie de sortir de ces pods pour se diriger vers ce genre de solution, non ?

1 Like

Je reste convaincu qu’il nous faut un système de stockage réellement décentralisé, qui se base d’une manière ou d’une autre sur le consensus de notre blockchain car ça me semble idiot d’essayer de créer un autre consensus parallèle qui sera forcément moins bon que ce que propose substrate.

Mais je n’ai pas avancé dessus depuis février car c’est énormément de boulot et j’ai perdu la motivation car je ne me sens pas suffisamment soutenu dans cette voie :confused:

Je pense clairement qu’il faut supprimer les pod Cs+ et discuter ensemble pour concevoir quelque chose qui se base sur le consensus de notre blockchain pour ne pas recréer sa propre (mauvaise) couche de synchronisation.
J’espère que trouvera le temps d’aborder le sujet aux RML, sinon il faudra faire une visio la dessus voir une autre rencontre IRL

2 Likes

Peut importe en fait, l’avenir des Pod CS+ : il y a toujours des gens qui voudront traiter a leur manière les donnes de la blockchain, en temps réel ou non, et il est inutile de vouloir les en empêcher.

Si quelqu’un veut travailler sur un outil quelconque, la communauté a intérêt à le laisser faire librement. Par exemple récemment une demande a été faite pour avoir les données de la WoT pour détecter les attaques Sybilles. Qui peut dire si demain cette analyse ne pourra pas être automatiser. Peut importe qu’il soit écrit en python ou autre. On commence avec un PoC et on fini parfois loin…

Chacun utilisera bien les technos qu’il peut et qu’il veut, en fonction de ses compétences et son temps dispo.

Je ne vais pas réécrire Gchange tout de suite, de toute manière, et il utilise les pod césium+.
Idem pour les graphiques, etc.

Plus j’y penses et plus je me dis qu’il faut de toute manière une API pour se connecter à la BC, en requetage ou en temps réel.
Ensuite, les gens feront ce que leur dicte leur conscience, sans attendre d’autorisation de personne. Et les gens feront ce qu’il on a faire avec.

1 Like

Du coup dans l’API fournit par substrate, savez vous s’il est possible :

  • d’ouvrir une websocket pour récupérer les évènements ?
  • de synchroniser un historique ? (TX, etc.)

Qui a parlé d’empêcher quoi que ce soit ? Pour qu’on puisse échanger sereinement j’ai besoin que tu arrêtes de me prêter des intentions que je n’ai pas :pensive:

Je ne suis pas d’accord, tu ne peux pas dire au nom de la communauté ce qui est dans son intérêt ou non.
Aussi j’estime que quand on développe un outil dont on sait lors du développement qu’il va impacter l’expérience de la plupart des utilisateurs, alors on a le devoir moral de se demander comment faire au mieux pour les utilisateurs, et de prendre en compte les retours de la communauté.

Personne ne peut t’empêcher de développer comme tu l’entends, mais nous avons le droit de ne pas être d’accord et de trouver que tu n’écoutes pas suffisamment les autres.

Ce que je te reproche justement c’est ce côté “chacun développe ce qu’il veut dans son coin”, j’en ai marre de ce manque de concertation et de cohésion, et c’est justement l’une des raisons de mes absences répétées ces derniers temps.

Avec le passage à duniter v2 et tout ce que ça implique, c’est le moment ou jamais de tout mettre à plat et de discuter ensemble de la nouvelle architecture technique.

Bien sûr qu’il faut itérer, faire une PoC puis rediscuter ensemble pour intégrer les retours, puis recommencer, mais j’aimerais qu’on fasse ça ensemble, et pas chacun dans son coin.
Pour ça encore faut-il réellement écouter, et faire confiance à ceux qui ont une meilleure expertise que nous sur leur spécialité.

Je vois malheureusement à tes messages que tu réponds à côté à quasiment tout, donc soi tu n’écoutes pas, soit je m’exprime vraiment mal (mais dans ce cas personne ne comprendrait), soit tu à des difficultés en conception, il serait alors temps de le reconnaître et d’écouter davantage ceux qui conçoivent mieux.

Un exemple où tu es à côté: dans ton message tu parles beaucoup de tout ce qui touche à l’indexation des données issues de la blockchain, ce qui est un sujet crucial mais qui est tout autre chose que le sujet que j’ai abordé dans ce fils.

Dans ce fils je parle d’une solution pour les données hors-blockchain (par exemple: profils, annonces, messages privés, et tout autre donnée possible et imaginable).

Encore une fois tu es à côté, j’en ai rien à faire de quel langage ou quelle techno, ce qui m’importe c’est l’architecture, et ce que ça implique en termes de fonctionnalités, de garanties, de sécurité, de centralisation ou décentralisation, etc

Oui, j’en parlerai aux RML

Non

1 Like

Benoît, je comprends ton point de vue, je ne souhaite pas appuyer une solution plutôt qu’une autre.

Cependant, j’aimerai insister sur un point: Il faut que tous les clients utilisent les mêmes sources de donnés, je ne vais pas stocker mes données dans des pod Gecko+ et ainsi recréer des silos de données en plus de Cs+, Tikka+ et un éventuel stockage libre côté Duniter.

Si tu pars sur des pod cs+ pour v2s, je n’aurais pas le choix d’en faire de même dans Gecko pour garder une cohérence de donnée pour les utilisateurs qui navigueront probablement entre Cesium, Tikka, Gecko et d’autres clients.

Enfin, c’est vrai que n’avoir q’un seul type d’endpoint et un seul réseau a gérer côté client, et surtout une seule api RPC ou gql pour les données blockchain et les metadata, ça simplifie pas mal et ça augmente la stabilité (2x moins de risque qu’un ou l’autre des endpoint soit HS ou désynchro).

Mais ça se discute.

2 Likes

Il ne s’agit pas d’opposer deux solutions, mais de définir ensemble le design technique (l’architecture) qu’on veut pour stocker les données des utilisateurs, en partant des besoins.

Pour moi les besoins sont:

  1. La décentralisation réelle.
  2. La simplicité pour l’utilisateur final (qu’il n’est pas à choisir une instance, et qu’il puisse retrouver les mêmes données partout).
  3. La possibilité de nommer des modérateurs.
  4. L’assurance qu’un contenu ne peut être modifié/supprimé que par son propriétaire ou par un modérateur autorisé.
  5. La vérifiabilité d’un contenu, pourvoir vérifier localement que se contenu est légitime et authentique.
  6. Pouvoir gérer tout type de donnée, ne pas se restreindre à un cas d’usage métier bien limité.

Le besoin 1. implique un protocole de synchronisation qui fonctionne réellement bien, ce qui n’est pas le cas des pod Cs+/gchange. Et c’est bien normal, la couche réseau p2p c’est de loin la partie la plus difficile, c’est pour ça que je suis convaincu qu’on ne doit pas la développer nous-même, mais se baser sur une solution existante où faire en sorte de ne pas avoir besoin de couche réseau p2p.

Le besoin 2. implique un mécanisme de consensus global, ce qui est exactement ce que nous apporte la blockchain Ğ1, c’est pourquoi je pense qu’on doit se baser dessus.

Pour le besoin 3., si on se base sur la blockchain Ğ1v2, alors on peut facilement définir des modérateurs via des mécanismes de gouvernances on-chain, intégrable très facilement grâces aux pallets substrate et notamment à la pallet collective.

Pour le besoin 4., ça implique qu’un pod hébergeant des données ne doit pas pouvoir en supprimer et propager cette suppression aux autres, ce qui implique que toute suppression de donnée doit être validée par la blockchain elle-même, pareil pour les éditions de données.

Le besoin 5., c’est le seul pour lequel je peux accepter qu’il ne soit pas couvert, du moins à moyen terme. J’aimerais au moins qu’il soit pris en compte dans le design technique de manière à ce qu’on est l’assurance de pouvoir implémenter de quoi y répondre à l’avenir.

Pour le besoin 6., c’est pour réduire la maintenance et le nombre d’API, ainsi que faciliter de développement de nouveaux services tiers décentralisés (Ğ1bnb, Ğ1covoiturage ,etc).

Je précise que tout ça n’a d’intérêt que pour des services décentralisés, si vous voulez créer un service centralisé ça ne sert à rien.

Si vous êtes d’accord avec moi sur les besoins, alors on peut discuter du design :slight_smile:

2 Likes

Ok tu ma achevé sur tes besoins :laughing:

C’est parfait pour moi.
Mais c’est toi qui voit si ça demande 6 mois de taf ou pas, je ne m’en rends absolument pas compte, et je ne pourrais pas t’aider perso la dessus.


Si je comprends bien, par defaut les noeuds ne stock pas d’historique de la blockchain, donc doivent consommer peu de stockage ?
Si on peut activer/désactiver facilement le stockage meta sur les noeuds Duniter, ça me semble super.


De plus, à priori tous les clients vont devoir intégrarir également avec un indexer type subsuid, ce qui fait encore d’autres noeud/réseau/api.
On peut aussi penser aux noeud wotwizard si on a besoin de données poussé de la wot, pour détecter les sibyles par exemple, informé sur son status ect …

Ca fait déjà 3 réseaux de noeuds à maintenir, et gérer leurs API, sans compter les Cs+ et Gchange…

Dans le meilleur des mondes, on aurait qu’un seul type de noeud et donc de réseaux pour tout ça, sauf Gchange.
Sur du long terme même pour gchange ça serait pertinent.

J’aimerais d’abord qu’on en discute ensemble à l’oral, et voir qui peut m’aider là-dessus. Peut-être qu’on peut trouver un design avec plusieurs étapes, et développer rapidement une 1ère étape qui ne couvre pas tous les besoins, mais qui est conçue de manière à pouvoir intégrer les évolutions prévues.

Si je suis tout seul je ne suis pas sûr de le faire, car avec mon boulot à plein temps je ne peux pas consacrer suffisamment de temps à la Ğ1 pour être sur plusieurs fronts en même temps, c’est très frustrant, je ne peux pas développer ne serait-ce que 5% de tout ce que j’aimerais faire :confused:

Où alors il faut que je délègue d’autres parties qui sont plus facilement délégeables, comme la partie indexation/squid, que je vais peut-être déléguer entièrement à @ManUtopiK et @gerard94 :slight_smile:

Attention, dans les besoins listés, rien n’implique de stocker les données au niveau des nœuds duniter-v2s, les données peuvent très bien être stockées par un autre programme à développer.

Dans les 2 cas c’est beaucoup de boulot en développement.

Mais si on choisissait de stocker les données au niveau du programme duniter-v2s lui-même, ce serait évidemment optionnel :slight_smile:

Pour répondre à la question, ça dépend ce que tu entends par “historique”. Les nœuds duniter-v2s stocke uniquement le storage on-chain, mais il y a un storage par block, et par défaut le storage de chacun des 256 derniers blocs finalisés est gardé.
Il y a déjà un mode archive (désactivé par défaut) qui permet de garder les storages de tout les blocs.

3 Likes

Je viens de mettre à jour mon 1er post, car mes réflexions sur ce système ont bien avancé depuis février. Les principaux changements sont :

  1. Tout ce qui peut être fait hors-blockchain sera géré par un logiciel dédié que j’ai nommé data-pod dans le 1er post. Outre que ça permet le découpage en micro-service, ça évite également le besoin d’API RPC spécifique aux fulls nodes, ce qui permet de garder la même API RPC que pour les light nodes, ce qui est essentiel pour que les light nodes puissent être utilisés par les wallets sans besoin de dev spécifique.
  2. L’api qui permettra d’interagir avec les data-pod sera fusionnée avec l’api qui permettra d’interagir avec les indexers, via un serveur hasura au milieu, de sorte que les wallets/apps/websites n’aient que deux api à gérer au total (au lieu de quatre).
  3. L’utilisateur ne déclarera plus lui-même ces changements de données en blockchain, mais enverra une payload signée au data-pod, et c’est le data-pod qui déclarera les changements en blockchain. Le but est double : d’une part simplifier le dev côté wallets/apps/websites (plus qu’une seule requête à faire pour changer une donnée), d’autre part réduire la taille de la merkle proof à fournir à la blockchain en groupant les modifications (chaque data-pod va publier d’un coup tous ses pending changes quand c’est son tour).
1 Like

C’est bien de se poser la question du stockage des données. Autant profiter de la migration pour y penser !

Il faut bien définir les besoins pour penser l’architecture. Je pense que nos données ont des propriétés différentes. Entre une photo de profile, ou un l’événement d’un ğmarché, la nature des données n’est pas la même, avec un stockage différent.
Est-ce qu’on a besoin de stocker une donnée tempo-géolocalisée comme un ğmarché dans la blockchain ? Dans 10 ans, on s’en foutra de savoir qu’il y a eu un ğmarché à trifouilli-les-bains le 10 aôut…
Par contre, utiliser la blockchain pour des données qui ne muteront jamais, ou d’autres qui pourraient être contrôlées par un système d’ACL lié à la toile de confiance, ça c’est intéressant !

@elois, qu’est-ce que tu entends par « décentralisation réelle » ? ipfs est dedans ?
Est-ce qu’une photo de profile doit être en blockchain par exemple, ou plutôt sur ipfs ?

« La possibilité de nommer des modérateurs », ça veut dire définir des rôles, pour modérer quoi ?
« L’assurance qu’un contenu ne peut être modifié/supprimé que par son propriétaire ou par un modérateur autorisé. »
Ça ressemble sérieusement à un système de contrôle tout ça ? Quel type ? Access Control Acronyms: ACL, RBAC, ABAC, PBAC, RAdAC, and a Dash of CBAC - DZone Security
Est-ce que ce n’est pas le genre de données qui devraient être stockées dans une bdd orientée graph ?

Pour l’instant j’ai plus de question que d’idées… Prenons le temps de bien clarifier les besoins !

@ManUtopiK les données ne serait pas elle-même en blockchain, seul le merkle root serait en blockchain.
Ma proposition ne concerne pas un système de stockage immutable, au contraire. L’idée n’est pas de stocker quoi que ce soit en blockchain, mais d’utiliser la blockchain pour définir un consensus global sur l’état des données, afin de permettre un stockage réellement décentralisé tout en gardant une bonne synchronisation :slight_smile:

Plusieurs critères doivent être vérifiés pour que la décentralisation soit réelle:

  1. Pas de perte (ni d’indisponibilité) de données si un pod du réseau tombe. ça implique de pouvoir retrouver exactement les mêmes données ailleurs, ce qui implique une très bonne synchronisation (ce qui n’est pas le cas des pod Cs+/Gchange).
  2. Pourvoir vérifier l’authenticité des données sans avoir à truster le pod qui nous fourni la donnée (ce qui n’est pas le cas des pod Cs+/Gchange).

Non. On à pas besoin d’IPFS, qui apporte principalement une couche réseau p2p qu’on à déjà avec substrate, l’idée est plutôt de se baser sur ce que substrate nous apporte pour minimiser la maintenance et pas avoir plusieurs consensus différents.

Ni l’un ni l’autre. Les données seraient stockées sur tout les pod dans un 1er temps, puis à moyen-terme seulement sur certains pod selon que la clé associée est dans leur plage de hash.

Pour beaucoup de types de données, il faut ure modération, comme pour les annonces par exemple:

Ma proposition est de définir des modérateurs via une gouvernance on-chain, d’autant que substrate apporte les outils pour faire ça simplement :slight_smile:

2 Likes

Ok. Merci pour les clarifications !

1 Like

Pour rappel tous les documents d’un Pod Césium/Gchange sont actuellement signés par leur émetteur. Il n’y a donc pas a “truster” le pod. Les clients peuvent eux même vérifier la signature s’il le souhaite.

La synchro fonctionne très bien, sans perte de données (Je ne sais pas où tu as vu cela). Mais évidemment, comme il n’y a pas de BC, l’ensemble de données d’un Pod a l’autre peut varier, du fait des règles des modérations. mais n’est pas souhaitable justement ?

Si la modération est centralisée, alors on retrouve un système centralisé…

2 Likes

La signature ne garantit pas l’authenticité de la donnée à l’instant t.
Ça garanti uniquement que l’auteur a bien publié telle version de la donnée par le passé.
Rien ne dit qu’elle est à jour, cette donnée a pu être modifiée ou supprimée depuis.
Il faut truster le pod Cs+/Gchange sur le fait qu’i s’agit bien de la dernière version de la donnée.

Avec ce que je propose, et grâce aux merkle proof, on pourra vérifier que la donnée qu’on récupère est bien la dernière version la plus à jour (à 1 ou 2 min prêt).
Quand tu tombes sur un profil ou une annonce qui n’a pas été mis à jours depuis plusieurs jours/semaines/mois, ça me semble utiles de pouvoir vérifier s’il n’y a pas eu de changement d’ici la, si ça se trouve le serveur est désynchro ou ment sciament en fournissant des données obsolètes, la signatuer de l’auteur er sera tout autant valide…

Lol, tu ne lis pas suffisamment le forum ML. Dès qu’oèun pod Cs+ tombe, passer sur un autre ne fait pas voir les mêmes données, il y a donc bien indisponibilité d’une partie des données temporairement.

C’est exactement ce que je propose de corriger, car pour moi cet aspect est un frein à l’adoption grand public.

Pas pour moi, je suis convaincu que le modèle fédératif, avec chaque pod ces propres règles, est voué à l’échec, en tout cas en permet pas l’adoption de masse, car dans la pratique tout le monde va choisir la même instance, et au final c’est centralisé dans la pratique.

Je pense que l’avenir est dans les système décentralisés à consensus global, qui ne demandent pas à l’utilisateur de choisir une instance, et qui garantisse d’avoir la même version des données partout.

Ça implique une modération collective on-chain, et personnellement je préfère, ça garanti un meilleur compromis prenant en compte davantage de diversité d’opinion, et limitant donc les abus.

Ça permet également de regrouper les efforts, plutôt que de modérer chacun son pod, et de mal le modérer parce qu’on a pas le temps…

Je ne parle pas de modération centralisée mais de modération on-chain, est ce tu dirai que la toile de confiance est centralisée sous prétexte qu’il n’y a qu’une seule vérité sur qui est membre ou pas à l’instant t ? Bien sûr que non.

Tu confonds ici centralisation et consensus global :wink:

2 Likes

Oui, ok, de ce point de vue je suis d’accord.

Oui, je n’y vais pas souvent ces derniers temps.

Je penses que tu confonds avec les problèmes d’anti-spam qui se déclenchait trop vite, ou la synchro entre le Pod et la BC, car le noeud Duniter était tombé (ex: “Pourquoi mes DU ne s’affichent plus”).
Mais des pertes de données (type: profiles, annonces, message etc.), je ne vois pas.
En même temps les Pod de @brepsles ne me semble pas à jour… De mon côté je n’ai plus de pb de synchro depuis longtemps.

J’ai bien compris que ce que tu proposes en mieux de ton point de vue : système décentralisés à consensus global VS système fédéré.

Cependant, il faut avoir conscience des points faibles de chaque solution.
Avoir une modération commune, on-chain, implique de se mettre d’accord sur des règles communes.
Ce sont ces règles qui seront centralisée, et donc non libre par définition (puisque non relatives à l’individu ou un groupe d’individu).

Il est donc faux de l’appeler système de “stockage libre”.

Un groupe d’individus motivés pour fonctionner avec d’autres règles de modération ne pourra pas utiliser ce système.

On quitte clairement le “plus petit dénominateur commun” sur laquelle devrait rester la monnaie libre G1.
Je ne suis vraiment pas favorable à cela. Je penses qu’on s’égare gravement.

Après réflexion, je suis d’avis de déconnecté la problématique des annuaires, profils, et autres données du consensus de la monnaie libre G1, et Duniter v2s, sous peine de créer une usine à gaz.
Concrètement, la débat sur les annonces type “armes à feu”, peut se porter sur des sujets plus sensible à arbitrer : charlatanisme, new age, etc. Et on ne sera clairement jamais d’accord ensemble sur ces sujets. Ça me parait assez évident.
Un système de modération impartial, ca n’existe juste pas. Où il n’y a aucune modération, ou alors pas de contenu du tout (juste des transferts, dans le cas d’une monnaie).

2 Likes

Comment peut tu affirmer ne pas avoir de problème de synchro s’il n’y a qu’une seul instance synchro :thinking:

Oui c’est le but, pour moi c’est un avantage, pas un inconvénient :slight_smile:

Je ne suis pas d’accord avec le terme “centralisé” ici, ça reviendrait à dire que l’ensemble des règles du protocole sont centralisés, elles sont communes, pas centralisées…

Devoir se mettre d’accord sur des règles communes, et donc trouver des compromis, c’est la meilleure garantie contre les abus.
Au fond je trouve que le système “chaque instance doit être libre de fixer ces règles”, c’est un peu comme le système libéral, “chaque entreprise doit être libre des choix quel qu’en soit les conséquences”.

Je ne suis pas d’accord avec cette vision, qui pour moi conduit toujours à l’oppression des plus faibles, et qui par effet ed réseau permet au plus fort d’imposer ces règles à tous, c’est ce que nous ont prouvé des GAFAM.

On peut changer le nom, à l’époque je l’avais nommé comme ça car 'est un système ou le type de donnée est libre, mais je suis d’accord qu’en autre terme conviendrais mieux, comme “générique” par exemple.

Je vais réfléchir à un autre nom, peut être stockage “prouvable”, puisse que l’un de fondements est de pouvoir prouver l’état des données à tout instant t.

On peut écrire de là même façon « Un groupe d’individus motivés pour fonctionner avec d’autres règles que celle de la Ğ1 ne pourra pas utiliser la Ğ1. ».

Ils devront faire une autre monnaie. Faire société c’est se mettre d’accord sur des règles communes, notre liberté s’arrête là ou commence celle des autres.

La modération devrait se limiter aux contenus illégaux et consensuellement graves (menaces de morts, discours haineux, etc).

Il y a plein de compromis possibles, comme un système de réputation des annonces, les annonces qui semblent proposer des services discutables pourrait être mal notée avec un warning dans l’UX, maies pas supprimées :slight_smile:

On est bien d’accord, je ne cherche pas un système de modération impartial ni juste, je cherche un système de modération démocratique, qui soit le fruit de la volonté collective, et pas juste de la volonté des mainteneurs du pod le plus utilisé.
Or par effet de réseau il finit toujours pas y avoir 1 ou 2 pod utilisés par 99% des utilisateurs, ce qui donne un pouvoir démesuré aux propriétaires/mainteneurs de ces pod (et une pression démesurée aussi).

1 Like

Cela étant, ce qui m’importe le plus dans ma proposition c’est le côté trustless (graçe aux preuves de merkle), et le côté consensus global sur l’état des données.

Il est probablement possible de faire en sorte de garder ces propriétés tout en autorisant une modération différente selon un « groupe » auquel on choisirai d’appartenir.

Je vais creuser cette voie, car même si je préfère une modération commune, c’est plus une conséquence technique et pas une volonté fondatrice de ma proposition.

Les volontés fondatrices c’est :

  • Totalement trustess donc 100% vérifiable sans truster aucun serveur
  • Un consensus global sur l’état des données
  • La scalabilité, donc DHT à terme
  • Un système de frais/quotas et de rémunération des hébergeurs de données, pour pérenniser la faisabilité à plus grande échelle.