Blockchain Performance and Scalability – Hyperledger Fabric

In the blockchain industry, you may often hear about the discussion on slow performance and limited scalability in terms of blockchain’s size over time, and the increasingly large number of on-board new network participants. You may hear blockchain comparisons to legacy technologies like “VISA-scale throughput” of thousands of transactions per second.  In this article, we will discuss some performance constraints in the Hyperledger Fabric blockchain.

Blockchains that require an access control layer built into the blockchain nodes to read restricted information on the blockchain can be created. This will limit the number of participants in the network who can transact in the consensus mechanism of the blockchain’s network. This kind of blockchain is called a permissioned blockchain.

The differences between public and permissioned blockchains are shown in the following table:

Hyperledger Fabric is the most widely-used permissioned blockchain in the Hyperledger family; it is the cornerstone of the Hyperledger projects hosted by the Linux Foundation. As an open-source enterprise-grade platform, Hyperledger Fabric leverages a highly-modular and configurable architecture. Hyperledger Fabric is optimized for a broad range of industry use cases, including the finance, banking, healthcare, insurance, and public sectors, as well as supply chains and digital asset management.

Hyperledger Fabric supports smart contact development in general-purpose programming languages, such as Java, Go, and Node.js. Hyperledger Fabric is also operating under a governance model to build trust between participants on a shared network.

In the public blockchain, anyone can join the network to execute a transaction. Bitcoin runs a Proof of Work (PoW) based consensus algorithm with 1 block creation time of 10 minutes and a fixed block size of 1 MB. The transaction processing peak throughput is between 3.3-7 transactions per second. The six-block confirmation latency takes around one hour. Currently, Ethereum uses a PoW based consensus that can process roughly 25 transactions per second. With the most recent Ethereum significant software upgrade, dubbed Istanbul on Dec 8, 2019, with several improvements to the network, Ethereum now allowed the integration of a second layer scaling solution to enable more than 3,000 transactions per second (TPS) while maintaining decentralization and privacy.

Ledger: This stores a chain of blocks, which keeps all immutable historical records of all state transitions.

Nodes: These are the logical entities of the blockchain. There are three types of nodes:

1. Client: Clients are applications that act on behalf of a user to submit transactions to the network.

2. Peer: This is an entity that commits transactions and maintains the ledger state.

3. Orderer: This creates a shared communication channel between clients and peers, and it packages blockchain transactions into blocks and sends them to committing peers.

Together with these key elements, Hyperledger Fabric is based on the following key design features:

Chaincode: Chaincode is a similar concept to a smart contract in other networks such as Ethereum. It is a program written in a higher-level language, executing against the ledger’s current state database.

Channels: A channel is a private communication subnet for sharing confidential information between multiple network members. Each transaction is executed on the channel which is only visible to the authenticated and authorized parties.

Endorsers: These validate transactions and invoke the chaincode, sending back the endorsed transaction results to the calling applications.

MSP: This provides identity validation and authentication processes by issuing and validating certificates. It identifies which certification authorities (CAs) are trusted to define the members of a trusted domain, and determines the specific roles an actor might play (member, admin, and so on).

At the high-level flow process, the transaction messages are submitted to the ordering service. The orderer then receives transactions from various channels and queues up these messages per channel. The orderer creates a new block of transactions per channel and delivers the block to all peers through the gossip protocol. The gossip protocol connects the peers in the channel and broadcasts ledger and channel data in a scalable fashion. The transaction message can be communicated in the same organization or between peers in different organizations in the same channel. When adding more peers to the network, it should only affect the performance on the channel peers attended. Other channels will not be affected. The protocol decouples network operations to ensure data integrity, data consistency, and scalability. In the public bitcoin blockchain, all transactions are handled through a series of sequential operations in blocks and are added to the ledger. This sequential process will not gain much performance benefit when using powerful hardware.

