Reputation-Based Leader Selection Consensus Algorithm with Rewards for Blockchain Technology

Abstract

Blockchain technology is an emerging decentralized and distributed technology that can maintain data security. It has the potential to transform many sectors completely. The core component of blockchain networks is the consensus algorithm because its efficiency, security, and scalability depend on it. A consensus problem is a difficult and significant task that must be considered carefully in a blockchain network. It has several practical applications such as distributed computing, load balancing, and blockchain transaction validation. Even though a lot of consensus algorithms have been proposed, the majority of them require many computational and communication resources. Similarly, they also suffer from high latency and low throughput. In this work, we proposed a new consensus algorithm for consortium blockchain for a leader selection using the reputation value of nodes and the voting process to ensure high performance. A security analysis is conducted to demonstrate the security of the proposed algorithm. The outcomes show that the proposed algorithm provides a strong defense against the network nodes’ abnormal behavior. The performance analysis is performed by using Hyperledger Fabric v2.1 and the results show that it performs better in terms of throughput, latency, CPU utilization, and communications costs than its rivals Trust-Varying Algo, FP-BFT, and Scalable and Trust-based algorithms.

1. Introduction

Undoubtedly, one of the biggest technologies with a bright future is blockchain technology. The cryptocurrency Bitcoin was the initial application that used blockchain technology [1]. A blockchain is a distributed ledger technology that eliminates the need for a centralized or outside entity to verify data. Recently, many government and private business sectors have adopted it on a large scale for various applications. According to data from the World Economic Forum (WEF), blockchain technology is expected to contribute 10% of the global Gross Domestic Product (GDP) by 2025 [2]. The primary factor driving the appeal of blockchain technology is its distinct features, which include the capability to transfer information between institutions in an effective, permanent, tamper-proof, and transparent manner while preserving its immutability and privacy [3]. Blockchain technology provides data security and reliability because when data is entered into the ledger, it cannot be lost [4].

Recently, blockchain-based techniques have mostly been employed by many security systems to ensure secure data verification and storage [5]. In addition, blockchain systems provide data integrity during transmission and protect against threats of message tampering [6]. Blockchain technology is simple to use and it works similarly to a peer-to-peer network in that transactions are initiated by users, and then a block is created. After every network node receives the created block, it is checked and added to the current chain using a consensus algorithm [7]. All blocks are connected with each other via hash values, and this connection of blocks makes it difficult for malicious users to alter data because they have to make changes to every block of the blockchain [8]. Moreover, a consensus algorithm is used, which helps in the security and efficient management of the blockchain network. Blockchain can be divided into three types: public, private, and consortium [9], which is why each type uses its own type of consensus algorithm.

A public blockchain is a decentralized permissionless blockchain where anyone on the network can view information and contribute to the consensus process. Examples of public blockchain include Proof of Work (PoW) and Proof of Stake (PoS) [10]. A private blockchain is permission-based, where data are accessible to selected nodes of the network; also, data modification acceptance is restricted to authorized parties. Similarly, the consensus process responsibility is assigned to a single or more than one pre-defined network node [11]. Consortium blockchain, sometimes referred to as Federated blockchain, allows information to be presented to all users or nodes, but it restricts who can accept and modify it. The goal is to share authority among several authorities to reach a consensus that is impartial and shared, rather than having a single full-control authority [12].

A consensus algorithm is one of the essential elements of a blockchain-based network that ensures a tamper-proof environment and the validity and consistency of the data saved [13]. That is why it is crucial to design a consensus algorithm carefully to obtain better results. The consensus process begins when a new block of transactions is disseminated to every mining node in the network. Currently, different types of approaches have been designed to manage the consensus process, and these approaches can be broadly divided into proof-based and vote-based approaches to select a leader/miner node for mining purposes [14].

In the proof-based consensus algorithms, the existing nodes of the network must do some mathematical work to become leaders. The node that first answers the problem correctly will append a block into the chain and receive a reward [15]. Some well-known examples are PoW [16], PoS and Delegated Proof of Stack (DPoS) [4], and Proof of Authority (PoA) [17]. Conversely, in the vote-based consensus algorithms, network nodes work in a collaborating manner to select a leader node. The most famous vote-based consensus algorithms are Practical Byzantine Fault Tolerance (PBFT) [18], Raft [19], and Ripple [8]. In recent years, a significant amount of effort has been made to enhance network performance in the domain of blockchain technology’s consensus algorithm. However, the majority of consensus algorithms are not created to improve all necessary network efficiency features such as throughput, latency, CPU utilization, communication overhead, and security in mind. From the literature review section, it can be concluded that all of the consensus algorithms do not cover all the important above-mentioned network efficiency features in one place. The following are the main contributions of the proposed consensus algorithm:

