Les potins jouent un rôle important dans Hyperledger Fabric. Dans ce didacticiel, nous examinerons le mécanisme de fonctionnement des potins lorsque le réseau Fabric est démarré par étapes, apprendrons quelques concepts de base dans Fabric, tels que le nœud / leader dominant, le nœud d'ancrage / l'ancre, etc., et comprendrons comment les
potins aident Hyperledger Fabric à devenir un évolutif La plateforme de la chaîne d'alliance.
Tutoriels et outils de développement de blockchain Hyperledger Fabric:
- Explication détaillée du développement de Fabric Blockchain Node.js
- Explication détaillée du développement de Fabric Blockchain Java
- Explication détaillée du développement de la blockchain en tissu Golang
- Outil de lancement BYFN en un clic pour Windows
- Boîte à outils de développement rapide de tissus
- Kit de développement Python Fabric Chain Code
1. Présentation de Fabric Gossip
La plupart d'entre nous ont commencé à apprendre du réseau de démonstration fourni avec Hyperledger Fabric, tel que First Network, et ont essayé la blockchain Fabric. First Network fournit un script byfn.sh pour nous montrer le processus typique de démarrage d'un réseau Fabric:
- Générer des données cryptographiques et des données de configuration de canal
- Démarrez les composants du réseau, tels que le classement des nœuds / ordonnanceurs, des nœuds pairs / pairs ...
- Rejoignez le nœud homologue au canal
- Mettre à jour le nœud d'ancrage
Après les opérations ci-dessus, le réseau Fabric est prêt et l'étape suivante consiste généralement à déployer le code de chaîne contenant la logique métier.
Certains des processus cachés en arrière-plan dans le processus ci-dessus sont intéressants. Dans ce didacticiel, nous examinons principalement le rôle des potins et comprenons comment cela aide à parvenir à une solution évolutive. Hyperledger Fabric utilise les potins comme mécanisme de communication point à point. Afin d'optimiser l'ensemble du processus de flux d'informations, Fabric a implémenté le protocole de diffusion de données de potins pour réaliser un déploiement et un fonctionnement du réseau évolutifs.
Les potins dans la documentation officielle Hyperledger Fabric en fournissent une description générale. Ici, nous allons extraire les informations pertinentes et démontrer la performance des potins en fonctionnement réel.
2. Configuration du nœud de démarrage de Fabric Gossip
La configuration du nœud de démarrage Gossip doit être effectuée sur chaque nœud / homologue homologue, et la configuration comprend un ou un groupe de nœuds homologues dans la même organisation. Lorsqu'un pair est opérationnel, il contactera d'autres nœuds de pair dans la liste pour la diffusion de potins de messages.
Dans la configuration classique du premier réseau, il y a deux nœuds homologues dans chaque organisation, donc un paramètre raisonnable est d'utiliser l'autre nœud homologue comme nœud de démarrage de potins. Il s'agit également du fichier de configuration (base / docker-compose-base .yaml). Ce qui suit ne montre que les informations du nœud homologue d'Org1, mais nous pouvons observer des informations similaires dans la configuration du nœud homologue d'Org2:
Lorsque le nœud homologue est démarré, il recherchera d'abord le nœud de démarrage pour la communication de potins. Plus tard, nous verrons également ce qui se passe si le nœud de démarrage n'est pas défini.
3. Noeud principal / pair leader de Fabric Gossip
Le nœud / chef de file d'une organisation est responsable de la réception des blocs du service de commande et de leur distribution à d'autres nœuds homologues de la même organisation. N'oubliez pas que dans un réseau Fabric, tous les nœuds homologues doivent recevoir de nouveaux blocs du service de commande. L'introduction du nœud leader optimise le processus de synchronisation de nouveaux blocs avec tous les nœuds homologues, car le service de commande n'a besoin que d'envoyer de nouveaux blocs au nœud leader de chaque organisation, puis le nœud leader est responsable de la synchronisation avec d'autres nœuds homologues.
Chaque organisation a son propre nœud de chef. Nous verrons cela dans la démo. Chaque canal possède également son propre nœud principal. Avant qu'un nœud homologue ne rejoigne un canal, il n'a pas le concept de leader. Ce n'est qu'après avoir rejoint le canal qu'il implique le nœud leader.
Dans une organisation, les nœuds leaders peuvent être configurés statiquement ou élus dynamiquement. Le paramètre par défaut dans First Network est déterminé par élection et la configuration est dans base / peer-base.yaml:
4. Le nœud d'ancrage / homologue d'ancrage de Fabric Gossip
Un nœud d'ancrage / homologue d'ancrage est nécessaire dans un réseau pour obtenir des informations sur les membres de canal d'autres organisations. S'il n'y a pas de nœud d'ancrage, la compréhension des membres du canal sera limitée à l'organisation actuelle. Par exemple, lorsqu'il n'y a pas de nœud d'ancrage, le nœud homologue dans Org1 sait uniquement que les autres nœuds homologues dans Org1 sont des membres de canal, mais ils ne peuvent pas savoir que les nœuds homologues dans Org2 sont également membres de canal. Au moins un nœud d'ancrage est requis dans un canal pour interrompre cette fragmentation des informations.
La configuration du nœud d'ancrage doit mettre à jour le canal. Utilisez d'abord configtxgen pour créer une transaction de mise à jour, signez la transaction et envoyez-la au service de commande, le service de commande générera un nouveau bloc de configuration, qui contient cette transaction utilisée pour mettre à jour la configuration du nœud d'ancrage. Lorsque ce bloc atteint tous les nœuds homologues du canal et est soumis par chaque nœud, tous les nœuds homologues savent également quel est le nœud d'ancrage, puis à travers la propagation des potins les uns des autres pour réaliser la compréhension des informations de l'ensemble des membres du canal, c'est-à-dire Y compris les membres au sein de l'organisation, ainsi que les membres extérieurs à l'organisation.
Dans la dernière partie, nous verrons les différentes opérations avant et après la configuration du nœud d'ancrage.
5. Présentation du réseau Fabric First
Nous utilisons First Ntwork, qui contient deux organisations Org1 et Org2. Chaque organisation contient deux nœuds homologues (peer0 et peer1). Le canal mychannel est défini et les 4 nœuds homologues sont ajoutés au canal. Peer0 est configuré en tant que nœud d'ancrage.
Lors de l'exécution de byfn.sh, le script effectue les tâches suivantes:
- Générer des données cryptographiques et des données de configuration de canal (étape 1)
- Démarrez tous les composants réseau (conteneurs) avec docker-composer (étape 2-5)
- Créez le bloc genesis de mychannel channel (bloc n ° 0) (étape 6)
- Ajouter les 4 nœuds homologues à mychannel (étape 7-10)
- Mettre à jour les informations de configuration de l'homologue d'ancrage des deux institutions (étapes 11-12)
Le réseau est prêt et chaque nœud homologue connaît les autres nœuds du canal. Voici le résultat de l'exécution du script (l'utilisation de l'option -n consiste à indiquer au script byfn de ne pas déployer le code de la chaîne):
Dans la démonstration suivante, nous suivons essentiellement le processus ci-dessus. Afin de mieux observer les résultats expérimentaux, nous décomposerons la configuration docker-compose un par un, puis modifierons le fichier de configuration ou réorganiserons l'ordre et observerons différents résultats.
6. Expérience de Fabric Gossip ÉTAPE 0: Préparation
Copiez un nouveau répertoire directement depuis first-network /:
cd fabric-samples
cp -r first-network kc-first-network
Nous effectuerons des opérations de suivi sur ce répertoire: kc-first-network /
Dans le même temps, le conteneur CLI d'origine dépend de tous les composants réseau démarrés. Puisque nous allons démarrer les composants du réseau un par un, commencez par commenter les dépendances.
7. Expérience Fabric Gossip Étape 1: Générer des données cryptographiques et des données de configuration de canal
Nous utilisons byfn.sh pour générer les données cryptographiques et les données de configuration de canal requises par le réseau Fabric.
cd kc-first-network
./byfn.sh generate
8. Expérience Fabric Gossip Étape 2: Démarrez le conteneur Orderer et CLI
docker-compose -f docker-compose-cli.yaml up -d orderer.example.com cli
9. Expérience Fabric Gossip Étape 3: Démarrer le nœud peer0.org1
docker-compose -f docker-compose-cli.yaml up -d peer0.org1.example.com
Ouvrez le terminal pour afficher le journal de peer0.org1.example.com:
docker logs -f peer0.org1.example.com
Concentrons-nous sur les activités liées aux potins. À partir du journal, nous pouvons comprendre le processus d'initialisation des potins et le processus de démarrage de l'instance de potins.
Cependant, comme le nœud de démarrage de potins est configuré, peer0.org1.example.com contactera peer1.org1.example.com,
mais peer1 n'est pas en cours d'exécution.
10. Expérience de Fabric Gossip Étape 4: Démarrez peer1.org1
docker-compose -f docker-compose-cli.yaml up -d peer1.org1.example.com
Nous n'avons pas vu le problème de ne pas pouvoir accéder au nœud de démarrage de potins similaire à peer0. En fait, peer1.org1.example.com est
également configuré avec peer0.org1.example.com comme nœud de démarrage de potins, et essaiera de contacter peer0.org1.example.com au démarrage. Depuis que peer0 a été démarré, il peut être vu dans le journal que peer1 a contacté avec succès peer0 (grpc.method = Ping, grpc.code = OK).
Presque au moment du lancement de peer1.org1.example.com, peer0.org1.example.com contactera également peer1.org1.example.com. Vous pouvez voir que les horodatages sont cohérents.
- instance de potins de peer1.org1.example.com démarrée en 06: 39: 05.878 (ci-dessus)
- peer0.org1.example.com a atteint peer1.org1.example.com en 06: 39: 05.892 (ci-dessous)
Cela signifie que les deux nœuds homologues ont été connectés au niveau de la couche potins. Notez qu'il n'y a actuellement aucun
rôle lié au canal , tel que le nœud principal ou le nœud d'ancrage. Ces concepts ne seront impliqués qu'après avoir rejoint le canal.
11. Expérience Fabric Gossip Étape 5: Démarrez le nœud homologue d'Org2
Afin de suivre le processus de démonstration du script byfn.sh, nous démarrons également peer0.org2.example.com et peer1.org2.example.com.
Un comportement similaire peut être observé:
docker-compose -f docker-compose-cli.yaml up -d peer0.org2.example.com peer1.org2.example.com
Puisque les deux nœuds ont démarré presque en même temps, nous n'avons pas vu le problème de la connexion de peer0 au nœud de démarrage de potins qui est apparu à l'étape 3.
12. Expérience Fabric Gossip Étape 6: Préparez un bloc de création pour le canal mychannel
docker exec cli peer channel create -o orderer.example.com:7050 --tls \
--cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem \
-c mychannel -f ./channel-artifacts/channel.tx
En conséquence, le fichier de bloc de genèse mychannel.block est stocké dans le conteneur CLI, qui est utilisé pour ajouter des nœuds homologues au canal mychannel.
13. Étape 7 de l'expérience Fabric Gossip: ajoutez peer0.org1 au canal mychannel
Notez que le paramètre par défaut du conteneur CLI est de se connecter à peer0.org1.example.com en tant qu'administrateur d'Org1.
docker exec cli peer channel join -b mychannel.block
Ce qui suit peut être observé à partir du journal:
- Utilisez le bloc genesis pour créer le grand livre de la chaîne mychannel
- Soumettre le bloc n ° 0
- mychannel rejoint le réseau de potins
- Les informations de configuration du nœud d'ancrage des deux institutions n'ont pas été trouvées
- Devenez le nœud dominant et soyez élu comme nœud dominant
14. Étape 8 de l'expérience Fabric Gossip: ajoutez peer1.org1 au canal mychannel
docker exec \
-e CORE_PEER_ADDRESS=peer1.org1.example.com:8051 \
-e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/ca.crt \
cli peer channel join -b mychannel.block
On peut observer que le contenu est similaire au journal de peer0.org1.example.com, sauf pour la partie élection du nœud dominant.
Par conséquent, du point de vue du canal, peer0.org1.example.com est le nœud dominant d'Org1, chargé de recevoir les nouveaux blocs du service de commande et de les envoyer à d'autres nœuds homologues dans Org1.
15. Expérience Fabric Gossip Étape 9: Le nœud d'homologue Org1 comprend les informations sur les membres du canal
Lorsque la relation dominante des nœuds homologues dans une organisation est déterminée, nous pouvons immédiatement voir dans les journaux des deux nœuds qu'ils ont compris les informations des membres dans le canal.
-
peer0.org1.example.com: connaît désormais peer1.org1.example.com en tant que membre de la chaîne
-
peer1.org1.example.com: connaît désormais peer0.org1.example.com en tant que membre de la chaîne
16. Expérience Fabric Gossip Étape 10: Ajoutez le nœud homologue d'Org2 au canal mychannel
docker exec \
-e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/[email protected]/msp \
-e CORE_PEER_ADDRESS=peer0.org2.example.com:9051 \
-e CORE_PEER_LOCALMSPID="Org2MSP" \
-e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt \
cli peer channel join -b mychannel.block
docker exec \
-e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/[email protected]/msp \
-e CORE_PEER_ADDRESS=peer1.org2.example.com:10051 \
-e CORE_PEER_LOCALMSPID="Org2MSP" \
-e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer1.org2.example.com/tls/ca.crt \
cli peer channel join -b mychannel.block
Semblable à la situation d'Org1 avant, nous pouvons voir:
- peer0.org2.example.com: en tant que leader, et connaissez également peer1.org2.example.com en tant que membre de la chaîne
- peer1.org2.example.com: voyez quelqu'un en tant que leader, et connaissez également peer0.org2.example.com en tant que membre de la chaîne
Nous savons maintenant que les ragots fonctionnent déjà au sein d'une même organisation, car les nœuds homologues se
comprennent mutuellement. Mais ce n'est pas encore terminé, car les nœuds homologues doivent également connaître les nœuds homologues d'autres
organisations, ce qui nécessite la configuration de nœuds d'ancrage / d'homologues d'ancrage.
17. Expérience Fabric Gossip Étape 11: Mettez à jour le nœud d'ancrage d'Org1
docker exec cli peer channel update -o orderer.example.com:7050 --tls \
--cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem \
-c mychannel -f ./channel-artifacts/Org1MSPanchors.tx
Nous avons d'abord vu qu'un nouveau bloc de bloc n ° 1 était généré et reçu et soumis par tous les nœuds homologues d'Org1 et d'Org2. Étudions-le.
Tout d'abord, examinons comment le nouveau bloc atteint chaque nœud homologue. Nous savons que le nouveau bloc est généré par le client. À partir de la trace tcpdump, nous voyons seulement que orderer.example.com communique avec peer0.org1.example.com et peer0.org2.example.com, mais ne communique pas avec les nœuds peer1 dans les deux organisations. Ceci est dû au fait que peer0 dans les deux institutions est le nœud dominant et que le client n'a besoin que d'envoyer le nouveau bloc au nœud dominant.
Notez que seuls deux paquets sont affichés ici.Il y a en fait une série de paquets envoyés du client aux nœuds peer0 des deux institutions. Non, nous n'avons pas vu le paquet envoyé à peer1.
De plus, en capturant le journal de réception du bloc n ° 1 sur chaque nœud pair, nous pouvons conclure:
- peer0.org1.example.com (horodatage: 07: 01: 34.583)
- peer1.org1.example.com (horodatage: 07: 01: 34.588)
- peer0.org2.example.com (horodatage: 07: 01: 34.631)
- peer1.org2.example.com (horodatage: 07: 01: 34.637)
Nous voyons que peer1 dans les deux institutions a reçu le bloc # 1 un peu plus tard que peer0. Bien que ce ne soit pas un mouvement suffisant, au moins il est conforme à la théorie selon laquelle le nœud dominant est responsable de la transmission de nouveaux blocs. C'est le mécanisme de l'évolutivité, en introduisant un nœud dominant et en divisant la diffusion de nouveaux blocs en deux couches.
Ensuite, nous examinerons ce qui se passe après que chaque nœud homologue a soumis le bloc au registre. Une fois que le nœud d'ancrage est connu, ces nœuds pairs effectueront des opérations de potins. Après plusieurs séries de diffusion de potins, nous pouvons voir les informations sur les membres de la chaîne:
- peer0.org1.example.com
- peer1.org1.example.com
-
peer0.org2.example.com
-
peer1.org2.example.com
Maintenant, chaque nœud homologue a maîtrisé la table de mappage des membres complète. Comme avantage supplémentaire, nous avons également vu comment le nœud pair d'Org2 a appris l'existence du nœud peer1.org1.example.com lors du processus de potins ultérieur.
Désormais, chaque nœud homologue du canal connaît déjà l'existence de l'autre, que ce soit dans la même organisation ou dans différentes organisations, le réseau est prêt.
18. Fabric Gossip Experiment Étape 12: Mettre à jour le nœud d'ancrage d'Org2
Nous voyons qu'un seul nœud d'ancrage est nécessaire dans un canal pour que le réseau fonctionne normalement. Cependant, il est recommandé que chaque organisation mette en place un nœud d'ancrage.
docker exec \
-e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/[email protected]/msp \
-e CORE_PEER_ADDRESS=peer0.org2.example.com:9051 \
-e CORE_PEER_LOCALMSPID="Org2MSP" \
-e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt \
cli peer channel update -o orderer.example.com:7050 --tls \
--cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem \
-c mychannel -f ./channel-artifacts/Org2MSPanchors.tx
Nous pouvons maintenant voir les changements dans la vue des membres de la chaîne.
19. Expérience Fabric Gossip: supprimez le nœud de démarrage Gossip de la configuration de l'homologue
Le nœud de démarrage de Gossip est configuré dans base / docker-compose-base.yaml. Mettez en commentaire la variable CORE_PEER_GOSSIP_BOOTSTRAP pour chaque nœud homologue. Les principales conclusions du journal sont les suivantes:
Après les étapes 3 et 4, nous pouvons voir que les deux nœuds homologues d'Org1 ne communiquent plus au niveau des potins. Après l'étape 5, les deux nœuds d'Org2 ont également une situation similaire.
Lorsque tous les nœuds homologues ont rejoint le canal mychannel, nous observons que tous les nœuds homologues sont élus comme nœud dominant.
- peer0.org1.example.com
- peer1.org1.example.com
- peer0.org2.example.com
- peer1.org2.example.com
Cela est dû au manque de communication de potins au sein de l'organisation. Mais y a-t-il un problème? Voyons ce qui se passe après la mise à jour du nœud d'ancrage (étape 11).
- peer0.org1.example.com
-
peer1.org1.example.com
-
peer0.org2.example.com
- peer1.org2.example.com
Après le processus de potins, tous les nœuds homologues du canal ont les informations correctes sur les membres du canal. Dans le même temps, nous avons également observé que certains nœuds pairs ne sont plus le nœud dominant.
- peer0.org1.example.com
- peer0.org2.example.com
Nos observations montrent que lorsqu'il n'y a pas de nœud de démarrage de potins configuré avec des nœuds homologues, l'élection des nœuds dominants dans une organisation est hors de contrôle, car chaque homologue se choisira comme nœud dominant. Dans tous les cas, ce n'est pas la situation souhaitée, car le client doit communiquer avec chaque nœud dominant. Lorsque la configuration du nœud d'ancrage est mise à jour, tous les nœuds homologues maîtrisent finalement les informations sur les membres du canal, et en même temps, certains nœuds ne sont plus les nœuds dominants, ce que nous attendons. Le résultat final est donc réalisable, même si nous n'avons pas défini le nœud de guide de potins pour chaque nœud pair au début.
Lien original: tutoriel sur l'expérience Fabric Gossip-Huizhi.com