Gossip plays an important role in Hyperledger Fabric. In this tutorial, we will examine the operating mechanism of gossip when the Fabric network is started in stages, learn some core concepts in Fabric, such as dominant node/leader, anchor node/anchor, etc., and understand how
gossip helps Hyperledger Fabric become a scalable The alliance chain platform.
Hyperledger Fabric blockchain development tutorials and tools:
1. Overview of Fabric Gossip
Most of us started to learn from the demo network that comes with Hyperledger Fabric such as First Network and tried the Fabric blockchain. First Network provides a script byfn.sh to show us the typical process of starting a Fabric network:
- Generate cryptographic data and channel configuration data
- Start network components, such as ordering nodes/orderers, peer nodes/peers...
- Join the peer node to the channel
- Update anchor node
After the above operations, the Fabric network is ready, and the next step is usually to deploy the chain code containing the business logic.
Some of the processes hidden in the background in the above process are very interesting. In this tutorial, we mainly examine the role of gossip and understand how it helps to achieve a scalable solution. Hyperledger Fabric uses gossip as a point-to-point communication mechanism. In order to optimize the entire information flow process, Fabric implemented the gossip data diffusion protocol to achieve scalable network deployment and operation.
The gossip in the official Hyperledger Fabric documentation provides a general description. Here we will extract relevant information and demonstrate the performance of gossip in actual operation.
2. Boot node configuration of Fabric Gossip
Gossip boot node configuration needs to be performed on each peer node/peer, and this configuration includes one or a group of peer nodes in the same organization. When a peer is up and running, it will contact other peer nodes in the list for gossip dissemination of messages.
In the classic First Network configuration, there are two peer nodes in each organization, so a reasonable setting is to use the other peer node as the boot node of gossip. This is also the configuration file (base/docker-compose-base .yaml). The following only shows the information of the peer node of Org1, but we can observe similar information in the peer node configuration of Org2:
When the peer node is started, it will first look for the boot node for gossip communication. Later we will also look at what happens if the boot node is not defined.
3. Leading node/leader peer of Fabric Gossip
The leading node/leader in an organization is responsible for receiving blocks from the ordering service and distributing them to other peer nodes in the same organization. Remember that in a fabric network, all peer nodes need to receive new blocks from the ordering service. The introduction of the leader node optimizes the process of synchronizing new blocks to all peer nodes, because the ordering service only needs to send new blocks to the leader node of each organization, and then the leader node is responsible for synchronizing to other peer nodes.
Each organization has its own leader node. We will see this in the demo. Each channel also has its own leader node. Before the peer node joins a channel, it does not have the concept of leader. Only after it joins the channel, does the leader node issue.
In an organization, leader nodes can be statically configured or dynamically elected. The default setting in First Network is determined by election, and the configuration is in base/peer-base.yaml:
4. The anchor node/anchor peer of Fabric Gossip
An anchor node/anchor peer is needed in a network to obtain channel member information of other organizations. If there is no anchor node, then the understanding of channel members will be limited to the current organization. For example, when there is no anchor node, the peer node in Org1 only knows that other peer nodes in Org1 are channel members, but cannot understand that the peer nodes in Org2 are also channel members. At least one anchor node is required in a channel to break this information fragmentation.
The configuration of the anchor node needs to update the channel. First use configtxgen to create an update transaction, sign the transaction and send it to the ordering service, the ordering service will generate a new configuration block, which contains this transaction used to update the anchor node configuration. When this block reaches all peer nodes in the channel and is submitted by each node, all peer nodes also know which is the anchor node, and then through each other's gossip propagation to realize the information understanding of the entire channel members, that is Including members within the organization, as well as members outside the organization.
In the later part we will see the different operation before and after configuring the anchor node.
5. Overview of Fabric First Network
We are using First Ntwork, which contains two organizations Org1 and Org2. Each organization contains two peer nodes (peer0 and peer1). The channel mychannel is defined and all 4 peer nodes are added to the channel. Peer0 is configured as an anchor node.
When executing byfn.sh, the script performs the following tasks:
- Generate cryptographic data and channel configuration data (Step 1)
- Start all network components (containers) with docker-composer (Step 2-5)
- Create the genesis block of mychannel channel (block#0) (Step 6)
- Add all 4 peer nodes to mychannel (Step 7-10)
- Update the anchor peer configuration information of the two institutions (Step 11-12)
The network is ready, and each peer node knows the other nodes in the channel. The following is the result of executing the script (using the -n option is to tell the byfn script not to deploy the chain code):
In the following demonstration, we basically follow the above process. In order to better observe the experimental results, we will decompose the docker-compose configuration of the peer nodes one by one, and then modify the configuration file or rearrange the order and observe different results.
6. Fabric Gossip experiment STEP 0: Preparation
Copy a new directory directly from first-network/:
cd fabric-samples
cp -r first-network kc-first-network
We will perform follow-up operations on this directory: kc-first-network/
At the same time, the original CLI container depends on all the network components that are started. Since we will start the network components one by one, comment out the dependencies first.
7. Fabric Gossip experiment Step 1: Generate cryptographic data and channel configuration data
We use byfn.sh to generate the cryptographic data and channel configuration data required by the Fabric network.
cd kc-first-network
./byfn.sh generate
8. Fabric Gossip experiment Step 2: Start Orderer and CLI container
docker-compose -f docker-compose-cli.yaml up -d orderer.example.com cli
9. Fabric Gossip experiment Step 3: Start peer0.org1 node
docker-compose -f docker-compose-cli.yaml up -d peer0.org1.example.com
Open the terminal to view the log of peer0.org1.example.com:
docker logs -f peer0.org1.example.com
Let's focus on gossip related activities. From the log, we can understand the initialization process of gossip and the startup process of the gossip instance.
However, because the gossip boot node is configured, peer0.org1.example.com will contact peer1.org1.example.com,
but peer1 is not currently running.
10. Fabric Gossip Experiment Step 4: Start peer1.org1
docker-compose -f docker-compose-cli.yaml up -d peer1.org1.example.com
We did not see the problem of not being able to access the gossip boot node similar to peer0. In fact, peer1.org1.example.com is
also configured with peer0.org1.example.com as its gossip boot node, and will try to contact peer0.org1.example.com at startup. Since peer0 has been started, it can be seen from the log that peer1 successfully contacted peer0 (grpc.method=Ping, grpc.code=OK).
Almost at the same time that peer1.org1.example.com is launched, peer0.org1.example.com will also contact peer1.org1.example.com. You can see that the timestamps are consistent.
- gossip instance of peer1.org1.example.com started in 06:39:05.878 (above)
- peer0.org1.example.com reached peer1.org1.example.com in 06:39:05.892 (below)
This means that the two peer nodes have been connected at the gossip layer. Note that there are currently no channel-related
roles such as leader node or anchor node. These concepts will only be involved after joining the channel.
11. Fabric Gossip experiment Step 5: Start the peer node of Org2
In order to follow the demonstration process of the byfn.sh script, we also start peer0.org2.example.com and peer1.org2.example.com.
Similar behavior can be observed:
docker-compose -f docker-compose-cli.yaml up -d peer0.org2.example.com peer1.org2.example.com
Since the two nodes started almost at the same time, we did not see the problem of peer0 connecting to the gossip boot node that appeared in step 3.
12. Fabric Gossip experiment Step 6: Prepare the genesis block for the mychannel channel
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
As a result, the genesis block file mychannel.block is stored in the CLI container, which is used to add peer nodes to the channel mychannel.
13. Fabric Gossip Experiment Step 7: Add peer0.org1 to the channel mychannel
Note that the default setting of the CLI container is to connect to peer0.org1.example.com as the Admin of Org1.
docker exec cli peer channel join -b mychannel.block
The following can be observed from the log:
- Use the genesis block to create the ledger of the channel mychannel
- Submit block#0
- mychannel joins the gossip network
- The anchor node configuration information of the two institutions has not been found
- Become the dominant node and be elected as the dominant node
14. Step 8 of Fabric Gossip experiment: add peer1.org1 to the channel 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
It can be observed that the content is similar to the log of peer0.org1.example.com, except for the election part of the dominant node.
Therefore, from the perspective of the channel, peer0.org1.example.com is the dominant node of Org1, responsible for receiving new blocks from the ordering service and sending them to other peer nodes in Org1.
15. Fabric Gossip experiment Step 9: Org1 peer node understands channel member information
When the dominant relationship of peer nodes in an organization is determined, we can immediately see from the logs of the two nodes that they have understood the member information in the channel.
-
peer0.org1.example.com: now know peer1.org1.example.com as channel member
-
peer1.org1.example.com: now know peer0.org1.example.com as channel member
16. Fabric Gossip experiment Step 10: Add the peer node of Org2 to the mychannel channel
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
Similar to the situation of Org1 before, we can see:
- peer0.org2.example.com: as a leader, and also know peer1.org2.example.com as channel member
- peer1.org2.example.com: see someone as leader, and also know peer0.org2.example.com as channel member
Now we know that gossip is already working within a single organization, because peer nodes
understand each other's existence. But this is not over yet, because peer nodes also need to know peer nodes in other
organizations, which requires the configuration of anchor nodes/anchor peers.
17. Fabric Gossip experiment Step 11: Update the anchor node of 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
We first saw that a new block block#1 was generated and received and submitted by all peer nodes of Org1 and Org2. Let's study it.
First, let's take a look at how the new block reaches each peer node. We know that the new block is generated by the orderer. From the tcpdump trace, we only see that orderer.example.com is communicating with peer0.org1.example.com and peer0.org2.example.com, but not communicating with peer1 nodes in the two organizations. This is because peer0 in the two institutions is the dominant node, and the orderer only needs to send the new block to the dominant node.
Note that only two packets are shown here. There are actually a series of packets sent from the orderer to the peer0 nodes of the two institutions. No, we did not see the package sent to peer1.
In addition, by capturing the log of receiving block#1 on each peer node, we can conclude:
- peer0.org1.example.com (timestamp: 07:01:34.583)
- peer1.org1.example.com (timestamp: 07:01:34.588)
- peer0.org2.example.com (timestamp: 07:01:34.631)
- peer1.org2.example.com (timestamp: 07:01:34.637)
We see that peer1 in the two institutions received block#1 a little later than peer0. Although this is not a sufficient move, at least it conforms to the theory that the dominant node is responsible for forwarding new blocks. This is the mechanism of scalability, by introducing a dominant node and splitting the broadcast of new blocks into two layers.
Next, we will examine what happens after each peer node submits the block to the ledger. Once the existence of anchor nodes is known, these peer nodes will perform gossip operations. After several rounds of gossip diffusion, we can see the member information of the channel:
- peer0.org1.example.com
- peer1.org1.example.com
-
peer0.org2.example.com
-
peer1.org2.example.com
Now each peer node has mastered the complete member mapping table. As an additional benefit, we also see how the peer node of Org2 learned about the peer1.org1.example.com node in the subsequent gossip process.
Now every peer node in the channel already knows the existence of each other, whether in the same organization or in different organizations, the network is ready.
18. Fabric Gossip Experiment Step 12: Update the anchor node of Org2
We see that only one anchor node is needed in a channel to make the network work normally. However, it is recommended that each organization set up an anchor node.
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
We can now see the changes in the channel member view.
19. Fabric Gossip experiment: remove the Gossip boot node from the peer's configuration
The boot node of Gossip is configured in base/docker-compose-base.yaml. Comment out the CORE_PEER_GOSSIP_BOOTSTRAP variable for each peer node. The main findings from the log are as follows:
After steps 3 and 4, we can see that the two peer nodes of Org1 no longer communicate at the gossip level. After Step 5, the two nodes of Org2 also have a similar situation.
When all peer nodes have joined the mychannel channel, we observe that all peer nodes are elected as the dominant node.
- peer0.org1.example.com
- peer1.org1.example.com
- peer0.org2.example.com
- peer1.org2.example.com
This is due to the lack of gossip communication within the organization. But is there any problem? Let us see what happens after we update the anchor node (Step 11).
- peer0.org1.example.com
-
peer1.org1.example.com
-
peer0.org2.example.com
- peer1.org2.example.com
After the gossip process, all peer nodes in the channel have the correct channel member information. At the same time, we also observed that some peer nodes are no longer the dominant node.
- peer0.org1.example.com
- peer0.org2.example.com
Our observations show that when there is no gossip boot node configured with peer nodes, the election of dominant nodes in an organization is out of control, because each peer will choose itself as the dominant node. In any case, this is not the desired situation, because the orderer needs to communicate with each dominant node. When the anchor node configuration is updated, all peer nodes finally master the channel member information, and at the same time, some nodes are no longer the dominant nodes, which is what we expect. So the final result is feasible, even if we did not set the gossip guide node for each peer node at the beginning.
Original link: Fabric Gossip experiment tutorial-Huizhi.com