• We introduce a resilient consensus algorithm for the leader selection in the consortium blockchain using the reputation values of the nodes and the vote-based method.
• Security analysis is carried out to evaluate the proposed consensus algorithm’s resilience against the malicious activities of network nodes.
• Hyperledger Fabric v2.1 is used for performance evaluation. The results were computed and compared in terms of throughput, latency, CPU usage, and bandwidth communication consumption with currently recognized consensus algorithms.

The rest of the paper is organized as follows: Section 2 provides a brief overview of different leader-based consensus algorithms that utilize the reputation value of nodes. Section 3 discusses the proposed consensus algorithms in detail. Section 4 presents a security analysis. Section 5 provides a performance analysis and comparison in terms of throughput, latency, CPU usage, and communication cost. Finally, Section 6 concludes the paper.

2. Literature Review

In this section, several reputation values and voting-based consensus algorithms for leader selection are discussed.

Wang et al. [20] proposed a grouped PBFT (GPBFT) consensus algorithm based on the trust level of the network nodes. First, it elects master and proxy nodes using the EigenTrust trust model. Next, it splits network nodes into several groups such that the consensus process within each independent group does not impact the other groups. This significantly lowers the communication overhead of the consensus process. Du et al. [21] introduced a Mixed Byzantine Fault Tolerance (MBFT) consensus algorithm for consortium blockchain, which divides network nodes into verifying nodes, backup nodes, and clients. Verifying nodes are further subdivided into a low-level consensus group (LCG) and a high-level consensus group (HCG). The LCG nodes pack the transactions sent by clients and deliver the mini-block to the HCG after the consensus has been obtained. The nodes authenticate and gather the mini-blocks from several LCGs into a large block. Now, a node is randomly selected from the HCG as a leader based on a random number to add this block to the existing chain. The responsibility of the backup node is to report any malicious behavior of the verifying node and verify a block packed by the verifying node.

Guo et al. [22] presented a proof-of-event recording system for autonomous vehicles and it divides vehicles into community, accident, and witness groups. The “community” group vehicles are outside the transmission range of the accident vehicles, while the “witness” group vehicles are closest to the accident vehicles. The election process begins with the “accident” vehicle broadcasting an election message containing the GPS coordinates of the “accident” vehicle as well as all of the IDs of “verifier” vehicles to all “verifier” vehicles. Each vehicle has a reputation score; a vehicle that has a reputation score higher than a pre-established threshold is referred to as a “verifier”, and a vehicle with the least delay time is selected as a leader verifier.

Zhang et al. [23] proposed a consensus algorithm based on the trust values of nodes and it divides network nodes into accounting, validating, and propagating. The nodes in the accounting group have the highest trust values, whilst the nodes in the validating group have lower trust values than those in the accounting group, but higher than those in the propagating nodes. A node is randomly selected from the accounting group nodes to serve as the current leader node, which is in charge of assembling transactions into blocks. The main job of the validating group is block validation, whereas the responsibility of the propagating group is block propagation inside the network. The network node responsibilities are dynamic as they are updated and modified based on their trust values at the end of each cycle.

Sarfaraz et al. [24] presented a reputation-based proof-of-cooperation algorithm for supply chain management applications. It classifies network nodes as high-authority or subordinate based on the trust level values of the nodes. The subordinate nodes are further separated into various groups, and each group creates a small transaction block that is forwarded to the authority nodes. These small blocks of subordinate nodes are combined into one large block by the authority nodes. Finally, a leader node of the authority nodes, which is randomly selected, adds the large block in the chain. The roles of the network nodes are flexible and change after each consensus round.

Na et al. [25] suggested an improved PBFT-based consensus algorithm with dual primary nodes known as Dual-Primary-Node-Derived Practical Byzantine Fault Tolerance (DPNPBFT). Initially, it chooses two master nodes by considering the concept of power separation. To prevent excessive centralization, as in a single master node system, the two master nodes monitor and check each other’s balances. Additionally, DPNPBFT’s architecture achieves a 49% fault tolerance rate, supports 1700 TPS, and also has good anti-host-node malicious performance and communication complexity at the O(N) level. Yu et al. [26] proposed a PoW-based consensus mechanism that selects a leader via the voting process and the reputation score of the node. To calculate the reputation score, it uses the total amount of legitimate work contributions made by a node over a given period. Olivera et al. [27] introduced a consensus algorithm based on the reputation values of the network nodes. Among high-reputation-value nodes, one is randomly chosen as a leader node. The reputation values of nodes are updated regularly after a specified period.

