Hyperledger Fabric is a young project and because of that there’s hardly any resources online. It’s a very long learning curve for anyone who jumps in without prior experience in blockchain architecture. Even for us, in spite of having knowledge with public blockchains, we faced issues and figuring them out was difficult. This article lists down the common mistakes that people make or misunderstand while developing with Hyperledger Fabric.
Organizations & Peers
When it comes to any Blockchain network, the first thing that comes to the mind is where do you define the decentralized nodes. With a HL Fabric network, the peers are the physical layer where the data is stored and processed. All the peers get their certified by a single Membership Service Provide (MSP). Where as the organizations are a just a grouping of peers.
Fabric Tools Version
It’s important to note that the version of cryptogen must match the version of Fabric that you’ll be developing with. Without this the crypto-config.yaml and configtx.yaml will not be read properly by the tools required to generate certificates.
Random Numbers In Chaincode
It’s a very common to create lot of random numbers to use as identifiers in our business logic. This works perfectly in a centralized system, however porting this logic to a blockchain network causes each of the endorsing peers to have different data. Subsequently causing the endorsement policy to fail since the ReadWrite set will not match when the orderer checks it.
Life Cycle of Crypto Config
When creating a new network, a default crypto config gets generated which contains the certificates for each component (Peer, Admins, CA and Orderers) of the network. During development it’s quite common to regenerate the config as many times as needed. However in production it’s dangerous to do this as it causes certain certificates to be invalidated. If so, you will come across this issue,
Principal deserialization failure (the supplied identity is not valid: x509: certificate signed by unknown authority (possibly because of “x509: ECDSA verification failure” while trying to verify candidate authority certificate “ca.org0”))
Installing & Instantiating Chaincode
The chaincode is the business logic that is used to verify data during each transaction. The chaincode should be installed and instantiated in all the peers that are involved in the endorsement process. However in other peers you will not need to store chaincode.
Endorsment Policy
It’s always advised to have more than one mandatory endorsing peer to prevent a single point of failure. If the network accepts any member to sign, they can easily modify their state data and submit an invalid transaction. This which will get reflected in all the peers without any second check as the ReadWrite set will be compared only with itself. Thus you make sure that you assign multiple levels of signing the transactions.
Ledger Data & State Data
In HL Fabric, there are two levels of data. The first one is the ledger data which holds all the transaction information in form of block which is the typical blockchain ledger. All the invoked transactions are recorded here, irrespective of whether it is successful or not. The second one is the state data, used to store the applications state. This data is stored either in Level DB or Couch DB. The ReadWrite sets are generated with this data.
These are the common things that people misunderstand during HL Fabric development that I noticed. I will keep extending this list as I find some more.
If you faced a common issue that I haven’t mentioned here, write to me!