Improvement of Hierarchical Byzantine Fault Tolerance Algorithm in RAFT Consensus Algorithm Election

Abstract

Currently, blockchain technology is not only gaining momentum in the financial industry but also showing promising developments in other sectors. Due to its suitability for various societal needs, an increasing number of non-financial institutions are expanding the scope of blockchain services beyond finance to areas such as healthcare service management and enterprise governance. The core of a blockchain system lies in consensus, which plays a crucial role in its performance and security. The PBFT algorithm is a widely used fault-tolerant consensus algorithm. However, it suffers from issues like high consensus latency, low throughput, and poor performance. In recent years, the HBFT algorithm has addressed these concerns. This paper proposes an improved HBFT blockchain consensus algorithm tailored for large enterprises and non-financial institutions with multiple independent functions. The goal is to achieve more efficient data management and election strategies that are both more secure than PBFT and more efficient than HBFT. Leveraging the enhanced HBFT consensus algorithm ensures stability and efficiency in the consensus and verification processes between organizations. Additionally, it enables the efficient management of data and value creation in the application context.

1. Introduction

The concept of distributed computing can be traced back to the 1960s and early 1970s when researchers recognized the potential of using multiple computers for parallel processing to significantly improve computational speed and processing capabilities. However, it was not until the 1980s and 1990s that distributed computing gained widespread attention and application. The development of distributed computing was driven by several factors. Firstly, the rapid development and proliferation of computer networks provided the infrastructure for distributed computing. Secondly, the research and development of distributed systems like distributed databases and distributed file systems laid the theoretical foundation and practical experience for resource sharing and collaborative work in the field of computing. Additionally, the demand for large-scale scientific and engineering computations also propelled the rapid growth of distributed computing.

In recent years, the rapid development of blockchain technology has made it popular and innovative in the field of distributed systems. As time goes by, an increasing number of industries and domains are recognizing the potential value of blockchain and actively exploring its applications for various purposes. Despite demonstrating enormous potential in different fields, blockchain technology also faces several challenges, including scalability, performance, privacy, and regulatory issues. A notable challenge lies in the proof-of-work [1] consensus mechanism used by Bitcoin, which hinders blockchain’s scalability and energy efficiency. The low throughput and excessive energy consumption associated with this consensus mechanism do not align with the requirements of real-world distributed systems, significantly impeding the future development of blockchain technology.

To overcome these issues, the blockchain community is actively researching and exploring new consensus mechanisms, such as Proof of Stake and Proof of Authority, which are believed to offer higher throughput and better energy efficiency. Through these new consensus algorithms, blockchain technology can better adapt to the demands of different industries and application scenarios, laying the foundation for its large-scale adoption.

Despite the challenges, the future prospects of blockchain technology remain optimistic. With continuous technological evolution and innovation, it is expected to make further progress in addressing scalability, performance, and privacy issues. Blockchain technology is poised to lead innovation in various domains such as finance, supply chain, Internet of Things, etc., laying a solid foundation for the future digital economy. However, as the first application of blockchain in the financial field, Bitcoin has attracted increasing attention from governments, financial institutions, and technology companies [2].

To address the challenges of scalability, performance, privacy, and regulatory concerns faced by blockchain technology, as well as to leverage the inherent security features in certain real-world scenarios, researchers and businesses are continuously seeking solutions. In consortium blockchain, particularly when it comes to choosing consensus algorithms, researchers and practitioners primarily focus on issues related to BFT (Byzantine Fault Tolerance) and CFT (Crash Fault Tolerance) based consensus algorithms.

BFT (Byzantine Fault Tolerance) is one of the methods used to address the Byzantine Generals’ Problem in distributed systems. In the Byzantine Generals’ Problem, there are some nodes that may be malicious, sending false information or executing incorrect operations, leading to a lack of consensus in the system. To solve this problem, BFT proposes a series of fault-tolerant consensus algorithms that enable the system to reach consensus even in the presence of a certain number of malicious nodes. One of the mainstream algorithms to address the BFT problem is PBFT (Practical Byzantine Fault Tolerance), which was introduced by Castro and Liskov in 1999 [3]. PBFT operates in an asynchronous environment and overcomes the efficiency limitations of the original Byzantine fault-tolerant algorithms, reducing the algorithmic complexity from exponential to polynomial levels, making it suitable for practical system applications. PBFT ensures that the system can achieve consensus and maintain security and correctness even in the presence of up to f malicious nodes, where f is at most one-third of the total number of nodes (n) in the network. Since the introduction of the blockchain concept in 2008, PBFT has found widespread application as a consensus algorithm in consortium and private blockchains. It offers higher security and faster execution speed than the traditional BFT algorithm when Byzantine failures are present. However, in real-world scenarios, distributed systems often have tree-like structures rather than star-like structures like PBFT assumes. Recognizing this limitation, Lv et al., proposed HBFT (Hierarchical Byzantine Fault Tolerance) in 2017, specifically designed for tree-structured distributed systems. HBFT introduces algorithms with upper bounds based on the depth and breadth of Byzantine nodes. It addresses the challenges of applying existing Byzantine systems to tree-structured distributed systems while reducing significant computational and storage resource requirements. HBFT offers significant advantages in terms of space complexity but introduces increased complexity in MAC (Message Authentication Code) computation, impacting the overall system performance. Additionally, HBFT continues to use PBFT’s view-change protocol for leader node replacement, which means that Byzantine nodes can only be replaced after consensus has been reached. This can lead to reduced consensus algorithm performance when faced with a large influx of message traffic, and therefore, it is a consideration that needs to be addressed. Overall, considering the limitations and potential impact on performance, it is important to carefully assess the choice of consensus algorithm, whether PBFT or HBFT, depending on the specific characteristics of the distributed system and its intended use case.

