1. Introduction à Hyperledger Fabric
Comme introduit dans le précédent article, le Public Blockchain est un réseau auquel tout le monde peut participer, interagir et consulter les données. Cependant, certaines organisations ne sont pas satisfaites de la transparence des données. D’autre part, la plupart des organisations n’ont besoin que des caractéristiques immuables de la Blockchain, ou si un groupe d’organisations construit un réseau, ils ont seulement besoin d’une “distribution” au sein de ces organisations et chaque réseau a un processus métier différent. Par conséquent, l’utilisation de la Public Blockchain n’est pas nécessaire et manque de confidentialité.
Alors que les réseaux Public Blockchain s’adaptent progressivement aux exigences de confidentialité du marché, Hyperledger Fabric est né pour répondre à ces besoins.
Hyperledger Fabric est l’un des 5 Frameworks Blockchain faisant partie de la stratégie Hyperledger Umbrella de la Linux Foundation : Hyperledger Indy, Hyperledger Fabric, Hyperledger Iroha, Hyperledger Sawtooth, Hyperledger Burror. Il est à noter que Hyperledger Fabric a été contribué par le géant IBM.
Hyperledger Fabric a une modularité élevée, ce qui permet aux entreprises de le “brancher et le jouer” pour construire une application Blockchain privée qui répond à leurs exigences métier.
La dernière version de Hyperledger Fabric au moment de la rédaction de cet article est la version 2.0.0-alpha.
Ainsi, on peut comprendre que Hyperledger Fabric est un réseau Blockchain privé ou un framework pour construire un réseau Blockchain privé.
2. Architecture d’un réseau Hyperledger Fabric
2.1 Architecture simple d’un réseau Hyperledger Fabric
N: (Network) Réseau.
NC: Network Configuration (Configuration du réseau).
C: Channel (Canal), regroupant les organisations ayant un rôle spécifique dans un processus métier. Par exemple, un canal pour la vente de voitures pourrait inclure deux organisations : le fabricant de voitures et le distributeur de voitures.
CC: Channel Configuration (Configuration du canal).
R: Organisation.
O: Orderer Node: Contrairement au Public Blockchain où tous les nœuds du réseau participent au processus de consensus, dans Hyperledger Fabric, seul l’Orderer participe à ce processus.
P: Peer, point d’interaction entre les membres de l’organisation correspondant au canal. Toute action de l’utilisateur doit passer par un pair (peer).
S: Smart Contract (Chaincode) installé sur le canal, définissant les structures et les actions que les utilisateurs peuvent effectuer pour interagir avec l’état des structures stockées dans le grand livre. Par exemple, une structure peut être définie comme suit:
type Car struct { CarID string OwnerID string Description string }L: Ledger (Grand livre), stocke l’état des objets. Par exemple :
car01 := Car{CarID: "Merc", OwnerID: "thienthangaycanh", Description: "ABC" }L’objet car01 sera stocké dans le grand livre sous forme de clé-valeur, la clé étant déterminée par le développeur du Smart Contract, et la valeur étant la valeur de car01 convertie en []byte. Bien sûr, la méthode de stockage du grand livre L suit le principe de la Blockchain, et le traitement ou le codage de cette paire de valeurs dépend d’IBM. Étant donné que ceci est une série de tutoriels d’utilisation, je vais simplement accepter les connaissances et les utiliser. Si vous voulez en savoir plus pour contribuer à ce Framework, vous pouvez cloner le projet et l’étudier à votre rythme sur https://github.com/hyperledger/fabric
CA: Certificate Authority, délivre des identités aux utilisateurs ou aux nœuds de l’organisation correspondante. Par exemple, lorsque l’utilisateur A est membre de l’organisation R1 et souhaite rejoindre le réseau, il envoie une demande à CA1, qui génère ensuite une identité comprenant une clé privée, une clé publique et d’autres attributs pertinents, qui est ensuite renvoyée à l’utilisateur A. A partir de là, A utilise cette identité pour effectuer des interactions avec le réseau, et le réseau sait automatiquement que A est membre de l’organisation R1.
A: Application, une interface (web, application mobile) facilitant l’interaction de l’utilisateur avec le système.
Tous ces composants sont soit exécutés sur Docker, soit définis dans le code, nous les considérons donc provisoirement comme des composants physiques du réseau. Il y a certains concepts que nous ne pouvons pas voir clairement mais qui sont très importants, nous les découvrirons plus tard.
2.2 Processus de construction du réseau
Étape 1. Big Bang
L’image ci-dessus montre le schéma de base d’un réseau N. Il comprend un noeud Orderer O4, qui exécute un service appelé Ordering Services. L’organisation R4 détient les droits de gestion du réseau N et ces informations sont stockées dans la configuration du réseau NC4. Le nœud CA4 est responsable de la délivrance des identités aux utilisateurs, aux pairs ou aux applications de l’organisation R4.
Il est donc étrange que R4 fournisse un Orderer O4 pour le réseau. Toutes les actions ultérieures, telles que l’ajout d’une organisation au réseau, l’ajout d’un canal, l’installation d’un chaincode sur un canal, l’initialisation d’un chaincode, la demande d’exécution d’un chaincode, etc., doivent passer par cet Orderer O4 (vous verrez cela clairement dans les articles suivants). Hyperledger Fabric utilise le terme “transaction” pour toutes ces actions.
Étape 2. Ajout d’une organisation de gestion
Au départ, NC4 était configuré pour permettre à l’utilisateur R4 de gérer le réseau. À cette étape, nous ajouterons l’organisation R1 au réseau et lui donnerons les mêmes droits de gestion que R4 :
- L’organisation R4 met à jour la configuration du réseau NC4 pour ajouter l’organisation R1 en tant qu’administrateur. Après cette étape, R1 et R4 ont des droits égaux sur la configuration du réseau.
- On peut voir que CA1 est également ajouté, CA1 fournira des identités aux utilisateurs de l’organisation R1. Après cette étape, les utilisateurs de R1 et de R4 ont tous les deux des droits de gestion sur le réseau.
- Bien que O4 s’exécute sur une infrastructure spécifique de R4, R1 a également des droits égaux à ceux de R4 sur O4.
Nous parlerons des services de commande dans les prochains articles, pour l’instant vous devez juste considérer O4 comme un point de contrôle de toutes les activités de tous les composants du réseau.
Étape 3. Définition d’un consortium
À l’heure actuelle, le réseau peut être géré par R1 et R4, mais il y a très peu d’actions qui peuvent être effectuées sur le réseau. Pour mapper les activités commerciales sur le réseau, la première chose à faire est de définir un consortium. Ce terme signifie littéralement un groupe d’organisations travaillant sur une activité commerciale particulière, par exemple, l’organisation de fabrication de voitures et l’organisation de distribution de voitures fabriquées par l’organisation de fabrication pour les consommateurs.
Un administrateur de réseau (R1 ou R4) définit un consortium X1 qui contient deux membres, R1 et R2. La définition de ce consortium est stockée dans la configuration du réseau NC4 et sera utilisée dans la prochaine étape de développement du réseau. CA2 est l’organe de délivrance des identités aux utilisateurs, nœuds et applications de l’organisation R2. Un consortium peut avoir un nombre quelconque d’organisations, ici nous utilisons le cas le plus simple avec 2 organisations.
Étape 4. Création d’un canal pour un consortium
Un canal est un moyen de communication permettant aux membres d’un consortium de communiquer entre eux. Il peut y avoir plusieurs consortiums et plusieurs canaux dans un réseau, mais chaque consortium n’a qu’un seul canal.
Un canal C1 a été créé pour le consortium X1. La configuration du canal C1 est stockée dans la configuration du canal CC1, totalement séparée de la configuration du réseau NC4. CC1 est géré par R1 et R2, ces deux organisations ont les mêmes droits sur C1. R4 n’a aucun droit sur CC1.
Le canal C1 fournit un moyen de communication privé entre les organisations de X1. On peut voir que le canal C1 est uniquement connecté à l’Orderer O4. Dans l’étape suivante, nous connecterons les composants tels que l’application et le peer.
Bien que le canal C1 fasse partie du réseau N, il est complètement séparé de N. Notez également que l’organisation R4 n’est pas incluse dans ce canal – ce canal est réservé au traitement des transactions entre R1 et R2. Dans l’étape précédente, nous avons vu comment R4 a accordé des droits de gestion du réseau à R1, puis R1 a créé un consortium. Pour comprendre cela implicitement, cela signifie que R4 a également accordé à R1 le droit de créer un canal ! Dans ce schéma, ce pourrait être R1 ou R4 qui a créé le canal C1. Encore une fois, notez que le canal peut avoir un nombre quelconque d’organisations qui y sont connectées – je prends l’exemple le plus simple avec 2 organisations.
La configuration du canal CC1 détient les décisions concernant les droits de R1 et de R2 sur le canal C1 – et nous pouvons clairement voir que R4 n’a aucun droit dans ce canal. R4 ne peut interagir avec C1 que s’il est ajouté par R1 ou R2 à la configuration du canal CC1. De plus, R4 ne peut pas s’ajouter lui-même à C1 – cela doit et ne peut être fait que par R1 et R2.
Jusqu’à présent, nous pouvons voir que la confidentialité de Hyperledger Fabric provient du canal. Hyperledger Fabric est très puissant en matière de confidentialité car il permet aux organisations de partager une infrastructure tout en maintenant leur propre confidentialité.
Toutes les mises à jour de la configuration du réseau NC4 à partir de ce moment n’auront aucun impact direct sur la configuration du canal CC1 ; par exemple, si la définition du consortium X1 change, cela n’affectera pas les membres du canal C1. Par conséquent, les canaux sont très utiles car ils permettent une communication privée entre les organisations qui constituent le canal. De plus, les données d’un canal sont complètement isolées du reste du réseau, ainsi que des autres canaux.
Étape 5. Peer et Ledger
Maintenant, nous verrons comment utiliser le canal pour connecter les organisations entre elles.
Un pair P1 a rejoint le canal C1. Chaque canal a un seul grand livre, et chaque pair stocke une copie de ce grand livre pour un accès par les utilisateurs de l’organisation correspondante. Par exemple, P1 de l’organisation R1 stocke une copie du grand livre L1 pour l’accès des utilisateurs de l’organisation R1.
L1 est “physiquement hébergé” sur le pair P1, mais “logiquement hébergé” sur le canal C1.
Maintenant, P1 et O4 peuvent communiquer via le canal C1.
Chaque composant, des utilisateurs aux pairs, en passant par les orderers, a besoin d’une identité. Par conséquent, P1 a également une identité (de type X.509 – vous n’avez pas besoin de vous soucier de ce qu’est X.509 pour l’instant) fournie par CA1, qui indique que P1 appartient à l’organisation R1.
Lorsque P1 démarre, il peut rejoindre le canal C1 en envoyant une demande à O4. Lorsque O4 reçoit cette demande, il utilise la configuration du canal CC1 pour déterminer les droits de P1 sur ce canal. Par exemple, CC1 détermine si P1 peut lire et/ou écrire des informations dans le grand livre L1.
Étape 6. Application et Smart Contract (Chaincode)
Maintenant que le canal C1 a un grand livre, nous pouvons commencer à connecter les applications pour utiliser un cas d’utilisation métier défini dans un smart contract.
Un smart contract S5 a été installé sur P1. L’application A1 de l’organisation R1 peut utiliser S5 pour accéder au grand livre L1 via le pair P1. Le canal contient actuellement A1, P1 et O4.
Tout comme les pairs, les orderers et les utilisateurs disposent d’une identité, une application a également une identité liée à l’organisation correspondante. Par exemple, A1 a une identité fournie par CA1 pour indiquer qu’elle appartient à R1.
Maintenant, A1 semble pouvoir accéder directement au grand livre L1 via P1, mais en réalité, tous les accès sont gérés par le smart contract S5. De manière simple, S5 définit tous les cas d’utilisation d’accès au grand livre L1 ; il fournit un ensemble de méthodes clairement définies selon lesquelles le grand livre L1 peut être interrogé ou mis à jour par qui. En résumé, l’application cliente A1 doit passer par le smart contract S5 pour interagir avec le grand livre L1 !
Les smart contracts peuvent être créés par les développeurs d’applications dans chaque organisation pour exécuter des processus métier partagés par les membres du consortium.
Un canal peut avoir plusieurs smart contracts.
Étape 6.1 Installation d’un smart contract
Après que le smart contract S5 a été codé, l’administrateur de l’organisation R1 doit l’installer sur le pair P1. C’est une opération simple ; ensuite, P1 peut voir la logique de mise en œuvre de S5 – le code qu’il utilise pour accéder au grand livre L1.
Lorsqu’une organisation a plusieurs pairs sur un canal, elle peut choisir les pairs sur lesquels elle souhaite installer un smart contract ; elle n’est pas obligée d’installer un smart contract sur chaque pair.
Étape 6.2 Initialisation d’un smart contract
Pour que les autres composants connectés au canal C1 sachent qu’un smart contract vient d’être installé, nous devons l’initialiser sur le canal C1. Dans cet exemple, il n’y a qu’un seul pair P1, un administrateur dans l’organisation R1 doit initialiser S5 sur le canal C1 en utilisant P1. Après l’initialisation, tous les composants sur le canal C1 sont conscients de l’existence de S5 ; cela signifie que maintenant S5 peut être invoqué par l’application cliente A1.
Veuillez noter que bien que tous les composants sur le canal puissent désormais accéder à S5, ils ne peuvent pas voir la logique programmatique de S5. Cela reste privé pour les pairs qui l’ont installé ; dans cet exemple, cela signifie P1. Conceptuellement, cela signifie que seule l’interface du smart contract est initialisée. Et l’installation d’un smart contract est aussi simple que le fait qu’il est physiquement hébergé sur un pair, alors que l’initialisation d’un smart contract signifie qu’il est logiquement hébergé sur un canal.
Politique de validation (Endorsement policy)
La partie la plus importante des informations à fournir lors de l’initialisation est une politique de validation. Elle décrit quelles organisations doivent approuver les transactions avant qu’elles ne soient acceptées par les autres organisations dans une copie du grand livre. La définition ressemble à R1 ET R2 ou R1 OU R2.
Invocation d’un smart contract
Lorsqu’un smart contract est installé sur un pair et initialisé sur un canal, il peut être appelé par une application. Les applications effectuent cela en envoyant une proposition de transaction aux pairs propriétaires des organisations désignées par la politique de validation. La proposition de transaction agit comme un paramètre d’entrée pour le smart contract (nom de la fonction, paramètres d’entrée de cette fonction), l’utilisant pour générer une réponse de transaction validée, renvoyée par le pair à l’application. Je parlerai du déroulement des transactions dans les prochains articles.
Étape 7. Réseau terminé
Ajout des pairs P2 et A2, CA2, installation de Smart contract pour P2 de manière similaire à R1.
