In the previous episode, we have compared Fabric and other blockchains on their basic characteristics and consensus algorithms. (Link to the previous episode -> Comparison between Hyperledger Fabric – Episode 1)

This episode examines some of the factors to consider when evaluating Fabric.

Factors to consider when evaluating Fabric

Purpose

Unlike a typical blockchain, Fabric is a platform designed to synchronize distributed DB. Rather than transaction content, the final results of the DB that are changed through transactions are used. If the purpose of using a blockchain is to save transactions that prove any actions or documents, a typical blockchain may be a more reasonable choice. Since a user directly signs transactions in a typical blockchain, it is possible to prove the actions of users. In Fabric, a separate function must be implemented to enable such a function.

Performance

The figure above illustrates the transaction forwarding process of Fabric. Before a transaction is broadcasted, peers participating in the channel validates the transaction. The higher the number of peers that operate remotely, or the slower the network performs, the longer it takes for transactions to be forwarded. Also, if multiple peers on the same channel try to send transactions at the same time, it affects the performance of Kafka, which functions as an orderer to ensure orders.

To overcome such issues, attempts have been made to improve performance, such as by putting multiple tasks in a single transaction and forwarding it. However, this method can be equally applied to a typical blockchain, and declining TPS as the number of peer increases can be a fatal weakness.

Competition with the legacy

When Fabric was initially launched, it included some features of a typical blockchain, such as the PBFT consensus algorithm. Today, it uses Endorser and Message Queue instead of the consensus algorithm to better suit the enterprise environment. It also services Private Data function, which enables forwarding data to a specific set of peers within the same channel.

These sophisticated features are being added because of the importance of privacy in the enterprise environment. Fabric, which started with the concept of a blockchain for distributed DB, inevitably challenges the already well-built legacy. Thus, it does not support many advantages of a typical blockchain.

Token system

Some of the clients who consider adopting blockchain intend to develop a token or points system. Such demands have much to do with how blockchain gained popularity through cryptocurrency. In a typical blockchain, its chains and smart contracts are designed while considering currency or token distribution.

The enterprise blockchain presented by Fabric does not have currency involved. Therefore, neither currency nor token is implemented in Fabric,  and a separate chaincode needs to be implemented when currency or token system is required.

Back to Raft and token

The Fabric website introduces as one of the differentiators of the blockchain designed for enterprise use that it “can leverage consensus protocols that do not require a native cryptocurrency.” It also abandoned PBFT, which made Fabric seem similar to the blockchain consensus algorithm and adopted orderer. Recently, IBM, the vendor of Fabric, has made attempts to build a public network by collaborating with several major IT corporations.

Fabric, which was designed in a similar structure with the existing legacy to target the enterprise market, must have experienced significant difficulties in competing with the legacy system. We think that such is the reason why Fabric introduced features of the public blockchain, which it had previously neglected, to provide unique advantages that the blockchain can offer in competing with the legacy system and moved on to pursue a new road map that differs from the past.

Conclusion

Fabric is a platform designed to target enterprise blockchains. To target the enterprise market, it included many features that are required in the existing legacy and eliminated those that are thought to be unnecessary.

However, there is a limit to becoming a general-purpose blockchain by only servicing a limited set of blockchain features when the blockchain can be used in diverse fields and in various ways. Since the typical blockchains are improving their performances by enhancing their consensus algorithms, it is imperative that Fabric also enhances its performance, which yet remains below expectations.

While the public blockchain improved its performance by introducing new features such as DPoS, the complex configuration of Fabric slowed down its performance, and Fabric even lost its backward compatibility. As of now, Fabric is in the process of going back to the original form of blockchain. However, because it had diverted from the path for a very long time, the systems already implemented by Fabric will have to bear the inconvenience from upgrading, and many clients who learned blockchain through Fabric will experience confusion.

Rather than limiting themselves to conventional needs, we hope that the current enterprise IT market leaders like IBM contribute to the blockchain ecosystem by devising new ideas that effectively utilize the benefits of blockchain.