IBM Blockchain Sets the Record Straight on, “Does HyperLedger Fabric Scale?”
Hyperledger Fabric is a blockchain protocol from IBM, and serves as its base of development with a modular architecture. Fabric combines different components of blockchain technology and makes them plug and play: consensus and membership services can easily be included.
Fabric was designed with the intention for enterprises to form their own blockchain networks that can scale to up to 1,000 transactions per second. Its network architecture was designed using the language Go and allows for the formation of consortium blockchains with customizable permissions. Its smart contract system is named Chaincode and every peer in the network runs what are called Docker containers.
To use resources efficiently, Fabric uses a lower amount of nodes than public chains and is able to compute a massive amount of data in parallel. This is what allows Fabric to scale more efficiently than chains open to the public such as bitcoin or ethereum. An added benefit of Fabric is that it allows confidential data to be stored and thus affording users with a greater level of privacy than public blockchains.
Since Hyperledger Fabric v1.1.0, the software has undergone numerous development and performance improvements to the chain’s scalability.
Scaling Hyperledger Fabric
There are actually two dimensions or forms of scale when it comes to blockchains. The first of which is performance of scale, which encompasses the number of peers connected in Fabric as well as the number of channels. The second form of scale is termed operational scalability as the associated chaincode grows as use increases.
Fabric architecture can be described as a network of overlapping networks. While technically feasible, this network configuration has in the past presented some challenges for companies that offer Fabric as a service, or as a blockchain solution.
Due to Hyperledger’s unique architecture, the network organically supports sharding. Sharding is a process where the shard channels are hosted on independent ordering services. What this means in practice is that as the shards become overloaded, one can set up a new ordering service to host the new channels without affecting uptime or the operations of the network.
Scaling Hyperledger Fabric In Practice
To start with how Hyperledger Fabric can scale, it’s worthwhile explaining the relationship between Fabric and its chaincodes. The current version release (V1.4.0 LTS) for managing Fabric and the associated chaincodes can at times be a tedious process to manage. The problem lays in the lack of in-built tools for administering channels and their respective chaincodes.
To rectify this management problem, the majority of the managed services using the IBM blockchain platform has implemented their own tools for state channel management; these resources make the user experience less cumbersome and easier to manage as a whole.
Fabric has a reputation of being cumbersome to use when deployed out-of-the-box. However, the release of software development kits (SDKs), as well as the command-line interface (CLI) can make the job easier.
The good news for the protocol is that there is an active community built around Fabric that do their very best to make the technology easier to use. Additionally, the next v2.0.0-beta release is set to introduce some anticipated changes. Specifically, the update will refactor the operations of the chaincode and its lifestyle. This will reportedly simplify the complexity that that comes with managing multiple channels as they are created.
Demonstrating The Performance Of Fabric At Scale
Despite popular opinion to contrary, Hyperledger fabric does not suffer from a degradation of performance from the number of channels when used at scale – even when the network surpasses a hundred or more channels at once. This fact can be seen firsthand with the release of Fabric v1.4.0 and v1.4.1.
An experiment last summer showing Fabric’s ability to scale was conducted last summer by IBM researchers. Their findings include a network 128 nodes and 325 channels, and was claimed to be quite successful.
The next step for IBM is to allow this test to be run on demand so that users and clients can see the results for themselves.