The fifth generation of blockchain, Hyperledger paved the way for business giants to enter the distributed technology sphere. With technology advancement, Hyperledger Fabric made it possible to tailor-design the blockchain architecture instead of the “one-solution-fits-all” approach.
Background
Hyperledger Fabric is a business-grade distributed ledger on blockchain which uses smart contracts, which are called chaincode, to enforce trust between parties.
Hyperledger was started by IBM as an open source project. Post building the application for enterprise grade applications, the tech giant decided to open source it. IBM partnered with Linux Foundation who are renowned for best maintaining open-source projects.
Hyperledger as a Problem Solver
Permissionless blockchains proved to be great for use-cases. However, when it came to implement permissionless blockchain to safeguard sensitive information, it failed! The problem was that the transaction nodes still needed to be approved, executed and maintained in a ledger by all the peers.
Hyperledger network is distributed only across the participating enterprises, these organizations only validate each other’s transactions. Hyperledger also solves the scalability issues and makes a high transaction throughput possible.
Pros of Hyperledger Fabric
#1 Modularity
Hyperledger Fabric is designed to have a modular architecture. Right from the core, Hyperledger fabric components are configured to meet the diversified businesses requirements.
According to the industry, there is definitely no “one blockchain that caters to all needs”. Hyperledger Fabric can be altered and configured in numerous ways to suit diverse business needs.
At a high level, Fabric is comprised of the following modular components:
- The consensus of transactions is established with a pluggable ordering service and then only the blocks are broadcasted to the peers.
- The entities in the network are associated with cryptographic identities through a pluggable membership service provider.
- An optional peer-to-peer gossip service disseminates the blocks output by ordering service to other peers.
- The output of the block can be broadcasted to peers by an optional peer-to-peer gossip service.
- Chaincode (Smart Contract) is run in isolation for e.g. Docker. Smart Contracts can be written in the standard programming languages however they cannot directly access the ledger state.
- A ledger can be developed to support a variety of DBMSs.
- Pluggable endorsement and validation policy enforcement can be developed independently according to requirement.
#2 Smart Contracts
Smart contracts aka ‘Chaincode’ in case of Hyperledger Fabric functions as the business logic in the blockchain technology. Chaincode takes leverage from in-built trust of the blockchain technology and underlying consensus from the peers.
3 key factors that apply to Smart Contract especially when applied to a platform:
- numerous chaincode (smart contract) runs parallelly in the network,
- they can be deployed dynamically, and
- application code should be considered as untrusted and potentially harmful.
As of now smart-contract in the blockchain run on an order-execute environment where the consensus protocol validate and order transactions and broadcasts it to all the peer nodes in the network, each peer node then sequentially executes the transaction.
Most blockchains today run on this order-execute blockchain environment. The issue in this order-execute environment is that the smart contract running here needs to be deterministic otherwise a consensus might never be reached. To solve this issue, smart contracts have been written in non-standard languages like Solidity with which the non-deterministic operations are eliminated. However, this hinders blockchain large scale adoption as smart contracts need to be written in an altogether new language and it may lead to programming errors. Moreover, as all transactions are only executed sequentially, performance and scale are limited.
#3 A New Approach
With Hyperledger Fabric a new architecture called ‘execute-order-validate’ is introduced. This architecture addresses the confidentiality, performance, resiliency, flexibility and scalability issues seen in the order-execute model by separating the transaction in 3 different steps:
This architecture is radically different from the order-execute model as Fabric executes transactions before finally reaching an agreement on the order.
The application-based endorsement policy in Fabric specifies which peer nodes, or how many of them need to validate to correctly execute the conditions mentioned in a smart contract. As a result, each transaction needs to be executed only by those peer nodes to fulfill the conditions of the transaction’s endorsement policy. This allows the system to parallelly execute multiple nodes thereby increasing overall performance and scale of the system. The first phase also eliminates any non-determinism, as erratic results can be filtered out before ordering.
As Fabric eliminates the non-determinism issue, it has become the first blockchain to enable the use of standard programming languages to write smart contracts. In the 1.1.0 release, the smart contracts will be written in either Node.js or Go; in the subsequent releases it is envisioned that the platform will support other popular programming languages like Java.
#4 Privacy and Confidentiality
As widely known, the public blockchain network runs on Proof-of-Work concept and the transactions are executed on every node. Every transaction and code that is implemented is visible to every node in the network. This means neither the smart contract stays confidential nor the transaction data which is processed. This means we have exchanged the privacy of the contract and data for the public consensus concept of PoW.
This lack of privacy is problematic for businesses. For example, in a supply chain business, some partners might be offered additional discounts as a means of solidifying business. If everyone in the network is able to see the contract and transaction, it won’t be possible to do business – everyone will ask for the discounted rates!
Hyperledger Fabric as a permissioned blockchain offers privacy and confidentiality through its channel architecture. With Fabric, one can establish a “channel” between the subset of participants who should be granted the right to access a set of transactions. Like a network overlay, only the nodes that participate in a channel have the access to the chaincode (smart contract) and transaction data. This helps to preserve confidentiality and privacy and builds trust in the network. To enhance the privacy and confidentiality aspect, Fabric is offering support to keep the data private and is developing zero knowledge proofs (ZKP).
#5 Pluggable Consensus
This modular architecture allows the platform to rely on well-established toolkits for CFT (crash fault-tolerant) or BFT (byzantine fault-tolerant) ordering.
The modular component for consensus in Hyperledger which is assigned to order transactions is not directly linked with the peers who execute transactions and maintain ledger. As consensus is modular, its implementation can be set to trigger with the trust assumption of a particular deployment or solution. Moreover, a Fabric network can have various ordering services supporting different applications or application requirements.
#6 Performance and Scalability
Varied factors like transaction, block and network size along with hardware limitations can affect the performance of blockchain platform. The Hyperledger community as of now is developing a new framework called ‘Hyperledger Caliper’ to deal with the performance and scalability issues.
While things seem to progress well in the development direction, benchmarking efforts are being undertaken to significantly improve the performance for the Fabric v1.1.0 release.
CONS OF FABRIC
In the crypto world, there are people who think Hyperledger Fabric comes with vital disadvantages. Their claim is debatable as these people are supporters of decentralized and public blockchains only.
Below are their concerns with Fabric, and the counterpoints from supporters of Fabric
| Concerns with Hyperledger Fabric | Resolutions |
| Fabric is permissioned and therefore negates the fundamental motive of a blockchain as it doesn’t allow complete transparency. |
Fabric is developed to be used in B2B (business-to-business) and B2C (business-to-consumer) environment where only trusted participants need to have the access.
|
| The consensus algorithm used in Fabric is not as secure as PoW. |
All the participants in Fabric network are already verified using an internal identity management system so there is no need to apply PoW.
|
| There is no crypto token in Fabric translating into no incentives for nodes to keep the network secure. | Fabric can support tokens. However, there is no need for tokens in this blockchain as such. With no tokens, there will be no anonymous transaction therefore, security will not be an issue and expensive mining isn’t necessary. |
| Fabric cannot be an immutable ledger without PoW. |
As Fabric is developed to be used in businesses and organizations with known participants, all bound by a code of governance and code of conduct of the organization, what is needed is a ‘tamper-evident’ system. The cryptographic hash will reveal if data is being tampered and then the organization can initiate the necessary corrective process.
|
So, we hope we helped you understand about Hyperledger Fabric and just made you think about if you could adopt it to accelerate the growth of your business. If you still need help, reach out to us and we’ll glad to be the guide.
Next up in the blockchain education series is Corda.
Also, do subscribe to our YouTube channel and watch the blog space to stay updated!
.jpg)
