## 4 Nazzfast Consensus Mechanism
### Block Creation Cycle
#### 4.4.1 Block Proposal Phase
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. 1. Prevote: [(0, 0)H + (0, 0)P + 15(10, 1)Vv + (10)W] = 175 messages
2. Prevote: [(0, 0)H + (0, 0)P + 15(10, 1)Vv + (10)W] = 175 messages
3. Pre-Commit: [(15,1)H + (15,1)P + (15)5C] = 112 messages
4. Commit: [(5)H + (5)P + 5(4)C + 5(4)C] = 50 messages
5. Corrector Time: [(5)P + (We only send and receive messages to 2/3 V-validators and wildcards for the pre-vote 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**

1. 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.