## 1 Introduction
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]. [PERSON] 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. 1. The consensus used the election process to select a block proposer instead of a round-robin algorithm. 2. A swapping mechanism occurs if the block is not produced by the pre-specified block proposer of the block creation cycle. 3. The orphan block gets dissolved so that transactions do not get stuck in the block. 4. The consensus has no locking mechanism. 5. Correctors and the additional concept of wildcard entry validator with V-validator are used to improve the security parameter of the consensus. 6. Forking is controlled in the consensus because multiple blocks do not get created and broadcast together in the block creation cycle. 7. The concept of a timesheet is used to speed up the commit process by correctors. 8. The reduced and fixed number of validators is used to improve the throughput of the consensus. 9. Only five correctors are used for the commit phase to improve the scalability. 10. 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. 11. 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.