Illustration of First Network Example in Hyperledger Fabric

This is a follow-up of my previous article on First Network example in Hyperledger Fabric (link). Here I wish to further illustrate what happens in the network during the First Network example is running.

The screen shot is taken when we run ./byfn up, which will perform the following steps

1. create all certificates for the First Network nodes, stored in crypto-config directory
2. create genesis block and all channel transactions, stored in channel-artifacts directory
3. use docker compose to bring up the nodes
4. create channel mychannel and join peers to the channel
5. designate anchor peers
6. install chaincode on peers
7. instantiate chaincode
8. query from ledger
9. invoke transaction on First Network and query the ledger

This article only focuses on steps after 3, all nodes are up and running.

As a reminder, here is the First Network setup.

The Network Setup

Here are the nodes of First Network.

Channel Creation

The creation of channel is to create a genesis block, which is block 0. The creation is done on Orderer, and the block 0 is created.

We use command peer channel create for channel creation.

After this command, block 0 is created as a file called mychannel.block.

Peers Join the Channel

Peer can join the channel with this mychannel.block file (block 0). Note that in the script the file exists in CLI container, and all commands are issued from CLI container. In real life we need to make sure all peers have the same block 0 file.

We use command peer channel join for each peer joining the channel.

peer channel join for all four nodes

Note that after joining the channel, the peer will have the ledger for this channel. Inside the ledger the blockchain begins with block 0, and the ledger world state is empty.

Configure Anchor Peers

In First Network, we will designate peer0.org1 and peer0.org2 as the anchor peers.

We use command peer channel join for each peer joining the channel.

Effectively this is an update on the channel setup, and each update generates a new block (block 1).

If we compare the content inside block 0 and block 1, we see some new information anchor_peers are included.

Block 1 (right side) contains anchor peer information

Similarly, when we do the same for Org2, another new block (block 2) is created.

Chaincode Installation

To use chaincode on a peer, chaincode needs to be first installed on the peer, and then instantiated. In First Network demonstration, chaincode is first installed on peer0.org1 and peer0.org2.

We use command peer chaincode install for each peer joining the channel.

Note that after chaincode is installed on these two peers, there is no update on ledger, both blockchain and world state.

Chaincode Instantiation

In the First Network example, the chaincode is instantiated on peer0.org2. As the chaincode is already installed, we can instantiate the chaincode here.

We use command peer chaincode instantiate for each peer joining the channel.

Note that during instantiation, we need to specify the arguments required on chaincode. The argument list is [“init”, “a”, “100”, “b”, “200”] in this example.

According to the chaincode, it will create two key value pair, “a” and “b”, with value 100 and 200, respectively. The instantiation causes a new block generated (block 3). After all peers receive the committed block from orderer, they update the ledger, appending block 3 on the chain and updating the world state.

If we inspect block 3, we will see the two values set on rwset (read write set). The “reads” part is empty as it is the first time defining these two keys. And the “writes” has the key value pairs. The value is encoded in base64. “MTAw” is 100, and “MjAw” is 200.

Query Current State

In the First Network example we query the value of key “a” on peer0.org1.

We use command peer chaincode query for each peer joining the channel.

Before query can be done, the chaincode needs to be instantiated. As the chaincode is installed already, the chaincode is first instantiated. Then query is performed.

Note that query does not create a new transaction, as there is no change on the world state. The result is directly retrieved from local world state.

Invoke to Update Value

Now we invoke a transaction to update the values. According to the chaincode design, the invoke requires an argument list of [“invoke”, “a”, “b”, “10”]. Also this transaction is sent to both Org1 and Org2 (here to peer0.org1 and peer0.org2) per endorsement policy required.

We use command peer chaincode invoke for each peer joining the channel.

According to the chaincode, this argument list [“invoke”, “a”, “b”, “10”] means to transfer 10 (value) from “a” to “b”.

Chaincode invoke will update the ledger, and therefore a new block (block 4) is generated. After all peers receive the new committed block from orderer, they append the block and update the world state.

If we take a look on block 4, we can see the rwset. In the “reads” part the keys are taken out from block 3 and transaction 0. And in the “writes” part the updated result (which corresponds to 90 and 210).

Query Current State

After the ledger is updated, we query the current state on peer1.org2. Note that we do not have the chaincode installed yet in this node.

We need to install the chaincode first.

We then query the value on peer1.org2.

As before, the installed chaincode is first instantiated before query is performed. Also, as query does not update the ledger, the result is directly taken from the local world state.

This is the end of First Network example. Hope you have a clearer picture what happens after we run this example.