by John Bentley on September 7, 2018
The Linux Foundation’s Hyperledger project provides an array of options when it comes to Blockchain frameworks. Backed by IBM, Hyperledger Fabric has become one of the more talked about Hyperledger Blockchain frameworks — as IBM has been using it as the basis of many enterprise engagements. IBM has also heavily promoted its Bluemix cloud environment as the “go to” for Hyperledger Fabric Hosting to raise interest in Hyperledger Fabric, as well as the Hyperledger Composer and Hyperledger Explorer tools.
Combining the free availability of the Hyperledger Framework and tools supporting with the backing of IBM, Hyperledger Fabric is an attractive alternative. However, like with any emerging technology, there is good and bad, and plenty of opportunity.
- Assets – the ability to define a basic data model to represent the entities stores on the chain. These code be thing such as a Vehicle, with Make, Model, Year and VIN fields and Bill Of Sale with Vehicle, Buyer, Seller, Price, and Settlement Date.
- Participants – definition of roles people and entities can play in the transactions, such as Vehicle Owner, Broker, and Financer with the ability to define fields in a similar fashion as assets
- Transactions – the actions that change the state of Assets and their relationship, such as Transfer Ownership, Make Offer, and Close Sale. Transactions interact with Assets and Participants.
- Events – custom definitions to inform systems and individuals participating in the Blockchain application, such as Offer Made, Offer Accepted, and Offer Rejected.
- Access Control Lists – defined how Assets can be changed by different Participants within the bounds of Transactions, such as a Vehicle Asset can have the ownership change by a Vehicle Owner Participant using the Transfer Ownership Transaction.
With Hyperledger Composer and Fabric, it is easy to quickly build and deploy a proof of concept. However, more advanced features like leveraging channels will be covered in the Bad.
Another benefit of Hyperledger Fabric is the ability to implement different Consensus Models for managing the blockchain. Consensus is the process by which a majority of nodes agree a transaction is valid. Hyperledger Fabric has made the Consensus Model changeable, currently offering SOLO and Kafka modules with other on development. This means that different Consensus Models can be applied to different blockchain applications needs while still leverage the same core coding techniques.
One more benefit is that since Fabric is permissioned based you cannot just join the network utilizing it. It can only be done through Membership Service Provider (MSP), which is responsible for issuing and validating the certificates, and authorizing users. If a user loses his account, admin can attach the account on the chain to new wallet that is created. This gives the level of user control required on Enterprise systems.
Finally, Hyperledger Fabric supports the creation of channels, which allows a Blockchain network to allow different organizations to exchange information over more private means. For example, a company may have separate channels for multiple competing suppliers. This allows a level of security and confidence above the ACL.
Hyperledger Fabric also has some challenges in its fundamental architecture. For example, the Channel functionality is an attractive feature as competitors do not want to sensitive information in a common data store and application security is not always reliable. However, Hyperledger’s Channel sets up point to point interaction between nodes owned by different organizations. A true blockchain replicates it’s data across all the nodes, improving the integrity and trustworthiness of the transactions and data on the chain.
Hyperledger Fabric’s “channel” method only shares the contract between two or more related parties. In this scenario, if one organization’s node goes down, other organization nodes can modify chain data, Then, the organization that is down has to accept the chain updates from the other organizations. (Think price collusion if multiple suppliers blocked access to their customer to fix prices.) This reduces the reliability to be the equivalent of much more affordable and well know solution using current database technology tied together with Standard APIs and encryption.
Another significant problem with Hyperledger Fabric’s architecture is the support of crash fault-tolerance (CFT) but not full byzantine fault-tolerance (BFT). CFT provides protection against a single node’s failure from disrupting the chain. So, if a node server goes down, the total system keeps on running. However, CFT does not protect the chain from tampering. BFT implements a mechanism to identify compromised nodes, removing the node from operation.
Without BFT, Hyperledger Fabric lacks the ability to guarantee the validity of the Blockchain.
Hyperledger Fabric’s attempt to support both multiple channels and consensus policies has made Hyperledger Fabric much more complicated to manage. Whereas most Blockchain Frameworks utilize a single node component to be run across the Blockchain network, Hyperledger Fabric requires a minimum four types of nodes
The Peer nodes are split into two with one maintaining the ledger and a special endorser which executes the transactions. To take further advantage of Hyperledger Fabrics functionality, you must also add Leader peer and Anchor peer into the mix.
Fabric boasts about reducing the network latency and execution of transaction by moving away from order-execute to execute-order method of committing transaction. This concept is adapted due to issues with Proof-Of-Work (POW) where high computing power is requisite. At the same time instead of having majority of endorsers individually agree on a transaction, Fabric commits transaction after one validation. This deviates from true consensus of what a blockchain is.
Normalize development between Hyperledger Composer and Chaincode, with more documentation focused on NodeJS. As of now most examples are in GO which leads to belief that other languages are not as robust or supported. Hyperledger Composer is more suited for POC than exporting the code for testing and production.
Fabric states that they are in currently in works of developing and integrating BFT, it will be a while before it is ready for production use. For now it can be implemented by adding a module with BFT for consensus, it would still require a lot of work on developing and implementing it.
Reduce number of nodes to be maintained to be max at three. The more types of nodes an organization maintains higher maintenance cost, the chances of failure and possibility of getting hacked also increase relatively.
Improve Channels by preventing chains from progressing when all organizations are not participating so integrity is maintained. Multiple Channels lead to multiple ledgers which can cause issue with data consolidation and secure maintenance. This again deviates from true concept of blockchain and Distributed Ledger.
Hyperledger Fabric use with Hyperledger Composer is a great tool to understand basic data integrity and isolate concepts that Enterprise need to maintain to stay true with Compliance and Info-Sec ruleset. Hyperledger Composer helps create a POC for permissioned based chains using Assets, Participants, Transactions, Events and Access Control Lists. It also helps understand the true near cost of setting up and maintaining chain systems.
At this point, Hyperledger Fabric is much more of a Distributed Database using Distrusted Ledger concepts to approximate a blockchain. However, it is not a blockchain or Distrusted Ledger as the integrity of the chain cannot be guaranteed.
The lack of BFT in a single channel implementation cannot protect against intentional or error-based corruption.
Furthermore, multi-channel scenarios introduced additional opportunities for the information stored by Hyperledger Fabric to be manipulated.
Therefore, Hyperledger Fabric should not be used for production applications until these issues are addressed.
Here are a few resources that may be useful for further research on the topic:
- Leader peer. When an organization has multiple peers in a channel, a leader peer is a node which takes responsibility for distributing transactions from the orderer to the other committing peers in the organization. A peer can choose to participate in static or dynamic leadership selection.
- It is helpful, therefore to think of two sets of peers from leadership perspective – those that have static leader selection, and those with dynamic leader selection. For the static set, zero or more peers can be configured as leaders. For the dynamic set, one peer will be elected leader by the set. Moreover, in the dynamic set, if a leader peer fails, then the remaining peers will re-elect a leader.
- It means that an organization’s peers can have one or more leaders connected to the ordering service. This can help to improve resilience and scalability in large networks which process high volumes of transactions.
- Anchor peer. If a peer needs to communicate with a peer in another organization, then it can use one of the anchor peers defined in the channel configuration for that organization. An organization can have zero or more anchor peers defined for it, and an anchor peer can help with many different cross-organization communication scenarios.