Aluko et al.’s [28] work is based on the reputation values, and the nodes with the greatest reputation values are included in a consensus group. Next, a leader is randomly selected from the consensus group using a random function. Uddin et al. [29] proposed a consensus algorithm for IoT applications using the voting process to select a leader or master node. The main goal of the proposed consensus algorithm is to increase scalability in terms of verification and validation rates. Bashar et al. [30] introduced a multi-leader-based consensus algorithm for healthcare applications. It assigns leadership responsibilities to a quorum or collection of nodes. Every member of the quorum submits a list of transactions as opposed to having one leader decide which outstanding transactions should be included in the block or removed. Pang et al. [31] presented a consensus technique called node-state-checkable Practical Byzantine Fault Tolerance, or sc-PBFT, to prevent the selected leader or master node from having any malicious records.

Hu et al. [32] proposed a delegated PoS or Reputation-DPoS consensus algorithm to improve the conventional DPoS consensus process. The network nodes are categorized into various trusted states based on their behavior. High-quality nodes within the network are then chosen as consensus nodes. Qushtom et al. [33] introduced an algorithm that combines PoS and PBFT, and it utilizes trust score and reward systems as essential elements. The outcomes demonstrate the effectiveness of the decision making, even in situations when there is a significant probability of dishonest node behavior. Misic et al. [34] presented an algorithm that combines multiple-entry PBFT voting on a permissioned blockchain network with the PoS consensus technique. It presents several PoS classes that are based on the initial stake and are voting honesty. Wang et al. [35] proposed an improved PBFT-based consensus algorithm using bidirectional waning credit value and the credit value of the nodes based on their performance in the consensus process. First, a few nodes are selected to form a committee based on the ballot and credit value, and then the committee nodes utilize the PBFT algorithm for consensus.

Liu et al. [36] presented an enhanced PBFT consensus algorithm using a grouping policy and credit model. To lower the likelihood that the master node is malicious, it divides network nodes into various categories based on the credit model, each with a distinct set of tasks. Qin et al. [37] designed a Weighted Byzantine Fault Tolerance (WBFT) consensus algorithm using node trust values to reduce the likelihood of the malicious behavior of malicious nodes and to enhance the security of the blockchain system. Liu et al. [38] developed a fast-pipeline Byzantine (FP-BFT) consensus algorithm that processes multiple rounds of transactions in parallel using a non-leader-pipeline framework. Consensus agreement can be obtained inside the committee by nodes broadcasting and voting after randomly choosing 2f + 1 nodes to form a committee for one round of transactions. Committee members who take part in the consensus are selected randomly to prevent monopolies, which leads to block producers.

Kapse et al. [39] proposed a trust-based hybrid consensus algorithm which combines PoW, PoS, and Proof of Temporal Trust (PoTT) to increase security while preserving higher QoS levels. To create miner-level trusts, the PoTT model combines temporal mining energy, throughput, block mining efficiency, and delay. These trust values are combined with stake levels and work efficiency to pick miners. Du et al. [40] proposed a trust-level consensus algorithm for the Internet of Vehicles to guarantee the security of the Road Side Units (RSUs) of the network by reducing the probability of malicious nodes taking part in the consensus process. Security and privacy concerns can compromise the robustness of autonomous vehicles and jeopardize passenger safety [41]. The proposed algorithm computes the reputation values of RSUs using a multi-weighted subjective logic (CRMWSL) model. Secondly, it enhances the consensus protocol of conventional double-layer PBFT, modifies the committee election procedure, and increases throughput by lowering the number of consensus nodes to guarantee the effectiveness of blockchain data consensus. To guarantee node credibility and a certain level of election randomness, the committee combines the hash method and credibility value. In the PBFT consensus process, the global consensus is carried out by the regional master node after the regional committee consensus has been completed. Hussain et al. [42] introduced a consensus algorithm based on the trust values of the network nodes. It divides network nodes into two groups, and a mining node is chosen randomly from the group of high trust values.

Table 1. Summary of leader-based selection consensus algorithms in blockchain.