This problem is classified under CFT, which stands for Crash Fault Tolerance. In CFT, nodes are assumed to only experience crash faults, meaning they may fail or crash but will not exhibit Byzantine faults like sending false information or executing incorrect operations. CFT algorithms focus on handling node crash faults and ensuring that the system can continue to function properly and maintain consensus in the event of such failures. These algorithms assume that as long as a majority of honest nodes are still operational, consensus can be achieved, and the system’s security can be maintained. In such cases, algorithms like Paxos or RAFT are commonly used as consensus algorithms, as well as other variants based on the principles of the original consensus algorithms. RAFT, proposed by Ongaro et al., in 2014, is an improvement over the Paxos algorithm [4]. Compared to Paxos, RAFT offers a simpler and more understandable design, making it easier to implement. It addresses the problem of effective consensus implementation in blockchain networks where the malicious behavior of nodes is not a concern, making it highly relevant and valuable for research purposes. Due to the higher security requirements in specific application scenarios, the RAFT algorithm has found widespread application in private blockchains. However, it can also be used in combination with other algorithms to cater to different types of blockchains. The flexibility and compatibility of the RAFT algorithm in non-Byzantine environments contribute to its wide adoption and significance in blockchain consensus research. Nonetheless, it is unfortunate that the RAFT algorithm cannot adapt to blockchains with lower security requirements.

In this paper, we propose integrating the RAFT algorithm into the HBFT algorithm to address two issues: the performance reduction of the HBFT algorithm when facing a large influx of message traffic and the inability of the RAFT algorithm to be used in blockchains with lower security requirements. In our proposed algorithm, nodes not only exchange information within the group but also rapidly eliminate nodes experiencing BFT or CFT behavior, thereby improving the algorithm’s performance. To ensure the security and efficiency of interactions between blockchain nodes, we also integrate the ECC (Elliptic Curve Cryptography) algorithm into our proposed algorithm. Experimental results demonstrate that our proposed algorithm outperforms the existing HBFT algorithm in comparative experiments, showing excellent performance. By integrating the strengths of the RAFT and HBFT algorithms, and incorporating ECC for secure and efficient interactions between nodes, our proposed algorithm offers an innovative and effective solution to the performance and security challenges faced by existing consensus algorithms. The experimental results validate the superiority of our approach, making it a promising candidate for practical implementation in various blockchain systems.

1.1. Our Contribution

Although the HBFT algorithm itself is already advanced enough, it has slightly lagged behind in changing the leader node and signature verification based on RSA. In this article, our contributions are as follows:

• To improve the fairness of the HBFT algorithm’s leadership node, granting each node higher authority.
• Combining the ECC signature algorithm with the HBFT algorithm enhances the security of HBFT. Additionally, this integration helps reduce the consensus phase’s latency, thereby increasing throughput.
• Currently, the mainstream research direction is to combine the original PBFT algorithm with RAFT algorithm. There are not many articles in the field of combining the multi-layer PBFT algorithm with the RAFT algorithm. This article provides a new idea for this research direction.

1.2. Related Work

Nakamoto et al., introduced the concept of blockchain in their paper “Bitcoin: A Peer-to-Peer Electronic Cash System” [1], which provided a new application scenario for distributed algorithms. They also proposed the most famous algorithm in the blockchain field, Proof of Work (PoW), which uses a mechanism to demonstrate computational effort. Since then, blockchain has evolved to include three different types with varying levels of security: public chains, consortium chains, and private chains. In the realm of consortium blockchains, consensus algorithms can be mainly categorized into two types. The first type is Byzantine Failure, with Practical Byzantine Fault Tolerance (PBFT) [3,5] being a representative consensus algorithm. The second type is Fail-Stop Failure, with RAFT [4] being a notable consensus algorithm in this category.

