La technologie Blockchain publique permet à tout le monde de rejoindre et d’interagir avec le réseau, ainsi que d’accéder aux données. Cependant, certaines organisations préfèrent garder leurs données confidentielles et ne souhaitent pas les rendre publiques. De plus, chaque organisation peut avoir des exigences spécifiques en termes de processus métier, ce qui rend l’utilisation de Blockchain publique inutile et non adaptée.
C’est là qu’intervient Hyperledger Fabric, une technologie aussi connue sous le nom de Blockchain privée. Hyperledger Fabric fait partie des cinq frameworks de Blockchain qui ont été développés par la Linux Foundation, notamment Hyperledger Indy, Hyperledger Fabric, Hyperledger Iroha, Hyperledger Sawtooth, et Hyperledger Burror. Ce projet a particulièrement été soutenu par IBM.
Hyperledger Fabric se distingue par sa modularité élevée, ce qui permet aux entreprises d’adapter facilement la technologie à leurs besoins spécifiques en matière de Blockchain privée.
La version la plus récente d’Hyperledger Fabric, au moment de la rédaction, est la 2.0.0-alpha.
Maintenant que nous comprenons qu’Hyperledger Fabric est un réseau privé, il est important de comprendre son architecture.
Architecture d’un réseau Hyperledger Fabric
L’architecture d’un réseau Hyperledger Fabric est composée de plusieurs éléments, tels que :
- N (Network) : le réseau lui-même.
- NC (Network Configuration) : la configuration du réseau.
- C (Channel) : le canal, qui regroupe plusieurs organisations ayant des rôles spécifiques dans un processus métier commun. Par exemple, un canal dédié à la vente de voitures comprendrait deux organisations : le fabricant de voitures et le distributeur.
- CC (Channel Configuration) : la configuration du canal.
- R (Organization) : une organisation.
- O (Orderer Node) : un nœud “orderer” qui est responsable du consensus dans Hyperledger Fabric. Contrairement aux Blockchain publiques, seuls les nœuds orderers participent au processus de consensus dans Hyperledger Fabric.
- P (Peer) : un point d’interaction entre les membres d’une organisation et le canal. Toutes les actions des utilisateurs doivent passer par un “peer”.
- S (Smart Contract) : aussi appelé “Chaincode”, il est installé sur le canal et définit les structures et les actions que les utilisateurs peuvent effectuer pour interagir avec l’état des structures enregistrées dans le grand livre (ledger). Par exemple, une structure de données comme celle-ci :
type Car struct {
CarID string
OwnerID string
Description string
}- L (Ledger) : le grand livre qui enregistre l’état des objets. Par exemple :
car01 := Car{CarID: "Merc", OwnerID: "thienthangaycanh", Description: "ABC"}L’objet “car01” sera enregistré dans le grand livre sous forme de clé-valeur, la clé étant déterminée par le code du Smart Contract, et la valeur étant la représentation en bytes de l’objet “car01”. Le grand livre est stocké de manière similaire à une Blockchain, avec un chiffrement et un traitement supplémentaires qui peuvent être détaillés en consultant le projet sur Github.
CA (Certificate Authority) : l’autorité de certification, qui délivre des identités aux utilisateurs ou aux nœuds des organisations respectives. Par exemple, lorsque l’utilisateur A est membre de l’organisation R1 et souhaite rejoindre le réseau, il doit envoyer une demande à CA1. CA1 créera ensuite une identité composée d’une clé privée, d’une clé publique et d’autres attributs, qu’elle remettra à l’utilisateur A. À partir de ce moment-là, l’utilisateur A utilisera cette identité pour interagir avec le réseau, et le réseau reconnaîtra automatiquement que cet utilisateur provient de l’organisation R1.
A (Application) : l’application ou l’interface (web, application mobile) qui permet aux utilisateurs d’interagir plus facilement avec le système.
Tous ces composants peuvent être exécutés dans des conteneurs Docker ou dans un environnement physique spécifique. Bien qu’il existe certains concepts qui ne sont pas visibles dans cette architecture, ils sont tout de même très importants et seront étudiés dans de futurs articles.
Processus de construction du réseau
Le processus de construction d’un réseau Hyperledger Fabric est divisé en plusieurs étapes :
Étape 1 : Big Bang
Dans cette première étape, un réseau N est créé avec un nœud “orderer” O4 qui exécute un service appelé Ordering Services. L’organisation R4 détient les droits d’administration du réseau N, et cette information est stockée dans la configuration du réseau NC4. Le nœud CA4 est responsable de la délivrance des identités aux utilisateurs, aux pairs (peers) et aux applications de l’organisation R4.
Comme vous pouvez le voir dans le schéma, R4 fournit un nœud orderer O4 au réseau. Toutes les actions ultérieures, telles que l’ajout d’organisations dans le réseau, l’ajout de canaux, l’installation de chaincodes pour les canaux, l’initialisation des chaincodes, la demande d’exécution des chaincodes, doivent toutes passer par cet orderer O4 (vous le verrez plus clairement dans les articles suivants). En Hyperledger Fabric, toutes ces actions sont considérées comme des transactions.
Étape 2 : Ajout d’une organisation d’administration
Dans cette étape, une organisation R1 est ajoutée au réseau et se voit accorder des droits administratifs similaires à ceux de R4 :
- L’organisation R4 met à jour la configuration du réseau NC4 pour ajouter l’organisation R1 en tant qu’administrateur. À partir de ce moment-là, R1 et R4 ont des droits équivalents en ce qui concerne la configuration du réseau.
- L’organisation CA1 est également ajoutée, elle fournit des identités aux utilisateurs de l’organisation R1. À partir de ce moment-là, les utilisateurs de R1 et de R4 ont les mêmes droits d’administration sur le réseau.
- Bien que O4 s’exécute sur l’infrastructure de R4, R1 a également des droits sur O4.
Nous en apprendrons davantage sur le fonctionnement de l’Ordering service dans les prochains articles. Pour l’instant, vous devez considérer O4 comme un point de contrôle centralisé pour toutes les opérations de tous les composants du réseau.
Étape 3 : Définition d’un consortium
Maintenant que le réseau est géré par R1 et R4, il y a encore peu d’actions pouvant être réalisées sur le réseau. Pour mapper des activités commerciales spécifiques sur le réseau, la première chose à faire est de créer un consortium. Un consortium est un groupe d’organisations qui travaillent ensemble pour réaliser une activité ou un processus commercial commun. Par exemple, un consortium pourrait regrouper un fabricant automobile et un distributeur automobile qui vend les voitures produites par le fabricant aux consommateurs finaux.
Un administrateur de réseau (R1 ou R4) définit un consortium X1 contenant deux membres : R1 et R2. La définition de ce consortium est enregistrée dans la configuration du réseau NC4 et sera utilisée dans les phases de développement du réseau ultérieures. CA2 est responsable de la délivrance des identités aux utilisateurs, nœuds et applications de l’organisation R2. Un consortium peut contenir un nombre quelconque d’organisations, mais nous utilisons ici l’exemple le plus simple avec deux organisations.
Étape 4 : Création d’un canal pour un consortium
Un canal est un moyen de communication qui permet aux membres d’un consortium de communiquer entre eux. Un réseau peut avoir plusieurs consortiums et plusieurs canaux, mais chaque consortium ne peut avoir qu’un seul canal.
Un canal C1 est créé pour le consortium X1. Sa configuration est enregistrée dans la configuration du canal CC1, qui est complètement séparée de la configuration du réseau NC4. CC1 est géré conjointement par R1 et R2, les deux organisations ayant 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 membres de X1. Nous pouvons voir dans le schéma que le canal C1 est initialement connecté à l’Orderer O4. Nous allons maintenant connecter les autres composants, comme l’application et le peer.
Bien que le canal C1 fasse partie du réseau N, il est complètement séparé de N. Il est également important de noter que l’organisation R4 n’est pas membre de ce canal – le canal est réservé pour les transactions entre R1 et R2. Comme nous l’avons vu précédemment, R4 a accordé des droits administratifs à R1, y compris la possibilité de créer un canal ! Dans ce schéma, l’une des organisations R1 ou R4 a créé le canal C1. Encore une fois, il convient de noter qu’un canal peut avoir n’importe quel nombre d’organisations connectées à lui – nous utilisons ici l’exemple le plus simple avec deux organisations.
La configuration du canal CC1 définit les droits que R1 et R2 ont sur le canal C1 – et comme nous le voyons, R4 n’a aucun droit sur ce canal. R4 ne peut interagir avec C1 que s’il est ajouté par R1 ou R2 dans la configuration du canal CC1. R4 ne peut pas s’ajouter lui-même au canal C1 – cela doit être fait par R1 ou R2.
Maintenant, nous pouvons voir que la confidentialité d’Hyperledger Fabric est réalisée par le canal. Hyperledger Fabric est très puissant en termes 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 après cette étape n’affecteront pas directement 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 utiles car ils permettent une communication privée entre les organisations membres d’un canal spécifique. 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
À ce stade, nous allons connecter les organisations en ajoutant un peer P1 sur le canal C1. Chaque canal a un seul grand livre, et chaque peer stocke une copie de ce grand livre pour que les utilisateurs de l’organisation correspondante puissent y accéder. Par exemple, P1 de l’organisation R1 stocke une copie du grand livre L1 pour que les utilisateurs de R1 puissent y accéder.
L1 est “physiquement hébergé” sur le peer P1, mais “logiquement hébergé” sur le canal C1.
Maintenant, P1 et O4 peuvent communiquer via le canal C1.
Tous les composants, y compris les utilisateurs, les peers, les orderers et les applications, doivent avoir une identité. Ainsi, P1 a également une identité (de type X.509 – sans entrer dans les détails techniques), délivrée par CA1, qui identifie P1 comme appartenant à l’organisation R1.
Lorsque P1 est démarré, 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 le canal. Par exemple, CC1 détermine si P1 est autorisé à lire et/ou à écrire des informations dans le grand livre L1.
Étape 6 : Application et Smart Contract (Chaincode)
Le canal C1 dispose maintenant d’un grand livre, nous pouvons commencer à connecter des applications pour utiliser un processus métier défini dans un smart contract.
Un smart contract S5 est installé sur P1. L’application A1 de l’organisation R1 peut utiliser S5 pour accéder au grand livre L1 via le peer P1. Dans le canal, il y a actuellement A1, P1 et O4.
Tout comme les utilisateurs, les ordonnanceurs et les peers, une application a une identité liée à l’organisation correspondante. Par exemple, A1 a une identité fournie par CA1 pour identifier A1 comme appartenant à R1.
Maintenant, il semble qu’A1 puisse accéder directement au grand livre L1 via P1, mais en réalité, tous les droits d’accès sont gérés par le smart contract S5. En simplifiant, S5 définit tous les cas d’utilisation d’accès au grand livre L1. S5 fournit un ensemble de façons explicites de lire, mettre à jour ou supprimer des données dans le grand livre, en fonction de qui effectue l’action. En d’autres termes, 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
Une fois que le smart contract S5 est codé, un administrateur de l’organisation R1 doit l’installer sur le peer P1. C’est une opération simple et une fois terminée, P1 peut voir la logique de mise en œuvre de S5 – le code utilisé pour accéder au grand livre L1.
Lorsqu’une organisation a plusieurs peers sur un canal, elle peut choisir les peers sur lesquels elle souhaite installer les smart contracts ; elle n’a pas besoin d’installer un smart contract sur tous les peers.
Étape 6.2 : Initialisation d’un smart contract
Pour que les autres composants connectés au canal C1 soient informés de l’existence du smart contract qui vient d’être installé, nous devons l’initialiser sur le canal C1. Dans cet exemple, avec seulement un peer P1, un administrateur de l’organisation R1 doit initialiser S5 sur le canal C1 en utilisant P1. Une fois initialisé, tous les composants du canal C1 sont informés de l’existence de S5, ce qui signifie que S5 peut maintenant être appelé par l’application cliente A1.
Il est important de noter que bien que tous les composants du canal puissent accéder à S5, ils ne peuvent pas voir la logique interne du programme de S5. Cela reste privé pour les peers sur lesquels il est installé ; dans cet exemple, cela signifie seulement P1. Conceptuellement, cela signifie que seules les interfaces du smart contract sont initialisées. De plus, l’installation d’un smart contract signifie simplement qu’il est “physiquement hébergé” sur un peer, tandis que son initialisation signifie qu’il est “logiquement hébergé” sur le canal.
Politique d’approbation
La chose la plus importante qui doit être définie lors de l’initialisation est une politique d’approbation. Elle décrit les organisations qui doivent approuver les transactions avant que les autres organisations ne les acceptent dans une copie de leur grand livre. Par exemple, une définition pourrait être R1 AND R2 ou R1 OR R2.
Invocation du Smart Contract
Une fois qu’un smart contract est installé sur un peer et initialisé sur un canal, il peut être appelé par une application. Les applications effectuent cela en soumettant une proposition de transaction aux peers propriétaires des organisations désignées par la politique d’approbation. 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), utilisant ces informations pour générer une réponse de transaction approuvée, renvoyée par le peer à l’application. Nous examinerons le flux des transactions dans un prochain article.
Réseau terminé
À ce stade, nous pouvons ajouter les autres composants, tels que P2, A2, CA2, et installer le smart contract sur P2, de manière similaire à ce que nous avons fait avec R1.
