Publications

Resource Analysis of Blockchain Consensus Algorithms in Hyperledger Fabric

IEEE Access, JCR 2020 IF 3.367 Top 34.249%, vol. 10, pp. 74902-74920, 2022, doi: 10.1109/ACCESS.2022.3190979.

Gyeongsik Yang, Kwanhoon Lee, Kyungwoon Lee, Yeonho Yoo, Hyowon Lee, Chuck Yoo

Download PDF

Abstract

In the blockchain network, the consensus algorithm is used to tolerate node faults with data consistency and integrity, so it is vital in all blockchain services. Previous studies on the consensus algorithm have the following limitations: 1) no resource consumption analysis was done, 2) performance analysis was not comprehensive in terms of blockchain parameters (e.g., number of orderer nodes, number of fault nodes, batch size, payload size), and 3) practical fault scenarios were not evaluated. In other words, the resource provisioning of consensus algorithms in clouds has not been addressed adequately. As many blockchain services are deployed in the form of blockchain-as-a-service (BaaS), how to provision consensus algorithms becomes a key question to be answered. This study presents a kernel-level analysis for the resource consumption and comprehensive performance evaluations of three major consensus algorithms (i.e., Kafka, Raft, and PBFT). Our experiments reveal that resource consumption differs up to seven times, which demonstrates the importance of proper resource provisioning for BaaS.

Paper summary

Compare consensus by the resources it consumes

CPU and network measurements reveal the resource cost behind blockchain transaction throughput.

This study compares Kafka, Raft and PBFT in Hyperledger Fabric, measuring resource consumption alongside throughput and latency. It varies ordering-node counts, batch and payload sizes, and failed nodes.

Compare consensus across deployment settings

Containerized nodes run across seven physical servers connected by 10-Gbps Ethernet. The main workload is smallbank, which generates banking transactions. The experiments vary ordering-node count, batch size, payload size and failed nodes, and measure CPU use and network traffic alongside throughput and latency. Profiling also separates nodes that accept or coordinate more work from nodes with lighter roles to expose differences within the ordering service.

The comparison varies deployment parameters and measures both transaction performance and resource use for Kafka, Raft and PBFT.View full-size figure
The comparison varies deployment parameters and measures both transaction performance and resource use for Kafka, Raft and PBFT.

Distinguish CPU cost, network cost and fault tolerance

The evaluated consensus implementations have different resource profiles. Raft uses less CPU than Kafka and PBFT in the reported comparisons, while Kafka has the lowest network bandwidth in the node-count experiments. Increasing batch size helps throughput only up to a threshold, because transaction arrival and block creation also matter. Node failures change performance and resource use within each algorithm’s fault-tolerable range; exceeding that range causes sharp throughput losses.

Resource patterns observed in the tested Fabric consensus configurations.
ComparisonObserved pattern
CPU consumptionRaft uses less than Kafka and PBFT
Network use as node count variesKafka uses the least bandwidth
Work across ordering nodesCPU consumption differs by node role

Key takeaways

  1. Consensus throughput alone hides resource tradeoffs. CPU and network profiles distinguish implementations that transaction rate cannot fully describe.
  2. Resource cost depends on deployment choices and node roles. Batch size, node count, failures and unequal ordering work all affect the measured behavior.