Ref	Publication Year	Mechanism	Throughput	Latency	Computational Cost	Communication Cost	Security Analysis
[20]	May, 2022	○ EigenTrust model ○ Vote-based	✓	✓	✕	✓	✓
[21]	May, 2022	○ Election-based ○ Node trust level	✓	✓	✕	✕	✓
[22]	Oct., 2021	○ Hyperledger Fabric ○ Group-based policy ○ Reputation score	✓	✓	✕	✕	✓
[23]	Sep., 2021	○ Trust values of node ○ Group-based policy	✓	✓	✓	✕	✕
[24]	Apr., 2023	○ Reputation score ○ Group-based	✓	✓	✕	✕	✓
[25]	July, 2022	○ Dual primary nodes ○ Vote-based	✓	✕	✕	✓	✓
[26]	Feb., 2019	○ Voting and reputation value of nodes ○ PoW-based	✓	✕	✕	✕	✓
[27]	Oct., 2020	○ Reputation values ○ Random function ○ Dolev threat model	✓	✓	✕	✕	✓
[28]	July, 2021	○ Reputation values ○ Random function	✓	✓	✕	✕	✓
[29]	Nov., 2021	○ Voting process to select a leader	✓	✓	✕	✕	✕
[30]	Aug., 2022	○ Multi-leader-based ○ Voting process	✕	✕	✕	✓	✓
[31]	Aug., 2022	○ Node reputation ○ PBFT	✓	✓	✕	✕	✓
[32]	Jan., 2021	○ Reputation-score- and vote-based ○ Ethereum platform	✕	✕	✕	✕	✓
[33]	July, 2023	○ Using PoS with PBFT ○ Node trust level ○ Reward system	✓	✓	✕	✕	✕
[34]	Feb., 2023	○ Initial stake and voting process ○ Semi Markov model	✓	✓	✕	✕	✕
[35]	Nov., 2023	○ Credit value ○ Vote-based ○ Group-based	✕	✓	✕	✓	✕
[36]	Aug., 2023	○ Credit model ○ Group-based	✓	✓	✕	✓	✕
[37]	Aug., 2022	○ Trust level of nodes ○ Group-based	✓	✓	✕	✕	✓
[38]	Apr., 2023	○ Vote-based ○ Random function	✓	✓	✕	✕	✓
[39]	May, 2024	○ Trust level ○ Using PoW and PoS	✓	✓	✕	✕	✕
[40]	Sep.,2023	○ Reputation values ○ PBFT	✓	✓	✕	✓	✓
[42]	Oct., 2024	○ Trust values ○ Group-based	✓	✓	✓	✓	✕
Proposed work		○ Reputation values ○ Random function ○ Election process	✓	✓	✓	✓	✓

(‘✓’: performed; ‘✕’: not performed).

summarizes the latest well-known leader-based selection consensus algorithms in terms of throughput, latency, computational cost, communication cost, and security analysis.

3. Proposed Consensus Algorithm

The proposed consensus algorithm uses the trust level or reputation value of network nodes and vote-based techniques to efficiently select a leader for appending a block in the chain. When the consensus process is initiated for the very first time, a random function is used to randomly select a node as a leader among the pre-authenticated nodes. This leader continues to append brlock(s) in the existing chain until its turn duration is completed; on the completion of the first round, the RV of the network nodes is updated and the process of election is re-started. Now, in this round, a leader node is selected from the group of candidate members based on the votes received from the members of the follower group. The proposed consensus algorithm is divided into computing reputation values for network nodes, node classification based on their reputation values, and leader node selection using the voting process phases. The various notations used are presented in

Table 2. Notations and their descriptions.

Notation	Description	Notation	Description
RV	Reputation Value	TB	Transaction block
RVavg	Average of RVs	XIJT	Initial joining time of a node X
S	Sum	YIJT	Initial joining time of a node Y
V	Variance value	BPT	Current block processing time
ki	Represents a node	RPT	Require processing time for a block
RVki	Reputation value of a ki	TSX	Time spent by a node X in the network
X	Node X	TSY	Time spent by a node Y in the network
Y	Node Y	k	Variable
IDX	Identity of a node X	STki	Number of successful transactions completed by ki
IDY	Identity of a node Y	TSki	Time spent in the network by ki
CG	Candidate group	UTki	Number of unsuccessful transactions tried by ki
FG	Follower group	p	Number of malicious nodes
Tn	Total number of nodes	Pr	Probability

.

3.1. Computing Reputation Value of Node

In this phase of the consensus algorithm, RVs for all network nodes are computed based on their performance and the time spent in the network. Here, the performance of a node ki is measured on the basis of the number ST_ki and UT_ki. It means that, if a node ki performs a block appending process within the RPT, then RV_ki is increased; otherwise, in the case where a node ki is not able to append a block in the RPT, then the RV_ki is decreased. Similarly, a node ki that spends more time in the network increases its RV_ki. The RV_ki can be computed as shown by Equation (1).

$${\mathrm{R}\mathrm{V}\mathrm{k}\mathrm{i}}^{\mathrm{n} }={\sum }_{\mathrm{k}\mathrm{i}=1}^{\mathrm{n}}(\mathrm{S}\mathrm{T}+\mathrm{T}\mathrm{S})-{\sum }_{\mathrm{k}\mathrm{i}=1}^{\mathrm{n}}\left(\mathrm{U}\mathrm{T}\right)$$

(1)

The RV of a node shows its trustworthiness; a node that has more RV is considered highly trusted and has more chances of becoming a leader and receiving some incentives as a reward. The RV of all nodes of the network is updated regularly after the leader round time has expired.

3.2. Node Classification

