Nazfast: An Exceedingly Scalable, Secure, and Decentralized Consensus for Blockchain Network Powered by S&SEM and Sea Shield

Featured Application

This work is not limited to cryptocurrency but can also be used in the healthcare industry, supply chain industry, energy industry, and many more.

Abstract

Blockchain technology uses a consensus mechanism to create and finalize blocks. The consensus mechanism affects the total performance parameters of the blockchain network, such as throughput. In this paper, we present “Nazfast”, a simplified proof of stake—Byzantine fault tolerance based consensus mechanism to create and finalize blocks. The presented consensus is completed in multiple folds. For block producer and validation committee selection, we used a secure and speeded-up election mechanism, S&Sem, in Nazfast. The consensus is designed for fast block finalization in a malicious environment. The simulation result shows that we approximately achieved three block finalizations in 1 s with almost similar latency. We reduced and fixed the number of validators in the consensus to improve the throughput. We achieved a higher throughput among other consensus of the same family. Because we reduced the number of validators, the safety parameters of the consensus are at risk, so we used Sea Shield to improve the overall consensus safety. This is another blockchain to save nodes’ details when they join/unjoin the network as validators. By using all three parts together, our system is protected from 28-plus different attacks, and we maintain a high decentralization by using S&Sem. Finally, we also enhance the incentive mechanism of consensus to improve the liveness of the network.

1. Introduction

Blockchain technology plays a very important role in cryptocurrency and many other systems. The key feature of the technology is to save information by creating blocks. In blockchain networks, a consensus mechanism is used to create and finalize blocks because there is no central authority. The blockchain network adopts the most suitable consensus as per its requirements. There are many consensus mechanisms in the literature. Mainly, we have three generations of blockchain available in the literature. The first generation used proof-of-work consensus in the blockchain, such as Bitcoin [1] and Litecoin [2,3]. The proof-of-work consensus has strong security, but it has very low throughput. The process utilized a very high energy to produce blocks. It is also very difficult to become part of the consensus process because it needs expensive modern hardware. To reduce the limitations of first-generation consensus, second-generation consensus arises, such as Ethereum [4], Tezos [5], and EOS [6]. Mostly, the second-generation consensus used coin staking to become part of the consensus process and does not require heavy machinery to process. Also, the second generation used smart contracts to remove the need for intermediaries. The smart contract is already programmed logic in the blockchain that can execute automatically on pre-defined rules to control the events. The second-generation consensus gives very good results. However, when the number of transactions or users increases, the throughput decreases. Due to issues in second-generation blockchain consensus, the third-generation blockchain consensus has emerged. The third-generation blockchain works in a heterogeneous environment. The environment supported expanded options to increase the throughput of the blockchain network, such as Proof of Optimum [7], Polkadot [8], and Avalanche [9]. All the presented consensus has limitations, and there is still a need for new consensus in the literature [10]. We present a consensus mechanism that supports a heterogeneous environment. There are different categories of blockchain networks available in the literature, such as public-permissioned, public-permissionless, private-permissionless, and private-permissioned. The presented consensus is suitable for public-permissioned blockchain networks.

The presented protocol is based on a dual-chain mechanism. There is a main chain that creates and finalizes blocks, and the other chain is to save nodes’ details when they join/unjoin the network as validators to improve the blockchain network safety. We used Nazfast consensus to create and finalize blocks of the main chain and Sea Shield, a blockchain technology consensus, to create and finalize blocks of another chain [11]. Sea Shield consensus improves proof-of-stake based consensus blockchain network safety. The consensus saves records in the chain without creating forks in the network. The Sea Shield consensus ensures the safety of the main chain by giving validators a long procedure for joining and unjoining the network. To improve the scalability and decentralization of the Nazfast consensus, the main chain used an election mechanism to select the number of proposers and validators for the block creation and finalization. We used S&Sem, a secure and speed-up election mechanism, to select block proposers and validators in our presented mechanism [12]. S&Sem is designed for a PoS-based blockchain network. We select S&Sem for our work because it provides improved decentralization, fairness, scalability, and security for the process. S&Sem also speeds up and secures the Nazfast consensus overall performance because it uses horizontal scaling.

Mainly, the design of the block creation and finalization of the main chain consensus is inspired by the Tendermint consensus [13]. We made changes in the design of Tendermint to provide improved consensus for PoS-BFT-based blockchain networks. This type of consensus is also called a hybrid consensus. A hybrid consensus uses multiple consensus algorithms together to achieve the result in the blockchain network. The hybrid approach provides a more efficient and improved blockchain consensus than previous consensus. There are multiple examples that show hybrid consensus efficiency [14].

Today, Tendermint is considered the most practical replacement for highly energy-consuming consensus, such as proof-of-work-based consensus used by Bitcoin cryptocurrency. It is simplified and improved by partial Byzantine fault tolerance (PBFT) consensus. It provides liveness in partially synchronous networks. The safety threshold of the consensus is 1/3 of the validators’ power of the network. If the network may contain malicious nodes, Tendermint is the best option [15]. Tendermint consensus has a higher throughput than other available consensus in the literature with respect to the number of validators and block sizes, such as Bitcoin [1] and Ethereum [4]. Tsai et al. [15] showed the performance of three consensus Quorum [16], Stellar [17], and Tendermint [18], in which Quorum has the highest performance and most stability, but in the presence of a non-malicious node. When working in a malicious environment, Tendermint is better because it is a 1/3 malicious node-tolerant consensus. The throughput of Tendermint is higher than other blockchains; however, not all others, as [19] showed. Burrow [20] blockchain that used Tendermint as a consensus has a lower throughput than Redbelly [21], a blockchain that used democratic Byzantine fault tolerance (DBFT) [22] as a consensus, although the latency for Redbelly and Tendermint are relatively similar because Redbelly exploits superblocks. The throughput of Tendermint is also very far from the Visa electronic payment network [23]. We present a consensus that uses the base of Tendermint consensus. Our consensus solves the limitations of Tendermint and provides a new enhanced consensus in terms of security, decentralization, and scalability. The major improvements in the consensus we have made in this paper that are different from the Tendermint consensus are given below.

• The consensus used the election process to select a block proposer instead of a round-robin algorithm.
• A swapping mechanism occurs if the block is not produced by the pre-specified block proposer of the block creation cycle.
• The orphan block gets dissolved so that transactions do not get stuck in the block.
• The consensus has no locking mechanism.
• Correctors and the additional concept of wildcard entry validator with V-validator are used to improve the security parameter of the consensus.
• Forking is controlled in the consensus because multiple blocks do not get created and broadcast together in the block creation cycle.
• The concept of a timesheet is used to speed up the commit process by correctors.
• The reduced and fixed number of validators is used to improve the throughput of the consensus.
• Only five correctors are used for the commit phase to improve the scalability.
• The election result is saved in the main chain so that the election committee can be traced easily during any future conflict for any particular block.
• We selected transactions in multiple ways to improve the decentralization and security of the system.
• We update the block structure according to our Nazfast consensus by removing the root hash of validations from the Nazfast header, because a block is being created in multiple segments.

The rest of the paper is organized as follows: Section 2 provides a short review of the Tendermint consensus related papers and the significance of the study; Section 3 presents the preliminaries for the Nazfast consensus mechanism; Section 4 describes the complete block production mechanism of the proposed Nazfast consensus; Section 5 shows the experiment and evaluation parts of the simulation work used to test NazFast; and Section 6 discusses the performance of the presented Nazfast consensus by comparative analysis with the Tendermint consensus and other networks. Section 7 provides limitations of our work. Finally, Section 8 concludes the study and discusses the future work.

2. Literature Review

There are many research works present in the literature that used the design of the Tendermint consensus to produce improved consensus, such as Xiangbin et al., who present a consensus that resolves censorship attacks [24]. They improved the Tendermint consensus by creating three different types of messages and a secondary responsibility for nodes. The methodology resists attacks by itself and establishes an honest chain. Lionel et al. [25] present a consensus TenderTee based on Tendermint that can tolerate half of the Byzantine nodes in the network. The network used a trusted abstraction to improve resilience in the system. Jovan et al. [26] proposed consensus BioHes based on the Tendermint consensus. They reduce the message complexity of the consensus and still manage to improve security. With a high number of validators in the network, the BioHeS consensus mechanism achieves a considerable difference thanks to its linear message count incrementation. Bonniot et al. [27] proposed PnyxDB, a Byzantine Fault Tolerant replicated datastore that shows both high scalability and low latency. It also supports an application-level voting process for the transaction. They compare their work with Tendermint and show that their system is able to reduce commit latencies under realistic conditions. Soohyeong et al. [28] proposed a multi-block consensus based on BFT to increase scalability. The transaction sets are propagated to the replicas. After verifying the block, the replicas can also add the block to the blockchain. They increase the throughput as the number of users increases. They try to control the amount of traffic used to create a single block by creating multiple blocks at once, but they have not applied the network capacity to the proposed scheme. Pollett et al. [29] proposed an improvement in proof-of-stake system security. They compare their system with Tendermint. They solve the denial of service issue against proposers of Tendermint by using Sentry nodes to prevent direct access to the recent proposer in the system. They propose tontines for proper block monitoring. Tontines are a group of validators to ensure the validators’ honesty in the system. Validators can create tontines to police each other’s activities in the system. They also proposed an improved incentive mechanism in the system. Feng et al. [30] proposed a consensus protocol called proof of trust negotiation (PoTN). The consensus provides security against DoS attacks due to a fixed number of validators in the system. The random honest validators are selected by a trusted random selection algorithm from the validators’ team. Their simulation result shows that it is more effective than the Tendermint consensus mechanism. Gao et al. [31] present a T-PBFT consensus based on the EigenTrust model. The proposed consensus reduces the probability of view change and improves the Byzantine fault-tolerant rate of the system. The consensus works in multiple stages. They select the high-quality node from the system to make a consensus group. The node quality is decided by the transaction between nodes. To reduce view change, they convert the single primary node into a primary group. They enhance the robustness of the primary group through group signature and mutual supervision. They compare the consensus with the Tendermint consensus and show that their consensus can optimize the BFT rate and reduce view change and communication complexity. Lei et al. [32] proposed a pipeline BFT consensus algorithm based on the architecture of Tendermint. It contains all the features of the Tendermint consensus except block finality. They handled the blocks in a chained model. They used parallelism in the vote phases and also modified the lock mechanism of Tendermint. They increased the throughput, but the blocks can overlap because of the handling process of the algorithm. Astefanoaei et al. [33] proposed Tenderbake, in which they try to solve dynamic repeated consensus issues. They proposed a single-shot consensus algorithm inspired by Tendermint. They improve two aspects of Tendermint. They remove the requirement of reliable broadcasting in the system and reduce the termination time of their proposed consensus. The termination of Tenderbake is f + 2 rounds, which is quite lower than Tendermint. In Tendermint, termination is performed in the same round after the processes have been synchronized, or in the worst case, after the size of the committee rounds. Tenderbake is not as optimistic and responsive as other consensus of the same family.

Tendermint consensus uses a deterministic approach to decide on the upcoming block proposer. Ngoc et al. [34] present an improvement in the Tendermint consensus by utilizing the Elliptic Curve Verifiable Random Function. It solves the issue of knowing the validator ahead of time. It used a fast and secure pseudorandom generation algorithm for a deterministic blockchain network. Amoussou-Guenou et al. [35] present the correctness and fairness of Tendermint-core. They proposed a one-shot consensus for the single-block validation. They also showed that the Tendermint consensus reward mechanism is not fair; therefore, they proposed an improved, fair rewarding mechanism for the system. The reward will be distributed according to the merit proportion of the participants in the system. Basem et al. [36] proposed an enhanced Tendermint blockchain. They proposed a lock-free algorithm by using the time-out property. They used reduced validators in the algorithm. For the validator’s subset selection in the algorithm, they considered data sensitivity and the node’s trustworthiness for the subset size and the random walk algorithm for the fair selection of the subset of the voter nodes. In their proposed algorithm, the validator selects another validator from the list. It has security risks because the validator may select a validator of their own choice, which can lead to centralization issues in the network, and also, this process increases the consensus time duration.

Significance of Study

We have visited the literature and observed the improvements in the Tendermint consensus. We have summarized the others’ work on Tendermint in terms of scalability, security, and decentralization in

Table 1. List of already addressed issues of Tendermint according to the literature.

	Resolve Issues	How to Resolve
Security	Resolves censorship attacks	Establishes an honest chain [31]
	Improve resilience in the system	Tolerate half of the Byzantine nodes [32]
	Solve the denial of service issue	Using Sentry nodes to prevent direct access [36]
	Reduce DoS attacks due to a fixed number of validators	Selected random honest validators [37]
	Solves the issue of knowing the validator ahead of time	By utilizing the Elliptic Curve Verifiable Random Function [38]
Decentralization	Reduces view change and improves BFT rate	Consensus works in multiple stages [39]
	Solve dynamic repeated consensus issues	Remove the requirement of reliable broadcasting and reduce the termination time [40]
	Improved reward mechanism	Distribution is performed according to the merit proportion [41]