In Hyperledger Fabric, the consensus is taken at the ordering service. By adding more peers, you can achieve better concurrency. The ordering service is designed in a modular way as it is totally pluggable. You can also select scalable consensus mechanisms (Solo, Kafka, and BFT) for application use cases. Kafka is primarily a distributed, fault-tolerant, high throughput message platform, which is batch-handling-capable. The Hyperledger Fabric Kafka ordering mechanism utilizes Apache Kafka to handle real-time endorsed transaction data. The ordering service, which can be set up as a cluster of orderers, processes messages with a Kafka cluster, which ensures that each orderer process receives transactions and generates blocks in the same order. This event-driven sync design makes for better performances. Kafka consensus is recommended for production use.

Some performance constraints in Hyperledger Fabric are as follows:

(1) Block-size scaling

(2) Endorser scaling

(3) Endorser policy

( 4) Channels and resource allocation

Block-size scaling

When we increase the block size, related transaction throughput in the block will be increased, but there are many other things that can impact performance. When the block size is increased, it requires more computing power; the storage requirement will go up, and more network bandwidth will be required.

(configtx.yaml), provided by Fabric is as follows:

Here are some configurations:

MaxMessageCount: This defines the maximum number of messages/transactions
to permit in a block per batch.

AbsoluteMaxBytes: This is the absolute maximum number of bytes allowed for serialized transactions/messages in a batch.

PreferredMaxBytes: This is the preferred maximum number of bytes allowed in a batch. A transaction/message larger than the preferred maximum bytes will result in a batch larger than the preferred max bytes. To get a higher throughput, you can increase MaxMessageCount to maximize throughput. In other cases, you can tweak parameters in configtx.yaml to optimize your transaction throughput.

Here is the research result from IBM Research team, the result looks at the impact of the block size and transaction.

Arrival Rate on performance:

When the transaction arrival rate increases, the throughput linear increases. At around 140 tps, the throughput reaches the saturation point and the latency increases significantly. All block sizes will have similar latency. This is because, when a peer receives an ordered transaction, it invokes the Validation System Chaincode (VSCC) to determine the validity of the transaction. During the VSCC phase, the number of validation requests can grow rapidly, which can impact commit latency. When the transaction rate increases before the saturation point, a smaller block size will be faster. When the arrival rate increases, there is no impact on the endorsement and broadcast latency, but there is an impact on transaction latency. The result of this is shown as follows:

Endorser scaling

The peer message communication occurs on the same channel. When adding an endorser’s node to a different channel, it should not impact the channel’s performance. However, in the same channel, adding endorser nodes will significantly impact the performance throughput.

Here, we mainly focus on endorser scaling on the same channel this will add endorsers on different channels that would not have any impact on the performance. Consequently, we limit the test to one channel.

Here is the result of some research on adding tps vs endorsers nodes:

We can see that throughput drops dramatically when endorser nodes increase. When endorse executes chain code, these endorse nodes run independently from one another.

Each endorse has to exchange a message for every endorse node in the same channel. This will significantly add process efforts for each message network communication, and it will impact performance throughput. Consequently, it is typically configured to limit the number of endorsers in the same channel.

The endorser policy

Hyperledger Fabric allows the user to define an endorsement policy to instruct a peer to execute a chaincode. This invokes the VSCC to validate the transaction; the transaction result can be added to the ledger. The endorsement policy can be expressed over principals using Boolean logic syntax.

The syntax of the language is as follows:

EXPR (E [, E…])

Here are a few examples of an endorsement policy:

AND(‘Org1.member’, ‘Org2.member’) requests 1 signature from each of the two principals AND (‘Org1.member’, OR (‘Org2.member’, ‘Org3.member’)) requests a member of the Org1 MSP and either 1 signature from a member of the Org2 MSP or 1 signature from a member of the Org3 MSP.

Here are some research results on the impact of the endorsement policy:

To reduce the VSCC latency and resource consumption, we can decrease the number of fabric identities, signatures, and sub-policies.

Channels and resource allocation

Research shows that, when adding more channels, the throughput increases and latency decreases. The resource utilization also increases:

Only network members in the same channel will involve validation and then commit the ledger process. Each channel transaction is isolated from the other channel. The transaction endorsement, validation, and commit can be executed in parallel when increasing the number of channels. This increases resource utilization with higher throughput.