In the node classification phase of the consensus algorithm, a node is either added to the C_G or F_G based on the node RV. At the beginning of each round, RV_avg is computed by using the RV of all nodes of the network, and the value for V is calculated using the variance formula. Next, the network nodes that have RVs greater than or equal to V are added in C_G and other nodes which have RVs greater than or equal to RV_avg and less than the value of V are added in the F_G. The nodes of the network having RVs less than the RV_avg wait until they achieve a level of reputation equal to or greater than RV_avg. The network nodes’ division into different groups based on their RV will help increase security and reduce the communication overhead burden of the consensus process because a leader is selected among highly trusted nodes, and, also, a specific number of network nodes cast their vote. Moreover, it provides equal opportunities to all nodes to become the leader and receive a reward. The RVs of the network nodes are updated and changed regularly after each round of the election, which provides equal opportunities to all network mining nodes to become the leader and receive a reward.

3.3. Leader Selection

The leader selection process is started after the completion of adding network nodes in the C_G and F_G processes. A leader node is selected from the members of the C_G by using the voting process, and the members of F_G will cast their votes to the members of C_G. A node in the C_G that receives more votes from the members of the F_G than other nodes becomes the leader for appending block(s) in the chain. Now, in the case where two or more than two members of C_G received an equal number of votes, then their RVs are checked and the member or node with the highest RV is the leader. Also, in the case where the RVs of the nodes are equaled, then the initial joining time of the nodes is checked and the node that has joined the network earlier than others is the leader. Once a leader node is decided, then it starts the process of appending block(s) to the existing chain. The number of successful appending block(s) in the chain will not only increase the RV of the leader, but it will also receive some incentives as a reward in the form of money. Otherwise, in the case of unsuccessful attempt(s) of the appending block(s), the leader will face a penalty in the form of money, and, also, their RV will be decreased. When the round time of the leader is expired, the RVs of all network nodes are updated, and the process of selecting a new leader is restarted. The entire process is shown in Figure 1 and Algorithm 1.

Algorithm 1: Leader based consensus algorithm
	Output: Select a node for appending a block