Scalability	Reduce the message complexity	Linear message count increment [33]
	Reduce commit latencies	Conditional endorsements that track conflicts b/w transactions [34]
	Increase the throughput	Control the amount of traffic used to create a single block [35]
	Increased throughput	Used parallelism in vote phases [42]

. All try to improve any property security, scalability, or decentralization of the blockchain network in their work. In this paper, we present a consensus inspired by Tendermint. It overcomes the limitations of Tendermint, such as the lock mechanism and fair block producer selection, and provides improved scalability, liveness, persistence, security, and a fair reward mechanism altogether. We try to improve almost all properties of blockchain in our consensus.

3. Preliminaries for the Nazfast Consensus Mechanism

The Nazfast consensus is designed for proof-of-stake-based blockchain. Our presented consensus uses a dual-chain blockchain network, such as in Figure 1, which shows two parallel chains working together. A main chain saves the records/transactions of the network by using the Nazfast consensus. A validator chain saves the node’s details when it becomes a validator and leaves its responsibility as a validator in the network to improve the overall security of the network.

In our previous work, we have presented Sea Shield. We used the Sea Shield consensus for nodes to become validators in the network. We embed all the properties of Sea Shield in our system. Sea Shield is a consensus designed to improve the safety of a PoS-based blockchain network. Sea Shield used a validator chain to save nodes’ details when it joined the network as a validator and when it left the system as a validator. After becoming a validator by using Sea Shield in the system, a validator may participate in the consensus process of the Nazfast. Nazfast used a reduced number of validators in the consensus process. Due to the large number of validators in the network, the Nazfast consensus process used an election mechanism (S&Sem) to select the “z” number of validators. The selected validators from S&Sem create and finalize blocks by using Nazfast for the main chain of the blockchain network. Figure 2 shows the overall process of the Nazfast consensus using Sea Shield [11] and the election mechanism [12].

The Nazfast consensus is based on the base of Tendermint consensus but uses an election mechanism instead of a round-robin algorithm for validator selection. Tendermint uses a round-robin algorithm that is very simple and easily predictable. To improve the scalability of the complete consensus, the Nazfast consensus used a fixed number of validators to validate the block; therefore, we need an efficient election algorithm to select validators. Therefore, we used S&Sem in our work. We already presented S&Sem and its validation in the paper [12]. We assume and inherit all the properties of S&Sem in our work.

Saving the Election Result

We save the election result in our main chain to deal with any forgery in the future. After the election mechanism and finishing other responsibilities, the election starter will create a block with all the details of the election result and digitally sign it. The block structure to save the election result is similar to the main chain of other blocks, except for transactions. Figure 3 shows the block structure. In the transactions, it would save all the election results of the current election. First figure in Section 4 describes the complete block structure for the main chain blocks. The block will be dealt with by any block creation cycle that is present at that time. The block will go through the consensus process and become part of the main chain like other blocks of the network.

4. Nazfast Consensus Mechanism

4.1. Types of Validators Used by Nazfast Consensus

There are four different types of validators used in the Nazfast consensus. Three types are based on the election results. For example, after a successful election process, we have the top 30 validators and an active validator pool to start the consensus mechanism, where an active validator is a validator that participated in the last two election rounds. These 30 validators are divided into three categories: proposer, V-validator, and corrector, according to their respective roles in the consensus. The fourth is the wildcard entry validator.

1.

Proposer validator

Proposer validator nodes are the building block of this consensus mechanism. Proposer validators are the ones who propose a block in each block creation cycle of every round.

2.

V-Validator

V-validator nodes are the nodes that verify the block produced by the block proposer during the block creation process. There are 15 V-validator nodes in the block creation process.

3.

Correctors

Correctors are the validators who revalidate the block after V-Validator verification. There are five correctors to validate each block during the block creation cycle.

4.

Wildcard Entry Validator

In each block creation cycle, we have a wildcard entry validator. It is an anonymous validator whose identity is unrevealed by all other selected validators. The validator is linked with any of the V-validators. The wildcard entry validator’s responsibility is like a V-validator. There is a pool of active validators with hidden identities. The wildcard entry validator can be any validator among all other active validators from this pool. For round one’s first block creation cycle, the election starter is selected randomly as a wildcard entry validator from the pool. If the election starter is inactive or not present in the system for any reason, then the network host will select the wildcard entry validator. After the first block creation cycle, every wildcard entry validator selects the next wildcard entry validator for the next block creation cycle in the new height phase. For the genesis block creation process, the host will select the wildcard entry validator. After the wildcard entry validator selection, the host will release the actual identity of the wildcard validator to the consensus group and its connections just before the start of the block creation process.

4.2. Round Description

There will be two rounds based on the election result. There are 10 proposer validators, 15 V-validators, five correctors, and wildcard entry validators to produce blocks in both rounds. Every round comprises 10 block creation cycles. It means 20 blocks would be created in these two rounds. For round 1, the top 30 selected validator nodes would be arranged in ascending order with respect to the election’s final voting result, and for round 2, the top 30 selected validators would be arranged in descending order. After the change, in order for round 2, validators were assigned new responsibilities as per their sequence number. The distribution process of 30 validators into three categories is similar for both rounds. The distribution of 30 selected validators for a round is as follows.

Table 2. The first 10 prime numbers in the top 30 become the proposer validator.

Block creation cycle no.	1	2	3	4	5	6	7	8	9	10
Sequence no. in the top 30	2	3	5	7	11	13	17	19	23	29

shows that the validator that is present in the second position of the list will produce a block in the first block creation cycle, like the validator that is present in the third position will produce a block in the second block creation cycle.

Table 3. The first 15 composite numbers in the top 30 selected validators are the V-validators. (Including 1).

Serial no.	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
Sequence no. in the top 30	1	4	6	8	9	10	12	14	15	16	18	20	21	22	24

shows that validators that are present in the first, fourth, sixth, and so on positions in the list will be V-validators for 10 block creation cycles.

Table 4. The last five composite numbers in the top 30 selected validators are the correctors.

Serial no.	1	2	3	4	5
Sequence no. in the top 30	25	26	27	28	30

shows that validators that are present in the 25th, 26th, and so on positions will become correctors for 10 block creation cycles.

4.3. Block Structure

To create a block in the network, the block producers first collect all valid transactions from the system according to the types discussed above. The zero-knowledge proof [37] will be used to validate the transactions. After collecting transactions, the block producer will create the block by using the Nazfast block structure. The block structure for Nazfast consensus is based on a general PoS-based network block structure. Figure 4 shows the block structure for the Nazfast consensus in the network. Part (a) in the figure shows the block structure for the Nazfast consensus. The block is divided into three parts: Header, Validation, and Transactions.

4.3.1. Header Description

(1)

Network Name: Name of the network or ID.

(2)

Height: Block placement number in the blockchain network.

(3)

Election Number: The election number by which validators were selected to create this block.

(4)

BlockCc: Block creation cycle number.

(5)

Round Number: The recent round number.

(6)

Date Time: The block creation date and time by the block creator.

(7)

Transaction Worth: Transaction details as per the network.

(8)

Fees: Every transaction contains fees; it is the sum of all transaction fees

$${\left(TF\right)}^n={\sum }_{i=1}^{j=n}{f}^i$$

where

• TFⁿ = total transaction fees;
• f = transaction fees;
• i = transaction number;
• n = total number of transactions.

(9)

Block H-1 hash: Hash of the previous block.

(10)

Root Hash of Transactions: Merkle tree [39] root of all transactions.

4.3.2. Validation Description

(1)

Host Name: There is a host concept in the system. It contains the ID of the host.

(2)

Election Starter Name: Election starter ID that deals with elections, by which the validators were selected.

(3)

Wildcard Entry Validator: Signature of the wildcard entry validator of this block creation cycle.

(4)

V-Validator Signature: Signatures of all V-validators that give pre-commit the block.

(5)

Correctors’ Signature: Signatures of all correctors who give their commit to the block.

4.3.3. Transactions Description

This section contains a list of transactions selected by the block producer from the mempool. Part (b) shows the block structure to save the election results in the blockchain network. It has similar header and validation sections that we already discussed. Only the transaction section will contain election result details.

4.3.4. Block-H Hash Description

Every block has the hash of the complete block. The block-H hash comprises a hash of the in-progress block header hash, a hash of all validation, and a hash of all transactions. Part (c) of the figure shows the chaining mechanism by using the block-h hash. Every block contains the last block’s hash for chaining. The chaining mechanism is very important in blockchain. By performing this, the blockchain becomes immutable [10]. Initially, a block producer will create a block with header details, a transaction list, a host name, and an election starter name and digitally sign it, such as in Figure 5. Validation section signatures and block-H hash will be empty at the start; they will be completed at the end of the block creation cycle. The block will be broadcast in its respective block creation cycle from the block producers to obtain validations from the V-validators, wildcard entry validators, and correctors.

4.4. Block Creation Cycle

In the Nazfast consensus, the block creation and finalization process is completed in phases. There are multiple block creation cycles in every round, and each block creation cycle has to complete four phases for a block to receive its final commit in the network. Figure 6 shows all phases of the block creation cycle for block finalization.

4.4.1. Block Proposal Phase

Each proposer validator proposed a block with its digital signature [42] in their respective pre-defined order. For example, in block creation cycle no. 1 of round 1, the validator at the second position in the selected top 30 validators will propose a block and broadcast it to all other proposers, V-validators, wildcard entry validators, correctors, and hosts. Likewise for block creation cycle no. 2, the validator at the third position in the top 30 selected list will propose a block. There is a time-bound Δ from the network for block proposal and broadcasting it to all other validators. The proposer has to propose a block within the proposed block time duration. If the proposer proposes the block in the proposal time period and the block gets accepted at the end of the block creation cycle, then the proposer will receive their block proposer reward and excellency points from the network. Otherwise, if a proposer fails to produce a block during block proposal time, then the swapping mechanism occurs to select a new proposer for this block creation cycle. If the new block proposer proposes a block and that block gets accepted at the end of the block creation cycle, then the new block proposer for this block creation cycle will receive a block proposer reward and points with respect to the default standard scale, and the block proposer that did not produce a block in his respective time would decline in his excellency scale.

Swapping Mechanism

When a block proposer does not produce a block between specified time bounds in its respective block creation cycle, swapping occurs. For example, the swapping mechanism for the block proposer with the V-validator in the block creation cycle 3. The block proposer’s place has been taken by the first validator in the V-validator list as the block proposer for this block creation cycle. The validator should be an active validator. The V-validator list is ordered in ascending or descending order as per that round. Once a V-validator becomes the block proposer, it cannot validate its own block. The place of the V-validator for this block creation cycle has become empty. Therefore, from the proposer list, the first proposer validator would take the place of the V-validator to complete the V-validator total count for that block creation cycle. The proposer validator should be an active validator.

If the block is not produced in block creation cycle 1 by the block proposer or after one swapping mechanism if the swapping situation is repeated in the same round for another block creation cycle that the proposer validator of that round did not produce a block in the specified time, then the second active validator from the V-validator list would take place as a block producer, and the second active validator from the proposer list would become a V-validator, and so on, such as in Figure 7. For every swapping mechanism in a round, the opportunity is given to the new V-validator to become a swapping proposer or for the proposer to become a V-validator.

Although the proposers and V-validators are already aware of this swapping rule and ready to take the positions of others, correctors keep an eye on the situation and can interrupt if needed. So that delay wouldn’t come during the block creation process, and the system remains in stable mode. We present Algorithm 1 for a better understanding of the proposal phase.

Algorithm 1 /*Phase ← proposal start */

/* represent comments in the algorithm*/

1.    phasec ← proposal 2.    proposal ← Function CreateBlock() 3.    broadcast (PROPOSAL, htc, blockCc, Ϭ, proposal) 4.    upon (PROPOSAL, htc, blockCc, Ϭ, α) from proposer while phasec = proposal do 5.       proposal_receive ← true 6.       Value ← α 7.    upon (PROPOSAL, htc, blockCc, Ϭ, *) while phasec = proposal do 8.        schedule OnProposalPeriodEnd(htc, blockCc) implemented after proposalPeriodEnd of current BlockCc 9. Function OnProposalPeriodEnd (height, blockcc): 10.    If proposal = null then   /* proposal not received */ 11.        If blockCc = 1 then 12.          swappingNumber ← swappingNumber +1 13.       Function SwappingMechanism (activeVvalidatorList[], activeProposerList[], swappingNumber, proposer) 14.          proposal ← getValue ()   /* getValue() by proposer*/ 15.       If proposal ≠ null then 16.        broadcast (PROPOSAL, htc, blockCc, proposal)

4.4.2. Check Validity Phase

