Architecting a Hyperledger Solution — Things to keep in mind

At the time of writing this article, there are not many resources available to derive the nodes and architect a Hypderledger Fabric solution. I hope this post will bring some amount of clarity in designing an enterprise level hyperledger fabric solution

You will have to keep following things in mind while architecting a hyperledger solution –

1. Fabric has a highly modular and configurable architecture suitable for a broad range of industry use cases including banking, finance, insurance, healthcare, human resources, supply chain.

The Fabric platform is also permissioned. Unlike a public permissionless network where the participants are known to each other, instead fabric is anonymous and therefore fully untrusted. This means that while the participants may not fully trust one another (they may, for example, be competitors in the same industry), a network can be operated under a governance model that is built off of what trust does exist between participants, such as a legal agreement or framework for handling disputes.

Fabric uses consensus protocols that do not require any cryptocurrency or mining to form blocks or execute smart contracts. It supports pluggable consensus protocols i.e. you can change the consensus protocol in hyperledger fabric. This allows customization of the solution to a particular use case or requirement. For example, when deployed within a single enterprise, or operated by a trusted authority, fully byzantine fault tolerant consensus might be considered unnecessary overload on performance and throughput. In such situations, a crash fault-tolerant (CFT) consensus protocol might be more adequate whereas, in a multi-party, decentralized use case, a more traditional byzantine fault tolerant (BFT) consensus protocol might be required.

2. A “node” is only a logical function in the sense that multiple nodes of different types can run on the same physical server. What counts is how nodes are grouped in “trust domains” and associated to logical entities that control them.

There are three types of nodes as per the hyperledger documentation:

1. Client or submitting-client: a client that submits an actual transaction-invocation to the endorsers, and broadcasts transaction-proposals to the ordering service.

2. Peer: a node that commits transactions and maintains the state and a copy of the ledger. Besides, peers can have a special endorser role ( need not require a separate node for this)

3. Ordering-service-node or orderer: a node running the communication service that implements a delivery guarantee, such as atomic or total order broadcast.

Validation of transactions occurs through the replicated execution of the chaincode and given the fault assumption underlying BFT consensus, i.e., that among the n validating peers at most f < n/3 may “lie” and behave arbitrarily, but all others execute the chaincode correctly. When executed on top of PBFT consensus, it is important that chaincode transactions are deterministic, otherwise the state of the peers might diverge.

Apart from the above mentioned nodes, you may also want to consider a node for certificate authority (CA). As the fabric implements a permissioned ledger, it contains a security infrastructure for authentication and authorization. For connecting to the network every peer needs to obtain an enrolment certificate from an enrolment CA that is part of the membership services. It authorizes a peer to connect to the network and to acquire transaction certificates, which are needed to submit transactions.

Other things to keep in mind while architecting any blockchain solution for an enterprise

1. The participants on the blockchain network must be identifiable

2. Networks need to be permissioned so that no unauthorised or anonymous user is able to join the network

3. There should not be much delay in transactions confirmation time. The latency should be low

4. The number of transactions that can processed in a particular time should be high. That is high through put is a must. You may need to do more research on expected transaction volume for your organisation and then compare it with performance or TPS of the blockchain platform you are planning to use

5. Confidentiality and privacy of transactions is of utmost important for an enterprise. The data must be kept private and should only be accessible to intended audience

Keeping the above points in mind will help you in improved decision making (in terms of ownership, security, nodes, cost) while architecting a blockchain solution. That’s fowsome! Cheers!

Feel free to connect me on Linkedin and Instagram

Architecting a Hyperledger Solution — Things to keep in mind was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.