Une plateforme Blockchain pour l'entreprise
Bonjour, chers lecteurs, je m'appelle Nikolai Nefedov, je suis un spécialiste technique IBM, dans cet article, je voudrais vous présenter la plateforme blockchain - Hyperledger Fabric. La plate-forme est destinée à la création d'applications métier au niveau de l'entreprise (classe Enterprise). Le niveau de l'article est destiné aux lecteurs non préparés ayant une connaissance de base des technologies informatiques.
Hyperledger Fabric est un projet open source, l'une des branches du projet open source Hyperledger, un consortium de la Fondation Linux. 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 grande vitesse des transactions et de leur faible coût, ainsi que de l'identification de tous les participants. Ces avantages sont obtenus en séparant le service de vérification des transactions et en formant de nouveaux blocs du registre distribué, ainsi qu'en utilisant une autorité de certification et en autorisant les participants.
Mon article fait partie d'une série d'articles sur Hyperledger Fabric dans lesquels nous décrivons le projet d'un système d'inscription des étudiants entrant dans une université.
Architecture générale de Hyperledger Fabric
Hyperledger Fabric est un réseau 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 un environnement Kubernetes.
Pour écrire des contrats intelligents (chaincode dans le contexte d'Hyperledger Fabric), nous avons utilisé Golang (bien que Hyperledger Fabric permette d'utiliser d'autres langages). Pour développer une application personnalisée, dans notre cas, Node.js a été utilisé avec le SDK Hyperledger Fabric correspondant.
Les nœuds exécutent la logique métier (contrat intelligent) - code en chaîne, 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 la façon dont les nœuds sont regroupés (domaine de confiance) et les fonctions du réseau blockchain auxquelles ils sont associés.
L'architecture générale ressemble à ceci :
Image 1. Architecture générale de Hyperledger Fabric
L'application utilisateur (Submitting Client) est une application avec laquelle les utilisateurs travaillent avec le réseau blockchain. Pour travailler, vous devez passer par une autorisation et disposer des droits appropriés pour différents types d'actions sur le réseau.
Les pairs (nœuds) jouent plusieurs rôles :
- Endorsing Peer est un nœud qui simule l'exécution d'une transaction (exécute le code du contrat intelligent). Après avoir validé et exécuté le contrat intelligent, le nœud renvoie les résultats d'exécution à l'application cliente avec sa signature.
- Le service de commande est un service distribué sur plusieurs nœuds, il est utilisé pour former de nouveaux blocs du grand livre distribué et créer une séquence pour l'exécution des transactions. Le service de commande n'ajoute pas de nouveaux blocs au registre (déplacés vers les homologues engagés pour de meilleures performances).
- Committing Peer - un nœud qui contient un registre distribué et ajoute de nouveaux blocs au registre (qui ont été formés par le service de commande). Tous les homologues de validation contiennent une copie locale du registre distribué. Le pair engageant, avant d'ajouter un nouveau bloc localement, vérifie la validité de toutes les transactions dans le bloc.
La politique d'endossement est une politique de vérification de la validité d'une transaction. Ces politiques définissent l'ensemble nécessaire de nœuds sur lesquels le 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 apportées aux objets du grand livre distribué.
WolrldState est un composant de registre distribué qui stocke les valeurs actuelles (extrêmes) de tous les objets de registre distribués.
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/17.12.1961/XNUMX, date de naissance - XNUMX/XNUMX/XNUMX, etc. WorldState et le registre distribué doivent être cohérents entre tous les membres d'un canal donné.
É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 est utilisée ici - CA (Certification Authority). 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 membres vérifient qu'un objet appartient à une organisation ou à un canal particulier.
Une transaction est, dans la plupart des cas, un enregistrement de nouvelles données dans un grand livre distribué.
Il existe également des transactions pour la création de canaux ou de contrats intelligents. La transaction est initiée par l'application utilisateur et se termine par une écriture dans le registre distribué.
Channel (Channel) est un sous-réseau fermé composé de deux participants ou plus dans le réseau blockchain, conçu pour effectuer des transactions confidentielles au sein d'un cercle limité, mais connu, de participants. Le canal est déterminé par les participants, son grand livre distribué, les contrats intelligents, le service de commande, WorldState. Chaque membre du canal doit être autorisé à accéder au canal 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 typique pour l'exécution d'une transaction en utilisant l'exemple de notre projet.
Dans le cadre de notre projet interne, nous avons créé un réseau Hyperledger Fabric, conçu pour enregistrer et enregistrer les étudiants entrant dans les universités. Notre réseau se compose de deux organisations, détenues par l'Université A et l'Université B. Chaque organisation contient une application cliente, ainsi que son propre pair d'engagement et d'approbation. Nous utilisons également les services communs du service de commande, du service d'adhésion et de l'autorité de certification.
1) Lancement de la transaction
L'application utilisateur, à l'aide du SDK Hyperledger Fabric, lance une demande de transaction et envoie la demande aux nœuds avec des contrats intelligents. La demande peut être de modifier ou de lire à partir d'un grand livre distribué (Ledger). Si nous considérons un exemple de notre configuration de test du système de comptabilité pour les étudiants universitaires, l'application cliente envoie une demande de transaction aux nœuds des universités A et B, qui sont incluses dans la politique d'approbation du contrat intelligent appelé. Le nœud A est un nœud situé dans l'université qui enregistre un étudiant entrant, et le nœud B est un nœud situé dans une autre université. Pour qu'une transaction soit enregistrée dans un registre distribué, il est nécessaire que tous les nœuds qui, selon la logique métier, doivent approuver la transaction, exécutent avec succès des contrats intelligents avec le même résultat. L'application utilisateur du nœud A, à l'aide des outils Hyperledger Fabric SDK, reçoit la politique d'approbation (politique d'approbation) et découvre à quels nœuds envoyer une demande de transaction. Il s'agit d'une demande d'appel (appel) d'un certain contrat intelligent (fonction de code blockchain) afin de lire ou d'écrire certaines données dans le grand livre distribué. Techniquement, le SDK client utilise la fonction correspondante, dont l'API reçoit un objet avec des paramètres de transaction, et ajoute également une signature client et envoie ces données via un tampon de protocole sur gRPC aux nœuds appropriés (approuvant les pairs).
Image 2. Initiation de la transaction
2) Exécution intelligente des contrats
Les nœuds (Endorsing Peers), ayant reçu une demande pour effectuer une transaction, vérifient la signature du client et si tout est en ordre, ils prennent alors un objet avec les données de la demande et exécutent une simulation de l'exécution d'un contrat intelligent (fonction chaincode) avec ces données. Un contrat intelligent est la logique commerciale d'une transaction, un certain ensemble de conditions et d'instructions (dans notre cas, il s'agit d'un chèque étudiant, est-ce un nouvel étudiant, ou est-il déjà inscrit, contrôle d'âge, etc.). Pour exécuter un contrat intelligent, vous aurez également besoin des données de WorldState. À la suite de la simulation de contrat intelligent sur le pair endossant, deux ensembles de données sont obtenus - Read Set et Write Set. Read Set et Write Set sont les valeurs originales et nouvelles de WorldState. (nouveau - au sens obtenu en simulant un smart contract).
Image 3. Exécution du contrat intelligent
3) Renvoyer les données à l'application cliente
Après la simulation du smart contract, les Endorsing Peers retournent à l'application cliente les données initiales et le résultat de la simulation, ainsi que le RW Set signé par leur certificat. À ce stade, il n'y a aucun changement dans le registre distribué. L'application cliente vérifie la signature de l'homologue endosseur et compare également les données de transaction d'origine envoyées et les données renvoyées (c'est-à-dire qu'elle vérifie si les données d'origine sur lesquelles la transaction a été simulée ont été corrompues). Si la transaction ne visait qu'à lire les données du registre, l'application cliente reçoit en conséquence le jeu de lecture nécessaire, et la transaction se termine généralement avec succès sans modifier le registre distribué. Dans le cas d'une transaction qui devrait modifier les données du registre, l'application cliente vérifie en outre si la politique d'approbation a été mise en œuvre. Il est possible que l'application cliente ne vérifie pas le résultat de l'exécution de la Endorsement Policy, mais la plateforme Hyperledger Fabric prévoit dans ce cas de vérifier les politiques sur les nœuds (Comitting Peers) au stade de l'ajout d'une transaction au registre.
Image 4. Renvoi des données à l'application cliente
4) Envoi d'ensembles RW aux pairs de commande
L'application cliente envoie la transaction avec les données associées au service de commande. Cela inclut l'ensemble RW, les signatures des homologues d'approbation et l'ID de canal.
Service de commande - Basé sur le nom, la fonction principale de ce service est de créer des transactions entrantes dans le bon ordre. Ainsi que la formation d'un nouveau bloc du registre distribué et la livraison garantie des nouveaux blocs générés à tous les nœuds Commiting, assurant ainsi la cohérence des données sur tous les nœuds contenant le registre distribué (Committing peers). 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 vital du système, il s'agit donc d'un cluster de plusieurs nœuds. Le service de commande ne vérifie pas la validité de la transaction, il accepte simplement une transaction avec un ID de canal spécifique, organise les transactions entrantes dans un ordre spécifique et forme de nouveaux blocs du grand livre distribué à partir de celles-ci. Un service de commande peut desservir plusieurs canaux en même temps. Le service de commande comprend un cluster Kafka, qui maintient la file d'attente de transactions correcte (inchangée) (voir point 7).
Image 5. Envoi d'ensembles RW aux homologues de commande
5) Envoi des blocs générés au Committing Peer
Les blocs formés dans le service de commande sont diffusés à tous les nœuds du réseau. Chaque nœud, ayant reçu un nouveau bloc, vérifie sa conformité avec la politique d'approbation, vérifie que tous les homologues d'approbation ont reçu le même résultat (Write Set) à la suite de la simulation de contrat intelligent, et vérifie également si les valeurs d'origine ont changé (c'est-à-dire - Read Set - données lues par le contrat intelligent à partir 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 le statut non valide.
Image 6. Envoi des blocs générés au pair engagé
6) Ajouter un bloc au registre
Chaque nœud ajoute une transaction à sa copie locale du grand livre distribué, et si la transaction est valide, alors Write Set est appliqué au WorldState (état actuel), respectivement, les nouvelles valeurs des objets qui ont été affectés par la transaction sont écrites . Si une transaction a reçu un jeton qui n'était pas valide (par exemple, il y avait deux transactions avec les mêmes objets dans le même bloc, alors l'une des transactions ne sera pas valide, car les valeurs d'origine ont déjà été modifiées par une autre transaction ). Cette transaction est également ajoutée au registre distribué avec un marqueur non valide, mais l'ensemble 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 indiquant que la transaction a été ajoutée au grand livre distribué pour toujours, ainsi que le statut de la transaction, c'est-à-dire si elle est valide ou non ...
Image 7. Ajouter un bloc au registre
SERVICE DE COMMANDE
Le service de commande se compose d'un cluster Kafka avec les nœuds ZooKeeper correspondants et d'un nœud de service de commande (OSN) situé entre les clients du service de commande et le cluster Kafka. Le cluster Kafka est une plate-forme de gestion de flux (message) distribuée et tolérante aux pannes. Chaque canal (sujet) 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 des sujets 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 des sujets de service de commande*
Liens utiles
Remerciements
J'exprime ma profonde gratitude à mes collègues pour leur aide dans la préparation de l'article :
Nikolaï Marina
Igor Khapov
Dmitri Gorbatchev
Alexandre Zemtsov
Ekaterina Guseva
Source: habr.com