After the block proposal, V-validators and wildcard entry validators will validate the authenticity of a block. Every block creation cycle has 15 V-validators. It will remain the same for round 1 to create 10 blocks. The first 15 composite numbers in the top 30 selected validator list in ascending order will be the V-validator for round 1, and the first 15 composite numbers in the top 30 selected validator list in descending order will be the V-validator for round 2. Each V-validator receives a block and checks its validity. If the block is acceptable, it will give its prevote to that block and broadcast it to the proposer, host, wildcard entry validator, and all other V-validators. If the V-validator has given a prevote to the block during the prevote time and also received 2/3 prevote for the same block from others in the specified time of prevote, then the V-validator may send a pre-commit to all five correctors, the proposer, and the host with the validators list that sent prevotes to them. There is a time bound for the prevote phase, and after this time, the phase automatically gets dissolved. In this specified time, if the V-validator did not receive 2/3 prevotes for that block, it will not send its pre-commit. If the specified time ends and a validator does not respond for any reason, then their pre-commit is considered nil.

The wildcard entry validator linked with any of the V-validators receives a block from its peer validator nodes, and if the block is acceptable, it gives its prevote to this block or votes nil and broadcasts it to the proposer, host, and all other V-validators. After receiving 2/3 of the prevotes from others, it sends its pre-commit to the correctors, proposer, and host with the V-validators’ list that sent the prevote. Wildcard entry validator vote response is very important, and there is a very low probability of voting as nil due to unavailability, because it has been selected from an active validator pool. Perhaps the wildcard entry validator vote can be nil due to an unacceptable block or any network issue. If there is a nil vote, the wildcard entry validator must submit an explanation to others. We present Algorithm 2 of the check validity phase to observe the phase clearly.

Algorithm 2 /*Phase ← Check validity start */

/* represent comments*/

1.     phasec ← validity 2.  upon (PROPOSAL, htc, blockCc, Ϭ, α) from proposer while phasec = proposal do            /* α is a roposal value */ 3.       if valid(α) then 4.          broadcast (PREVOTE, htc, blockCc, Ϭ, id(sender)) 5.     upon (PREVOTE, htc, blockCc, Ϭ, ∗,) while phasec = validity do                 /* (*) represent any value */ 6.       schedule OnPrevotePeriodEnd (htc, blockCc) implemented after prevotePeriodEnd of current BlockCc 7.    upon (PROPOSAL, htc, blockCc, Ϭ, α) from proposer AND +2/3 (PREVOTE, htc, blockCc, Ϭ, id(sender)) from Ꝭ while valid(α) ∧ phasec = validity do 8.       If validator_ send_prevote ← true 9.          broadcast (PRECOMMIT, htc, block, Ϭ, Ꝭ, id(sender))           /* Ꝭ it is the list of validators that send prevote*/ 10.         phasec ← commit 11.    upon (PRECOMMIT, htc, blockCc, Ϭ, Ꝭ, ∗) while phasec = validity do 12.       schedule OnPreCommitPeriodEnd (htc, blockCc) implemented after precommitPeriodEnd of current BlockCc

4.4.3. Commit Phase

There are five correctors in the consensus process. Correctors are the final ones who validate the block and its contents and commit the block. All V-validators and wildcard entry validators send their pre-commit to the correctors. To commit the block, the corrector validates and accepts the block and also must receive pre-commit from the wildcard entry validator and 2/3 pre-commit from the V-validators within the specified time. Similarly, it also has a specified time bound like every other phase, and after this time, the phase automatically ends. If the corrector accepts the block and receives all required votes for the block during the specified time, it gives a commit to the block and broadcasts it to other correctors, proposers, and hosts with the validators’ list that sent pre-commit and prevote for this block. Else, after the completion of the specified time, the corrector rejects the block, and a new block creation cycle is started after the new height phase. In Algorithm 3, we present a detailed algorithm of the commit phase.

Timesheet

All five correctors did a similar procedure for the 10 blocks at every round and maintained a timesheet. There are two sets of correctors for both rounds. The Corrector that commits 10 blocks fastest in any of the rounds becomes the next election starter. Fastest commit means, in terms of total time duration for 10 blocks, that the corrector takes to commit in the block creation cycles.

corrector time duration for a block = | final commit time—2/3 pre-commit received time |

Corrector time duration for a block is the time duration in which a corrector finalizes the block. The time starts when a corrector receives 2/3 pre-commit for a specific block and ends when it commits to the block. For n correctors, the total commit time duration for 10 blocks:

CTⁿ = x1 + x2 + x3 + x4 + x5 + x6 + x7 + x8 + x9 + x10

$${\left(CT\right)}^n={\sum }_{i=1}^{j=10}{x}^k$$

where

• CT = Total commit time duration for 10 blocks
• n = Corrector no.
• j = Block creation cycle
• i = Initial value
• x = the corrector time duration for a block
• k = block no.

$$\mathrm{FC}=\max {\int }_1^{10}\left(CT\right)$$

where

• FC = Fastest commit time between both rounds of correctors
• n = corrector no.

∵ Election-starter = (FC)ⁿ

The corrector saves a record of block commit time to make a list at the end. The correctors broadcast their timesheets to each other so that they know the new election starter.

The timesheet includes

• 2/3 pre-commit time;
• Final commit time;
• Total duration.

Algorithm 3 /*Phase ← Commit start */

/* represent comments*/

1. upon (PROPOSAL, htc, blockCc, Ϭ, α) from proposer AND (PRECOMMIT, htc, blockCc, Ϭ, Ꝭ, id(sender))) from     wildcardentryvalidator[blockCc] AND +2/3(PRECOMMIT, htc, blockCc, Ϭ, Ꝭ, id(sender)) from v-validators(ⱴ) while phasec = commit do     /* ⱴ validators list that send precommit */ 2.      2/3preCommitRecievedTime[n] ← time 3.      If valid(α) then 4.          forgery ← false 5.          InvalidOrforgeryDetail ← nil 6.          finalDecisionc [htc] ← α 7.          commitTime[n]← time 8.          correctorTime[n]← commitTime[n]- 2/3preCommitRecievedTime[n] 9.          Function updateTimeSheet(correctorTime[n], round, htc, blockCc) 10.          broadcast (COMMIT, htc, blockCc, Time, finalDecisionc [htc], forgery, InvalidOrforgeryDetail, Ꝭ, ⱴ) 11.          phasec ← newheight 12.      else 13.          forgery ← true 14.          InvalidOrforgeryDetail ← Details of forgery by corrector[n] 15.          finalDecisionc [htc] ← nil 16.          correctorTime[n] ← 0 17.          Function updateTimeSheet(correctorTime[n], round, htc, blockCc) 18.      broadcast (FORGERY & DETAIL, htc, blockCc, Time, finalDecisionc [htc], forgery, InvalidOrforgeryDetail, Ꝭ, ⱴ)/* send to host*/ 19.          phasec ← newheight 20.  upon (COMMIT, htc, blockCc, Ϭ, Ꝭ, ∗) while phasec = validity do 21.    schedule OnCommitPeriodEnd (htc, blockCc, finalDecisionc [htc], r) implemented after commitPeriodEnd(blockCc)

4.4.4. New Height Phase

It is a special phase after every three phases of the block creation cycle. There is also a specified time for this phase. The network set this specified time. The total time for this phase is divided into two parts, called corrector time and network time. In the corrector time, the block is finalized, and in the network time, the system is stabilized for the next block creation cycle. The corrector time starts with the start of the new height phase time and ends according to the network-specified time for this part. After the end of corrector time, network time is started and ends with the end of the new height phase time. Figure 8 shows the new height phase parts in detail.

4.4.5. Corrector Time

To finalize the block for broadcasting into the network that is committed in the commit phase, a corrector collected commits from the other correctors for the same block. After receiving all correctors’ responses for this block, if the forgery has not been reported by any other corrector or received more than 2/3 commits, then the corrector will send a block with all the received signatures of V-validators, wildcard entry validators, and other correctors for this block to the proposer validator. The proposer validator collects all the signatures from every corrector and combines them for the validation section of the block. The proposer collects a union of the signatures from every corrector validation list, such as the union set of signatures ‘s’ of all correctors is notated as Y ∪ Z.

More formally, s ∊ Y U Z if s ∊ Y or s ∊ Z (or both).

The validation section will contain all the V-validator and corrector signatures that give pre-commit and commit to the block during the block creation cycle. The proposer completes the block validation section and computes block hash H, which is a hash of the block header, validation, and transactions of the block. The proposer digitally signs the block and broadcasts it to the wildcard entry validator, all correctors, the host, and V-validators. After the broadcast of the block, the network time will start. To save time, the Network Time (a) job is parallel to the Network Time (b) job because both jobs can be performed together in the network. In network time (a), the proposer waits for the end of the complaint time for the block to broadcast to the whole network, while the network may start distributing the reward or penalty of the block because the block is already accepted in the commit phase.

4.4.6. Network Time

(i)

Network Time (a)

There is a time bound ∆ for the correctors to complain against the proposer for the validation set only. Because at this stage, proposers are only allowed to change in the validation section. After the given time, if no complaint is received, the proposer starts broadcasting the block to the whole network. Broadcasting is performed by any network rule; we suggest the gossip protocol for broadcasting. After a time-bound, if the corrector does not receive any revised response on the block from the proposer, it may also start broadcasting the block to the network. The broadcasting of committed blocks between all peers is completed during this phase. Every node in the network will update its ledger by adding this committed block, including those validators that were involved in this block creation process, because no one is allowed to update their ledger with the new block before the specified timeout of the block.

(ii)

Network Time (b) (Parallel with the network time (a))

1.

The block is created during the block creation cycle:

At the end of the corrector time, if the block was created during the block creation cycle, the network will distribute rewards and excellency points to the validators who participated in the block creation process as per network rules. The corrector that did not respond in the commit phase would not receive reward and excellency points from the network for this block. Only those correctors that commit the block will receive a commit block reward and excellency points from the network.

After the broadcasting of the new block, the height number is increased by 1 because a new block is added to the blockchain ledger in the current block creation cycle. The forking [40] issue of blockchain is also controlled in our consensus by creating and broadcasting one block at a time in the network with the consent of all correctors.

2.

The block is not created during the block creation cycle:

At the end of the corrector time, if none of the correctors or proposers broadcasted the block to the whole network due to any reason, or if the network host did not receive 2/3 commits for the block after receiving all correctors’ responses on the block, or if forgery has been reported to the network from the correctors for this block, then the network host will broadcast nil for this block creation cycle to the network. If forgery has been reported, the network will implement the reward and penalty mechanism for this block creation cycle. The host distributes rewards, penalties, and excellency points according to the network rule to the proposer, V-validators, wildcard entry validator, and correctors for the forged block creation cycle.

If the block has been rejected in the block creation cycle or by any corrector due to forgery, then this block is dissolved by its proposer. Blocks created using PoS-based consensus are energy efficient and easily recreated by others, so dissolving the block is better than keeping the block for the next block creation cycle, such as in Tendermint [13]. It is the responsibility of the proposer that if his block did not get committed, it dissolved the block and returned all transactions to the pool from his block in the new height phase. So that the next proposers may use those transactions in their block. By dissolving and returning transactions to the pool, we are saving transactions from getting stuck in the unconfirmed block for a long time, like in another consensus [1].

4.4.7. Anonymous Forgery Catcher

Network nodes can detect forgery after broadcasting the block to the whole network because our network has anonymous forgery catchers. Their identities are hidden from everyone; they will only appear if they find any forgery in the block. The block forgery can be found by any node of the network as well. The network can punish the block proposer even after the block finalization because validators cannot be dishonest and leave the system due to the extra bonding time commitment to the network [11]. In such a situation, other validators included in the forge block creation cycle would also be punished by the network.

4.4.8. New Block Creation Cycle Setting

To start the new block creation cycle, the network would also upgrade and reset the required parameters for the next block creation cycle of the consensus. For example, if selection of the wildcard entry validator and its connection for the next block creation cycle has been completed, the network would increase the block creation cycle number by 1, and if the current block creation cycle number reached 10, then it would update the round number to 2. Similarly, when the block creation cycle number reached 20, the network reset the block creation cycle number and round number to 1 and released a logbook to all nodes. The logbook is a list of all requests’ details received by the host of joining/unjoining nodes as validators [11] during the latest 20-block creation cycle. The height number would remain the same for the next block creation cycle if the new block was not created in this cycle. The next block creation cycle will start after the end of the specified time set by the network for this new height phase.

5. Experiment and Evaluation

Experiment Setting: The recent study also uses an open (Jackson) queuing network [38] to theoretically analyze the network with a blockchain network. In our paper, we used the simulation environment to analyze the performance of the entire presented system rather than performing mathematical modeling for the conditions.

Simulation Environment: For evaluation of our presented consensus, we develop an entire heterogeneous network model [41] because our consensus has a side chain and parallel execution of the election mechanism. We develop a prototype simulation environment in C# to implement the proposed Nazfast consensus. In the implementations, we generated and used a pair of public and private keys for the encryption and decryption process. We implement all the cryptographic algorithms, such as RSA for encryption using a key size of 2048, SHA-256 for hashing output, which is 256 bits long, digital signature for authenticity, Merkle tree root for easy computation, and zero-knowledge proof for validating data. We also apply broadcast delay in our simulation to create a real-time environment. We calculate the propagation delay by using an exponential distribution [43]. The calculation is provided in the Sea Shield paper [11].

