documentation hyperledger-fabric documentation officielle

• ##Introduction
  Hyperledger Fabric est une plate-forme pour les solutions de registre distribué avec une architecture modulaire qui offre une sécurité, une résilience, une flexibilité et une évolutivité élevées. Il est conçu pour prendre en charge la mise en œuvre enfichable de différents composants et s'adapter à des écosystèmes économiques complexes.
  • ### Privé et autorisé
  • ###Canal
    Certains participants peuvent être des concurrents et ne veulent pas que chaque transaction qu'ils effectuent soit connue de tous les participants, par exemple, un prix spécial qu'ils n'offrent qu'à certains participants et à d'autres non. Si deux participants forment un canal, seuls ces deux participants ont une copie du registre du canal, et aucun autre participant.
• ##chaîne de blocs
  • ### Un registre distribué
    • #### Le registre de la blockchain est souvent décrit comme décentralisé car il est répliqué sur de nombreux participants au réseau, chacun collaborant pour maintenir le registre.
    • #### ne peut pas être modifié, peut être utilisé comme système de preuve
  • ###Contrat intelligent : fournir un accès contrôlé au registre
    Écrit en code chaîne, lorsque l'application doit interagir avec le registre, il est appelé par l'application en dehors de la blockchain. Dans la plupart des cas, le code blockchain n'interagit qu'avec la base de données du grand livre, l'état mondial (par exemple, les requêtes), pas avec le journal des transactions.
  • ###Consensus : le processus de synchronisation du registre sur l'ensemble du réseau
    • #### Les transactions doivent être écrites dans le grand livre dans l'ordre dans lequel elles se sont produites, même si elles peuvent se trouver dans différents ensembles de participants du réseau. Pour ce faire, l'ordre des transactions doit être établi et il doit y avoir un moyen de rejeter les transactions illégales insérées de manière incorrecte (ou malveillante) dans le grand livre. Par exemple, PBFT (Practical Byzantine Fault Tolerance) peut fournir un mécanisme permettant aux copies de fichiers de maintenir la cohérence entre les copies, même en cas de corruption. Ou, dans Bitcoin, trier un processus appelé minage, dans lequel des ordinateurs concurrents s'affrontent pour résoudre un puzzle cryptographique qui définit l'ordre dans lequel tous les processus sont ensuite construits.
    • #### Un consensus est finalement atteint lorsque l'ordre et le résultat des transactions dans un bloc répondent aux critères de vérification explicites des politiques. Ces freins et contrepoids se produisent pendant le cycle de vie d'une transaction et incluent l'utilisation de politiques d'approbation pour spécifier quels membres spécifiques doivent approuver une classe de transaction et le code de chaîne du système pour garantir que ces politiques sont appliquées et maintenues. Avant de s'engager, les nœuds utiliseront ces codes de chaîne système pour s'assurer qu'il existe suffisamment d'approbations et qu'elles proviennent des entités appropriées. De plus, avant que des blocs contenant des transactions ne soient ajoutés au grand livre, il y aura une vérification de contrôle de version au cours de laquelle l'état actuel du grand livre est convenu. Cette vérification finale empêche les opérations de double dépense et autres menaces susceptibles de compromettre l'intégrité des données, et permet d'exécuter des fonctions sur des variables non statiques.
    • #### En plus des nombreuses approbations, vérifications et vérifications de version qui ont lieu, une authentification continue se produit dans toutes les directions du flux de transaction. Les listes de contrôle d'accès sont mises en œuvre au niveau du réseau (services de commande aux canaux) et les charges utiles sont signées, confirmées et vérifiées à plusieurs reprises au fur et à mesure que les propositions de transaction passent par différents composants architecturaux. En résumé, le consensus ne se limite pas à une commande convenue pour un lot de transactions ; il s'agit plutôt d'une caractéristique globale qui est un sous-produit de la vérification continue des transactions au fur et à mesure qu'elles progressent de la proposition à l'approbation.
  • ### Grand livre partagé
    • ####WorldState
      Le composant worldstate décrit l'état du registre à un moment donné. C'est la base de données du grand livre
    • #### Journal des transactions
      Enregistre toutes les transactions qui ont produit la valeur actuelle dans l'état mondial ; il s'agit de l'historique des mises à jour de l'état mondial. Le grand livre comprend ensuite la base de données d'état mondial et l'historique du journal des transactions. Les journaux de transactions n'ont pas besoin d'être enfichables. Il enregistre uniquement les valeurs avant et après la base de données du grand livre utilisée par le réseau blockchain.
    • ####Fonctionnalités Interroger
      et mettre à jour les registres à l'aide de recherches basées sur des clés, de requêtes de plage et de requêtes de clé composite - Requêtes en lecture seule à l'aide du langage de requête enrichi (si vous utilisez CouchDB comme base de données d'état) - Requêtes d'historique en lecture seule (requêtes de registre pour historique des clés) pour prendre en charge les schémas de provenance des données - transactions contenant la version de la clé/valeur lue par le code de chaîne (jeu de lecture) et la clé/valeur écrite par le code de chaîne (jeu d'écriture) - contenant la signature de chaque endosseur, et Transactions soumis au service de commande - Emballé dans des blocs dans l'ordre et "distribué" du service de commande aux nœuds sur le canal - Les nœuds vérifient la transaction conformément à la politique d'approbation et appliquent la politique - Avant d'ajouter le bloc, une vérification de version est effectuée pour s'assurer que l'état de l'actif lu après l'exécution du code blockchain n'a pas changé - Une fois la transaction vérifiée et validée, elle ne peut pas être modifiée - Le registre du canal contient des blocs de configuration qui définissent les politiques, les listes de contrôle d'accès et d'autres informations pertinentes - Le canal contient le fournisseur de services d'adhésion Un exemple de programme qui permet la dérivation de matériel cryptographique à partir de différentes autorités de certification
  • ### Réseau Blockchain
  • Une infrastructure technique qui fournit des services de registre et de contrat intelligent (chaincode) pour les applications

    

    • R4 est désigné comme initiateur du réseau, qui a le pouvoir de définir la version initiale du réseau. R4 n'effectuera aucune transaction commerciale dans le réseau. **R1 et R2 ont besoin d'une communication privée sur l'ensemble du réseau, tout comme R2 et R3.
    • L'organisation R1 dispose d'une application client qui peut effectuer des transactions commerciales dans le canal C1. ** L'organisation R2 a une application cliente qui effectue un travail similaire dans les canaux C1 et C2. L'organisation R3 peut le faire dans le canal C2.
    • Le nœud P1 conserve une copie du registre L1 de C1. Le nœud P2 conserve une copie du registre L1 de C1 et du registre L2 de C2. Le nœud P3 conserve une copie du registre L2 de C2.
    • Ce réseau est géré selon les règles précisées dans la configuration réseau NC4, et l'ensemble du réseau est géré par les organismes R1 et R4. Le canal C1 est géré selon les règles spécifiées dans la configuration de canal CC1, qui est gérée par les organisations R1 et R2. Le canal C2 est géré selon les règles spécifiées dans la configuration du canal CC2, ce canal est géré par les organisations R2 et R3
    • Il existe un service de commande O4 jouant le rôle de noeud administrateur réseau pour ce réseau N et utilisant les canaux système. Le service de commande prend également en charge les canaux applicatifs C1 et C2 pour commander des transactions, les ajouter à des blocs et les distribuer. Chaque organisation a une autorité de certification préférée.
  • ### Créer un réseau

    • 

      
      Dans notre exemple de réseau N, le service de commande 04 est constitué d'un seul nœud configuré selon une configuration de réseau NC4. Au niveau du réseau, l'autorité de certification CA4 est utilisée pour attribuer des informations d'identité aux administrateurs et aux nœuds du réseau de l'organisation R4. *
      Autorité de certification : CA4, elle sera utilisée pour émettre des certificats aux gestionnaires et aux nœuds du réseau
      CA4 joue un rôle important dans notre réseau, car elle distribuera des certificats X.509, qui peuvent être utilisés pour identifier le composant de l'organisation R4. Le certificat émis par l'autorité de certification peut également être utilisé pour fournir une signature pour la transaction afin d'indiquer qu'une organisation approuve le résultat de la transaction. L'approbation est une condition préalable pour qu'une transaction soit acceptée et enregistrée dans le grand livre.
      ​
    • Des administrateurs réseau peuvent être ajoutés

      

      
      Bien que le client O4 s'exécute sur l'infrastructure de R4, il peut partager des privilèges administratifs si R1 peut y accéder. C'est-à-dire que R1 ou R4 peuvent mettre à jour la configuration réseau NC4 pour permettre à R2 d'effectuer certaines fonctions dans la maintenance du réseau. De cette manière, bien que R4 exécute le service de commande, R1 dispose également de droits d'administrateur complets et R2 a des droits limités pour créer de nouvelles fédérations. Les services de commande sont généralement multi-nœuds et peuvent également être configurés sur différents nœuds dans différentes organisations. Par exemple, nous pourrions exécuter O4 dans R4 et nous connecter à O2, qui est un autre ordonnateur dans l'organisation R1. De cette manière, nous avons une structure de gestion multi-nœuds et multi-organisations.
    • définir la coalition

      

      
      L'administrateur réseau définit une fédération X1 à deux membres, composée des organisations R1 et R2. La définition de cette fédération est stockée dans la configuration réseau NC4 et sera utilisée dans le développement ultérieur du réseau. CA1 et CA2 sont les autorités de certification correspondantes pour ces deux organisations. *
      En raison de la configuration de NC4, seuls R1 et R4 peuvent créer de nouvelles fédérations. Cette icône montre une nouvelle fédération X1, qui définit R1 et R2 comme ses organisations fédérées. Nous voyons également que CA2 est également ajouté pour identifier les utilisateurs de R2. Notez qu'une fédération peut contenir n'importe quel nombre d'organisations, ici nous n'incluons que deux organisations comme configuration la plus simple.
      Nous pouvons voir qu'une fédération définit un sous-ensemble d'organisations dans un réseau qui partagent un besoin de pouvoir effectuer des transactions entre elles, dans ce cas R1 et R2 pour pouvoir effectuer des transactions. Cela a du sens pour un groupe d'organisations qui partagent un objectif commun.
    • Créer un canal pour la fédération

      

      • Utilisez le canal C1 créé par la confédération X1 pour R1 et R2. Ce canal est géré via la configuration de canal CC1 et est complètement indépendant de la configuration du réseau. CC1 est géré par R1 et R2, qui ont des droits égaux sur C1. R4 n'a aucun droit sur CC1.
      • Bien que C1 fasse partie du réseau N, il est très différent de ce réseau. Notez également que les organisations R3 et R4 ne sont pas dans ce canal, car ce canal est uniquement destiné au traitement des transactions entre R1 et R2. Dans l'étape précédente, nous avons vu comment R4 a pu attribuer des autorisations à R1 pour créer de nouvelles fédérations. R4 permet également à R1 de créer des canaux. Dans cette figure, les organisations R1 et R4 créent le canal C1. Encore une fois, un canal peut contenir n'importe quel nombre d'organisations, mais nous n'en avons inclus que deux jusqu'à présent, ce qui est la configuration la plus simple.
      • cc1 est une règle de canal, seuls les utilisateurs ajoutés à cc1 peuvent interagir avec le canal c1
      • Une fois qu'un canal est créé, seule l'organisation spécifiée dans la configuration du canal peut le contrôler. Toute modification apportée à NC4 n'affectera pas CC1. Par exemple, si la définition de consortium X1 est modifiée, cela n'affectera pas les membres du canal C1
    • Nœuds et registres

      

      
      Un nœud pair P1 rejoint le canal C1. Physiquement, P1 stockera une copie du registre L1. P1 et O4 peuvent utiliser le canal C1 pour la communication. ​
      • Un nœud homologue est un composant réseau qui stocke une copie du registre de la blockchain.
        Un élément clé de la configuration de P1 est une information d'identité X.509 émise par CA1, qui associe P1 à l'organisation R1. Lorsque P1 démarre, il peut rejoindre le canal C1 en utilisant la séquence O4. Lorsque O4 reçoit cette demande d'adhésion, il utilise la configuration de canal CC1 pour déterminer les autorisations de P1 dans ce canal. Par exemple, CC1 décide si P1 peut lire ou écrire des informations dans le grand livre L1.
    • Application et code de chaîne de contrat intelligent

      

      
      Le contrat intelligent S5 est installé sur P1. L'application cliente A1 dans l'organisation R1 peut utiliser S5 pour accéder au grand livre via le nœud homologue P1. A1, P1 et O4 sont tous reliés au canal C1, et ils peuvent tous utiliser les facilités de communication fournies par ce canal.
      • Dans notre exemple, l'application cliente A1 est associée à l'organisation R1, et bien qu'elle soit en dehors du réseau blockchain Fabric, elle peut être connectée au réseau via le canal C1.
      • L'application cliente A1 doit obtenir le registre L1 via le contrat intelligent S5.
      • Considérez les contrats intelligents comme la gestion des transactions, et le code de chaîne gère la façon dont les contrats intelligents doivent être emballés et déployés
      • Définir le code de chaîne
        Le code de chaîne sera installé sur le nœud homologue de l'organisation. Une organisation doit approuver une définition de code de chaîne avant de pouvoir utiliser le contrat intelligent installé pour interroger le grand livre et approuver la transaction.
      • Politique d'approbation
      • appeler un contrat intelligent
    • réseau complet

      

      
      Ce réseau a été agrandi par l'ajout de l'infrastructure de la nouvelle organisation R2. Plus précisément, R2 ajoute le nœud homologue P2, qui stockera une copie du registre L1, et le code blockchain S5. R2 a approuvé la même définition de code blockchain que R1. P2 rejoint également le canal C1, qui possède également une application client A2. A2 et P2 utilisent un certificat émis par CA2 pour identifier A2 et P2. Tout cela montre que A1 et A2 peuvent utiliser le nœud pair P1 ou P2 pour appeler S5 sur C1
    • type de nœud homologue
      • taper
        • *nœud de validation*. Chaque nœud homologue du canal est un nœud de soumission. Ils recevront les blocs générés, et une fois ces blocs vérifiés, ils seront en outre soumis à la copie du registre du nœud pair.
        • *nœud d'approbation*. Chaque nœud homologue avec un contrat intelligent installé * peut * agir comme un nœud d'approbation. Cependant, pour *devenir* un véritable nœud d'approbation, le contrat intelligent sur le nœud doit être utilisé par l'application cliente pour générer une réponse de transaction signée.
      • Rôle
        • Nœud maître : lorsque l'organisation a plusieurs nœuds homologues dans le canal, il y aura un nœud maître, qui est responsable de la distribution des transactions du nœud de tri aux autres nœuds de retrait de l'organisation.
          • Nœuds maîtres sélectionnés statiquement : 0 ou plusieurs nœuds peuvent être configurés en tant que nœuds maîtres
          • Nœud maître élu dynamiquement : un nœud sera élu comme nœud maître. Si un nœud maître échoue, les nœuds restants rééliront un nœud maître.
        • Nœuds d'ancrage : communication interorganisationnelle
      • Il n'y a qu'un seul canal, et il n'y a qu'un seul grand livre logique qui interagit avec ce composant de canal. Les nœuds homologues P1 et P2 ont la même copie du registre L1
    • Service de tri
      Un composant qui collecte les transactions approuvées des applications, puis il trie ces transactions en blocs, et ces blocs sont distribués à chaque nœud homologue du canal. À chacun de ces nœuds de validation, la transaction est enregistrée, qu'elle soit valide ou invalide, et leur copie locale du registre est mise à jour.
    • Distribution décentralisée des transactions : plusieurs points de commande
    • modifier la politique
    • réseau entièrement formé

      

      
      Sur cette figure, on voit que le réseau blockchain Fabric comprend deux canaux applicatifs et un canal de tri. Les organisations R1 et R4 sont responsables de la voie de séquençage, R1 et R2 sont responsables de la voie d'application bleue et R2 et R3 sont responsables de la voie d'application rouge. L'application cliente A1 est un élément de l'organisation R1 et CA1 est son autorité de certification. A noter que le nœud P2 de l'organisation R2 peut utiliser le moyen de communication en bleu et le canal d'application en rouge. Chaque canal d'application a sa propre configuration de canal, ici CC1 et CC2. La configuration des canaux des canaux du système fait partie de la configuration du réseau NC4.
  • Identité : chaque participant (un élément actif pouvant utiliser des services à l'intérieur ou à l'extérieur du réseau) possède une identité numérique encapsulée dans un certificat numérique X.509* qui détermine l'autorité exacte sur la ressource et la propriété du participant dans l'accès du réseau blockchain à l'information .
    • corps principal
    • L'identité peut être vérifiée, elle doit provenir d'une autorité de confiance. Le fournisseur de services d'adhésion (Membership Service Provider, MSP) est une autorité de confiance dans Fabric. Un MSP est le composant qui définit les règles régissant l'identité effective de l'organisation. L'implémentation MSP par défaut dans Fabric utilise des certificats X.509 comme identités, en utilisant un modèle en couches d'infrastructure à clé publique (PKI) traditionnel (plus d'informations sur PKI plus tard)
  • PKI et MSP fonctionnent ensemble de la même manière, PKI fournit une liste d'identités et MSP indique quels sont les membres d'une organisation donnée participant au réseau
    • PKI est comme un fournisseur de cartes qui attribue de nombreux types différents d'identités vérifiables, et est un ensemble de technologies Internet qui fournissent une communication sécurisée au sein d'un réseau

      

      
      Éléments d'une infrastructure à clé publique (PKI). Une PKI est constituée d'autorités de certification qui délivrent des certificats numériques à différentes parties (par exemple, utilisateurs d'un service, fournisseurs de services), puis les utilisent pour s'authentifier dans les messages échangés avec leur environnement. La liste de révocation de certificats (CRL) d'une autorité de certification constitue une référence aux certificats qui ne sont plus valides. La révocation des certificats peut se produire pour un certain nombre de raisons. Par exemple, un certificat peut être révoqué parce que le matériel cryptographiquement privé associé au certificat a été rendu public.
      • Certificats numériques, tels que X.509
      • clé publique et clé privée
        • Les mécanismes d'authentification traditionnels reposent sur des signatures numériques
        • Techniquement, un mécanisme de signature numérique nécessite que chaque partie détienne deux clés pour une connexion cryptée : une clé publique largement disponible et une clé privée qui agit comme une ancre pour l'autorisation, et une clé privée qui est utilisée pour produire une signature numérique sur un message. . Le destinataire d'un message signé numériquement peut vérifier l'origine et l'intégrité du message reçu en vérifiant que la signature supplémentaire est valide sous la clé publique de l'expéditeur prévu.
      • Autorité de certification CA
        • CA racine, CA intermédiaire et
          CA de chaîne de confiance Il existe deux formes : CA racine et CA intermédiaire. Parce que les CA racines (Symantec, Geotrust, etc.) doivent délivrer en toute sécurité des centaines de millions de certificats aux internautes, il est utile de décentraliser ce processus vers des CA dites intermédiaires. Ces AC intermédiaires disposent de certificats délivrés par l'AC racine ou d'autres AC intermédiaires, ce qui permet d'établir une « chaîne de confiance » pour tout certificat délivré par n'importe quelle AC de la chaîne. La possibilité de remonter jusqu'à l'autorité de certification racine permet non seulement d'étendre les capacités de l'autorité de certification tout en assurant la sécurité (permettant aux organisations utilisant des certificats d'utiliser des autorités de certification intermédiaires en toute confiance), mais limite également l'exposition de l'autorité de certification racine, qui, s'il est compromis, l'ensemble de la chaîne de confiance est compromis. En revanche, si le CA intermédiaire est compromis, l'exposition sera beaucoup plus faible.
        • Fabric CA : Fabric fournit un composant CA intégré qui permet la création de CA dans votre réseau blockchain
      • Liste de révocation de certificats
        Utilise une CRL pour vérifier si un certificat est toujours valide. Si un imitateur tente de transmettre un certificat numérique non valide à un vérificateur, il peut d'abord vérifier la CRL de l'autorité de certification émettrice pour s'assurer qu'elle n'est pas répertoriée comme non valide.
    • Le MSP est similaire à la liste des fournisseurs de cartes acceptés par le magasin, déterminant quelles identités sont des membres de confiance (participants) du réseau de paiement du magasin. Les MSP transforment des identités vérifiables en membres de réseaux blockchain.

      

      
      Une pièce d'identité est comme votre carte de crédit, utilisée pour prouver que vous pouvez payer. MSP est similaire à une liste de cartes de crédit acceptées.
    • Domaine MSP
      • localement au niveau du nœud participant (local MSP)
        • Défini pour les clients et les nœuds qui permettent aux utilisateurs de se vérifier dans leurs transactions en tant que membre d'un canal (comme dans une transaction de code blockchain) ou en tant que propriétaire d'un rôle spécifique dans le système (comme un administrateur d'organisation dans une transaction de configuration) .
        • Chaque nœud doit définir un MSP local, car il définit qui a des droits d'administration ou de participation à ce niveau, l'organisation, les administrateurs de l'organisation, les administrateurs du nœud et le nœud lui-même doivent tous avoir la même racine de confiance
        • Il existe également des nœuds de tri, qui sont utilisés pour vérifier les participants, les nœuds
      • Dans la configuration du canal (canal MSP) : définir les droits de gestion et de participation au niveau du canal

        

        
        Un fragment d'une configuration de canal. json, qui comprend deux MSP organisationnels.
        • Les MSP de canal déterminent qui a autorité au niveau du canal. Le canal MSP définit les membres du canal, et le canal MSP est également instancié sur le système de fichiers de chaque nœud du canal, et est maintenu synchronisé par consensus
        • Les MSP locaux sont définis uniquement sur le système de fichiers du nœud ou de l'utilisateur auquel ils sont appliqués
        • Chaque nœud a une copie de chaque MSP de canal sur son système de fichiers local, comment les MSP locaux et les MSP de canal coexistent dans le réseau :
        • Le champ OU du certificat spécifie l'unité commerciale à laquelle appartient l'identité.
          • Comment les rôles et ou sont représentés dans les certificats :
          • node ou
            Dans l'exemple ci-dessus, MSP a 4 rôles possibles de node OU :: Client, Peer, Admin, Issuing Candidate
          • Remarque : Pour les MSP de canal, le simple fait qu'un participant ait un rôle d'administrateur ne signifie pas qu'il peut gérer une ressource spécifique. La capacité réelle d'une identité donnée à gérer le système est déterminée par la politique de gestion des ressources du système
          • Différentes organisations d'un consortium peuvent utiliser ou pour se distinguer. Mais dans ce cas, différentes organisations doivent utiliser la même autorité de certification racine et intermédiaire pour leur chaîne de confiance, et attribuer le champ OU pour identifier les membres de chaque organisation. Cela rend le système plus centralisé que prévu lorsque chaque organisation a la même autorité de certification ou chaîne de confiance
        • Le dossier MSP local contient les sous-dossiers suivants :
          • config.yaml : configurez les fonctionnalités de classification des identités dans Fabric en activant le nœud "Node OUs" et en définissant des rôles acceptables
          • cacerts : ce dossier contient une liste de certificats X.509 auto-signés pour les cas racine approuvés par l'organisation représentée par ce MSP. Il doit y avoir au moins un certificat CA racine dans ce dossier MSP. Il s'agit du dossier le plus important car il identifie les autorités de certification à partir desquelles tous les autres certificats doivent être dérivés pour être considérés comme des membres de l'organisation respective afin de former une chaîne de confiance.
          • middlecerts : ce dossier contient une liste de certificats X.509 pour les autorités de certification intermédiaires approuvées par cette organisation. Chaque certificat doit être signé par l'une des autorités de certification racine du MSP ou toute autre autorité de certification intermédiaire émettant une chaîne d'autorités de certification menant éventuellement à des autorités de certification racine de confiance. Les autorités de certification intermédiaires peuvent être utilisées pour représenter les subdivisions d'une organisation.
            • Notez qu'il est possible d'avoir un réseau fonctionnel sans autorité de certification intermédiaire, auquel cas ce dossier sera vide.
            • Comme le dossier CA racine, ce dossier définit l'autorité de certification à partir de laquelle le certificat doit être émis afin d'être considéré comme membre de l'organisation
          • admincerts (obsolète depuis Fabric v1.4.3 et versions ultérieures) : ce dossier contient une liste d'identités qui définissent les participants avec le rôle d'administrateur pour cette organisation. Généralement, il doit y avoir un ou plusieurs certificats X.509. Il est recommandé d'utiliser le rôle admin pour spécifier l'administrateur du nœud lorsque l'utilisateur s'enregistre auprès de l'autorité de certification. Cette identité est ensuite identifiée comme admin par la valeur du rôle Node OU dans son signcert. Pour rappel, afin de profiter des rôles administratifs, la fonctionnalité "classification des identités" doit être activée dans la configuration. En définissant "node ou" sur Enable : true
          • keystore : (clé privée) : ce dossier est défini pour le MSP local du nœud d'homologue ou de commande (ou dans le MSP local du client) et contient la clé privée du nœud. Cette clé est utilisée pour signer les données
            • La configuration du canal MSP n'inclut pas ce dossier, car le canal MSP est uniquement destiné à fournir des fonctions d'authentification, pas des fonctions de signature
            • Si vous utilisez HSM (Hardware Security Module) pour la gestion des clés, ce dossier est vide car la clé privée est générée par HSM et stockée dans HSM
          • signcert : contient un certificat émis par l'autorité de certification du nœud, qui peut être utilisé pour générer une signature vérifiée par toute personne disposant d'une copie de ce certificat. Ce dossier est requis pour les MSP locaux et doit contenir une clé publique.
            • L'accès à ce dossier doit être limité aux utilisateurs ayant la responsabilité administrative de l'homologue.
            • La configuration du canal MSP n'inclut pas ce dossier, car le canal MSP est uniquement destiné à fournir des fonctions d'authentification, pas des fonctions de signature
          • tlscacerts : ce dossier contient une liste de certificats X.509 autosignés d'autorités de certification racine approuvées par l'organisation pour une communication sécurisée entre les nœuds à l'aide de TLS. Les messages MSP TLS impliquent des nœuds à l'intérieur du réseau
          • tlsintermediatecacerts : ce dossier contient une liste de certificats d'autorité de certification intermédiaires approuvés par l'organisation représentée par le MSP pour une communication sécurisée entre les nœuds à l'aide de TLS.
          • operationscerts : ce dossier contient les certificats requis pour communiquer avec l'API Fabric Operations Service
        • Channel MSP comprend en outre :
          • Certificats révoqués : si l'identité de l'auteur a été révoquée, les informations d'identification sur cette identité - mais pas l'identité elle-même - sont conservées dans ce dossier. Pour les identités basées sur x.509, ces identifiants sont une paire de chaînes appelées un identifiant de clé de sujet (SKI) et un identifiant d'accès à l'autorité (AKI) qui sont vérifiés chaque fois qu'un certificat est utilisé pour s'assurer que le certificat n'est pas révoqué
  • Stratégie:

    

    • Configuration du canal système : Chaque réseau commence par un canal système de service de commande. Il doit y avoir au moins un canal du système de commande du service de commande dans le réseau, qui est le premier canal à créer. Le canal contient également qui est membre du service de commande (organisation de service de commande) et qui effectue des transactions dans le réseau (organisation de la confédération). Les politiques du bloc de configuration du canal du système de commande régissent le consensus utilisé par le service de commande et définissent la façon dont les nouveaux blocs sont créés. Les canaux système déterminent également quels membres du consortium peuvent créer de nouveaux canaux.
    • Configuration du canal d'application : les canaux d'application sont utilisés pour fournir un mécanisme de communication privé entre les organisations de la fédération. Les stratégies des canaux d'application régissent la possibilité d'ajouter et de supprimer des membres du canal. Les canaux d'application régissent également le consentement organisationnel requis avant que les codes blockchain ne soient définis et validés sur le canal à l'aide du cycle de vie du code blockchain Fabric. Lors de la création initiale du canal système, il hérite par défaut de tous les paramètres de service de commande du canal système de commande. Dans le même temps, ces paramètres (y compris les politiques qui les régissent) peuvent être personnalisés par canal.
    • Liste de contrôle d'accès (ACL)
    • portée de la politique
    • Politique d'approbation des contrats intelligents
    • stratégie de mise à jour
    • Comment écrire des politiques dans le tissu
      • Stratégie de signature : prise en charge du tri et de plusieurs relations logiques
      • Politique ImplicitMeta : efficace dans la configuration du canal basée sur l'arborescence des politiques construite de manière hiérarchique
        • La méta-politique implicite agrège les résultats de l'arborescence de configuration profonde finalement définie par la politique de signature. Ils sont cachés car ils sont construits implicitement sur la base de l'organisation actuelle dans la configuration du canal, et ce sont des méta-informations car leur évaluation ne dépend pas d'une spécification MSP spécifique, mais de leurs autres sous-stratégies dans l'arborescence de configuration.
        • Respecter le principe d'ouverture et de fermeture
        • NodeOUs pour plus de granularité et de contrôle
      • Exemple d'utilisation de la stratégie de signature
      • Exemples d'utilisation d'implimeta
      • cycle de vie
  • Nœud : maintenir le registre et le code de chaîne

    

    
    La redondance est intentionnellement fournie dans les réseaux de fabric car elle évite les points de défaillance uniques
    • 
      Le réseau blockchain est composé de nœuds Peer, et chaque nœud conserve une copie du registre et du contrat intelligent. Dans cet exemple, le réseau N est composé de nœuds P1, P2 et P3, dont chacun maintient son propre registre distribué L1. P1, P2 et P3 utilisent le même code blockchain S1 pour accéder à leurs copies du grand livre distribué. Plusieurs registres et codes de chaîne peuvent être maintenus
    • Applications et nœuds homologues : lorsque les applications doivent accéder aux registres et aux codes de chaîne, elles doivent toujours se connecter aux nœuds homologues. En se connectant aux nœuds homologues, les applications peuvent exécuter des codes de chaîne pour interroger ou mettre à jour les registres. Le résultat de l'interrogation du grand livre renverra immédiatement
      le nœud homologue et le nœud de tri, garantissant que le grand livre a le dernier grand livre sur chaque nœud homologue. Dans cet exemple, l'application A se connecte à P1 et appelle le code blockchain S1 pour interroger ou mettre à jour le registre L1. P1 appelle le code blockchain S1 pour générer une réponse de proposition, qui contient des résultats de requête ou des propositions de mises à jour du grand livre. L'application A reçoit la réponse à la proposition et, pour les requêtes, le flux se termine ici. Pour les mises à jour, l'application A crée une transaction à partir de toutes les réponses, qu'elle envoie au donneur d'ordre O1 pour commande. O1 collectera les transactions dans le réseau et les regroupera en blocs, puis distribuera ces blocs à tous les nœuds homologues, y compris P1. P1 valide la transaction avant de la valider dans le grand livre L1. Lorsque L1 est mis à jour, P1 générera un événement, qui sera reçu par A pour marquer la fin du processus.
      • Un nœud homologue indépendant est actuellement incapable de mettre à jour le grand livre, car les autres nœuds homologues doivent d'abord accepter la modification (c'est-à-dire parvenir à un consensus), et le nœud homologue renverra une proposition de mise à jour à l'application, et le nœud homologue sera basé sur le protocole précédent d'un autre nœud pour appliquer cette mise à jour
    • Nœuds et canaux homologues
      Les canaux permettent à des nœuds et applications homologues spécifiques du réseau blockchain d'interagir les uns avec les autres. Dans cet exemple, l'application A peut communiquer directement avec les nœuds pairs P1 et P2 en utilisant le canal C. Vous pouvez considérer un canal comme un chemin de communication entre une application et un nœud homologue. (L'ordonnanceur n'est pas représenté dans ce schéma, mais il doit exister dans un réseau opérationnel.)
    • Nœuds et organisations homologues : il n'y a pas de ressources centralisées ici. Si ces organisations n'apportent pas leurs nœuds, le réseau N n'existera pas. À moins que et jusqu'à ce que les organisations apportent leurs ressources, un tel réseau ne sera pas formé. Sinon, ce réseau ne sera pas Le sens de l'existence
    • Nœud pair et identité : chaque nœud pair du réseau se verra attribuer un certificat numérique par l'administrateur de l'organisation à laquelle il appartient.
      Lorsqu'un nœud pair se connecte à un canal, son certificat numérique identifiera son organisation via le canal MSP. Dans cet exemple, P1 et P2 ont des identités émises par CA1. Le canal C détermine par le biais de politiques dans sa configuration de canal que les identités de CA1 doivent être associées à Org1 à l'aide de ORG1.MSP. De même, P3 et P4 sont reconnus par ORG2.MSP comme faisant partie de Org2.
    • Pairs et donneurs d'ordre : les applications qui mettent à jour les registres sont introduites dans un processus en trois étapes
      • Dans la première phase, l'application fonctionne avec un sous-ensemble de nœuds d'approbation, chacun d'entre eux approuvant la mise à jour du grand livre proposée pour l'application, mais n'appliquant pas la mise à jour proposée à leur copie du grand livre.
      • Dans la deuxième phase, ces endossements dispersés seront rassemblés et regroupés en blocs sous forme de transactions.
      • Dans la dernière étape, ces blocs sont redistribués à chaque nœud pair, où chaque transaction est vérifiée avant d'être appliquée à la copie du registre du nœud pair.
      • Phase 1 : Proposition : L'application génère une proposition de transaction, qu'elle envoie à une série de nœuds requis pour approbation. Chacun des nœuds d'approbation utilisera alors indépendamment la proposition de transaction pour exécuter le code de chaîne afin de générer une réponse à la proposition de transaction, et le résultat de la réponse sera renvoyé à l'application. La proposition de transaction sera exécutée indépendamment par le nœud homologue, et le nœud homologue renverra
        la réponse de la proposition pour approbation. Dans cet exemple, l'application A1 génère la transaction T1 et la proposition P, et l'application enverra la transaction et la proposition au nœud homologue P1 et au nœud homologue P2 sur le canal C. P1 exécute le code blockchain S1 avec la transaction T1 et la proposition P, qui génère une réponse R1 à la transaction T1, qui fournit une approbation E1. P2 exécute le code blockchain S1 avec la proposition de transaction T1 P, qui génère une réponse R2 à la transaction T1, qui fournit une approbation E2. L'application A1 reçoit deux réponses d'approbation, appelées E1 et E2, pour la transaction T1.
        • L'application sélectionne le nœud homologue à mettre à jour conformément à la règle d'approbation. Le nœud homologue fournit l'approbation en ajoutant sa propre signature numérique à la réponse de la proposition et utilise sa clé privée pour fournir une signature pour l'ensemble du chargement. Cette approbation est ensuite utilisée pour prouver que le pair de l'organisation a généré une réponse particulière
        • Une application peut demander une réponse de proposition mise à jour. Peu probable mais très grave, la différence de résultats pourrait être due au fait que le code blockchain est non déterministe et qu'un pair individuel ne peut pas savoir que le résultat de ses transactions est non déterministe - jusqu'à ce que le problème non déterministe soit découvert, les réponses de transaction doivent être collectées ensemble en comparaison
      • Phase 2 : Trier et regrouper les transactions en blocs
      • La troisième étape : vérification et soumission
        Le deuxième rôle du nœud de commande est de distribuer le bloc au nœud Peer. Dans cet exemple, le nœud de commande O1 a distribué le bloc B2 au nœud homologue P1 et au nœud homologue P2. Le pair P1 traite le bloc B2, produisant un nouveau bloc qui sera ajouté au registre L1 de P1. Pendant ce temps, le pair P2 traite le bloc B2, produisant un nouveau bloc qui sera ajouté au registre L1 de P2. Une fois ce processus terminé, le grand livre L1 sera mis à jour de manière cohérente vers les nœuds homologues P1 et P2, et ils peuvent également informer les applications connectées que la transaction a été traitée.
        ​
        • Le code de chaîne n'est exécuté que dans la première phase - le secret est garanti, mais la sortie est partagée avec tous les nœuds
      • Nœuds de commande et consensus : l'ensemble du processus de traitement des transactions est appelé consensus
  • Grand livre : stocke des informations factuelles importantes sur les objets métier, y compris les valeurs actuelles des propriétés de l'objet et l'historique des transactions qui ont produit ces valeurs actuelles
    • Registre, faits et état :
      • Registre:
        • L'état mondial est une base de données qui stocke la valeur actuelle d'un ensemble d'états du grand livre. Grâce à l'état mondial, le programme peut accéder directement à la valeur actuelle d'un état du grand livre sans parcourir l'intégralité du journal des transactions pour calculer la valeur actuelle. Par défaut, l'état du registre est représenté par des paires clé-valeur, qui peuvent être créées, mises à jour et supprimées, de sorte que l'état du monde peut changer fréquemment.
        • Une blockchain est un journal des transactions qui enregistre tous les changements qui ont contribué à l'état actuel du monde. L'histoire qui nous aide à comprendre tous les changements qui ont contribué à l'état actuel du monde ne peut être altérée.

          

          
          Le grand livre L se compose de la blockchain B et de l'état mondial W, où l'état mondial W est déterminé par la blockchain B. On peut aussi dire que l'état mondial W est dérivé de la blockchain B.
      • État mondial : seules les transactions signées par les organisations d'approbation pertinentes mettront à jour l'état mondial, la possibilité de changement en temps réel.

        

        
        Un état mondial du grand livre se compose de deux états. Le premier état est : clé=CAR1 et valeur=Audi. Dans le deuxième état, il y a une valeur plus complexe : key=CAR2 et value={model:BMW, color=red, owner=Jane}. Les deux versions d'état sont 0.
      • Blockchain : un journal sérialisé d'une collection de blocs liés, où chaque bloc contient une série de transactions, chaque transaction représentant une requête ou une opération de mise à jour sur l'état du monde. L'en-tête de chaque bloc contient un hachage des transactions du bloc, ainsi que le hachage de l'en-tête du bloc précédent. Toutes les transactions sur le bloc-notes sont séquencées et liées cryptographiquement. Ce hachage et cette liaison rendent les données du grand livre très sécurisées.

        

        
        La blockchain B comprend quatre blocs B0, B1, B2 et B3. B0 est le premier bloc de la blockchain, également appelé bloc de genèse.
        Dans la figure ci-dessus, nous pouvons voir que le bloc B2 a un bloc de données D2, qui contient toutes les transactions de B2 : T5, T6, T7.
      • bloc
        • en-tête de bloc

          

          
          Détails de l'en-tête de bloc : l'en-tête de bloc H2 du bloc B2 comprend le numéro de bloc 2, la valeur de hachage CH2 des données de bloc actuelles D2 et la valeur de hachage de l'en-tête de bloc précédent H1.
        • Numéro de bloc : Le numéro commence à partir de 0 (bloc initial), et chaque fois qu'un nouveau bloc est ajouté à la blockchain, le numéro du numéro augmentera de 1.
        • Hachage du bloc courant : le hachage de toutes les transactions contenues dans le bloc courant.
        • Hachage de l'en-tête de bloc précédent : hachage de l'en-tête de bloc précédent dans la blockchain.
        • La section de données de bloc contient une liste ordonnée de transactions. Les données de bloc sont écrites lorsque le service de commande crée des blocs.
        • La section des métadonnées du bloc contient l'heure à laquelle le bloc a été écrit, ainsi que le certificat, la clé publique et la signature de l'auteur du bloc. L'émetteur du bloc ajoute alors également un indicateur valide ou invalide à chaque transaction, mais comme cette information est générée en même temps que le bloc, elle n'est pas incluse dans le hachage.
      • Transaction : la transaction enregistre la mise à jour de l'état du monde et est stockée dans les données du bloc dans le bloc

        

        
        La transaction T4 se trouve dans les données de bloc D1 du bloc B1.T4 comprend le contenu suivant : en-tête de transaction H4, une signature de transaction S4, une proposition de transaction P4, une réponse de transaction R4 et une série d'endossements E4.
        • L'en-tête est désigné par H4, qui enregistre certaines métadonnées importantes sur la transaction, telles que le nom et la version du code blockchain pertinent.
        • La section de signature, notée S4, contient une signature cryptographique créée par l'application cliente. Ce champ permet de vérifier que les détails de la transaction n'ont pas été falsifiés, car la génération de la signature de la transaction nécessite la clé privée de l'application.
        • La partie proposition, notée P4, est responsable de l'encodage des paramètres d'entrée que l'application fournit au contrat intelligent, qui génère ensuite des mises à jour du registre des propositions. Lorsque le contrat intelligent est en cours d'exécution, cette proposition fournit un ensemble de paramètres d'entrée qui, avec l'état mondial actuel, déterminent le nouvel état mondial du grand livre.
        • La partie de la réponse est désignée par R4, qui enregistre les valeurs avant et après l'état du monde sous la forme d'un ensemble de lecture-écriture (RW-set). La réponse de la transaction est la sortie du contrat intelligent. Si la vérification de la transaction réussit, la transaction sera appliquée au grand livre, mettant ainsi à jour l'état du monde.
        • Comme indiqué dans l'endossement E4, il fait référence à un ensemble de réponses de transaction signées, ces signatures proviennent des organisations concernées spécifiées dans la politique d'endossement, et le nombre de ces organisations doit répondre aux exigences de la politique d'endossement.
      • Options de base de données d'état mondial : y compris LevelDB et CouchDB - enfichable
        • LevelDB est l'option par défaut pour la base de données d'état mondiale, et il est très approprié d'utiliser LevelDB lorsque l'état du grand livre est une simple paire clé-valeur. La base de données LevelDB est colocalisée avec le nœud homologue et elle est intégrée dans le même processus de système d'exploitation que le nœud homologue.
        • CouchDB : la structure d'état du grand livre est un document JSON, et les types de données impliqués dans les transactions commerciales sont généralement très riches, et CouchDB peut prendre en charge diverses formes de requête et de mise à jour pour ces types de données. En termes d'implémentation, CouchDB s'exécute dans un processus de système d'exploitation distinct, mais il existe toujours une relation 1:1 entre les nœuds et les instances de CouchDB. Les contrats intelligents ne peuvent voir aucun des éléments ci-dessus.
      • Exemple de fabcar de grand livre

        

        
        Le grand livre L contient un état mondial W et une blockchain B. Parmi eux, W contient quatre états, et les clés de chaque état sont : CAR0, CAR1, CAR2 et CAR3. Et B contient deux blocs 0 et 1. Le bloc 1 contient quatre transactions : T1, T2, T3, T4.
      • Espaces de noms
        • Chaque code blockchain a son propre état mondial qui est distinct de l'état mondial de tous les autres codes blockchain. L'état mondial réside dans un espace de noms, de sorte que seuls les contrats intelligents qui résident dans le même code blockchain peuvent accéder à un espace de noms donné.
      • Canaux : chaque canal a un registre complètement indépendant
  • service de tri
    • Configuration de l'ordonnateur et du canal : les ordonnateurs maintiennent également une liste des organisations autorisées à créer des canaux - les fédérations. La table elle-même est conservée dans la configuration du "canal du système de commande" (également appelé "canal du système de commande"), cette liste et le canal dans lequel elle réside ne peuvent être modifiés que par l'administrateur de la commande
    • Nœud de commande et identité (MSP) : le nœud de commande appartient à l'organisation et utilise une autorité de certification (CA) distincte pour chaque organisation.
    • Nœuds de commande et flux de transaction
      • Phase 1 : Proposition
      • Phase 2 : Commandez et regroupez les transactions en blocs

        

        
        Le premier rôle d'un responsable de la commande est de regrouper les mises à jour du grand livre pour les propositions. Dans cet exemple, l'application A1 envoie la transaction T1 au donneur d'ordre O1, endossé par E1 et E2. Dans le même temps, l'application A2 envoie la transaction T2 endossée par E1 au donneur d'ordre O1. O1 regroupe la transaction T1 de l'application A1 et la transaction T2 de l'application A2, ainsi que les transactions d'autres applications du réseau, dans le bloc B2. On peut voir qu'en B2, l'ordre des transactions est T1, T2, T3, T4, T6, T5, mais ce n'est peut-être pas l'ordre dans lequel ces transactions sont arrivées chez le donneur d'ordre ! (Cet exemple montre une configuration de service de commande très simple avec un seul donneur d'ordre.)
        • Le nombre de transactions dans un bloc dépend de la taille souhaitée du bloc et des paramètres de configuration du canal liés au temps d'intervalle maximal (pour être exact, les paramètres BatchSize et BatchTimeout)
        • Les blocs générés par le service de commande sont définitifs, et la finalité d'Hyperledger Fabric signifie qu'il n'y a pas de fourches de grand livre, c'est-à-dire que les transactions vérifiées ne sont jamais réécrites ou supprimées.
        • Le nœud de commande ne fait que trier, aucune transaction n'a lieu
      • Phase 3 : Vérification et soumission : tous les nœuds homologues n'ont pas besoin d'être connectés à un nœud de commande. Les nœuds homologues peuvent utiliser le protocole de commérage pour associer des blocs à d'autres nœuds.

        

        
        Le deuxième rôle des nœuds de commande est de distribuer des blocs aux nœuds homologues. Dans cet exemple, le donneur d'ordre O1 distribue le bloc B2 aux nœuds P1 et P2. Le nœud P1 traite le bloc B2, en ajoutant un nouveau bloc au registre L1 sur P1. Dans le même temps, le nœud P2 traite le bloc B2, ajoutant ainsi un nouveau bloc au registre L1 sur P2. Une fois ce processus terminé, le registre L1 sur les nœuds P1 et P2 est constamment mis à jour, et chaque nœud peut informer les applications connectées qu'une transaction a été traitée.
        • L'approbation du nœud correspond à la politique d'approbation et n'est pas invalidée par d'autres transactions récemment validées qui peuvent être en cours d'exécution lorsque la transaction a été initialement approuvée. Les transactions invalides restent toujours dans les blocs créés par le donneur d'ordre, mais le nœud les marque comme invalides et ne met pas à jour l'état du registre.
      • Mise en place du service de tri
        • Raft (recommandé) : en tant que nouvelle fonctionnalité de la v1.4.1, Raft est un service de tri Crash Fault Tolerant (CFT) basé sur le protocole Raft dans [etcd](https://coreos.com/etcd/) . Raft suit un modèle "leader-suiveur", dans lequel un nœud leader est élu sur chaque canal, dont les décisions sont reproduites par les suiveurs. Le service de commande Raft sera plus facile à configurer et à gérer que le service de commande basé sur Kafka, et sa conception permet à différentes organisations de contribuer des nœuds au service de commande distribué.
          • Tolérance aux crashs : le système peut tolérer la perte de nœuds, y compris le nœud leader, à condition qu'il reste un grand nombre de commandes (appelé "quorum")
          • Raft est plus facile à configurer, supporté nativement, et avec Raft, tout est intégré dans votre commande.
          • Kafka et Zookeeper ne sont pas conçus pour fonctionner sur un grand réseau, vous devez obtenir vous-même la mise en miroir requise, Kafka utilise un pool de serveurs
          • Notion de radeau
            • Entrée de journal : l'unité principale de travail dans un service de commande de radeau est une « entrée de journal », et la séquence complète d'entrées est appelée un « journal ». Si une majorité de membres (en d'autres termes un quorum) s'accorde sur l'entrée et son ordre, alors nous considérons que l'entrée est cohérente et reproduisons le journal à différents ordonnateurs
            • Ensemble de consentement : Ordonnateurs qui participent activement au mécanisme de consensus pour un canal donné et reçoivent une copie du journal du canal.
            • Machine à états finis (FSM). Chaque commande dans Raft a un FSM qui, ensemble, garantit que la séquence de journaux dans chaque commande est déterministe (écrite dans le même ordre).
            • Quorum. Décrit le nombre minimum d'accordeurs qui doivent confirmer une proposition.
            • Chef
            • Disciple
          • Raft dans le flux de transactions : les créateurs de canaux (et les gestionnaires de canaux) peuvent sélectionner un sous-ensemble de commandes disponibles et ajouter ou supprimer des commandes selon les besoins (tant qu'un seul nœud est ajouté ou supprimé à la fois). Ni les nœuds eer ni les applications n'ont besoin de savoir qui est le nœud leader à un moment donné. Seul le donneur d'ordre a besoin de savoir.
          • Comment Raft élit un leader : un nœud est toujours dans l'un des trois états suivants : suiveur, candidat ou leader. Tous les nœuds commencent initialement en tant qu'abonnés. Dans cet état, ils peuvent accepter les entrées de journal du chef (s'il a déjà été élu) ou voter pour le chef. Si aucune entrée de journal ou aucune pulsation n'est reçue pendant une certaine période de temps (par exemple, 5 secondes), le nœud se promeut à l'état candidat. Dans l'état candidat, les nœuds demandent des votes aux autres nœuds. Si un candidat obtient le quorum de voix, il est promu chef. Le leader doit accepter les nouvelles entrées de journal et les répliquer aux suiveurs.
          • Instantanés : Raft utilise un processus appelé "instantanés" dans lequel l'utilisateur définit le nombre d'octets de données à conserver dans le journal. Cette quantité de données déterminera le nombre de blocs (cela dépend de la quantité de données dans le bloc. Notez que seuls les blocs complets sont stockés dans l'instantané).
            Supposons que le réplica retardé R1 vient de se reconnecter au réseau. Son dernier bloc est 100. Le leader L est au bloc 196 et est configuré pour capturer 20 blocs. R1 recevra ainsi le bloc 180 de L, puis répartira les requêtes pour les blocs 101 à 180. Ensuite, les blocs 180 à 196 seront répliqués sur R1 via le protocole Raft normal.
        • Kafka (obsolète dans la v2.0) : similaire au tri basé sur Raft, Apache Kafka est une implémentation CFT qui utilise une configuration de nœud "leader et suiveur". Kafka utilise un ZooKeeper pour la gestion. Les services de commande basés sur Kafka sont disponibles depuis Fabric v1.0, mais de nombreux utilisateurs peuvent trouver les frais administratifs supplémentaires liés à la gestion d'un cluster Kafka décourageants ou indésirables.
        • Solo (obsolète dans la v2.0) : l'implémentation Solo du service de commande est uniquement destinée aux tests et ne contient qu'un seul ordonnateur. Il est obsolète et peut être complètement supprimé dans une future version. Les utilisateurs Solo existants doivent migrer vers un réseau Raft à nœud unique pour bénéficier des mêmes fonctionnalités.
  • Contrats intelligents et chaincode
    • contrat intelligent

      

      
      Les contrats intelligents définissent des règles entre différentes organisations avec un code exécutable. Les applications invoquent des contrats intelligents pour générer des transactions qui sont enregistrées dans le grand livre.
    • Le contrat intelligent définit la logique de transaction qui contrôle le cycle de vie des objets métier dans l'état mondial, puis la logique de transaction est intégrée dans le code de chaîne, puis le code de chaîne sera déployé sur le réseau blockchain. Les contrats intelligents peuvent être considérés comme des gestionnaires de transactions, et le code de chaîne gère la façon dont les contrats intelligents sont conditionnés pour le déploiement

      

      
      Un contrat intelligent est défini dans un code blockchain. Et plusieurs contrats intelligents peuvent également être définis dans le même code blockchain. Lorsqu'un code blockchain est déployé, tous les contrats intelligents de ce code blockchain sont disponibles pour les applications.
    • Grand livre : les contrats intelligents écrivent (mettent), lisent (obtenent) et suppriment (suppriment) principalement l'état dans l'état mondial, et peuvent également interroger les enregistrements de transaction immuables de la blockchain.
      • chaîne de blocs
      • état du monde
      • async createCar(ctx, carNumber, marque, modèle, couleur, propriétaire) { const car = { couleur, docType : 'voiture', marque, modèle, propriétaire, } ; attendre ctx.stub.putState(carNumber, Buffer.from(JSON.stringify(car)));}
    • Approbation : Indique quelles organisations du réseau blockchain doivent signer la transaction générée par un contrat intelligent donné pour déclarer que la transaction est valide

      

      
      Chaque contrat intelligent est associé à une politique d'approbation. Cette politique d'approbation définit quelles organisations doivent accepter une transaction générée par un contrat intelligent avant qu'elle puisse être certifiée valide.
      • Trois des quatre organisations participant au réseau blockchain doivent signer la transaction avant qu'elle ne soit considérée comme valide. Toutes les transactions, qu'elles soient valides ou invalides, sont ajoutées au grand livre, mais seules les transactions valides mettent à jour l'état du monde.
    • transaction valide
      • Les contrats intelligents extraient un ensemble de paramètres d'entrée appelés propositions de transaction et les utilisent en conjonction avec la logique du programme pour lire et écrire le grand livre. Les modifications apportées à l'état du monde sont capturées sous forme de réponses de proposition de transaction (ou simplement de réponses de transaction), qui contiennent un Ensemble d'écriture, qui contient à la fois l'état de lecture et le nouvel état qui n'a pas été écrit (si la transaction est valide)
      • L'état du monde n'est pas mis à jour lors de l'exécution du contrat intelligent

        

        
        Toutes les transactions ont un identifiant, une proposition et une réponse signée par un groupe d'organisations. Toutes les transactions, valides ou non, sont enregistrées sur la blockchain, mais seules les transactions valides mettent à jour l'état du monde.
      • Une transaction est distribuée à tous les nœuds du réseau et chaque nœud la valide en deux phases.
        • Tout d'abord, la transaction est vérifiée par rapport à la politique d'approbation pour s'assurer que la transaction a été signée par suffisamment d'organisations.
        • Deuxièmement, continuez à vérifier la transaction pour vous assurer que son ensemble de lecture de transaction correspond à la valeur actuelle de l'état mondial lorsque la transaction est signée par le nœud d'approbation, et qu'elle n'a pas été mise à jour au milieu. Si une transaction réussit les deux tests, elle est marquée comme valide.
    • allée

      

      
      Les canaux fournissent un mécanisme de communication complètement indépendant entre un groupe d'organisations. Lorsqu'une définition de code blockchain est soumise à un canal, toutes les applications sur le canal peuvent utiliser les contrats intelligents dans ce code blockchain.
      • Le code de contrat intelligent est installé dans le package de code de chaîne du nœud de l'organisation, mais seulement après que le code de chaîne est défini sur le canal, les membres du canal peuvent exécuter le contrat intelligent
    • Intercommunication : un contrat intelligent peut appeler d'autres contrats intelligents sur le même canal ainsi que des contrats intelligents sur d'autres canaux. Cela permet aux contrats intelligents de lire et d'écrire des données d'état mondial qui seraient autrement inaccessibles en raison des espaces de noms de contrats intelligents
    • code de chaîne du système
      • Code de chaîne du système de cycle de vie (LSCC)
      • Configurer le code de chaîne du système (CSCC)
      • Code de chaîne du système de requête (QSCC)
      • Code de chaîne du système d'approbation (ESCC)
      • Code de chaîne du système de vérification (VSCC)
    • Cycle de vie du chaincode - définition sur le canal
      • Les membres du canal s'accordent sur les étapes suivantes, que toutes les organisations du canal n'ont pas besoin de suivre :
        • Code de chaîne d'emballage
        • Installer le code blockchain sur les pairs
        • Approuver une définition de code blockchain dans l'organisation
        • Appliquer le code blockchain au canal
      • Phase 1 : Conditionnement des contrats intelligents

        

        
        Le code blockchain doit être empaqueté dans un fichier tar, se terminant par une extension de fichier .tar.gz.
        • Le fichier tar doit contenir deux fichiers (pas de répertoires) : le fichier de métadonnées "metadata". Json" et un autre tar "code.tar.gz" contient le fichier de code blockchain.
        Metadata. Contient un json spécifiant le langage du code blockchain, le chemin du code et l'étiquette du package. Vous pouvez voir un exemple de fichier de métadonnées ci-dessous :
        Le code blockchain est créé par Org1 et Org2 sont empaquetés séparément. Les deux organisations utilisent MYCC_1 comme étiquette de package pour identifier les packages à l'aide du nom et de la version. Il n'est pas nécessaire que les organisations utilisent la même étiquette de package.
      • Phase 2 : Installer le code blockchain sur les pairs

        

        
        Les administrateurs pairs d'Org1 et Org2 installent le package de code blockchain MYCC_1 sur les pairs connectés au canal.
        L'installation du package de code blockchain générera un code blockchain et créera un hachage MYCC_1: de l'identifiant du package.
      • Phase 3 : Approuver la définition du code blockchain dans l'organisation
        • Le processus d'approbation de l'organisation équivaut à un vote d'acceptation. Les membres du canal peuvent l'utiliser après avoir autorisé son utilisation. Il implique les paramètres suivants (identifiant de package) ​​qui doivent être cohérents entre les organisations.
          • nom
          • version
          • séquence
          • politique d'approbation
          • configuration de collecte
          • Plugins ESCC/VSCC
          • Initialisation : si vous utilisez l'API de bas niveau fournie par l'API Fabric Chaincode Shim, votre Chaincode doit inclure la fonction Init pour initialiser le Chaincode.

        • 

          
          Les administrateurs d'organisation d'Org1 et d'Org2 approuvent la définition du code blockchain pour leur organisation MYCC.
          Une définition de code blockchain comprend des champs tels que le nom du code blockchain, la version et la politique d'approbation. Étant donné que les deux organisations utiliseront des codes blockchain pour prendre en charge les transactions, les définitions d'approbation pour les deux organisations doivent inclure packageID.
          ​
      • La quatrième étape : lorsqu'un nombre suffisant de membres du canal approuvent la définition du code blockchain, la définition du code blockchain peut être soumise au canal, d'abord envoyée aux pairs membres du canal, les pairs vérifient la définition du code blockchain approuvée, l'approuvent, la soumettent au service de tri , puis revenir au canal

        

        
        Un administrateur d'organisation d'Org1 ou Org2 valide la définition de code blockchain sur le canal. La définition sur le canal n'inclut pas le packageID.
        • Les organisations peuvent approuver les définitions de code blockchain sans installer de packages de code blockchain
        • Une fois que MYCC est défini sur le canal, Org1 et Org2 peuvent commencer à utiliser le code blockchain. La première invocation du code blockchain démarre le conteneur de code blockchain sur chaque pair.
    • Mettre à jour le code de la chaîne : le code de la chaîne peut mettre à jour le formulaire d'approbation, et il prendra effet immédiatement après l'avoir soumis au canal, pas besoin de l'appeler spécialement
      • Remballer le code blockchain
      • Installez le nouveau package de code blockchain sur le nœud
      • Approuver une nouvelle définition de code blockchain
      • commiter la définition sur le canal
  • données privées
    • Collecte de données privées :

      

      • Données privées réelles : le protocole de potins est envoyé point à point aux organisations qui peuvent le voir, et les autres ne peuvent pas le voir
      • Valeur de hachage des données : la partie publique, écrite dans le registre après le tri des endossements
    • Concernant l'utilisation d'un canal séparé ou d'une collecte de données privées au sein d'un canal existant :
      • Canal : l'intégralité du registre doit être tenue secrète
      • collection : partie

        

        
        En prenant Figure comme exemple, différentes exigences de confidentialité entre différentes organisations
    • Flux de transactions utilisant des données privées
      • Une application cliente soumet une demande de proposition pour que des endosseurs appartenant à un ensemble autorisé exécutent une fonction de code blockchain (lecture ou écriture de données privées). Les données privées, ou les données utilisées pour générer des données privées en code blockchain, sont envoyées dans le champ transitoire de la proposition.
      • Le nœud d'approbation simule la transaction et stocke les données privées dans le magasin de données transitoires (le stockage temporaire local du nœud). Ils distribuent des données privées aux nœuds Peer autorisés via [gossip]() conformément à la politique de collecte de l'organisation.
      • Les pairs qui approuvent renvoient les réponses de proposition au client. Les réponses de proposition contiennent l'ensemble de lecture-écriture approuvé, qui contient les données publiques, ainsi que toute clé de données privée et les hachages de valeur. Les données privées ne seront pas renvoyées au client. En savoir plus sur les recommandations avec des données privées
      • Les applications client soumettent des transactions (y compris des réponses de proposition avec des hachages de données privées) au service de commande. Les transactions avec des hachages de données privées sont également incluses dans les blocs. Les blocs avec des hachages de données privées sont distribués à tous les nœuds. De cette façon, tous les nœuds du canal peuvent vérifier les transactions avec des valeurs de hachage de données privées de la même manière sans connaître les vraies données privées.
      • Au moment de la soumission du bloc, les nœuds autorisés détermineront s'ils ont accès aux données privées conformément à la politique collective. Si les nœuds y ont accès, ils vérifient d'abord leur magasin de données transitoires local pour voir s'ils ont reçu des données privées au moment de l'approbation du code blockchain. Si ce n'est pas le cas, ils essaient d'extraire les données privées d'autres nœuds autorisés, puis vérifient les données privées par rapport au hachage sur le bloc public et soumettent la transaction et le bloc.
      • Lorsque la vérification ou la soumission est terminée, les données privées sont déplacées vers les bases de données privées de ces nœuds et des copies du stockage privé en lecture-écriture. Ces données privées stockées dans le magasin de données transitoires sont ensuite supprimées.
    • partager des données privées
      • Utilisez la clé publique correspondante pour suivre l'état public, et de même pour le privé
      • Contrôlez si le client peut accéder aux données privées via le code de chaîne (que ce soit dans le certificat ou si le mot de passe est cohérent)
      • partage hors bande : hachage de vérification
      • Partager des données privées avec d'autres collections : le code blockchain GetPrivateDataHash() vérifie s'il y a des données privées dans la collection, supprime les données de votre collection une fois la vérification réussie et génère la clé dans la collection d'autres organisations, ce qui peut nécessiter une approbation supplémentaire
      • Utiliser des données privées pour l'approbation de la transaction : pour obtenir l'approbation de l'autre partie avant la fin de la transaction, le code de chaîne lui permet d'avoir un consentement préalable ou de signer une clé privée sur son/votre ensemble de données privées, puis d'utiliser GetPrivateDataHash() pour vérifier
      • Garder les commerçants privés : utiliser un hachage de données privées