PBFT (Practical Byzantine Fault Tolerance) [6] was proposed by Miguel Castro and Barbara Liskov. The PBFT algorithm can operate in an asynchronous environment and addresses the inefficiency of the original Byzantine fault-tolerant algorithm by optimizing it, reducing the algorithmic complexity from exponential to polynomial levels. This optimization made Byzantine fault-tolerant algorithms practical for real-world system applications, and PBFT has been widely adopted. PBFT ensures both safety and liveness as long as the number of faulty nodes does not exceed one-third of the total nodes. However, due to its high communication complexity, PBFT is only scalable to a few dozen nodes. When the number of nodes in the network exceeds this threshold, the time required for transaction consensus in PBFT significantly increases, leading to a decrease in throughput. To address the scalability challenge of PBFT, researchers have conducted in-depth studies on the algorithm. Cowling et al., proposed a hybrid Byzantine fault-tolerant state machine replication protocol called HQ in 2006 [7]. Although HQ did not fundamentally change the structure of PBFT, it optimized the scenario where clients do not compete when sending requests. In 2007, Dahlin et al., introduced speculation techniques to Byzantine protocols, resulting in the Zyzzyva and Zyzzyva5 protocols [8]. While these protocols greatly improved system performance under normal conditions, they suffered a significant performance degradation when faced with Byzantine problems. In their work, Suri et al., presented the Srcooge protocol, which inherited the framework of the Zyzzyva protocol and increased the number of servers to improve system performance. In addition to server-side speculation, Cowling et al., proposed a Byzantine system based on client speculation (client speculation) in 2009 [9]. In 2017, Lv et al., introduced a tree-based topology design for Byzantine fault-tolerant systems, using a multi-branch tree approach to optimize the complexity of the PBFT algorithm. This optimization reduced the communication complexity from O(P²) to O(P), while also improving scalability [10]. Tang et al., proposed an improved algorithm called tPBFT (Trust-Based Practical Byzantine Fault-Tolerant) that is suitable for high-frequency transaction scenarios in consortium chains. It dynamically adjusts the consensus node list by introducing a trust fairness scoring mechanism among nodes in the network [11]. The dynamic adjustment of consensus nodes, when combined with optimization algorithms from artificial intelligence, can significantly enhance the performance of blockchain systems by preselecting nodes. Lei et al., presented an algorithm based on reputation called RBFT, where a node’s reputation determines its probability of being selected as the new primary node to generate new blocks [12]. Zhang et al., proposed the GH algorithm based on PBFT, which divides all replicas into multiple groups, with each group having a primary node. Clients broadcast requests to all nodes, and PBFT is executed within each group, followed by another round of PBFT execution among the primary nodes in each message [13]. Li et al., introduced a scalable PBFT algorithm that uses VRF (Verifiable Random Function) for selecting consensus nodes and simplifies the checkpoint protocol, making it suitable for dynamic networks [14]. Schwartz [15] utilizes the RPCA (Ripple Protocol Consensus Algorithm), which is a high-performance BFT algorithm. Ripple’s consensus is achieved only among validation nodes, and each validation node is preconfigured with a trusted node list called the Unique Node List (UNL). ABC [16] designed a PBFT consensus mechanism with a grouping scoring mechanism and an artificial bee colony optimization process. It uses the artificial bee colony algorithm to preselect a reliable set of nodes and then improves consensus efficiency through grouping mechanisms and a simplified PBFT submission process. The authors of [17] proposed an improved blockchain consensus algorithm based on a genetic algorithm. By combining the genetic algorithm with PBFT, they devised a fitness function for blockchain nodes, iteratively generating high-quality consensus node groups while limiting the consensus to a small portion. Guo et al. [18] proposed a blockchain-based framework for mobile edge computing (B-MEC) for adaptive resource allocation and computation offloading in future wireless networks. The blockchain serves as an underlying system providing management and control functionalities [19]. By dividing nodes into groups and adopting RAFT for consensus within each group, the consensus process is expedited. The RAFT consensus mechanism elects a leader within each group. To ensure efficient consensus between leaders, the PBFT (Practical Byzantine Fault Tolerance) mechanism is employed. This combination guarantees consensus efficiency while maintaining security and reliability.

Paxos is a consensus algorithm for distributed systems proposed by Lamport et al., in 1990 [20]. It is a message-passing-based algorithm that provides efficient fault tolerance and is widely recognized as one of the most effective solutions for achieving distributed consensus. However, Paxos is known for its complexity, steep learning curve, and difficulty in reproduction. After the introduction of RAFT, many researchers have conducted studies and advancements in the field. Lin et al. [21] designed a hybrid consensus mechanism called LRPBFT, which combines the RAFT and PBFT algorithms using a link identification approach. Each subgroup adopts the RAFT consensus algorithm to form a committee and elect a leader, while the committee uses the PBFT algorithm for consensus and leader election. Pan et al. [22] introduced monitoring nodes into the RAFT algorithm to enhance Byzantine fault-tolerance capabilities by analyzing the strengths and weaknesses of the PBFT and RAFT algorithms. These advancements and studies have further explored the RAFT algorithm, addressing its limitations and improving its efficiency and performance in various contexts and applications [23]. An improved PBFT algorithm was proposed to enhance the fault tolerance of the algorithm.

However, to our knowledge, there is currently no research on considering RAFT to improve performance in the leader election stage of HBFT-based blockchain.

1.3. Organization

Section 2 of this article introduces the System and Problem Statement, while Section 3 elaborates on the basic knowledge and techniques involved in the algorithm in this article, providing a foundation for subsequent design. Section 4 discusses in detail the design part, including election operations, consensus completion, and alternative signature algorithms. Subsequently, in Section 5, this article analyzed the actual performance of the proposed algorithm through experiments and demonstrated its performance in practice. Finally, in Section 6, the content of this article is summarized and some ideas for future improvement directions are proposed.

2. System and Problem Statement

2.1. System Model

The Byzantine Model is a consensus algorithm in the field of distributed systems, aimed at solving the problem of Byzantine Fault [6]. Byzantine failures refer to the possible occurrence of arbitrary fault behavior among nodes in a distributed system, including sending incorrect messages, unresponsive messages, sending inconsistent messages, etc. At present, it is mainly used in blockchain, distributed databases, cloud computing, distributed storage systems, Internet of Things and other fields.

PBFT (Practical Byzantine Fault Tolerance) is a fault-tolerant consensus algorithm designed to address the Byzantine fault problem in distributed systems. The Byzantine fault problem refers to the presence of malicious nodes (Byzantine nodes) in a distributed system that can send incorrect messages and disrupt the normal operation of the system. The PBFT algorithm introduces the concept of a replicated state machine, allowing nodes in the system to achieve consensus and execute operations in the same order, even in the presence of Byzantine nodes. It exhibits high fault tolerance and security in practical applications. However, it is important to note that the performance of the PBFT algorithm is directly proportional to the number of nodes, as it requires a significant amount of message passing and verification. To improve performance, optimization techniques such as fast path optimization, batching, and asynchronous communication can be employed.