System Configuration: The proposed consensus is based on the PoS-PBFT blockchain network. This network can be used by any type of organization, large or small. The application of the presented consensus is not limited to cryptocurrency; it can be used in the health industry [44], internet of things (IoT) [45], media [46], government [47], and so on. Therefore, network nodes can be general-purpose computers and have general configurations; for that reason, we used the lowest system configuration for testing the simulation system.

The system configuration that is used for the entire implementation and testing for the Nazfast has the operating system Microsoft Windows 10 having system type x64-based PC with the Intel(R) Core(TM) i7-7700 CPU @ 3.60 GHz, 3600 MHz, four core(s), and eight logical processor(s). The system has 16.0 GB of installed physical memory (RAM) and 7.06 GB of available physical memory, while total virtual memory in the system is 31.4 GB. However, during the entire network system testing process, we used other configurations for obtaining results as well.

Network Size: We used a minimum node requirement of 500 and a minimum validator requirement of 90 for the simulation. Nodes are required for network system establishment. Nodes become validators, and the election mechanism requires a minimum of 90 validators; therefore, we also keep 90 validators as the minimum validator requirement to complete the process. We may run several simulations; in one simulation, 20 block creation cycles are made.

Number of Transactions: We do not restrict the number of transactions in the block; the network may decide the number of transactions by itself according to the network storage capacity. We run simulations with a minimum number of transactions, such as four to six.

Node Behavior: The system is Byzantine fault-tolerant and may survive under malicious activities by nodes. We evaluated the complete system under different conditions. Malicious activities that are possible in the system, and the node responds to those conditions.

Evaluation:

For the entire network security evaluation of the Nazfast system, we divide the blockchain architecture into several layers, similar to a traditional network’s Open System Interconnect (OSI) model [48], because communication on the blockchain network also consists of different sections. There is no formal architecture layer defined in the literature on the blockchain. Hence, we defined it as an infrastructure layer, data layer, network layer, and protocol layer. All those layers of blockchain architecture are involved in the communication. The application layer may also be considered a blockchain layer. However, we have not worked on the application layer in our proposed work. We have tested our proposed blockchain architecture layers under different conditions to examine the security, scalability, and decentralization of the Nazfast consensus. In this section, we only provide security evaluations. Many attacks are tested on a simulation, and few are controlled logically. We discuss the logically controlled attacks thoroughly in this section. Further evaluations are presented in the discussion section, Section 7 of the paper. Figure 9 provides a short overview of security attacks that are discussed in this paper under the umbrella of blockchain architecture. We provide a brief discussion on each security condition result below.

Infrastructure Layer Vulnerabilities

The infrastructure layer is the basic layer of the blockchain, in which hardware and software are included. The infrastructure layer defines the network’s nature because blockchain networks are either private, public, or a consortium of any type [49]. After nature, the initial infrastructure nodes are the second main module of the blockchain network. Below, we discussed the vulnerabilities that can somehow affect the infrastructure layer of our proposed blockchain network.

• Bribery Attack

Condition: A bribery attack is considered a severe attack in blockchain [50]. In bribery attacks, validators engage in conspiracies in the network so that they can make other validators biased by performing any type of forgery. By this attack, validators may obtain confirmation of forged transactions in the block by gaining acceptance from other validators. Our consensus may suffer from this attack. The main chain blocks can be forged by bribery. We used some techniques to overcome this attack, as below.

Result: We try to control the bribery attack by selecting block producers in a very challenging way. S&Sem gives all the required control over the block producer selection. It controls the bribery attack by using different techniques, such as the winners of the last election cannot take part, multiplication by a random number, extra bonding time comment, and so on. The short-range attack is also a type of bribery attack. Our system resists this attack well because when a validator wants to get its staked coin back and unjoin the network as a validator, it first has to pass its extra bonding time duration, and then a validator can get its coin back. Extra bonding time improves security because a longer bonding time reduces short-range attacks. A validator can be easily punished if its coins remain in the stakes for a long time after the election process.

2.

Block Withholding Attack

In this type of attack, the attacker becomes part of the block production team but does not produce a block [51] or a block that has not been received by others for any reason in the system. This type of attack is also possible in our consensus mechanism. Our consensus may suffer from this attack. We tested this attack under multiple conditions and observed the results of the consensus resistance after this attack.

Condition: If the block proposer of the main chain does not produce a block within its specified time.

Result: We tested the issue on different block creation cycle numbers and used a swapping mechanism to solve the issue. We applied the complete swapping mechanism described in Section 4 and selected new block producers for the block creation cycle.

Condition: If the wildcard entry validator does not receive a proposal or an invalid proposal.

Result: The wildcard will respond if the proposal is valid or not; if the proposal is not valid, it responds nil. If the proposal is not received, it responds with a process error because wildcard response is very important and has to respond in any situation.

Condition: If the block proposal is not sent to all the v_validators of the block creation cycle.

Result: We observe the following two results for this condition:

(a) If more than 2/3 of the V-validators receive the proposal block, then consensus will not stop, and a block will be created in this block creation cycle.

(b) If less than 2/3 of the V-validators did not receive the proposal block, then consensus will be affected and a block will not be created.

Condition: After V-Validators, we have correctors in our system to validate the block. If correctors do not commit, broadcast the block on time, and hold it in the network.

Result: Our system resists this attack by using a reward mechanism. We attracted correctors to receive the election starter title as a reward. Correctors need to complete their jobs the fastest to gain this title. Because the corrector who did the fastest commit job will become the next election starter and would be rewarded by the system, the corrector would do their job as soon as possible. There are also rewards for forgery caught in the block for the correctors in the system. Due to both mechanisms, the probability of completing the consensus on time with honesty becomes high. The security and liveness of the consensus also improve.

3.

Pool Hopping Attack

Condition: In this attack, block producers only create blocks when the block rate is high in the system. It may weaken the liveness of the network. Others also try to prevent this attack in their blockchain system by using different techniques such as smart contracts [52]. Our system may also encounter this attack, and we used different techniques to resist this attack.

Result: In Nazfast, the block producer is already selected by S&Sem. The S&Sem attracts validators to become block producers in many ways, such as to become valid validators and to gain excellency points, they must participate in the election process. Therefore, the rate is just one factor in the system. However, it may become a problem if the Nazfast block producers do not create a block in the network due to rate fluctuation. Hence, we suggested a uniform block production rate in the system to prevent a pool-hopping attack.

4.

Block Discarding Attack

In this type of attack, an attacker intentionally discards other blocks in the block creation process so that only pre-decided blocks can get approved in the system [53]. It is performed by an attacker or a group of attackers in the system. They can forge the transaction by attempting this attack on the blockchain network system. We discuss a few situations of this attack in our consensus.

Condition: If the prevote does not send to the whole V-validators.

Result: There are also two situations.

(a) The consensus gets affected if V-validators of the block creation cycle do not receive prevotes from 2/3 of other V-validators.

(b) The consensus does not get affected if the V-validator receives at least 2/3 prevote of others and does not receive prevote from complete other V-validators of the block creation cycle.

Condition: Not all prevote sender’s validators send pre-commit to the correctors.

Result: The block will not be created by correctors if a minimum of 2/3 pre-commit is not received by V-validators.

Condition: All correctors do not send a commit.

Result: The corrector cannot proceed if it does not receive all the commits for the block. After a timeout, the block will be discarded if it does not receive all commits.

5.

Fork After Withholding Attack (FAWA)/Selfish Mining

Condition: In a fork withholding attack, in this type of attack, the attacker holds the valid block and does not release it to the network. Instead, they keep it private. After some time, the attacker releases the withheld valid blocks to the network to create a fork in the system [54]. This attack was found in early consensus mechanisms, such as in Bitcoin [1]. This attack is almost similar to a selfish mining attack [55]. It is also a high-severity attack in the previous blockchain consensus. An adversary creates/mines the valid block and does not broadcast it to the network. Upon broadcasting the blocks, they create a fork, and it can hijack the main chain. Both attacks are similar in disrupting the network and the block propagation issues but only differ in their strategies. We discuss both attacks on our consensus together in the conditions below. If the block producer holds the block and does not produce on time and tries to create a fork in our network system.

Result: To create a successful fork in the network system, several valid blocks should be broadcast together. Our system is resistant to this attack because we only allow one block at a time. Every block creation cycle has a block producer to produce a block. If it does not broadcast a block in its turn, the block will be useless because, at the end of every block creation cycle, the block that does not get committed should be dissolved by the block creator and the transaction returned to the pool. However, if the block producer keeps the block for further broadcast, it is also not possible. We used a strong block producer selection process in our consensus that does not allow block producers to get reelected again easily.

6.

Nothing-at -Stake Problem (Attack)

Condition: Most of the previous PoS-based consensus algorithms face an issue that is called the nothing-at-stake problem. In which an adversary tries to create an alternative chain to gain profit by losing nothing. It does forgery in the system with nothing to lose [56]. Others try to solve this issue by using different techniques [57]. Our consensus resists this issue in different ways.

Result: Our network system used Sea Shield to save bond transactions, and we used a long process to release the bond. If the validator needs to take their stake back, the network will stop the validator from any type of contribution as a validator and make them stop until they complete the unjoin process. The total time calculation of S&Sem also contributes to resisting nothing-at-stake problems because it contains coin age and the extra bonding time factor of the validator.

Data Layer Vulnerabilities

In a blockchain network, transactions are considered a main component of the data layer. There are multiple choices of data storage available in the blockchain, on-chain and off-chain. Both have their advantages and disadvantages [58]. We suggest on-chain storage for our proposed work because it provides immutable and transparent data. To increase the security of the data, the blockchain uses different cryptographic techniques to secure its data from any forgery. We apply the cryptography technique ‘zero-knowledge proof’ [37] to verify the data. This technique proves the data without revealing it. We used this technique in many places to maintain the privacy of the system. We also used multiple cryptographic techniques to secure the data. Below, we discussed these techniques.

Hash Collision Attack: The hash collision attack affects the data layer of the blockchain. When two or multiple inputs have similar hash values, it is called a hash collision attack. To avoid this attack, we used the SHA-256 secure hash algorithm to hash the data layer in the proposed system. The SHA-256 algorithm [59] for hashing in the complete system also improves the authenticity of the system.

Eavesdropping Attack: It is considered a low-severity attack in blockchain networks. In this attack, an adversary tries to gain sensitive information to disrupt the network. To avoid such a type of attack, cryptography algorithms’ symmetry and asymmetry [60] are mainly used to encrypt the network data. We used strong encryption asymmetry algorithms such as the Rivest–Shamir–Adleman(RSA) algorithm [61], to protect our network system.

Private Key Prediction: The RSA algorithms used public keys [62] and private keys [63] for the encryption and decryption process. The encryption depends on the private key in the system. The private key should be kept secret and should not be easily guessed by anyone else. We used a strong cryptographic pseudorandom number generator [64] to avoid a private key prediction attack.

We used cryptography techniques to reduce attacks on our proposed blockchain network system data. However, our proposed system data layer may be attacked under the conditions below. We tested the conditions and derived the possible solutions to the issue according to our network system.

• Cryptographic Attack

In this type of attack, an adversary tries to gain access to the sensitive data by breaking the cryptographic processes that guard these data [65]. These attacks weaken the authenticity, integrity, or validity of the system. We also tested some conditions that may encounter cryptographic attacks. We apply the strongest encryption, decryption, and hashing algorithms as a prevention from cryptographic attacks in the consensus.

Condition: If the block is not sent by the block proposer.

Result: Every receiver validator first confirms whether the block is sent by the proposer or not by checking the digital signature [42] of the block. If the block is not sent by the proposer, the block will be rejected by others.

Condition: If an invalid transaction is received in the block.

Result: After the verification of the block sender, if the block is sent by the proposer, then the receiver validator will validate the block by checking the transaction validity by zero-knowledge proof [37] and report forgery if necessary.

2.

Transaction Malleability Attack

It is a very critical attack on blockchain consensus. In this type of attack, the adversary tries to change their ID before block confirmation to obtain the deposit twice from the network. This attack has been addressed by others as per their work [66]. Our network system may also encounter a situation related to this attack. The situation arises when the validator changes its identity from validator to node in the network.

Condition: We have seen a special transaction that is performed by an unjoin validator in Sea Shield [11]. The unjoin block of the validator chain is created with an unjoin transaction by a validator. It is like a dummy transaction because the validator does not receive the stake amount at the same time when the transaction is made. Generally, the transaction is considered as confirmed just after the block finalization, and the receiver may use its amount, but in the Sea Shield, the host will release the stake amount to the unjoin validator after the complete unjoin process. The unjoin block is posted in the network, but the receiver has to wait for the complete unjoin process of Sea Shield to use that unjoin bond coin. In this situation, the unjoin validator may claim that it did not receive an amount from the network and try to obtain twice the amount from the network or use that amount before the host released it to the validator because it was present in the unjoin block.

Result: For the security and integrity improvement of our network, we introduced a transaction posted by the host in the main chain of Nazfast after releasing the stake to the unjoin validator. We added this transaction in the block of the main chain so that the unjoin validator will not claim that it did not receive the amount from the host. The transaction holds the proof that the host has released the amount to the unjoin validator. The main chain block validation committee also validates the transactions of the block that used the unjoin coin of any previous network validator to stop forgery in the system.

