This is my notes about my development experience based on HyperLedger Fabric v1.0 during the last 3 months: May 2017 to Aug 2017.
CAs, Orderers and Peers
A HyperLedger Fabric network has the following 3 types of nodes:
CA: used for user authentication.
Orderer: Central node(can be more than one) to verify and order the transaction.
Peer: Normally there are multiple peers in a fabric environment which stores blockchain and handle the requests.
You can see that a HyperLedger fabric network is NOT a p2p network as Bitcoin or Ethereum because of the existence of orderer/CA nodes.
Chaincode
Like ethereum, HyperLedger Fabric supposts running code(“smart contract”) inside it. In HyperLedger Fabric the code is called chaincode. At this moment, HLF(HyperLedger Fabric) supports chaincode written in Golang and Java. Unlike Ethereum, HLF does not have a VM mechanism to execute chaincode. Instead, in HLF the chaincode looks like a embeded program in which you can leverage the libraray/APIs provided by HLF and finally be invoked by HLF. Comparing to Ethereum, it’s simpler but less prepared.
Docker
Each node (CA/Orderer/Peer) is a Docker instance of the offical HyperLedger Fabric image. When executing a user provided chaincode, HLF will start a Docker instance in which the chaincode is executed. HLF highly depends on Docker.
You can run a full HLF network on a computer which has Docker installed. Each CA/Orderer/Peer node is a Docker instance. By default they use the following ports:
CA service: 7054
Orderer: 7050
Peer: 7051 for peer service, 7053 for event hub service
If all the nodes are on the same Docker host, you can use command like “docker run -p 7151:7051” to forward the request from host port the the Docker instance port.
Relations
A HLF network can have multiple orderers.
A HLF network can have multiple peers.
A HLF network can have multiple organizations, each organization can have multiple users. There are two types of users: admin user and normal user.
A peer belongs to a specific organization. One Organization can has one or more peers.
A channel is a combination of multiple peers from different organizations across which the business logic(chaincode, aka smart contract) is running. The organzations of a channel share blockchain data. If you do so, the channel is built for the involved organizations and they share information over this channel. Note that a peer is unnecessarily binded to only one channel. Instead, it can binded to multiple channels, which means a peer can store data of multiple blockchains, each for a channel. So one channel can have (and should have) multiple peers, and one peer can belong to multiple channels.
Configuration
Use the “cryptogen” command to generate the cryptographic artifacts based on the given “crypto-config.yaml” file.
Use the “configtxgen” command to generate the basic files to start a HLF network like “genesis.block/channel.tx/Org1MSPanchors.tx/Org2MSPanchors.tx”(depends on the organizations you created).
SDK
When a HLF network is ready, you can either use the command line tools provided by HLF or a program using HLF SDK to execute operations on it. Both the command line tools and the programs using HLF SDK, essentially they send GRPC requests to the CA/Orderer/Peer nodes to operate. The nodes in a HLF network use GRPC to communicate.
Currently there are 3 offical HLF SDKs devided by the implementing language: NodeJS, Java and Python. At this moment(Aug 2017) the degree of maturity is NodeJS > Java > Python.
In our project we encapsulate our business logic into a Java web application and make it a Docker image:
It provides REST APIs for outside world to execute operations on the HLF blockchain, such as invoking chainchain, query blockchain transaction/block information.
It uses SDK provided by HLF(in our case it’s Java SDK) to perform the operations under the hood.
The Java web application(war) is packaged with Tomcat in the Docker image and is ready to accept HTTP REST requests after the Docker instance is started.
Process
Here is the process to make the whole thing work.
Use “cryptogen” and “configtxgen” to gegerate files which are needed to start a HLF network. And you have to define the organizations/users/CAs/Orderers/Peers information in this step.
Setup the the HLF network and start CA/Orderer/Peer the nodes.
Create channel.
Make the selected peers join the channel.
Install chaincode on the peers.
Instantiate the chaincode on the peers.
Start the API web application in the Docker images(note the configuration of the web app should point to the correct CA/Orderer/Peer nodes).
Now you can send request to the API web application to perform operations on the blockchain.