1:	START: Election process starts
2:	RVavg = n1 + n2 + n3 + …… + ni/n;
3:		For (k = 1; k <= Tn; k++)
4:			ki = ki − RVavg;
5:			ki = (ki)2;
6:			S = S + ki;
7:			V = S/n;
8:		End For
9:		For (k = 1; k <= Tn; k++)
10:			If (RVki >= V)
11:				CG ← ki
12:			Else
13:				If (RVki < V && RVki >= RVavg)
14:					FG ← ki
15:				End If
16:			End If
17:		End For
18:	Nodes of FG cast vote
19:			If (votes of X > all other nodes)
20:				If (IDX matched)
21:					timer.start();
22:					While (timer.Elapsed.Totalseconds < Xseconds)
23:					If (BPT < PST)
24:							X appends block and get reward
25:							TBX = TBX + 1;
26:					Else
27:							TBX = TBX − 1;
28:					End If
29:					End Loop
30:					RVX = TBX + TS;
31:				End If
32:			Else
33:					If (votes of X = = Y)
34:						If (RVX = = RVY)
35:								If (XIJT > YIJT)
36:									If (IDX matched)
37:										timer.start();
38:										While (timer.Elapsed.Totalseconds < Xseconds)
39:											If (BPT < RPT)
40:											X appends block and get reward
41:											TBX = TBX + 1;
42:											Else
43:											TBX = TBX − 1;
44:											End If
45:										End Loop
46:											RVX = TBX + TSX;
47:									End If
48:								Else
49:									If (IDY matched)
50:										timer.start();
51:										While (timer.Elapsed.Totalseconds
52:											If (BPT < RPT)
53:											Y appends block and get reward
54:											TBY = TBY + 1;
55:											Else
56:											TBY = TBY − 1;
57:											End If
58:										End Loop
59:											RVY = TBY + TSY;
60:									End If
61:								End If
62:						End If
63:					End If
64:				End If
65:		Timer.stop();
66:	Update RV values of the all nodes
67:	Election Process Re-starts

4. Security Analysis

Security is a crucial evaluation metric for consensus methods, and the goal of current research is to guarantee secure and reliable operation in a complex network environment. Regarding security analysis, the proposed work considers only important security aspects, as mentioned below. The proposed consensus algorithm is dependent on the voting process and RV. The network consists of a finite set Π of nodes where n ≥ 1 such that $\mathrm{\Pi }=\{\mathrm{1,2},3,\dots ,n\}$. Any node that is not active on the network for a specified amount of time is considered as crashed. A node may behave normally before it appears to crash, while a malicious node is the one whose ID is not matched. Let us suppose p represents a number of malicious nodes. We assume $p<{\displaystyle \raisebox{1ex}{$n$}\!\left/ \!\raisebox{-1ex}{$2$}\right.}$; this means the majority of nodes are valid and are behaving normally.

4.1. Resistance Against a Correct Node Becomes Inactive

The decision of an active node needs to be circulated so that the decision process continues until the leader selection. Hence, an active node is never blocked forever during a round. The values of RV and V are calculated before a round begins on the basis of which nodes are separated in $C_G \mathrm{a}\mathrm{n}\mathrm{d} F_G$. So, for any active node i, if the equation $v>{RV}_i\ge {RV}_{avg}$ is not satisfied, it has to wait for the next round without being inactive in the network, while rest of the nodes in $F_G$ will start casting their votes until the round completes and a block is appended. If an active node becomes dormant for longer than TS, its RV value becomes low in the network and, hence, may not be considered an active contestant for the voting process.

4.2. Secure Against Invalid or Malicious Node Participation

For every round, the values for ${RV}_{avg}$ and $v$ are computed to separate nodes into two groups. The authenticity of nodes is checked at different steps to ensure that only authentic nodes participate in the voting process. The situation is simple if a single node receives a higher number of votes. But, if two nodes X and Y receive an equal number of votes such that $\mathrm{X}==\mathrm{Y}$, then their RV values are compared to make the decision process easy. If the RV value of X and Y is also equal, the comparison is made on the basis of UT for both nodes. It follows that, during the first round of identity check, the probability of malicious nodes p becomes half such that $\mathrm{Pr}[p=={\displaystyle \raisebox{1ex}{$n$}\!\left/ \!\raisebox{-1ex}{$2$}\right.}|$ $n\ge 1]$. During the second round of identity check, when two nodes receive the same number of votes, the probability of p becomes even lower such that $\mathrm{P}\mathrm{r}[p=={\displaystyle \raisebox{1ex}{$n$}\!\left/ \!\raisebox{-1ex}{$2+1$}\right.}|$ $n\ge 1]$. This further eliminates the chances of malicious nodes taking part in the voting process. This collectively makes the chances of a malicious node taking part in the voting process lower to ${\displaystyle \raisebox{1ex}{$n$}\!\left/ \!\raisebox{-1ex}{$2$}\right.}$, which is equal to the above-assumed $p<{\displaystyle \raisebox{1ex}{$n$}\!\left/ \!\raisebox{-1ex}{$2$}\right.}$.

4.3. Robustness to a Situation When Two or More Valid Nodes Receive the Same Number of Votes

However, there is confusion about which node is given the chance to append a block to the blockchain when two or more nodes receive the same number of votes. The choice is finally made on the basis of the RV value of all the nodes and, further, if consensus is not achieved, the decision is made on the basis of UT for every node.

$$\mathrm{Pr}[X==Y|{RV}_X=={RV}_Y| X_{UT}>Y_{UT }˄ Y_{UT}>X_{UT}|(X,Y)\notin p]$$

4.4. Resistance Against Impersonation Attack

A malicious node may pretend to be a valid node and want to become the leader. To become the leader, the node will require a maximum number of votes from the members of F_G. When a new leader is selected, then the current leader announces it in the C_G, so that everyone must know about it. Moreover, during the block-appending process, the newly selected leader is re-authenticated, so it is hard for a malicious node to impersonate the leader. Similarly, a member of F_G cannot be impersonated because their identity is verified during the vote-casting process.

4.5. Secure Against Sybil Attack

In the system, a node must register itself before participating in the consensus process. To perform a Sybil attack, a node must have a good value of reputation to become a member of C_G and F_G groups. Moreover, in the consensus process, only one node is selected as a leader to complete the block-appending process; so, in the case where a malicious node declares itself as leader, then the node must forward a request to the current leader for identity validation. In the case of the specified number of unsuccessful or malicious attempts, it will be blocked and unable to rejoin the network, and, at the same time, a message about this malicious activity will be broadcast to other nodes in the network. Similarly, since in the voting process, a valid node casts only one vote, if a node tries to cast one or more than one vote, then, again, it will be caught by the previous leader because the identity will not be validated.

4.6. Resists to Denial of Service (DoS) Attack

During the consensus process, only authenticated and high-reputation-value nodes are competing for the leader selection that is selected via a voting process. First of all, a malicious node must have a good RV to cast a vote; if a normal or malicious node tries to cast more than one vote, then it can be easily caught by the current leader as each node is authenticated during the voting process. When the number of tries exceeds the specified limit, then the node is blocked and the current leader informs other nodes about the malicious activity.

Table 3. Functionality feature comparison.

Features	Trust-Varying Algorithm	FP-BFT	Scalable and Trust-Based	Proposed Algorithm
Resistance to correct node becomes inactive	✕	✕	✕	✓
Secure against invalid or malicious node participation	✓	✓	✓	✓
Robust to when two or more nodes receive the same number of votes	✕	✕	✕	✓
Impersonation attack	✕	✓	✓	✓
Sybil attack	✓	✕	✓	✓
DoS attack	✓	✓	✓	✓

✓ Satisfied. ✕ Not mentioned.

shows the comparison analysis of functionality features with other existing related consensus algorithms.

5. Performance Analysis and Comparison

To evaluate the results, the Hyperledger Fabric v2.1 is used on a Lenovo laptop with 8 GB RAM. Four peer nodes have were used with different ordered nodes. The results are generated by measuring the performance of the proposed algorithm on different parameters, such as throughput and latency, CPU consumption, bandwidth utilization, and successful detection of malicious activity.

Table 4. Simulation parameters.

Parameter	Value
Network Area	1600 m2
Number of Nodes	230
Network	Hyperledger
Block Size	1 MB
Simulation Time	25 Min
Network Traffic	Random

shows the simulation parameters defined for the simulation of the study.

5.1. Throughput

The performance of the proposed algorithm has been evaluated against benchmark Trust-Varying Algorithm [23], FP-BFT [38], and Scalable and Trust-Based consensus algorithm [40]. The proposed algorithm has been evaluated for throughput, latency, and resource consumption (bandwidth and CPU). Figure 2 shows the throughput of the proposed consensus algorithm in comparison with FP-BFT, Trust-Varying algorithm, and Scalable and Trust-Based algorithm, which shows that the change in the number of nodes brings an impact on the throughput of the algorithm. The throughput of the consensus algorithm decreases when the number of nodes increases. Figure 2 shows that the proposed consensus algorithm is slightly faster than the FP-BFT and Trust-Varying Algorithm. The throughput of the proposed system is 5 when the number of nodes is 130 and that of FP-BFT is 4, while Trust-Varying Algorithm is also 5. Similarly, at 10 nodes, the throughput of the proposed consensus algorithm is 500, while that of FP-BFT is 450, and the Trust-Varying Algorithm is 350. The main reason for this is that the voting process of the proposed consensus algorithm is time-bound and needs to be completed within a specified amount of time. This reduces the latency and enhances the throughput besides reducing the communication cost. However, the throughput of the proposed consensus algorithm matches that of the Scalable and Trust-Based consensus algorithm when the number of nodes reaches 230. With the smaller number of nodes, the throughput of the Scalable and Trust-Based consensus algorithm is not better than the other two benchmarks.

5.2. Latency

The latency goes on increasing once the number of nodes is increased, as shown in Figure 3. When the number of nodes is 10, the latency is the lowest, which means that the latency for the proposed algorithm is 5, and for that of FP-BFT and Trust-Varying Algorithm, it is 10. Once the number of nodes starts to increase, the latency shows a gradual increase. At 100 nodes, the latency for the proposed consensus algorithm is 365, while that for FP-BFT is 385 and for Trust-Varying Algorithm is 395. At 130, the latency for the proposed algorithm is 500, and for that of FP-BFT, it is 580, and for the Trust-Varying Algorithm, it is 585. The reason behind this is the time to process the transactions and block creation. Since only valid nodes in the proposed consensus algorithm are allowed to participate in the consensus process, this further reduces the time of the voting process to be completed and, hence, the latency is reduced to a considerable level. However, a major difference between the proposed consensus algorithm and that of FP-BFT and the Trust-Varying Algorithm is not observed in terms of performance. The latency in comparison with the Scalable and Trust-Based consensus algorithm is similar when the batch size is smaller, but once the batch size goes on to increase, we observe heavy fluctuations in the latency, particularly in the behavior of Scalable and Trust-Based consensus algorithms. At the same time, a minor or no heavy variation is observed in the behavior of the proposed algorithm when the batch size is increased. But, the overall latency in all four compared models shows similar or minor changes, and it can be said that, for latency, all four work almost similarly with negligible variations.

5.3. Resource Consumption

Two parameters have been evaluated in terms of resource consumption: (1) CPU cycle consumption and (2) bandwidth consumption. Figure 4 shows CPU cycle consumption when the number of nodes is increased. It can be seen that, once the nodes are added to the network, the CPU utilization increases, and the performance of the CPU is reduced. So, initially, when there was a smaller number of nodes, the performance of the CPU was higher, but, when the number of nodes continued to increase, the performance of the CPU continued reducing. The main reason behind this is that, with an increasing number of nodes, more exertion is initiated by the CPU, which exhausts its performance and, hence, the process takes longer to complete. The comparison is performed with FP-BFT, Trust-Varying, and Scalable and Trust-Based consensus algorithms. It is observed, in all four cases, that, with the increasing batch sizes, more CPU cycles are consumed and the performance of the CPU is reduced. However, it is better, in the case of the proposed consensus algorithm, when the number of nodes is lower, and, with an increase in the batch size, the CPU cycle of the proposed algorithm becomes almost similar to the Scalable and Trust-Based consensus algorithm. This means that, with an increasing number of nodes, the Scalable and Trust-Based consensus algorithm works better as compared to the other two benchmarks.

Communication overhead is the number of extra bits that are sent during the transmission in addition to the original message, which increases bandwidth consumption [43]. Similarly, more bandwidth is consumed when the number of nodes is increased in the network. Figure 5 shows the resource consumption second part, which is the bandwidth consumption with an increasing number of nodes. It is clear from Figure 5 that, when more nodes are added to the system, they require more bandwidth to transmit their decisions/votes to the servers. Hence, it puts exertion on the available bandwidth, requiring more bandwidth to accommodate the needs of an increasing number of nodes. Initially, when the number of nodes was lower, the bandwidth required for both models was lower. However, the number of nodes is added gradually, and the bandwidth consumption is enhanced for both models. In the case of the proposed consensus algorithm, there is a slight reduction in the consumption of bandwidth as compared to the FP-BFT and Trust-Varying Algorithm. The main reason is that there is a tight scrutiny process that eliminates the malicious nodes to consume the bandwidth and, hence, the bandwidth is only consumed for valid transmission. This reduces pressure on bandwidth to some extent. However, for the communication bandwidth consumption as compared to the Scalable and Trust-Based consensus algorithm, we observed a similar behavior right from the beginning. However, slight variations were observed with the increase in the batch size until the batch size reached 230 nodes, but the overall consumption of the bandwidth remained the same.

5.4. Security Against Malicious Nodes

The security of the proposed consensus algorithm measured against the number of malicious nodes during the consensus process is presented in Figure 6. We have tried to observe the security of the proposed algorithm in the presence of a heavy influx of malicious nodes and a light influx of malicious nodes. It was observed that the security is quite optimal. It provides the strict and consistent detection of malicious nodes throughout the consensus process. With a heavy influx of malicious nodes, the security becomes more strict and offers the detection of malicious nodes more frequently and diligently, while in the presence of a light influx of malicious nodes, the security remains diligent, and detection, as well as the filtration of malicious nodes, continues to work to make the consensus process defect-free.

5.5. Computational Complexity During the Reputation Evaluation and the Voting Process

The computational complexity of the proposed consensus algorithm during the reputation evaluation and the voting process can be obtained by calculating the time spent in different steps. The computational time of the proposed algorithm for the reputation evaluation can be obtained as mentioned in Equation (2):

$$T_C={\sum }_{i=1}^n{T}_{RV}+T_{RVavg}+T_V$$

(2)

where $T_{RV}$ is the time to compute the reputation value of a network node, $T_{RVavg}$ is the time to compute the average of the reputation values of the network nodes, and $T_V$ is the time to compute the variance value.

Similarly, the computational time of the algorithm for the voting process evaluation can be obtained as mentioned in Equation (3):

$$T_C={\sum }_{i=1}^n{T}_G+{\sum }_{i=1}^n{T}_{Cast}$$

(3)

where $T_G$ is the time taken to divide network nodes into candidate and follower groups and $T_{Cast}$ is the time taken to cast the votes.

Equations (2) and (3) can be combined to obtain the computational complexity of the proposed consensus algorithm during the reputation evaluation and the voting process.

$$T_C={\sum }_{i=1}^n{(T}_{RV}+T_G+T_{Cast})+T_{RVavg}+T_V$$

(4)

Equation (4) can be simplified.

$$T_C={\sum }_{i=1}^{n}T+T_{RVavg}+T_V$$

(5)

Equation (5) shows the total computational complexity of the proposed algorithm during the reputation evaluation and the voting process.

6. Conclusions and Future Work

The proposed work presented a resilient consensus algorithm to select a leader based on the reputation value of the nodes. One of the key elements that directly impacts network efficiency is the consensus algorithm; the majority of the consensus algorithms currently in use have problems such as low throughput, high latency, high CPU and communication bandwidth consumption, and the presence of malicious nodes in the algorithms, which is a major contributor to consensus process failure. To address the aforementioned problems and improve network performances, the proposed consensus algorithm selects a leader as a miner node for appending a block based on the reputation value of the nodes, which reduces network resource utilization. The security analysis demonstrates that the proposed consensus algorithm offers a high degree of protection against harmful actions carried out during the consensus process. The performance analysis is performed in terms of throughput, latency, CPU utilization, and communication bandwidth consumption. According to the simulation findings using Hyperledger Fabric v2.1, the proposed consensus algorithm offers higher throughput, lower latency, lower CPU utilization, and lower communication bandwidth usage as compared to the relevant competitors. The security and performance analysis make it a suitable choice for blockchain-based networks. In future work, we intend to enhance it to accomplish a quick and reliable consensus process. Theoretical investigations into the scalability and vulnerability properties of the proposed consensus algorithm will also be part of our future study. Moreover, our focus will be on designing a modified version of the proposed algorithm to make the consensus process more lightweight and secure, and its implementation via the recommended platform.