3.

Time-Locked Transaction Attack

Condition: In this type of attack, an adversary uses coins that are in locked form in the network. The coin is not allowed to be used for some specified amount of time, such as when one party has padlocked some tokens for a specified time and attempts to spend them before their release time [67]. In our consensus, we have bonded coins in the network. The validator may try to use that bonded stake before unjoining the network. However, we resist the attack by using the approach below.

Result: This attack is not possible in our system because we used a validator chain, and all the bonded stake transactions are present in the chain. All V-validators and correctors have this chain. Also, the host has posted a transaction on the main chain that has details of the unjoin validator’s coin. While validating transactions of the block, they can validate the transaction from the validator chain and the main chain, and if they find forgery, they can reject the transaction.

4.

False Top-Up Attack

Condition: It is a critical exploit that can squeeze all the coins from the blockchain system, in which an adversary makes a false transaction in the system and obtains the right coins [68]. Suppose this attack is successful; it can cause significant damage to the system. We used wildcard entry validator to resist this attack in the system, as discussed below.

Result: The purpose of the wildcard entry validator is to improve the security of the consensus process. If someone tries to dishonestly select all 30 validators, there is a possibility that the wildcard entry validator will be honest and report the dishonesty of others. There is also a time constraint to make the wildcard entry validator dishonest by others because the wildcard entry validator joins just before the block creation cycle, so it is not pre-determined by any other member of the network. This feature also improves its security.

5.

Rug Pull Attack

Condition: A rug pull attack is considered the deadliest attack in blockchain [69]. The attacker stacks a good/fancy token in the blockchain. However, after some time, when the network trusts the node and shifts its token/amount/reward to the attacker, the attacker instantly withdraws the amount and leaves the system by performing any type of forgery. We can also encounter this risk in our proposed consensus because it uses coin staking in the network for nodes to become validators, so we consider the following solution to reduce the security risk of the network.

Result: The system used Sea Shield consensus to save the nodes’ records in the validator chain when they become validators or leave their responsibilities as validators in the system. It used an extra bonding time concept and a long procedure to join and unjoin the network while taking care of the network security. By using Sea Shield consensus, rug pull attacks becomes very difficult in the network.

Network Layer Vulnerabilities (P2P)

The network layer creates an environment for data transmission within the entire blockchain network. The peer-to-peer network architecture [70] makes data communication possible in the blockchain network. The blockchain uses many security measures to maintain the confidentiality of the data. Every piece of data that is received in the network does not get accepted because there are many security checks available in the blockchain. After all verification processes, the data will be accepted in the system. The trusted execution environment (TEE) ensures the integrity of the data transmission in the network. Below, we discuss the vulnerabilities that are possible in our presented mechanism network layer.

• Sybil Attack

Condition: A Sybil attack is a very acute vulnerability of the blockchain system, in which an adversary may control many nodes of the network system by creating multiple identities to do forgery or misconduct [53]. Our presented consensus can be threatened by Sybil attacks. We try to avoid this attack at some points of our consensus, such as in the block producer selection part, as below.

Result: S&Sem gives protection from Sybil attacks. It uses the concept of a vote flag that mitigates false identity forgeries in the network during the block producer selection. The vote flag is a combination of multiple elements and is only released to those validators who do not request to unjoin the network. The validator who is already about to leave the system cannot become part of the election mechanism competition. The list of active validators is released by Sea Shield to the S&Sem because it contains all the details of the active validators in the system. The Sea Shield keeps track of all the active validators of the system so that the network restricts them from participating in the voting process. After using the vote flag in the system, it will become very difficult for users to create their multiple IDs or vote in the system. The details of the vote flag are discussed in the paper [12].

2.

Eclipse Attack

Condition: This attack is performed in the network layer of the blockchain. The adversary tries to manipulate nodes one after the other. The adversary disconnects a node from the network and connects it to a malicious node in the network [71]. In this attack, the adversary attacks a single node or a selected part of the network. Our consensus may be attacked by this condition.

Result: In our consensus, we used the concept of host. The host updates the network peers before every election process. We have observed it in step 1 (network setting) of the S&Sem process. If this attack happens in our network system. The network will soon be able to get its original form back. This attack will not last long in our proposed blockchain network.

3.

Double Voting Attack

Condition: This attack happens in the blockchain network that uses a voting mechanism to select the block producers. The adversary may broadcast multiple votes in the system during voting so that the system may crash, delay, or lose liveness. We can also encounter this problem in our consensus because we used an election mechanism in our consensus to select a block producer. We resist this attack in the following way.

Result: The election mechanism used voting in the selection process. Hence, the election mechanism results directly affect our consensus. Therefore, S&Sem used a check duplicity round in the election mechanism to stop this attack [12]. We also inherit all the reward systems of the S&Sem in our network. Therefore, we attract validators by rewards to find duplicity in the voting process. It also controls malicious activities in the system.

4.

Alien Attack

Condition: A blockchain network contains many nodes, which can be near or far, according to the network. Sometimes, it becomes hard for nodes to distinguish themselves in the network due to the pool population. Therefore, this attack is also called a peer pool population attack. This attack was first identified by the SlowMist Team. This population leads to an alien attack on the network. Alien nodes distract real nodes of the network. They can appear between two nodes, apply a delay, and cause falsification [72]. Below, we discuss the attack on our network.

Result: We have also proposed a blockchain network consensus. It could have more nodes and can deal with this situation. Furthermore, in our network, the validator plays a very important role, and they have to get each other for the S&Sem election and Nazfast consensus; therefore, an alien attack has to be controlled. ID chain is considered to be the best solution for this issue. We used a validator chain to save the validator’s record so that every validator has a unique ID, and all the other network validators have access to this information because the validator chain is also a blockchain. By using a validator chain with Sea Shield consensus, the network validators will not get confused or disturbed due to the pool population attack because of any alien in the network, and also, aliens would not create any conflict between peers. The network also constantly updates and manages its peers for continuous improved progress.

5.

Denial of Service Attack

Condition: It is a low-severity attack in the blockchain. In this attack, an adversary tries to attack the system by creating numerous requests to the network. The network gets flooded due to over-requests, and as a result, it will be out of service [73]. Other proposed solutions, according to their network, such as [74], have been proposed for efficient and flexible DDoS mitigation solutions. In our consensus, we also deal with this situation at some point.

Result: It is possible in all four phases of the Nazfast consensus. Any committee member may broadcast multiple votes or proposals to the network in any phase. The other committee member will only consider the first received proposal or vote in any phase, and discard the remaining others. It may slow down the system, but the network may come out of this condition. The system may punish the adversary by checking the digital signature.

Protocol Layer Vulnerabilities (Consensus)

The protocol layer is an essential part of the blockchain network. A consensus mechanism determines how peers reach decisions in the network. There are many protocols available in the literature for different types of blockchain networks, such as CE-PBFT [75], ReVo [76], Proof of Fairness [77], and FuzzyChain [78]. We also present a consensus mechanism in this paper for a PoS-based blockchain network with improved efficiency. As we discussed, this is the main component of the blockchain, and it should not be attacked. However, our presented mechanism may be attacked in different ways. Below, we evaluate the conditions that can affect our system and its countermeasures.

• Long-Range Attack

Condition: In this attack, an adversary tries to create a fork in the blockchain. The new branch contains a partially or completely different history from the base chain. Such as consider our main chain Nazfast (Nf) blocks (Nf0, Nf1, Nf2, Nf3, …., Nfn). An adversary tries to transform Nf into Nf’ consisting of k ≥ n blocks so that (Nf’0, Nf’1, Nf’2, Nf’3, …., Nf’k) [79]. With time, the branch becomes longer and succeeds the blockchain. The adversary may have confirmed forged transactions in the system by using this fork. Our system may encounter and resist this attack as below.

Result: Our system is resistant to this attack. The proposed network used two consensuses: Sea Shield for the validator chain and Nazfast for the main chain. Both consensuses are resilient to forking. We already described the forking issue of Nazfast in the discussion section of the paper and the forking issue of Sea Shield in the paper [11]. Mainly, the proposed architecture of both consensuses does not create a fork in the network. We control this attack in our system by not allowing forking in the blockchain. We control the issue by not creating a fork because Sea Shield results are used by entire networks such as S&Sem and Nazfast. The Nazfast consensus used S&Sem election results, and S&Sem used Sea-Shied outputs. Therefore, we designed the fork without consensus. Due to its fork-free nature, it is also resilient to long-range attacks.

2.

Liveness Denial

Condition: This attack happens when, intentionally or unintentionally, the block production in the blockchain network stops. It leads to a temporary or permanent network shutdown [80,81]. We also deal with the situation in our proposed work.

Result: Nazfast consensus required S&Sem results to complete the process. For any reason, if S&Sem cannot work and the Nazfast runs out of the block producers’ list, then the block production will be stopped in the network. To resist this situation, we suggested holding three elections before the start of the next round.

3.

Finney Attack

Condition: In this attack, an adversary pre-mines/creates a block with a transaction and creates an identical transaction before the pre-mined block is broadcast to the network. It will cause a transaction forgery in the system [82]. This attack is common in previous blockchain consensus, such as in the PoW consensus [83]. It is like a class of double-spending attacks [84]. Below, we discuss how our system resists this attack.

Result: This situation may not be created in our system because the block producers are selected by the strong S&Sem. It is very difficult to pre-determine who will get selected for the block production in the next election by S&Sem, and if they become the block producer, they would have very little time to manipulate the system. Nodes are unaware of their selection, so when they become a block producer, they will create a block with the recent transactions that are present in the pool and broadcast it in their turn. For instance, if it happens, then the block validators and correctors of the block will check the transaction validity. Each block creation cycle has only one block, and the finalized block is broadcast to the whole network. All transactions in the network are considered invalid/unconfirmed until they become part of any block. Therefore, the identical transaction has not created any problem and gets rejected when it becomes part of any future block.

4.

Alternative Historical Attack

Condition: This attack is also called a block reorganization attack in many places. This attack requires huge computing power to perform. In this attack, an adversary sends a transaction to the recipient and simultaneously tries to create a fork in the network with the transaction that returns the same amount. Suppose the adversary succeeds in creating a longer chain than the main chain. The forged transaction will be confirmed in the network [85]. It is also a type of double-spend attack.

Result: Our network is resistant to this type of attack because it does not allow forks. Every block creation cycle has its height number, and only one block is created at one height. The network will not increase the height number until the block is created and finalized by all committees of that block creation cycle number. Only the block that obtains its final commit is broadcast in the whole network. Every node has the same previous block hash in the network. So, if the block producer creates a block with a different previous block hash, the V-validator and corrector will apply forgery on that block producer at the time of validation. Suppose all the V-validators and correctors together try to validate a block that has a different previous block hash created by an adversary block producer and give its final commit; then the host will stop it because we have a host entity in the network that has all the records of the main blockchain, and the host confirms the previous block hash in every block before broadcasting it in the network to control the forking. The network nodes can also raise complaints about the different previous block hash in the received block to control any type of forgery in the network. This attack is only possible if the adversary has control of more than 2/3 of the total network nodes, and achieving such significant control over the network is not a piece of cake.

5.

51% Attack

Condition: This attack is the most highly severe attack in the blockchain consensus. Almost every blockchain consensus encounters this type of attack in its network. In this attack, a single entity has very high powers in the network. It might be because of its high stakes or computational power in the network. It can lead to a 51% attack [86], in which the majority has the ruling power of the network. Our consensus may resist this attack under the following conditions.

Result: This attack affects the decentralized nature of the blockchain network. Our consensus tries to avoid the influence of a single entity in the network by using S&Sem. The S&Sem has multiple factors to get selected for the block producer, such as total time calculation, stake value, voting, and randomization. Because of all these factors, a single entity cannot control the whole system.

6.

Grinding Attack

Condition: Grinding attacks are also very dangerous for blockchain networks [87]. A validator may precompute the protocol so that it can manipulate the block producer selection process to select it as the block producer/slot leader for the next block creation cycle. Some protocols use randomness to avoid this attack [88]. We also control the attack in our network with the below solution.

Result: We used S&Sem in our network, and S&Sem reduces grinding attacks since it is very difficult to pre-determine the block producer in the network. The S&Sem process creates so many constraints for the validators that they cannot become block producers by forgery. It is not easy for the validator to manipulate the network and become a block producer by using any incorrect approach in S&Sem.

7.

Coin Age Accumulation Attack

Condition: In a coin age accumulation attack, a validator may have enough time and resources so that it can manipulate the system by its powers. The attack is also addressed by others in the literature, such as [57]. In this attack, due to the saturation of resources, an adversary can easily be selected for the block producer/slot leader in the selection. The Initial consensus of PoS used the coin age mechanism in its consensus for block validator selection, such as PPcoin [89]. Coin age calculation depends on the number of coins. Coin age calculation is used to strengthen the consensus by encouraging long-term participation in the network. We also used this technique in our election mechanism, S&Sem. The coin age technique is very useful for engaging the validators long-term in the network. It improves the liveness of the network. However, due to coin age calculation for validator selection, it may lead to coin age accumulation attack [90,91].