HBFT is an improvement of the PBFT algorithm in 2017 [10] that can be applied to a structured Byzantine fault-tolerant system. It is designed to address the challenges of performance and scalability in large-scale distributed systems while maintaining system security and fault tolerance. To achieve this goal, HBFT organizes system nodes into multiple levels or hierarchies, with each level consisting of multiple subcommittees. The consensus protocol within each subcommittee is performed using the PBFT algorithm, and cross-subcommittee consensus is achieved through a similar protocol. In the internal network communication process, each subcommittee has a primary node and multiple backup nodes. The primary node of each subcommittee participates in the global consensus process, while backup nodes are responsible for backing up the consensus at their respective levels. In the event of a primary node failure, the backup nodes within the subcommittee take over its role to ensure the normal operation of the system. The hierarchical structure of HBFT improves system scalability, as nodes within each subcommittee can execute the consensus protocol in parallel, reducing consensus latency. Additionally, the protocol between subcommittees reduces the complexity of message exchange and computation, thereby improving system performance. Furthermore, HBFT provides strong fault tolerance and can tolerate malicious nodes and Byzantine faults.

Figure 1 illustrates the consensus process of the degree-3 HBFT algorithm protocol.

Table 1. Comparison of three algorithms.

Characteristics	PBFT	HBFT	RAFT
Communication complexity energy saving	O(P2)	O(P)	O(P)
Byzantine Fault Tolerance	33%	<66%	N/A
Scalability	Low	High	High
Degree of de-centralization	High	High	Low
Fairness of leader node	Medium	Medium	High

provides a comparison of three algorithms, revealing that each algorithm has its advantages and disadvantages. The RAFT algorithm demonstrates better performance but cannot handle Byzantine faults. The PBFT algorithm falls short in some aspects, while the HBFT algorithm performs well but lacks the fairness of the RAFT algorithm. Hence, the HBFT algorithm can benefit from the insights of the RAFT algorithm to address its shortcomings.

2.2. The Improved HBFT

Our mHBFT consensus algorithm employs blockchain technology to construct a distributed architecture. While ensuring system security, our approach focuses on optimizing the performance of the HBFT consensus algorithm through two main methods. Firstly, during the layering process, we utilize the election mechanism from RAFT to replace the view-change technique. By using a voting-based leader election approach, we can rapidly select leaders and leverage the stability of the RAFT algorithm to ensure the stability of the blockchain. Secondly, we leverage ECC as a replacement for RSA to expedite the consensus time of the HBFT algorithm, thus increasing throughput while maintaining system security. In Section 5, we provide experimental evidence to validate this idea. Finally, we incorporate batch processing operations to further enhance the performance of our mHBFT consensus algorithm. The addition of batch processing further optimizes the efficiency of our approach. By integrating these optimizations, our mHBFT consensus algorithm demonstrates improved performance while maintaining security and stability. The combination of RAFT’s election mechanism, ECC, and batch processing operations contributes to the overall efficiency and effectiveness of our solution.

3. Preliminaries

In this section, we will introduce the technologies to be used in the initial implementation of our algorithm proposed in this paper.

The RPC (Remote Procedure Call) protocol is a protocol used for remote invocation, allowing client applications to call functions or procedures on a remote server over a network, as if they were calling local functions. The RPC protocol is commonly used in building distributed systems and client/server applications. When implementing RPC, the following guarantees and objectives are typically followed:

Transparency: RPC should be transparent to the developers of client and server applications, who do not need to be aware of the implementation details of remote invocation and can use RPC just like local functions.

Interoperability: RPC should be able to interoperate across different platforms and programming languages. Therefore, it must have a consistent interface and protocol.

Reliability: RPC should ensure the reliability of invocations in case of network or server failures. Therefore, it must have mechanisms such as retry, timeout, and error handling to handle such situations.

Efficiency: RPC should have high-performance capabilities, allowing fast data transmission over the network while maintaining low latency and high throughput.

Security: RPC should have necessary security mechanisms to protect the security and confidentiality of remote invocations. This includes mechanisms such as encryption, authentication, and authorization.

4. Design

4.1. The Advantages of the mHBFT Algorithm

The proposed mHBFT algorithm in this paper is designed as a blockchain storage strategy based on the HBFT algorithm. We consider its advantages and features from the following perspectives:

• Strong fault tolerance: The HBFT algorithm can ensure the consistency and correctness of the entire system even in the presence of up to (P − 1)/3 × (2l − 2)/L Byzantine nodes (i.e., malicious nodes) in the network, thus demonstrating strong fault tolerance.
• High performance: Compared to traditional BFT algorithms, the HBFT algorithm achieves higher performance in scenarios with fewer Byzantine nodes. This is because it employs a scalable design where nodes are distributed in a hierarchical manner and consensus is reached through multiple rounds of protocols. This approach allows for optimal utilization of system resources, thereby improving performance.
• Security: The HBFT algorithm ensures the security of the entire system by employing cryptographic techniques to guarantee the confidentiality and integrity of messages, thereby preventing attacks from malicious nodes. We aim to enhance the security of the HBFT algorithm without compromising its core functionality.
• Fairness: The HBFT algorithm ensures fairness among all nodes during the consensus process, where each node has an equal opportunity to participate and receive equal rewards. Our goal is to enhance fairness for all nodes, allowing them not only to participate in the consensus but also to have the chance to become leader nodes and gain higher privileges.
• Scalability: We aim for the HBFT-RAFT algorithm to maintain the high scalability of the original HBFT algorithm while incorporating the benefits of the RAFT algorithm.

