Organisations illimitées sur Hyperledger Fabric

Question

Vue d'ensemble

Mon architecture de blockchain exige que chaque utilisateur individuel garde ses données privées. Il peut y avoir un nombre illimité d'utilisateurs (disons des millions). Selon la documentation de Hyperledger Fabric

Une organisation peut être aussi grande qu'une multinationale ou aussi petite qu'un individu

Voici une architecture qui me vient à l'esprit:

1. Ma société aura l'Organisation A sur le réseau commercial
2. Chaque fois qu'un utilisateur s'inscrit, je créerai une nouvelle Organisation N et un nouveau Canal C sur le réseau commercial.
3. Chaque nouveau canal aura deux membres: l'Organisation A et la nouvelle organisation ajoutée de l'utilisateur N

Je n'ai pas volontairement choisi les Données Privées car le tutoriel Ajouter une Org au canal suggère que si N organisations existent dans un canal particulier, alors N-1 organisations doivent signer la transaction pour permettre à la nouvelle organisation d'entrer. Comme il n'y a aucun partage de données entre chaque organisation utilisateur, je crée des canaux illimités (un canal pour chaque organisation utilisateur).

Questions :

1. J'essaie d'éviter la complexité linéaire qui se produira lorsque j'essaierai d'ajouter une nouvelle Org à un canal existant. Est-ce que mon architecture résout efficacement l'augmentation linéaire de la complexité?
2. Rencontre-je un autre problème avec cette conception?
3. Quelque chose d'antinomique concernant ma conception?

Answer 1

Il n'y a pas de problème réel du point de vue technique à avoir un grand nombre de canaux bilatéraux. Le processus pour ajouter une nouvelle organisation signifierait que vous devez créer le nouveau canal, joindre le pair utilisateur au canal, joindre l'Org A au canal, puis instancier tout code de chaîne sur ce canal. Assez facile à automatiser. À un moment donné, vous devrez peut-être créer plusieurs pairs pour l'Org A et répartir les canaux entre ces pairs.

D'un autre côté, vous pourriez envisager d'utiliser des données privées combinées avec une validation basée sur l'état. Au lieu de créer un canal entre l'Org A et chaque utilisateur, vous pourriez créer une collection Org A / Org N à la place, puis utiliser la validation basée sur l'état pour ne nécessiter la validation que de l'Org A et de l'Org N. L'inconvénient ici est qu'Org N+1 ... Org N + X finirait par obtenir des hachages de toutes les clés/valeurs pour tous les utilisateurs ... ce que vous pourriez ne pas vouloir (surtout puisque cela oblige les utilisateurs à stocker des données qui ne les concernent pas).

Answer 2

Je pense que c'est assez évident qu'il n'est pas une bonne idée de créer une organisation par utilisateur lorsque vous avez des millions d'utilisateurs. Dans Hyperledger, une organisation aurait ses propres pairs et cela n'a pas de sens au niveau de l'utilisateur. De plus, gérer un réseau pratiquement illimité avec un nombre illimité d'organisations et de chaînes n'est tout simplement pas pratique, même du point de vue de la maintenance, sans parler du point de vue de la construction.

Je vous suggère d'explorer d'autres moyens de sécuriser les données des utilisateurs. Une manière serait de les crypter, de les hacher, selon ce qui convient le mieux à votre scénario et ensuite de les stocker sur le grand livre. Mais alors, les utilisateurs feraient toujours partie d'une ou plusieurs organisations, où le nombre total d'organisations est gérable.

D'après ce que vous avez dit jusqu'à présent, je ne suis pas convaincu qu'Hyperledger soit la solution idéale pour vous. Peut-être que votre propre réseau Ethereum fonctionnerait mieux pour cela, car vous y avez des comptes d'utilisateurs. Si vous n'avez pas besoin d'une solution blockchain, vous voudrez peut-être rester sur une façon standard de construire quelque chose de ce type.