Result: By using S&Sem and Sea Shield together, we control this attack in our system. The S&Sem used other parameters with coin age calculation, such as stake value, extra bonding time commitment, vote value, and randomness. Coin age calculation is also secured by Sea Shield because we use a validator chain to store coin age, stake value, and extra bonding time in the network; therefore, manipulation is not possible with the data record.

8.

Block Double Production Attack

Condition: In this attack, a block producer produces many blocks simultaneously at a single height to pollute the network system [92]. It can lead to other attacks in the system as well, such as short-range or long-range. Our system may encounter this attack.

Result: Our block producer may create and broadcast multiple blocks together at their turn to the block-validating committee of the network. Our system will resist this attack logically. Our network system allows one block at one height during the block creation cycle. If any member of the block creation committee receives multiple blocks from a similar sender (sender confirmation by the digital signature of the block), it will only consider the first block that it has received from it and discard the remaining received blocks. The block creation cycle will only proceed for a block that has 2/3 prevote. If a block obtains a 2/3 prevote among other blocks from the committee, the other blocks definitely cannot obtain the required prevote from the network and automatically get discarded from the system; the only block that will proceed further is the only valid block. The system may punish the block producer if it finds an intentional block double production attack from the block producer in the network.

9.

Intentional Misuse

Intentional misuse is also considered a security risk in blockchain. The validator intentionally forged the system by using any wrong means. Many types of intentional misuse are available in the blockchain [93], such as 51% vulnerabilities, liveness attacks, and Selfish mining. We evaluated a few intentional attacks that can damage our proposed network system, such as the proposer creating a forged block and sending it to V-validators. We tested this scenario under two different conditions.

Condition: The proposer creates an unfair block and sends it to a few V_validators.

Result: If only a few validators receive a forged block, consensus will not stop, and a block will be created. However, if forgery is confirmed by any V-validator, the host will check whether it is a network attack or from the proposer itself. If the proposer attacks, the proposer will be punished by the network.

Condition: The proposer sends a forge block to more than 2/3 V_validators.

Result: The network will confirm the forgery; if it is not a network attack, then the proposer will be punished for creating the forged block.

We have other intentional mistakes that can emerge in our system, such as those we discuss below.

Condition: The corrector sends an incorrect forgery report to the host.

Result: The proposer created a fair block, and all but a few correctors sent a forgery report to the host to receive the forgery reward. The host will confirm and apply a penalty to those correctors who sent incorrect forgery reports to the host.

Condition: The Wildcard validator tries to become dishonest while selecting the next wildcard validator.

Result: In our proposed system, every wildcard entry validator selects the next wildcard entry validator from a pool where their identities are hidden from the system. The wildcard validator selects the next wildcard anonymously. However, if somehow the wildcard entry validator does any planned attack, such as selecting a malicious validator as a wildcard entry intentionally for the next block creation cycle. The system has 2/3 liveness; hence, the wildcard entry validator response cannot affect the block creation cycle. However, this situation would not last long because the system updates the pool randomly with the hidden identities just before every wildcard entry selection, so that no one knows the true identity of the wildcard before selection. Moreover, the system also broke the sequence after the 20-block creation cycles, and the election starter will select the next wildcard entry validator from the pool. The election starter is also unknown, and who the election starter will be will be revealed at the end of the 20-block creation cycles. Therefore, in the first block creation cycle of every round 1, the election starter selects the wildcard entry validator to stop the intentional attack in the system.

We are summarizing the list of vulnerabilities in

Table 5. List of attacks that may affect block finalization time and validators’ participation.

Attack Name	Block Finalization Time	Validator Participation Rates
Bribery Attack	Is not affected	May be affected
Block Withholding	May be affected	Is not affected
Pool Hopping	Is not affected	May be affected
Block Discarding	May be affected	May be affected
Fork After Withholding	May be affected	Is not affected
Sybil Attack	Is not affected	May be affected
Eclipse Attack	Is not affected	May be affected
Alien Attack	May be affected	May be affected
Denial of Service	May be affected	Is not affected
Liveness Denial	May be affected	May be affected
51% Attack	Is not affected	May be affected
Coin Age Accumulation	Is not affected	May be affected
Block Double Production	May be affected	Is not affected
Intentional Misuse	May be affected	May be affected

Note: Our system has recovered from all of the above attacks by already defined processes, explained well in the evaluations.

that can affect the block finalization time and validators’ participation in the network. We have already discussed that the system may be affected by these attacks; however, it will soon recover from the attack. Because our system has the capacity to resist and recover from the attacks, as we explained above.

6. Discussion

Comparison with Tendermint on Security Aspects

Our presented consensus is different in many ways from the Tendermint consensus. Below is the list of the differences between our consensus and the Tendermint consensus. These changes feature the Tendermint consensus to improve the security of the entire presented network system.

• Correctors and Wildcard Entry

In our proposed system, to mitigate the risk of forging due to a pre-determined block proposer by-election mechanism, correctors and the additional concept of wildcard entry validator with V-validator are used in the consensus mechanism. These security measures are not present in the Tendermint consensus. Although Tendermint consensus does not use an election mechanism for block proposer selection, instead, it uses a round-robin algorithm to select the block proposer. Still, there is a chance of forgery due to the block proposer in the network. We used these concepts to improve the security of the Nazfast consensus. Beyond the V-Validator set of a block for validation, Correctors are an additional block security verifier in the block creation cycle. Any intentional forgery due to pre-determined proposers will also be controlled in the network by a wildcard entry validator.

2.

Saving the Election Record

The validator set that validates the block in the network changes over time. In Tendermint, knowing the validator set that validates the particular previous block in a chain is a slow process and also computationally data-intensive. We need to download all previous blocks before that specific block and verify by checking the digital signature and hashes. Execute the corresponding transaction to obtain the change in the validator set so that the exact validator set of the block can be achieved [94]. In our proposed mechanism, the election result will be the validator set for block creation cycles. We saved the election result in the main chain block to resolve any future conflict or dispute between validators. It will be fast and take less computation than other methods to get the validator set in the future. Also, we used a swapping mechanism and wildcard entry validator concept in the block creation process, which is why the election result must be saved so that we can trace the validation set of a particular block easily. Election results should also be saved in the blockchain system as a permanent record for future penalties and punishments against any forgery to improve the overall security of the network.

3.

Anonymous Block Forgery Catcher

In Tendermint, we have not found any way to catch forgeries after a block is broadcast into the network. Once the block is released to the network, it is finalized and cannot be altered. However, there is still a chance of forgery in the block due to the block validation set falsification. We use the concept of a block forgery catcher in the network to control any misconduct in the network system. After the broadcast, the forged block can be identified and punished by the network by using the anonymous block forgery catcher. Our blockchain network system also perceives the feature of no editing in the block after block finalization in the network. After the confirmation of forgery, the network will not edit the false block; instead, it creates a new block and adds it to the chain that contains all the falsification details of the forged block. The block will be created and validated as a regular block by the recent block creation committee of the network. The network will also punish the block proposers and the committee for the false block.

4.

Validation Committee Signatures

Tendermint adds the last block commit in the block to keep signatures safe. It collects all the commits of the last block and adds them into the recent block. During this time, the commits can be lost or edited. The committee can also be changed. The block proposer and validation committee signatures are very important in our proposed network. Therefore, to avoid any destruction, we completed the block with all its signatures by the proposer in the same block creation cycle under the block validation committee. Due to this, no validator signature of the validation section would be lost or edited.

Scalability

Tendermint is considered an efficient and fault-tolerant consensus among the consensus family of blockchains. We used Tendermint as our main comparison consensus in our work because we used the concept of multiple phases in Nazfast, such as Tendermint. Tendermint consensus provides liveness in the presence of malicious nodes. We simulate and observe the behavior of Tendermint consensus under different conditions in our work. We observe the consensus time by different network arrangements, as Figure 10 shows the block creation time with two connections, and Figure 11 shows the block creation time with all others in the network having a propagation time of 0.2. The simulation process shows a significant difference in both results. We observe variation in the block creation time due to the change in the number of connections in the network.

Figure 12 shows the block creation time change with respect to different numbers of connections in the network, having similar validator numbers and propagation time. It depends on the application network and which network arrangement will be used to deploy the blockchain. To achieve maximum execution time for better results of simulations, we used maximum connections in execution to complete the further simulation process. The block creation time is also affected by the propagation delay time of a network. We used 0.1 as a propagation time in the simulation with connections to all validators in Figure 13. In Figure 13, we may observe that it takes a little different time than Figure 11 results. However, to achieve more realistic results, we used 0.2 propagation time throughout our simulations.

We also observed that Tendermint consensus block creation time is affected by the number of transactions in the blocks. Figure 14 shows the block creation time with respect to the number of transactions in the block. The consensus takes more time according to the number of transactions, due to the transaction validation process in the consensus. We evaluate Tendermint consensus from the inside, and we find from Figure 10, Figure 11 and Figure 13 that Tendermint consensus block creation time majorly increases with the increase in validators in the system. It is happening because the consensus involves all the validators of the system in the block-creation process. Therefore, we run the Tendermint simulation with the minimum requirement to achieve the least block creation time of Tendermint, such as five validators, three transactions, two connections, and a 0.2 propagation delay.

Figure 15 shows the simulation results with minimum initialization; we observe an average of 1.2 s as the minimum time for block creation in the Tendermint consensus. However, as the number of validators increases, the block creation time increases, and the throughput decreases. It will eventually drop the blockchain network performance. In the Nazfast consensus, we try to overcome the time increment problem to improve the scalability of the consensus. Our presented consensus is different in many ways from the Tendermint consensus to improve the scalability issue. Below, we present the major differences that we made in our consensus in comparison with the Tendermint consensus.

Comparison with Tendermint on Scalability Aspects

• Reduced and fixed validators

The consensus used BFT layers for block finalization to improve security, such as the Tendermint consensus. The BFT layer has a high communication overhead rate. It reduces throughput and improves network latency. Tendermint uses network validators to sign the block for validation. It also increases block finalization time and reduces the throughput of the network. We also used the BFT layer for security; therefore, to improve the throughput of the complete consensus, we reduced and fixed the number of validators for the consensus to improve the scalability of the network. We used only fifteen V-validators, one wildcard entry validator, and five correctors in every block validation process instead of involving complete validators of the network. Hence, we have achieved block finalization in very little time.

If we increase the number of validators in the validation process, the throughput time will be increased. They are directly proportional to each other.

Block finalization time (Bt) ∝ No. of validators in the validation committee (Nv)

Bt ∝ Nv

∵ Bt/Nv = k

∴ Bt = k (Nv)

where k is the non-zero, positive constant of proportionality.

In such a case, where the values Nv₁ and Nv₂ of Nv correspond to the values Bt₁ and Bt₂ of Bt, respectively, then it turns into the following:

Bt₁/Nv₁ = Bt₂/Nv₂

Therefore, the reduced and fixed number of validators in the Nazfast consensus leads to a higher throughput with less communication overhead in the proposed network.

2.

Only five correctors for a commitment

In Tendermint consensus, all the validators of the system are involved in the validation process. It creates strong broadcasting pressure in the network. The communication overhead is also very high. In our proposed work, to reduce the total time of a block creation cycle, we reduce the number of validators in the commit phase. During the block creation cycle, “check validity phase”, V-validators of the recent block creation cycle send their vote, which is pre-committed to correctors rather than to each other. Each V-validator sends their vote to five correctors instead of sending it to the remaining 14 V-validators and the wildcard entry validator. It reduces message broadcasting pressure and improves scalability. Also, it increases the consensus’s security because five new validators commit a block as correctors and check its correction for any forgery.

3.

Timesheet concept

We used the additional concept of corrector in the Nazfast consensus to improve the security that the Tendermint consensus does not use. However, we do not want to increase the throughput time of the network due to the work of correctors in the consensus mechanism. Therefore, we used the idea of maintaining a timesheet to speed up the commit process. Correctors speed up the commit process to gain the next election-starter reward. Due to the reward mechanism, the correctors’ work does not get delayed, and the throughput of the complete mechanism increases.

By applying all those techniques, we have succeeded in blocking finalization in a very small amount of time with almost similar latency in the network. Figure 16 shows the block creation time by the Nazfast consensus. We have observed an average of three block finalizations in 1 s on a small number of validator sets.

The block producers may create their block with transactions any time after the election process result declaration in the network and broadcast it in their respective block creation cycle. Therefore, the observed time for block creation starts with the block proposal and ends at the final commit state of the new height phase. We calculated the confidence level of our results by considering a 95% alpha value. Given the confidence interval rate, the results ensure that 95% of samples are in the range from 0.333745948 ± 0.177220195 for block creation with a similar number of validators. Figure 17 shows the block creation time with the error bar of the Nazfast consensus.