4.2. Committee Election

To enhance consensus efficiency and algorithm stability, we propose the mHBFT consensus algorithm. The mHBFT algorithm combines the benefits of the layered approach in HBFT with the advantages of the RAFT algorithm in leader selection and detection. This combination ensures the stability of the blockchain and improves consensus efficiency. In this section, we will only introduce the operational process of the mHBFT algorithm when an election operation is required.

The system designed in this paper undergoes a hierarchical processing of nodes during the initialization process. In each layer, the RAFT leader election algorithm is used to elect the leader for that layer, allowing each layer to operate independently. Utilizing the RAFT algorithm for leader selection empowers nodes with higher authority. To prevent system crashes or temporary interruptions due to device failures, network connectivity issues, or other reasons that may hinder consensus, the algorithm incorporates the heartbeat mechanism from the RAFT algorithm to monitor the liveness of nodes within each layer, ensuring the stability of the blockchain. This enables quick resolution of CFT (crash fault-tolerant) events when detected. Moreover, the leadership nodes in this algorithm are randomly generated, ensuring a higher level of fairness. Finally, the mHBFT algorithm allows for convenient integration of results to achieve consensus. The leader election process of the mHBFT consensus algorithm is depicted in Figure 2 as shown in the election process.

4.3. Model Comparison

In this section, we will compare the model proposed in this paper with other models that combine PBFT and RAFT algorithms. We will also discuss the advantages of the algorithm proposed in this paper. The consensus process of the PBFT algorithm is depicted in Figure 3. It can be observed that PBFT’s communication complexity during consensus can be O(N²). As a result, as the number of nodes increases, the consensus latency will significantly rise, leading to a decrease in performance, including throughput.

Other models combine the original PBFT algorithm with the RAFT algorithm by dividing blockchain nodes into two groups: the consensus group and the candidate group. For example, RBFT proposed in [19] adopts a sharding approach to partition the blockchain network nodes into groups. Within each group, RAFT is used for consensus, and leaders are elected through the RAFT consensus mechanism. Between leaders, the PBFT mechanism is used for consensus, ensuring consensus efficiency. RBFT also incorporates supervisor nodes to address the issue of RAFT consensus being unable to resist Byzantine malicious behavior, thus ensuring the security of the consensus mechanism. Figure 4 illustrates the consensus process of the RBFT algorithm. As shown in the figure, RBFT’s communication complexity is similar to PBFT, both being O(N²), indicating a relatively low scalability. When supervisor nodes detect Byzantine nodes within the group, a new node is re-elected to replace it as the leader and participate in consensus. While this approach effectively addresses the issue of RAFT’s inability to detect Byzantine nodes, it introduces additional operations and cannot handle CFT problems promptly.

Our algorithm is based on the HBFT algorithm model, integrating the RAFT election process, a trust mechanism, and corresponding detection mechanisms. Once a Byzantine node is detected, the algorithm initiates a re-election process within the group to select a new leader node, effectively pushing the Byzantine node to the lowest level of the layered network. This prevents the Byzantine node from quickly returning to the main consensus area and assuming the role of a leader node. Additionally, our algorithm, after incorporating the RAFT algorithm, can detect CFT (crash fault-tolerant) issues with leader nodes at other times. Moreover, our algorithm exhibits O(N) communication complexity, as discussed in Section 4.6 of this paper.

4.4. The Re-Election Process

The original HBFT algorithm’s view-change protocol can be triggered by the client. In this type of triggering mechanism, the client is typically responsible for determining whether the servers have reached a consensus. If a consensus is not reached, it indicates that there might be issues with the server’s operations. If the issue lies with the primary node, the client can request the server to replace the primary node.

In our improvement of the HBFT algorithm, we have enhanced the handling mechanism for unexpected node behavior. Instead of using view-change to replace Byzantine nodes within the group, we decided not to adopt this approach because the replacement nodes generated through view-change might lack representativeness. Additionally, if the blockchain encounters CFT situations instead of BFT scenarios and cannot be addressed promptly, it could significantly reduce the blockchain’s efficiency. To address these concerns, we have chosen to utilize the election mechanism from the RAFT algorithm as a replacement for view-change. This way, we can more effectively elect representative nodes to replace Byzantine nodes within the group. By incorporating the RAFT algorithm, we can also implement the heartbeat mechanism, allowing us to detect leader nodes without having to wait for the consensus phase to end. This improvement ensures better maintenance of blockchain stability. With these modifications, our enhanced HBFT algorithm can efficiently handle unexpected situations, maintain representativeness in node replacements, and promptly address issues related to both CFT and BFT scenarios, thereby improving the overall efficiency and stability of the blockchain.

The main difference between our improved HBFT and the original HBFT lies in the ability to rapidly detect when a leader within the group becomes a Byzantine node. Once we detect the occurrence of a BFT or CFT situation within the group, our algorithm utilizes its own selection mechanism to quickly choose a new leader node and broadcasts this information to other nodes outside the group for verification. During the leader node election process, the eligibility of the elected leader is confirmed based on the leader’s historical records. We have referred to existing consensus algorithms and made improvements and adjustments based on the HBFT algorithm during the leader node election process. Figure 5 illustrates the flowchart of the operation when a leader node is detected to become a Byzantine node during the consensus process and the message is sent to other nodes within the group to initiate the re-election process.

Suppose there is a group in a certain layer of the system, consisting of n nodes. When a node in the group detects that the leader node has become a Byzantine node, it will send a request for a re-election to the remaining nodes, excluding itself. This stage is referred to as t1, and the number of communications in t1 is

