IBM Answers Questions About Hyperledger Fabric Blockchain Performance and Scale
In a recent blog post, IBM aims at answering the questions and doubts that several individuals in the cryptocurrency market had about the Linux Foundation’s Hyperledger Fabric performance and scale. According to the company, there has been a lot of confusion and FUD related to this issue.
According to IBM Hyperledger Fabric does not have problems with scaling. However, it might not offer the results expected for specific applications. Thus, the company explains that the results will have an impact depending on the kind of use that firms give to it.
Christopher Ferris, IBM Distinguished Engineer, and CTO Open Technology in the IBM Digital Business Group, started to write a series of articles to provide best practices guidance and the latest information related to the Hyperledger Fabric.
He starts the post by explaining that when considering the performance of any blockchain framework there are several factors that can affect the framework itself. The first thing that Ferris mentions is that there is an application client. The programming language in which this client was written will have an impact on the choice of Hyperledger Fabric software developer kit (SDK). Furthermore, the client itself can have some issues since there is no software defect-free, according to Ferris.
The second thing that he shares is that there is the Hyperledger Fabric peer (endorser/committer) and choice of ledger database. The two ledger databases are LevelDB and CouchDB.
Finally, he says that there is a physical and/or virtual infrastructure that all of the services run on that can severely affect performance.
Users and individuals have been asking several questions regarding what can have an effect on the performance of the Hyperledger Fabric. Some of the things asked by users were the number of endorsing peers, the number of endorsements, the number of organizations, the complexity of chaincode, the size of transactions, the memory allocation, the network speed and many others.
Although Ferris will not be trying to address all these questions in just an article, he will be trying to provide some answers to these and other questions.
The first question that he will answer is ‘Does the number of endorsers effect performance?.’ About it, he says that yes, it will affect the performance depending on the network composition.
In order to provide a full answer, Ferris gives a very interesting example with some assumptions.
“Say you have a network that has two organizations with two peers each for resilience. These peers are each joined to a channel comprised of the two organizations. […] Let’s say that the endorsement policy requires a single endorsement from either organization. Let’s further start with only one of each organization’s peers configured as an endorser.”
He went on saying that the transaction load generator will be randomly selecting one of these endorsers for each transaction proposal. Ferris says that for this experiment, the network will be running Hyperledger Fabric 1.3.0 in a single Kuebrnetes cluster running on the IB Container Service.
The results were the following:
Ferris shows that it is possible to scale throughput by load balancing endorsement across a pool of endorsers.
He noted that there will be a moment in which transaction latency becomes untenable due to the fact that peers become saturated and consume all the CPU available. According to Ferris, it is possible to scale beyond the number of TPS shown in the results, if they decide to tolerate more latency.
He has also talked about another myth that spread that says that Hyperledger Fabric limits the number of peer nodes in a network. He says that this is very far from being the truth.
In the future, Christopher Ferris will be addressing several other issues, some of those were mentioned in the article. This would help interested parties to understand how Hyperledger Fabric works and how it scales properly in case it is needed.