In our presented consensus, one block creation cycle consists of many phases. Figure 18, Figure 19, Figure 20, Figure 21 and Figure 22 show the time of each phase during a block creation process. We used 500 test samples to calculate the average results with a 0.2 propagation delay while connected to all other network validators. We observe that the proposal phase takes an average of 0.027822161 s to complete. The check validity phase has two stages, prevote and precommit, prevote takes an average of 0.296942 s, and pre-commit takes an average of 0.01747 s. The commit phase takes an average of 0.004887 s, and the new height takes an average of 0.00781 s. The system bounds the maximum time for a phase; after that, it will automatically time out. The system may also fix the minimum time for each phase to dissolve. We have recorded and presented the average minimum time taken for each phase on the simulator. From Figure 23, we have observed that the prevote phase takes the longest time among all. The prevote takes more time because the validators first validate the block in this phase and then confirm with their prevote in the system.

Election Process Scheduling and Scaling to Speed Up the Process:

The election process result is used in the Nazfast consensus mechanism to create and finalize blocks. 20 blocks in two rounds will be made on the result of one election; therefore, after every 20 block creation cycles of Nazfast, the new election result is required to start a new round. The first election should be held and end before the start of the genesis (very first) block creation cycle; otherwise every election for the next two rounds will begin with the start of the current block creation cycle 1 of round 1 and be executed in parallel with the block creation cycles of Nazfast. The election process should end before the end of block creation cycle number 20 of the current round of Nazfast so that the next round may use the result of the current election. If the election has not ended for any reason, the next block creation cycle may have to wait to get started. For any inconvenience, we recommend that three elections should be performed before the genesis block creation cycle of the main chain. In our proposed mechanism, we have observed three block finalizations in 1 s for the main chain in Figure 16 and Figure 17, and we need new election results after every 20 block creation cycles.

∵ 3 blocks ≈ 1 s

∴ 20 blocks ≈ 6.66 s

Therefore, we have approximately 6.66 to 7 s of time duration for new election results. We have observed that in Figure 24, 100 validators take approximately (5.5 + 1) seconds on average with any number of groups, where + 1 s for system settings to complete the election according to the S&Sem. The time duration is satisfactory for this number of validators; however, we observed that in Figure 25, if the number of validators is increased in the network system, the election time is also increased for a similar number of groups. For the time increment, we recommend horizontal scaling, which S&Sem is already using. The election is held in groups in the S&Sem. S&Sem maximum suggests 30 groups for the election. Since all groups work in parallel, we suggest each group should not exceed more than 100 validators for our system. To control delay in the main chain block creation cycle, the election time cannot exceed 7 s in our system. However, if the system encounters an increased number of validators that cannot be fitted into 30 groups, the system should break the validators into more groups so that the election time will not exceed 7 s. If the system breaks validators into more groups, then the top 30 would be selected among all groups’ results for the block creation cycle. The S&Sem proposed many ways of scaling processes to improve the efficiency of the system, such as “Time Scaling with the number of Validators by using horizontal scaling”, “Parallel execution of steps”, and “Parallel Processing of Jobs in Steps”. We inherit all the scaling ways for the election process in our proposed system, which are discussed in the S&Sem paper to increase the presented system’s overall efficiency.

Scaling to Improve Throughput

There are multiple strategies that we used in our presented consensus to speed up the network output. If the network wants to reduce block creation time, we suggest some parallel processing in the block creation phases. We have four phases in the block creation process. In the last new height phase, we have new block creation cycle settings. In this step, only the host is occupied in the new settings, while all others (the validation committee) are free. We suggest that the next block creation cycle may start in parallel with the new block creation cycle setting step, such as in Figure 26. The next block proposal phase gets started, and the block producer broadcasts the block to the block validation committee while the host is busy with the settings. We have already observed that there is a time bound for the block proposal phase in the block creation cycle. By performing this parallel work, the system may save time and improve the throughput of the network.

We used parallelism at many places in our presented work to increase our throughput, such as in the new height phase network time (Figure 27a). We have three major processes in our system, and all three processes also work in parallel (Figure 27b). We also used parallelism in the S&Sem process to speed up the election mechanism. We try to reduce time to increase network efficiency in terms of throughput.

Communication Message Overhead

The presented consensus is based on the Byzantine fault tolerance technique. This technique involves high-message communication in the system, also called Byzantine atomic broadcast. We used this technique in our distributed system to maintain liveness and fault control. However, the high communication broadcast leads to the low throughput of the system. Therefore, we scale the process to control the high communication overhead by creating a small number of committees in the system for the block creation process. Each broadcast affects the system’s cost, time, and network efficiency. We calculate the total broadcast of the Nazfast consensus to show the network’s efficiency. Figure 28 shows the overall communication overhead of the Nazfast consensus.

Calculating Efficiency

Big ‘O’ and big omega ‘Ω’ notations are used to find the efficiency of the algorithms [95]. There are three measures to find the efficiency. Big O for worst, big theta for average, and big omega for best in terms of time. We find the best and worst cases by calculating the communication message overhead of the system. For the best case, ‘Ω’, we calculate the lower bound of the system by reducing any possible extra communication messages during consensus. For the worst case, ‘O’, we calculate the upper bound of the system by counting the maximum communication overhead messages during the consensus.

Worst Case (Ω): The maximum communication message overhead that is needed to create a block in a consensus process is below.

We can observe from Figure 28 and present the details of every phase of message communication of each entity. Refer to

Table 6. List of variables and their description.

Variable	Description
H	Host
W	Wildcard Entry Validator
Vv	V-Validator
P	Proposer
C	Corrector
N	All network nodes
msg	Message

for the variable details that are used in the below equations.

(a) Proposal: [H+ (9)P + (15)Vv + (5)C + W] = 31 messages

(b) Prevote: [(15, 1)H + (15, 1)P + 15(14, 1)Vv + (15)W] = 272 messages

(c) Pre-Commit: [(15,1)H + (15,1)P + (1 +15)5C] = 112 messages

(d) Commit: [(5)H + (5)P + 5(4)C + 5(4)C] = 50 messages

(e) Corrector Time: [(5)P + (15)Vv + W + H + (5)C] = 27 messages

(f) Network Time: N

The worst case takes (a + b + c + d + e + f) in total of (492 + N) messages as the maximum communication message overhead of the system during all phases of the Nazfast consensus.

We used the BFT concept in our consensus mechanism. The BFT concept allows 2/3 of total V-validators to create a block as well; we reduce the number of messages and calculate the minimum message overhead to create a block in the network system.

Best Case (Ω): The minimum requirement needed to create a block in a block creation cycle is below.

(a) Proposal: [(0)H+ (6)P + (10)Vv + (0)C + W] = 17 messages

We only send a message to the initial six proposers because proposers need to receive the block within the time; otherwise, the swapping mechanism is activated for the new proposer assignment. We also send messages to 2/3 V-validators and the wildcard entry validator because they are required to give prevotes.

(b) Prevote: [(0, 0)H + (0, 0)P + 15(10, 1)Vv + (10)W] = 175 messages

We only send and receive messages to 2/3 V-validators and wildcards for the prevote phase.

(c) Pre-commit: [(0,0)H + (0,0)P + (1 +10)4C] = 44 messages

2/3 V-validator and corrector send and receive with wildcard validator

(d) Commit: [(0)H + (0)P + 5(4)C + 5(4)C] = 40 messages

Only correctors receive and send messages themselves.

(e) Corrector time: [(5)P + (10)Vv + W + H + (5)C] = 22 messages

We can only reduce V-validator in corrector time because all others are necessary according to consensus.

(f) Network Time: N

The best case takes (a + b + c + d + e + f) in total of 298 + N messages as the minimum message overhead of the system. We reduced 194 messages to improve system’s performance.

We only considered the message that is involved in the block creation process. We compromised security for the best-case message calculations. The application network of Nazfast can omit these messages; however, it will weaken the block creation process’s safety and the overall security of the network as well. Therefore, we simulated with 492 + N messages to obtain our throughput results.

Reducing NIL message broadcast

We also suggested that if the block has not been created in the corrector time, the network may reduce the NIL message broadcast from the network time of the New-height phase. It saves the message broadcasting pressure, but it will create problems and increase the chance of forking in the system because network nodes would not know that the block is not created in this block creation cycle, or they did not receive the block. Therefore, we sent NIL for every block creation cycle that does not create the block. We also suggested that the application network may omit the NIL broadcast from the revote and the pre-commit phase. Tendermint consensus also uses NIL messages against unworthy/invalid blocks in the prevote, pre-commit phases. However, it increases the message communication broadcast. To reduce the message broadcast pressure. If the block response has not been sent by V-Validator or V-Validator finds the block unworthy and it does not send NIL, the network will automatically consider it as NIL. Reducing the nil message broadcast eventually improves the system’s throughput, and it leads to improved efficiency.

Decentralization

Decentralization in a blockchain network means the network cannot be controlled by any single entity. We used a consensus mechanism to reach an agreement on such networks. We present the Nazfast consensus for PoS-based networks. A PoS-based blockchain network focuses on strong decentralization because it does not require heavy machinery to operate like PoW [1] consensus. In the previously presented consensus for PoS consensus in the literature [18,96,97], almost all the validators or validators’ set of the network took part in the consensus process to improve network decentralization. We also try to enhance the decentralization aspect of our blockchain network by using many ways that are discussed below, with a comparison of Tendermint consensus.

Comparison with Tendermint on Decentralization Aspects

• Small validation committee effects on decentralization

Tendermint consensus uses a large size of validation set to increase the decentralization aspect of the network. However, due to a large validator set, the throughput decreased, and it also lowered the network efficiency. To improve the scalability of the consensus, we reduced and fixed the number of validators in the consensus. It increased the network’s throughput of Nazfast. However, it decreased the network decentralization. The presented consensus used a very small committee size that strongly affects the decentralization aspect of the network. The system controlled this issue by using an election mechanism in the network to select the block production committee. The S&Sem involves all the nodes in the election to improve decentralization. The S&Sem used many techniques to improve the decentralization in the network, such as providing a chance for less coinage validators in the network to participate in the competition by restricting the last election result finalists from competing again in the next election. Competition must be between three times the number of validators selected from the group, so that each finalist goes through a competition in the network. There are many attractions used by validators that participated in the election competition to obtain votes from other nodes. These attractions also maintain liveness, and due to the involvement of others in the voting, it improves the decentralization aspect of the network as well.

2.

Fork control to improve network stability and decentralization

Tendermint consensus may have forks due to many reasons in the network, such as a temporary fork, a fork due to the partition of resources, or a fork due to the forging of validators. Tendermint consensus may suffer from these forks, but the consensus recovers its state quickly by resolving issues. In our presented consensus, Forking does not happen because blocks have a timestamp sequence number, and each block creation cycle has only one block at one height. No two blocks are created or broadcast at a similar time in the network for the same height. Due to this, if the network received a block with increased height, such as block 13 after block 11, it may ask the network about the missing block 12. Therefore, if the block has not been received, the node may request its peer node or network host to send it a missing block. We also broadcast NIL for the block creation cycle that does not create the block. Nil broadcasting clarifies the network if the block has been created or not in this block creation cycle.

Comparison with Tendermint on Liveness Aspects

Fault Tolerance:

The presented network system is based on Byzantine fault tolerance. The Byzantine fault tolerance means our network still achieves consensus in the presence of malicious nodes in the system. We use the concept of 2/3 percent at many places so that our system does not collapse due to small malicious activity by someone in the network. We also used different techniques to maintain the liveness of the network, which are discussed below.

• Swapping mechanism to maintain liveness

Tendermint uses a round robin mechanism for block producer selection. If the block producer does not produce a block, the system suffers because block creation is the fundamental part of a blockchain network. To maintain the liveness of the Nazfast consensus, we add a swapping mechanism. Every block creation cycle has its pre-specified block proposer. If the block is not produced by the block producer for any reason, the swapping mechanism is used to select a new block producer to produce the block for this cycle. Due to this mechanism, every block creation cycle has a block, and the blockchain network system remains alive.

2.

The block gets dissolved to achieve liveness

In Tendermint consensus, if the block does not get confirmed, the transactions get stuck in the block for a long time before confirmation. In our consensus, we used another way to overcome this issue. We had the block dissolved by its block producer. When a block does not commit in a block creation cycle, the block gets dissolved in the new height phase by its own block creator. Due to this mechanism, no orphan blocks remain in the blockchain network, and unconfirmed transactions do not get stuck for a long time waiting to obtain their confirmation in the network.

3.

No locking mechanism to improve liveness

Tendermint uses a locking mechanism in multiple ways, mainly at voting rounds. The validator used a locking mechanism to show its support for a specific proposal and does not give a vote to any other proposal. We remove this concept from our consensus because in our presented consensus, every block creation cycle has only one block; hence, no locking mechanism is required in any phase. We do not keep blocks in a pending state for confirmation in our consensus.

4.

Valid validator concept

We used the concept in S&SEm [12] of a valid validator to become a participant in the election competition. Therefore, every validator needs to become a valid validator in the network. To become a valid validator, it has to give a vote in the elections. Due to this condition, all the validators of the network have to be active in the network. For this reason, the whole network’s liveness is improved.

Incentive mechanism of our consensus