t1 = n − 1.

(1)

When other nodes receive the message, they will send corresponding requests to the leader node to confirm whether it has become a Byzantine node. In this case, the number of communications is

t2 = n − 2.

(2)

After discovering that the leader node has become a Byzantine node, an intragroup election will be held. The RAFT election algorithm will be used to vote on the candidate node, where the communication number is

t3 = n − 1.

(3)

When a candidate node receives more than half of the votes, it will become a leader and notify the superior group that it has become a leader node. The communication number here is 1, and it will also broadcast itself as a leader node to other members in the group. The communication number at this stage is

t4 = n.

(4)

So, if there is a situation where the leader node becomes a Byzantine node, the total number of communications for the re-election of nodes within the group is

tSum = t1 + t2 + t3 + t4 = 4n − 4.

(5)

After comparing the view-change algorithm used in the original HBFT algorithm with our improved algorithm for re-election, we have discovered that our enhanced re-election algorithm significantly reduces the communication count and time required when dealing with Byzantine issues in the system. This is a positive development for our system.

4.5. Optimization and Security Analysis in the Consensus Stage

4.5.1. Consensus Stage Optimization

In the PBFT algorithm, digital signatures serve the purpose of ensuring message integrity, identity authentication, and resistance against attacks from Byzantine fault nodes. Digital signatures not only provide identity verification but also validate whether messages have been tampered with. In the PBFT algorithm, the RSA algorithm is commonly used for digital signatures. In RSA, nodes use their private keys to encrypt messages and generate digital signatures, while other nodes can use the corresponding public keys to verify the signatures. RSA is known for its high reliability and strong security. However, it has been criticized for its relatively slow encryption/decryption speed and the requirement for larger key lengths. As a result, the use of RSA in the PBFT algorithm can impact the algorithm’s operational speed in the system, thereby reducing system throughput and increasing latency, among other adverse effects.

Refs. [24,25] provide a comparison between RSA and ECC. Although the ECC ecosystem is relatively less mature compared to RSA and is suitable for relatively smaller environments, in the experiments conducted, the ECC algorithm outperforms RSA in terms of operational efficiency and security. For RSA to achieve this security level, it requires a 2048-bit key. On the other hand, ECC, being more efficient in terms of key size and security, only needs a 224-bit key to achieve the same level of security. Additionally, the ECC algorithm outperforms RSA in terms of total runtime for encryption and decryption, which is beneficial for the current requirements of the PBFT algorithm. The advantages of ECC over RSA in terms of key size and operational efficiency make it a promising choice for cryptographic operations, especially in resource-constrained environments, which could potentially improve the overall performance and efficiency of the PBFT algorithm.

4.5.2. Security

When the primary node is a Byzantine node, it may broadcast inconsistent pre-prepare messages to all consensus nodes or not respond to client requests. In such abnormal situations, the consensus cannot be reached in the prepare phase, triggering a RAFT election to replace the primary node. Our solution aims to reduce trust in the malicious primary node. In subsequent operations to update the set of consensus nodes, the malicious primary node is moved to the lowest level of the hierarchical network. This ensures the trustworthiness of the nodes involved in the consensus. The specific operations have been described in Section 4.2.

When the number of Byzantine nodes in a certain layer is f, and the total number of nodes in that layer is greater than or equal to 3f + 1, any node can receive consistent messages from at least 2f nodes during the prepare and response phases. Therefore, in this layer, Byzantine nodes do not affect the consensus process. In summary, the improved consensus algorithm in this paper can successfully pass verification in each round, and the results are trustworthy. By utilizing the ECC elliptic curve encryption algorithm, compared to the RSA encryption algorithm used in the original HBFT algorithm, the ciphertext in the consensus phase of this paper is more secure and reliable, and the signature verification phase is more time-efficient than in the original HBFT algorithm. This will be further discussed in detail in the experimental analysis section in Section 5.

4.6. Improving the Communication Complexity of HBFT

For the PBFT (Practical Byzantine Fault Tolerance) algorithm, communication complexity is an important consideration. Optimizing communication complexity can improve the system’s performance and efficiency, reduce resource consumption, and ensure the reliability and stability of the communication process. PBFT is a fault-tolerant consensus algorithm used to solve the Byzantine Fault Tolerance problem in distributed systems. In PBFT, nodes achieve consensus by exchanging messages with each other frequently, so communication complexity directly affects the algorithm’s performance. While reducing communication complexity can improve performance and scalability, other factors such as security and fault tolerance need to be considered as well.

Communication complexity refers to the total amount of communication between nodes during the execution of an algorithm. It can be calculated based on the number of messages exchanged, message sizes, and message transmission patterns. In this paper, the algorithm calculates the communication complexity by considering these factors during the corresponding steps of the algorithm.

In the proposed algorithm described in Figure 6, assuming the top layer consists of n/3 nodes, the middle layer consists of n nodes, and the bottom layer consists of 3n nodes, the communication count for submitting and distributing tasks can be calculated as follows:

T_submit = T_distribute = n + 3n + n/3,

(6)

T_consensus = 4n.

(7)

Based on the analysis, the communication complexity of the proposed algorithm in this paper can be considered as O(n). Compared to the algorithm that combines PBFT and RAFT, the proposed algorithm in this paper shows significant improvement in terms of communication complexity. Additionally, the algorithm will further benefit from the batch processing operation that will be introduced. The experimental data will be presented in detail in the next section to demonstrate these improvements.

