Bonjour, chers lecteurs, je m'appelle Nikolai Nefedov, je suis consultant technique chez IBM, dans cet article, je voudrais vous présenter la plate-forme blockchain - Hyperledger Fabric. La plateforme est conçue pour créer des applications métier au niveau de l'entreprise (classe Enterprise). Niveau article - pour les lecteurs non formés ayant une connaissance de base de la technologie informatique.
Hyperledger Fabric est un projet open source, l'une des branches du projet open source Hyperledger, un consortium Linux Foundation. Hyperledger Fabric a été initialement lancé par Digital Assets et IBM. La principale caractéristique de la plate-forme Hyperledger Fabric est sa concentration sur les applications d'entreprise. Par conséquent, la plateforme a été développée en tenant compte de la rapidité des transactions et de leur faible coût, ainsi que de l'identification de tous les participants. Ces avantages sont obtenus grâce à la séparation du service de vérification des transactions et à la formation de nouveaux blocs du registre distribué, ainsi qu'à l'utilisation d'une autorité de certification et à l'autorisation des participants.
Mon article fait partie d'une série d'articles sur Hyperledger Fabric dans le cadre desquels nous décrivons la conception d'un système de comptabilité pour les étudiants entrant dans une université.
Architecture générale du tissu Hyperledger
Hyperledger Fabric est un réseau de blockchain distribué composé de divers composants fonctionnels installés sur des nœuds de réseau. Les composants Hyperledger Fabric sont des conteneurs Docker qui peuvent être téléchargés gratuitement à partir de DockerHub. Hyperledger Fabric peut également être exécuté dans les environnements Kubernetes.
Pour écrire des contrats intelligents (chaincode dans le contexte d'Hyperledger Fabric), nous avons utilisé Golang (bien que Hyperledger Fabric vous permette d'utiliser d'autres langues). Dans notre cas, Node.js avec le SDK Hyperledger Fabric correspondant a été utilisé pour développer une application personnalisée.
Les nœuds exécutent la logique métier (contrat intelligent) - chaincode, stockent l'état du registre distribué (données du grand livre) et exécutent d'autres services système de la plate-forme. Un nœud n'est qu'une unité logique, différents nœuds peuvent exister sur le même serveur physique. Beaucoup plus important est de savoir comment les nœuds sont regroupés (domaine approuvé) et à quelles fonctions du réseau blockchain ils sont associés.
L'architecture générale est la suivante:
Image 1. Architecture générale du tissu Hyperledger
Application utilisateur (Submitting Client) - une application avec laquelle les utilisateurs travaillent avec le réseau blockchain. Pour travailler, vous devez être autorisé et disposer des droits appropriés sur différents types d'actions sur le réseau.
Les pairs jouent plusieurs rôles:
- Endorsing Peer - un nœud qui simule l'exécution d'une transaction (exécute un code de contrat intelligent). Après avoir vérifié et exécuté le contrat intelligent, le nœud renvoie les résultats de l'application cliente avec sa signature.
- Service de commande - un service distribué sur plusieurs nœuds, sert à former de nouveaux blocs d'un registre distribué et à créer une séquence de transactions. Ordering Service n'ajoute pas de nouveaux blocs au registre (pour améliorer les performances, cette fonction a été transférée à Committing Peers).
- Committing Peer - un nœud qui contient un registre distribué et ajoute de nouveaux blocs au registre (que le service de commande a formé). Tous les homologues engagés contiennent une copie locale du registre distribué. Le pair engagé, avant d'ajouter localement un nouveau bloc, vérifie la validité de toutes les transactions au sein du bloc.
La politique d'approbation est une politique de validation des transactions. Ces politiques déterminent l'ensemble de nœuds nécessaire sur lequel un contrat intelligent doit être exécuté pour que la transaction soit reconnue comme valide.
Le registre distribué - Lerger - se compose de deux parties: WolrldState (également appelé - State DataBase) et BlockChain.
BlockChain est une chaîne de blocs qui stocke les enregistrements de toutes les modifications qui se sont produites avec les objets de registre distribués.
WolrldState est un composant d'un registre distribué qui stocke les valeurs actuelles (extrêmes) de tous les objets dans un registre distribué.
WorldState est une base de données, dans la version de base - LevelDB ou plus complexe - CouchDB, qui contient des paires clé-valeur, par exemple: Prénom - Ivan, Nom - Ivanov, date d'enregistrement dans le système - 12/12/21, date de naissance - 17/12/1961, etc. WorldState et le registre distribué doivent être cohérents avec tous les membres de ce canal.
Étant donné que Hyperledger Fabric est un réseau dans lequel tous les participants sont connus et authentifiés, une autorité de certification dédiée - CA (Autorité de certification) est utilisée ici. CA fonctionne sur la base de la norme X.509 et de l'infrastructure à clé publique - PKI.
Le service d'adhésion est un service par lequel les participants vérifient la propriété d'un objet dans une organisation ou un canal particulier.
Une transaction est, dans la plupart des cas, un enregistrement de nouvelles données dans un registre distribué.
Il existe également des transactions pour créer des canaux ou des contrats intelligents. La transaction est lancée par l'application utilisateur et se termine par un enregistrement dans le registre distribué.
Un canal est un sous-réseau fermé composé de deux ou plusieurs participants dans un réseau blockchain, conçu pour effectuer des transactions confidentielles au sein d'un cercle restreint mais bien connu de participants. Le canal est défini par les participants, son registre distribué, les contrats intelligents, le service de commande, WorldState. Chaque membre de la chaîne doit être autorisé à accéder à la chaîne et avoir le droit d'effectuer différents types de transactions. L'autorisation est effectuée à l'aide du service d'adhésion.
Scénario d'exécution de transaction typique
Ensuite, je voudrais parler d'un scénario d'exécution de transaction typique en utilisant notre projet comme exemple.
Dans le cadre de notre projet interne, nous avons créé le réseau Hyperledger Fabric, qui est conçu pour inscrire et enregistrer les étudiants entrant dans les universités. Notre réseau se compose de deux organisations appartenant à l'Université A et à l'Université B. Chaque organisation contient une application client, ainsi que son homologue engagé et avenant. Nous utilisons également les services communs Ordering Service, Memebership Service et Certification Authority.
1) Initiation de transaction
L'application utilisateur, à l'aide du SDK Hyperledger Fabric, lance une demande de transaction et envoie une demande aux nœuds avec des contrats intelligents. La demande peut être pour la modification ou la lecture d'un registre distribué (Ledger). Si nous considérons un exemple de notre configuration de test d'un système pour les étudiants universitaires en comptabilité, l'application cliente envoie une demande de transaction aux nœuds des universités A et B, qui sont inclus dans la politique d'approbation du contrat intelligent appelé. Le nœud A est un nœud qui se trouve dans une université qui inscrit un étudiant entrant, et le nœud B est un nœud qui se trouve dans une autre université. Pour que la transaction soit stockée dans un registre distribué, il est nécessaire que tous les nœuds qui, selon la logique métier, approuvent la transaction réussissent les contrats intelligents avec le même résultat. Le noeud Une application utilisateur, à l'aide des outils SDK Hyperledger Fabric, reçoit une politique d'approbation et recherche les noeuds auxquels envoyer une demande de transaction. Il s'agit d'une demande pour invoquer un contrat intelligent spécifique (fonction chaincode) pour lire ou écrire certaines données dans un registre distribué. Techniquement, le SDK client utilise la fonction correspondante, dont l'API transmet un objet avec les paramètres de transaction, et ajoute également la signature du client et envoie ces données via le tampon de protocole via gRPC aux nœuds correspondants (homologues approuvant).
Image 2. Initiation de transaction
2) Exécution d'un contrat intelligent
Les nœuds (Endorsing Peers), ayant reçu une demande de transaction, vérifient la signature du client et, si tout est en ordre, prennent un objet avec les données de demande et démarrent la simulation de l'exécution du contrat intelligent (fonction chaincode) avec ces données. Un contrat intelligent est une logique commerciale d'une transaction, un certain ensemble de conditions et d'instructions (dans notre cas, c'est une vérification d'étudiant, c'est un nouvel étudiant, ou est-il déjà inscrit, vérification d'âge, etc.). Pour exécuter un contrat intelligent, vous aurez également besoin des données de WorldState. À la suite de la simulation du contrat intelligent sur le pair avenant, deux ensembles de données sont obtenus - Ensemble de lecture et Ensemble d'écriture. L'ensemble de lecture et l'ensemble d'écriture sont les valeurs originales et nouvelles de WorldState. (nouveau - au sens obtenu lors de la simulation d'un contrat intelligent).
Image 3. Exécution d'un contrat intelligent
3) Retour des données à l'application cliente
Après la simulation du contrat intelligent, Endorsing Peers renvoie à l'application cliente les données initiales et le résultat de la simulation, ainsi que le RW Set, signé avec leur certificat. À ce stade, aucune modification n'est apportée au registre distribué. L'application cliente vérifie la signature de l'homologue endosseur et compare également les données source de la transaction envoyée et les données qui ont été renvoyées (c'est-à-dire qu'elle vérifie si les données source sur lesquelles la transaction a été simulée ont été déformées). Si la transaction était uniquement destinée à la lecture des données du registre, l'application cliente reçoit en conséquence le jeu de lecture nécessaire, ce qui termine généralement la transaction avec succès sans modifier le registre distribué. Dans le cas d'une transaction qui est censée modifier des données dans le registre, l'application cliente vérifie en outre la mise en œuvre de la politique d'approbation. Il est possible que l'application cliente ne vérifie pas le résultat de la politique d'approbation, mais la plate-forme Hyperledger Fabric dans ce cas prévoit de vérifier les politiques sur les nœuds (Comitting Peers) au stade de l'ajout d'une transaction au registre.
Image 4. Retour des données à l'application cliente
4) Envoi d'ensembles RW à des pairs commandants
L'application client envoie la transaction avec les données associées au service de commande. Cela inclut l'ensemble RW, les homologues approuvant et l'ID de canal.
Service de commande - basé sur le nom, la fonction principale de ce service est de construire les transactions entrantes dans le bon ordre. Ainsi que la formation d'un nouveau bloc du registre distribué et la livraison garantie de nouveaux blocs formés à tous les nœuds de validation, garantissant ainsi la cohérence des données sur tous les nœuds contenant le registre distribué (homologues de validation). Dans le même temps, le service de commande lui-même ne modifie en rien le registre. Le service de commande est un composant essentiel du système, c'est donc un cluster de plusieurs nœuds. Le service de commande ne vérifie pas la validité de la transaction, il accepte simplement la transaction avec un identifiant de canal spécifique, organise les transactions entrantes dans un certain ordre et forme de nouveaux blocs du registre distribué. Un service de commande peut desservir plusieurs canaux simultanément. Le service de commande comprend un cluster Kafka, qui prend en charge la file d'attente de transactions correcte (inchangée) (voir l'article 7).
Image 5. Soumission d'ensembles RW à des pairs commandants
Les blocs formés dans le service de commande sont transmis à tous les nœuds du réseau. Chaque nœud, après avoir reçu un nouveau bloc, vérifie sa conformité avec la politique d'approbation, vérifie que tous les homologues approuvant ont reçu le même résultat (ensemble d'écriture) à la suite de la simulation d'un contrat intelligent, et vérifie également si les valeurs d'origine ont changé (c.-à-d. Ensemble de lecture - données lues par un contrat intelligent de WorldState) depuis le début de la transaction. Si toutes les conditions sont remplies, la transaction est marquée comme valide; sinon, la transaction reçoit un statut non valide.
Image 6. Envoi de blocs formés à Committing Peer
6) Ajout d'un bloc au registre
Chaque nœud ajoute une transaction à sa copie locale du registre distribué, et si la transaction est valide, le jeu d'écriture est appliqué à WorldState (état actuel), en conséquence, les nouvelles valeurs des objets qui ont été affectés par la transaction sont enregistrées. Si la transaction a reçu un marqueur - non valide (par exemple, deux transactions ont eu lieu avec les mêmes objets dans le même bloc, alors l'une des transactions se révélera non valide, car les valeurs initiales ont déjà été modifiées par l'autre transaction). Cette transaction est également ajoutée au registre distribué avec un jeton qui n'est pas valide, mais le jeu d'écriture de cette transaction ne s'applique pas à l'état actuel de WorldState et, par conséquent, ne modifie pas les objets participant à la transaction. Après cela, une notification est envoyée à l'application utilisateur que la transaction est ajoutée à jamais au registre distribué, ainsi que l'état de la transaction, c'est-à-dire si elle est valide ou non ...
Image 7. Ajout d'un bloc au registre
SERVICE DE COMMANDE
Le service de commande se compose d'un cluster Kafka avec les nœuds ZooKeeper et les nœuds de service de commande (OSN) correspondants, qui se trouvent entre les clients du service de commande et le cluster Kafka. Kafka Cluster est une plateforme de gestion de flux (messagerie) à tolérance de pannes distribuée. Chaque canal (rubrique) dans Kafka est une séquence immuable d'enregistrements qui ne prend en charge que l'ajout d'un nouvel enregistrement (la suppression d'un enregistrement existant n'est pas possible). Une illustration de la structure du sujet est donnée ci-dessous. C'est cette propriété de Kafka qui est utilisée pour construire la plateforme blockchain.
extrait de kafka.apache.org
Image 8. Structure de rubrique de commande de service
Liens utiles
Youtube - Construire une blockchain pour les entreprises avec le projet Hyperledger
Hyperledger Fabric Docs
Tissu Hyperledger: un système d'exploitation distribué pour les chaînes de blocs autorisées
Remerciements
J'exprime ma profonde gratitude pour l'aide apportée à la préparation de l'article à mes collègues:
Nikolay Marina
Igor Hapov
Dmitry Gorbachev
Alexander Zemtsov
Ekaterina Kurdenkova
Ekaterina Guseva