Why “BYFN” Again? Isn’t there an official one?
Right, in Hyperledger Fabric document, there is a “Building Your First Network” Tutorial, but I think it is not detailed enough. This tutorial set is more or less the same as the official one, but with some more explanations on files.
In case you are not so familar with Blockchain, I recommend that you could take a look here. That covers what Blockchain, Hyperledger Fabric and Smart Contract (Chaincode) are conceptually.
But you might also read my short summary at the moment:
Basically, Blockchain is a cryptographically linked list of data blocks. Hopefully, it is unmodifiable and decentralised, following a certain consensus. In Fabric, Orderer is the consensus, Peer maintains the Blockchain data.
Hyperledger Fabric is one of implementations of Blockchain, and it is intended to use in business context, where there is a group of organisations joining in the Blockchain network (each organisation then contributes some nodes in the network).
Smart Contract (Chaincode) is a program that is interacting with the Blockchain following certain business logics. In Fabric, Peer is the node to run it.
Hyperledger Fabric — The Transaction Flow
Here is the simplified transaction flow in Hyperledger Fabric (how a transaction is submitted and written into the Blockchain ledger, I assume that there is no error):
- The client sends a transaction request to Backend with Hyperledger Fabric SDK. (Client → SDK)
- Backend forms a transaction proposal and sends it to the Peer Node. (SDK → Peer)
- Peer node executes smart contract (chaincode) and sends the result to Backend. (Peer → SDK)
- Backend sends the transaction to Orderer node. (SDK → Orderer)
- Orderer node will collect some number of transactions (or trigger timeout) and orders for those transactions. Then, it packs those transactions into a Block and broadcasts to Peer nodes. (Orderer → Peer)
- Peer nodes validate the transaction, commit the transaction into the Blockchain ledger, and send transaction committed notification to Backend. (Peer → SDK)
- Backend sends success notification to the Client. (SDK → Client)
Overall, the flow: Client → SDK → Peer → SDK → Orderer → Peer → SDK → Client. The path is kind of long…
1. Install Prerequisites
We use Hyperledger Fabric v1.4 in this tutorial.
First of all, you could install prerequisites by following the official instructions:
2. Files Structure
In this part 1 tutorial, I am going to introduce files in BYFN. I plan to introduce all files in 2 parts. Then, we continue some practical steps.
Let’s switch to BYFN directory (*supposed that you finish the prerequisite part, you should have all needed files and directories):
This is the file or directory list that we will study:
- docker-compose-cli.yaml (Part 1)
There are other files in fabric-samples/first-network/, but they are not directly related to BYFN, we will ignore them.
In order to develop Blockchain application, we need to have a Blockchain network first, right? This is a file related to setting up the network.
This is a Docker compose file, which defines your (virtual) Fabric network, such as what nodes are in the network, their internal use domain names, etc.
Line 1 defines our Docker network name, such that our nodes could have a “place” to talk to each other. And this “place” is named byfn.
Line 4 defines a list of nodes in the network.
Line 5 defines a node in our network — Orderer, which helps decide how transactions and blocks are ordered in the Blockchain network.
You see in line 6, there is an extends, which is to re-use another base Docker compose file. I could smell the odor of “Inheritance” in programming.
Line 9 defines this node’s name in the network. Finally, line 10 defines which network this node belongs to.
And line 13–43 are similar, but they define another type of nodes in our network — Peer, which is to maintain the Blockchain ledger, validate the transaction, execute smart contract (chaincode) in the Blockchain network.
Line 45 defines the cli, that is, command line interface, to control (send commands to) network nodes. Line 47 indicates the image of this cli, just like a Windows 10 image for a Windows 10 virtual machine.
Line 48 tty is to make sure that the cli keeps running. Line 50 we are defining some environment variables used by some programs for the cli, such as GOPATH — where the go library is.
Line 62 specifies what the default location is when we access the cli. Line 63 specifies that when the cli starts, executes this Linux command automatically.
Line 64 defines mount points for the cli. That is, we map some directories in our local machine, probably your Linux, to some directories in the cli (which is a virtual machine, called container in Docker).
Line 70 specifies that the cli depends on some other containers, like: without them, without me.
That’s all for part 1. Hopefully, I could finish introducing files and directories within 2 parts. Then we can continue some practical steps.