5. Modification of the HBFT Algorithm

In this research, we conducted simulation experiments on a computer using the GO programming language to evaluate the performance of the PBFT, HBFT, and mHBFT consensus algorithms. The experiments involved testing the performance of blockchains with varying numbers of nodes. To validate the implementation of the consensus, we ensured that clients received the correct consensus results. The experiments were conducted on a China, Guangxi, Lenovo computer equipped with an i5-11400F 2.6 GHz processor and 16GB RAM. Through these experiments, we assessed and compared the throughput and transaction latency of the three consensus algorithms. The purpose of these experiments was to gain a deeper understanding of the performance characteristics of different consensus algorithms and to identify any potential advantages or limitations of each algorithm under different node numbers and workload conditions.

5.1. Algorithm

The HBFT algorithm is an improved version of the PBFT (Practical Byzantine Fault Tolerance) consensus algorithm, where consensus can be reached by a subset of nodes corresponding to less than two-thirds of the total nodes. PBFT consensus requires all nodes to perform repeated verification and confirmation, which increases the operational cost of the network and leads to duplicate processing.

In our mHBFT algorithm, our goal is to improve the efficiency and stability of the PBFT consensus algorithm in asynchronous networks by adopting flexible node selection and leader node election formulas during the consensus process. Unlike the previous HBFT algorithm, which used a fixed method to select representative nodes, our improved algorithm employs a flexible approach for this purpose. Figure 7 illustrates the consensus process of our improved HBFT algorithm. To enhance the performance of the blockchain, we utilize a more efficient broadcasting method. Instead of broadcasting data to all nodes like in the PBFT algorithm, we only broadcast data to nodes within our own group. Additionally, we only accept reply messages from nodes within our group. This communication strategy significantly reduces the complexity of the algorithm and simplifies the consensus process, thereby improving the overall performance of the blockchain. By leveraging this approach, we can achieve a more streamlined and efficient consensus process in the mHBFT algorithm, leading to increased throughput and reduced latency in the blockchain network.

Moreover, our algorithm incorporates the RAFT election approach in the election process, granting greater power to individual nodes. This results in increased randomness in the selection of leader nodes, which helps to better protect the blockchain network.

The RAFT algorithm is a consensus algorithm used in distributed systems. Its goal is to achieve consistency and fault tolerance in a distributed system, ensuring data consistency among multiple nodes and maintaining system availability in the event of node failures. The RAFT algorithm achieves consensus by electing a leader and using a heartbeat mechanism to maintain the continuity of the leader. Each node can be a candidate, leader, or follower. When a node starts up, it becomes a candidate and initiates a new election. During the election process, the candidate requests votes from other nodes and becomes the leader when it receives a majority of votes. Nodes can time out during the election process to prevent the process from indefinitely prolonging. In summary, the RAFT algorithm is a consensus algorithm used to achieve consistency in distributed systems. It employs leader election, log replication, and security mechanisms to achieve fault tolerance and data consistency.

Based on the characteristics of the RAFT algorithm and drawing inspiration from multiple papers that combine PBFT with the RAFT algorithm, we propose the integration of the HBFT algorithm with the RAFT algorithm. In Figure 8, we demonstrate the transition relationships between the leader, candidate, and follower states in the RAFT algorithm. In our assumed scenario, our algorithm ensures that each layer and each group have at least nodes participating in the consensus. By having a minimum of nodes participating in each layer and group, our algorithm satisfies both the minimum node requirement for consensus involved in the PBFT algorithm and the minimum node requirement for the election phase in the RAFT algorithm. Our integrated algorithm can promptly react and elect a new leader when a leader node is either elected or detected to have problems, making our network more stable. This integration allows us to leverage the advantages of both algorithms and enhance consensus efficiency and stability.

5.2. Throughput

In this section, we conducted experiments on the blockchain network with an increase in the number of nodes from 4 to 25. The nodes were divided into different groups for the experiments. Our goal is to evaluate the scalability and performance of the integrated HBFT and RAFT algorithm in the network environment.

The experiments involved measuring various performance metrics such as throughput, transaction latency, and consensus efficiency for each configuration of nodes and groups. The results of these experiments would provide valuable insights into the behavior and capabilities of the integrated algorithm under different network conditions, helping us assess its suitability for practical deployments in real-world blockchain systems with varying node numbers and group structures.

TPS, or Transactions Per Second, refers to the number of transactions or operations that can be processed per second. It is a commonly used metric to measure the processing capacity and throughput of a system, network, or application. In this paper, we define TPS as the number of transactions submitted per second. TPS is influenced by factors such as system architecture design, the number of system nodes, and the size of data input. To evaluate the performance of our proposed algorithm improvements in terms of TPS, we conducted experiments and compared them with the HBFT and PBFT algorithms. We kept the data size and the number of agreed-upon transactions constant and performed experiments with 4 to 25 nodes. The results show the relationship between TPS and the number of nodes, as illustrated in Figure 9, which presents a comparison of TPS between mHBFT and PBFT and HBFT algorithms.

$$\mathrm{TPS}=\frac{\mathrm{T}\mathrm{r}\mathrm{a}\mathrm{n}\mathrm{s}\mathrm{a}\mathrm{c}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{s}}{td}.$$

(8)

Formula (7) represents the calculation formula for TPS, where td denotes the time taken to complete one consensus.