Validator nodes play a vital role in the PoS-based blockchain network. It creates blocks for the network by using a consensus mechanism. Their presence ensures the liveness of the blockchain. Almost all blockchain networks use incentives for nodes to become validator nodes in the network. Incentivization is the main component of any blockchain architecture to attract validators. Our presented blockchain network also has an incentive mechanism to stabilize the network. We have different types of incentives in our system for validators, such as excellency points and rewards. Also, to control the forgery and malicious behavior of nodes in the network, we also used penalty/coin slashing in the network. We have discussed each below.

Rewards and penalties for each entity

• V-validator and Wildcard Entry Validator Rewards and Penalties

If the block gets accepted by the corrector and added to the blockchain ledger as a new block, all V-validators and wildcard entry validators that send pre-commit to this block will receive their rewards and excellency points at the end of the block creation process. The V-validators that did not participate in the pre-commit phase, although they were in the selected 15 V-validators for this block creation cycle, would not receive rewards and excellency points.

2.

Corrector Rewards and Penalties

The corrector that first found any guilt or forgery in the block creation process receives a bonus forgery reward, plus a corrector reward, and also a bonus excellency point with a corrector point. The other corrector that found the forgery after the first corrector would receive a routine block corrector reward and an excellency point. The network would punish by imposing a penalty on those correctors that did not find forgery in the block while the block is claimed as forged by any other corrector and all those v-validators that gave a pre-commit to this forged block and the proposer of the block. With a penalty, they would also decline in their excellency scale due to a penalty point deduction from their excellency scale.

3.

Block Reward Distribution

In Sea Shield, a validator may share its reward for creating a block in the main chain. We also encourage this rule in our network system. Those nodes that took an interest in creating blocks of Sea Shield will be eligible to receive a part of the reward from the validator that creates a block in the main chain. We used Sea Shield to become a node in a validator in our network. Sea shield consensus needs nodes’ active participation to maintain the liveness of the network. Therefore, the Nazfast consensus block producer may share its block reward with the node that supports it in becoming a validator in the Sea Shield consensus.

Comparison with Other Networks

Our presented consensus is based on proof of stake—Byzantine fault tolerance (PoS-BFT). Our presented consensus used a reduced number of validators by using an election mechanism to accelerate the consensus process. Below, we compare our work with the consensus that lies under the same family of Tendermint and with other major consensus available in the network.

Comparison with the Same Family of Consensuses

The EOS.IO uses a voting mechanism to select block producers and PBFT for block finalization. EOS.IO was presented by Ian Grigg in 2017 [98]. The EOS.IO software (v.1.0.0.) (block.one) used the DPoS [99] algorithm for the block creation process. They used a voting mechanism to select 21 block producers for one round to create blocks. Block producers encourage token holders to vote for them, such as offering rewards or attractions to give them a vote, or using many other ways. The selected block producers produced blocks in a round-robin fashion. The EOS used PBFT (Practical Byzantine Fault Tolerance)-style consensus for block finalization. Every block goes through the commit and pre-commit phases to decide the validity of the block. The block also required 15 other block producers to sign the block for finalization. The EOS.IO produces blocks every 0.5 s. If the block has not been produced, a 0.5 s gap in the blockchain network is observed. Our presented consensus used the swapping mechanism to reduce the time gap and select new block producers. We have already discussed the comparison of Tendermint with Nazfast consensus in the discussion section. Quorum IBFT [16] means IBFT consensus used for the Quorum blockchain. IBFT has a higher throughput than PBFT. However, it has many issues, such as centralization due to validators, because of the dynamic set of validators in the system, and network management becomes challenging. We also used the block creation committee that changes after two rounds; therefore, we saved the election result in the main chain and used Sea Shield for complete details. Avalanche [9] consensus used the gossip protocol with a repeated random sampling method. Each node uses a subset of validators from the network to confirm the state of the transaction. Due to this, it leads to centralization issues in the network. However, it has a good throughput. In our system, we provide improved decentralization in our consensus. Hyperledger Fabric [100] used the PBFT approach. It used a leader and multiple phases to commit a block. Due to the BFT approach, it has a high communication overhead and low scalability. We solve these issues in our consensus by providing high throughput with less communication overhead. Stellar (FBFT) [17] is a blockchain network that uses FBFT consensus. The FBFT consensus is also based on the BFT concept. The consensus faces issues like governance and centralization risks. In our presented consensus, we try to overcome these issues.

Overall Comparison with Other Consensuses

Casper consensus has two versions. Casper friendly finality gadget [101] and Casper the correct by construction [102]. In the initial case, the Casper FFG used PoS with Pow style for block finalization, but later in CBC, it became completely PoS. Casper FFG has slower block production compared with other networks. However, Casper CBC has improved the block production rate. However, our presented consensus has a higher throughput than Casper’s. Polkadot [8] used a parachain model. It has a relay chain (main chain). Consensus has been achieved in the main chain. It also has many parachains. Parachains are individual blockchains that run parallel to the main chain. It is considered an improved consensus. However, it has issues such as centralization and governance complexity. We solve all these in our consensus with improved throughput. Algorand [96] used a cryptographic sortation mechanism to select the leaders for block creation. It provides instant finality to the transactions. Due to the sortation mechanism, fewer coinage validators have a lower chance of participating in the consensus. However, we provide fewer coinage validators to participate in the mechanism. A raft [103] consensus mechanism is also used as a leader to coordinate the consensus process. They select a leader through a process, and the leader commits the log/block after receiving acknowledgments from others. Raft uses leaders for processing clients’ requests. If the leader failed to process, a new leader would be selected, and it would create a delay in the system. We used a swapping mechanism to ensure the liveness of the system. The raft also has a scalability issue; throughput degrades eventually with the increase in the network size. Laksa [104] consensus is based on PoS consensus. The consensus is designed for large-scale blockchain systems. They optimize the protocol by creating committees. They select committees so that the system has improved decentralization and scalability. Since multiple committees work simultaneously, coordinating and justifying their actions without any system will lead to mismanagement in the network. To some extent, we also used parallel processing in the system. However, we used the host and election starter concept in the system to reduce any mismanagement in the system. We have Aptos [105], Shardeum [106], and SuiLutris [107] blockchain networks in the literature that provide high throughput. Such as the Aptos blockchain network, which utilizes the Tetra BFT consensus mechanism to achieve block consensus. For fast finality, it uses parallel transaction processing. It uses a PoS style for validator selection in the consensus. It has sub-second finality because it has the Tetra BFT consensus mechanism. Shardeum consensus is designed for a fast, secure, and scalable blockchain network. The Shardeum blockchain network uses two consensus mechanisms for block finality. Shedeum utilizes a sharding mechanism to permit linear scalability and fast transaction processing. Sui Lutris is a smart contract platform. It integrates consensusless agreement with a high-throughput consensus protocol to achieve high efficiency. It is a hybrid architecture emerging blockchain. Sui Lutris is the upgraded version of Sui [108]. Sui Latris used parallel execution of transactions in the blockchain network to gain high throughput. However, these are highly scalable blockchain networks, but still less than our system throughput. Solana [109] used PoH [110] and PoS in the block creation. Using them together, it provides a very high throughput, but it requires high hardware specifications to handle the large number of transactions and maintain the validator’s performance. However, we do not use heavy machinery in our consensus. Our consensus is efficient without wasting energy on heavy computations. We have presented a system that efficiently resolves the issues of these consensuses, such as providing strong decentralization, high throughput, and a secure system that does not require heavy machinery to process as well.

We are trying to improve all aspects of blockchain. We already discussed the security evaluation in comparison to others in Section 6 and decentralization in Section 7. We present a scalability comparison in

Table 7. Comparison of the presented blockchain network system’s block time with others.

Ref.	Consensus Mechanism	Block Time (s)	Finality
	Nazfast	~0.3	Final after block vote
[112]	EOS.IO	~0.5	Final after block vote
[14]	Tendermint (Cosmos)	~1	Final after block vote
[16]	Quorum IBFT	~1	Final after block vote
[113]	Avalanche	~1–2	Probabilistic finality
[100]	PBFT (Hyperledger Fabric)	~2–5	Final after block vote
[17]	Stellar (FBFT)	~5	Final after block vote
Other Major Consensuses
[114]	Proof of Work (Bitcoin)	~600	Probabilistic, after six blocks
[101]	Casper FFG	~12–14	Deterministic finality
[4]	Proof of Stake (Ethereum)	~12	Final after a few blocks
[8]	Polkadot	~6	Deterministic finality
[115]	Algorand	~4	Deterministic finality
[102]	Casper CBC (Casper Network)	~1–2	Deterministic finality
[103]	Raft	~1–2	After consensus round
[104]	LaKSA	~>1	Probabilistic finality
[99]	Delegated Proof of Stake (Bitshare)	~1	Finality after Confirmation
[108]	Aptos (Tetra BFT + PoS)	~1	Deterministic finality
[116]	Shardeum	~1	Deterministic finality
[107]	Sui Lutris	~0.5	Deterministic block finality
[109]	Solana (PoH + PoS) continued to 2023	~0.4	Probabilistic finality

with other blockchains’ consensus under the same family, such as EoS.IO, Tendermint, PBFT (Hyperledger Fabric, San Francisco, CA, USA), Stellar FBFT, Quorum IBFT, and Avalanche. We also compared with other major consensuses that are different in terms of architecture available in the literature, such as Proof of Work (Bitcoin, Frigate Bay, Saint Kitts and Nevis), Proof of Stake (Ethereum, Zug, Switzerland), Delegated Proof of Stake (Bitshare, Blacksburg, VA, USA), Raft, Algorand, Polkadot (NPoS), Solana (PoH + PoS), Casper (CBC), Casper FFG (Ethereum 2.0), LAKSA, Aptos (Tetra BFT + PoS), Shardeum, and Sui Lutris. As per the literature study [111], performance is still a critical issue of blockchain. We have observed from a complete Table 7 that our presented blockchain network consensus system has high throughput; it takes less time than any other consensus of the same family and with others as well.

Deployment in the real-world network

The deployment of blockchain is based on the type of network it is using. There are many blockchain networks available in the real world, such as Bitcoin [1], Ethereum [4], and Ethermint [117]. All were deployed according to their need. The general deployment of any blockchain network requires many stages. It has a backend deployment, a frontend deployment, and blockchain network configurations. For a completely operational blockchain, it has a ledger, peer network, membership services, wallets, events, system management, and system integrations. There are multiple actors, such as the operator, developer, end user, and data storage, in the blockchain network that operate complete components of the network. It depends on the application network and how it uses the Nazfast consensus in its network. Either users or front-end software are used to operate the network for the Nazfast consensus. The Nazfast consensus can be deployed under the PoS blockchain umbrella architecture. It does not need any special hardware, nor does it have any special requirements for deployment. It can be implemented in our traditional peer-to-peer environment settings.

7. Limitations of Nazfast

The election mechanism provides a block creation committee list; if it does not supply a list on time or before time, the whole system will suffer, and the throughput of the system will decrease. We have already discussed the solution to this problem in the scalability section of the discussion. The concept of a host is involved in every fold of consensus; that is why it should work actively and be alive, or else the whole system will be slowed down. We already suggested that an additional alternate host for emergency situations would be suitable for the solution of this problem.

8. Conclusions

This paper presents a Nazfast consensus mechanism that has multiple folds. The consensus process used an election process (S&Sem) to securely select a fixed number of validators between all active validators for each block creation cycle. We involve all validators in the election process to improve decentralization, but it decreases the scalability of the network. Therefore, we use parallelism and the horizontal scaling concept to control the scalability issue due to the election mechanism in the network. After applying these techniques, our system overcame the scalability issue by using all validators of the network while maintaining strong decentralization. Selecting a reduced number of validators from the election process reduces message broadcasting pressure in the consensus and improves the throughput of the complete network. For the block creation process, we used PoS-BFT-based consensus, Nazfast, which achieved block finalization in a deterministic approach under a malicious environment. Tendermint is considered better than many consensus mechanisms. The results show that we achieved higher BPS (blocks per second) than Tendermint consensus and many other consensuses in the literature. We achieved three blocks in 1 s in our simulation. The important feature of our consensus is that we achieved block finalization with almost similar latency on any number of validators in the network. However, due to the reduced validator committee, the security of the consensus is at risk. Therefore, we used another validator chain with a consensus (SeaShield) to improve the overall security of the network. Mainly, the network uses two consensus mechanisms parallel to each other in the network, with another important feature that both consensus mechanisms create blocks by not allowing forking in the network. By using all three parts together in the network, we achieve a very secure network system. Our presented work reduces security risks and gives protection from 28-plus security vulnerabilities of the network. We also provide an incentive mechanism for our consensus to attract validators in the consensus process and improve decentralization of the network. Hence, in a concise statement. We presented a consensus mechanism for a blockchain network that is extremely secure and provides a very high throughput with a greater degree of decentralization.

Future Work

Evolution 4.0 is considered the future of blockchain. To boost blockchain efficiency, this new evaluation supports blockchain to integrate with new technologies. In the future, we will also try to integrate our system with any other technology to gain a better result from our existing work and to overcome the limitations of the presented work.