From the TPS comparison graph in Figure 9, we can observe that our algorithm maintains consistent TPS with the HBFT algorithm until the total number of nodes reaches seven, and it outperforms the PBFT algorithm significantly. However, when the total number of nodes exceeds seven, the throughput of our algorithm starts to gradually deviate from the HBFT algorithm’s TPS. This indicates that our algorithm demonstrates a high-performance advantage as the total number of nodes increases.

Furthermore, as the total number of nodes increases, the algorithm’s TPS decreases, indicating an increase in consensus latency. To address this issue, we propose integrating batch processing operations into the improved algorithm. Batch processing operations can significantly improve efficiency, reduce errors, enhance consistency, and provide convenience, offering significant benefits and advantages. Figure 10 shows the TPS comparison graph after integrating batch processing operations, displaying the experimental results between algorithms with and without batch processing operations. The results demonstrate a noticeable improvement in TPS for our algorithm after integrating batch processing operations. This indicates that batch processing operations alleviate the latency issues caused by an increase in the number of nodes.

Based on the comprehensive analysis of Figure 9 and Figure 10, our mHBFT algorithm’s throughput will increase by approximately 10% compared to the HBFT algorithm when incorporating batch processing operations at the same number of nodes. This is a significant result, indicating that our algorithm’s efficiency and performance are effectively enhanced by combining batch processing operations and utilizing ECC instead of the RSA algorithm. These improvements enable our algorithm to handle transactions more efficiently while maintaining high security levels. As a result, our mHBFT algorithm demonstrates promising practical applications in distributed systems.

5.3. Latency

In this section, we compare the latency of the mHBFT algorithm with the HBFT and PBFT algorithms by varying the number of nodes. We recorded the time interval from transaction initiation to the client receiving the completion of consensus, which serves as the measure of latency. The experiments were conducted multiple times, and the average values were taken for comparison.

The system latency is defined as the average time interval from the activation of the protocol in the first node to all nodes reaching consensus and obtaining the result. Additionally, we also considered the baseline latency in the experiments, which refers to the delay required for each node to propose a single transaction throughout the protocol execution process. Figure 11 illustrates the comparison of latency between PBFT, HBFT, and the proposed improved algorithm in terms of the number of nodes.

We measure the time interval from when the data are sent from the client to when the corresponding data are received as our benchmark for latency. As shown in Figure 11, the proposed improved algorithm, the PBFT algorithm, and the HBFT algorithm all experience a slight increase in latency with the increase in the number of nodes. However, it is evident that the improved algorithm exhibits a much slower growth rate in latency compared to both the HBFT and PBFT algorithms. Specifically, the PBFT algorithm’s latency reaches 180ms. Therefore, from these experiments, we can conclude that our algorithm reduces latency by 66% compared to PBFT and by 33% compared to HBFT. This improvement in latency allows our algorithm to handle company transactions more efficiently, enabling companies with multiple functional departments to achieve consensus more quickly and complete tasks assigned by upper management in real-life scenarios.

5.4. Discussion

Based on the simulation experiment results mentioned above, our mHBFT algorithm demonstrates significant improvements over the HBFT algorithm in various aspects. By adopting the mHBFT algorithm, it becomes feasible to utilize the proposed hierarchical Byzantine fault-tolerant consensus mechanism to manage internal affairs within real-world companies, which holds tremendous significance for the practical adoption of blockchain technology in everyday life.

Compared to HBFT, the mHBFT algorithm exhibits outstanding performance in terms of throughput, latency, and consensus efficiency. The combination of the RAFT election process and flexible leader node selection enhances the stability of the algorithm. Additionally, replacing the RSA algorithm with the ECC algorithm for cryptographic procedures in our HBFT algorithm accelerates the consensus process, reducing latency and improving throughput while maintaining system security and efficiency. Furthermore, the introduction of batching in our HBFT algorithm further enhances consensus efficiency and mitigates the impact of increasing node numbers on latency.

With these enhancements, our mHBFT algorithm has demonstrated better performance in TPS, latency, and consensus efficiency. It opens up possibilities for the real-world application of blockchain networks in various large-scale companies to efficiently manage transactions and accomplish tasks.

6. Conclusions

With the development of society and the rapid progress of science and technology, blockchain technology is expected to be widely applied and become the mainstream technology for efficient management and value creation of internal and external data for enterprises and organizations. Due to the need for redundant consensus and verification processes among all nodes in the presence of Byzantine faults, PBFT incurs higher network operating costs as the number of nodes increases. Additionally, the PBFT algorithm itself may not be well-suited for the operational structure within large enterprises and organizations. Therefore, in the future, the HBFT consensus algorithm is likely to replace the PBFT algorithm for consensus within major enterprises and organizations.

Indeed, in the proposed strategy, where the HBFT algorithm is combined with the RAFT algorithm for blockchain, it has been shown that the HBFT algorithm performs more efficiently and provides fairer operation in a tree-based network model compared to the HBFT algorithm alone. Additionally, by incorporating the ECC signature algorithm and batch processing, the algorithm enhances the security and scalability of the system. These improvements contribute to the overall effectiveness and reliability of the consensus process in the blockchain network.

In this paper, we have modified the view-change protocol of HBFT by incorporating the RAFT election algorithm into our algorithm. In the future, we aim to further improve the election strategy by introducing trust mechanisms and similar methods to achieve more secure and efficient elections. Additionally, we aspire to grant greater power to individual nodes in the network. Regarding the security of the ECC algorithm, it may not be exceptionally high. However, we can enhance the security of the algorithm by selecting encryption algorithms with higher security, such as homomorphic encryption, as a replacement for the ECC algorithm, thus enhancing the overall security of the algorithm.