# PnV: An Efficient Parallel Consensus Protocol Integrating Proof and Voting
## 4 PnV Consensus Protocol
### Three-Phase Consensus Process
Consequently, each transaction only necessitates transmission to a single bookkeeper, thereby diminishing superfluous communication while also reducing network bandwidth consumption and node memory resource utilization. ## 6 Research Method and Experiment

In this section, we implement the proposed PnV protocol in a consortium blockchain environment by using Golang [26]. We conducted our experiments on four ZTE R8500 G4 servers. Each server was equipped with 128 GB of memory and an Intel(R) Xeon(R) Gold 6248R Processor running at a speed of 2.3 GHz \(\times\) 96. In order to eliminate any potential impact from read-write disk operations, each node did not store the block group in the database. Other parameter settings can be found in Table 2. \begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **Value** \\ \hline Transaction size & 40 Bytes \\ Block header size & 692 Bytes \\ Vote header size & 400 Bytes \\ Vote size of a block & 100 Bytes \\ Vote result header size & 170 Bytes \\ Vote result size of a block & 400 Bytes \\ Message header size & 266 Bytes \\ Bandwidth & 10 Gbps \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Configuration of parameters. ### Consensus Throughput and Network Load

First, we set the number of voters to 4 (\(N_{p}=4\)) to examine the influence of varying the number of bookkeepers (\(N_{b}\)) and the number of transactions per block (\(K\)). By manipulating both variables, we record the corresponding values for consensus throughput and network load in each scenario. The results depicted in Figure 4 demonstrate that the throughput of PnV exhibits an initial increase followed by a subsequent decrease as the number of bookkeepers increases. Moreover, the throughput experiences varying degrees of enhancement with an escalation in the number of transactions per block. The peak throughput reaches over 350,000 transactions per second (tx/s). In terms of network load, it is inevitable for communication data between nodes to augment and consequently lead to an increase in network load as the number of nodes increases. This can be attributed to the fact that both transmission time and processing time escalate alongside an increase in transaction volume. When there are only a few nodes, the rate at which time consumption increases is lower than that of transactions, resulting in an upward trend for throughput. Conversely, when there is a large number of nodes, the pace at which time consumption grows surpasses that of transactions, leading to a downward trend for throughput. ### Comparison from an Algorithmic Perspective

In this section, we present a comparative analysis of the throughput and delay performance among PnV, PoV, and BFT-SMART [8]. We specifically chose these two protocols, as PoV represents the first fusion consensus approach, while BFT-SMART serves as a prominent example of voting-based consensus. To ensure comparability with BFT-SMART, both PnV and PoV were configured with an identical number of voters to bookkeepers (\(N_{v}=N_{b}=n\)). The maximum number of transactions per block (\(K\)) was set to 10,000. The experimental results are illustrated in Figure 5, showcasing the trend of PnV's throughput as initially increasing and then decreasing as the number of nodes increases. In contrast, both PoV and BFT-SMART exhibit a gradual decline in throughput. Notably, PnV achieves its peak throughput at \(n=20\), which is approximately five times higher than that of PoV and BFT-SMART. Furthermore, even in the worst-case scenario, PnV's throughput remains about twice as high as that of PoV and BFT-SMART. In terms of delay performance, PnV demonstrates relatively favorable results when fewer nodes are involved. Consequently, compared with PoV and BFT-SMART, PnV exhibits superior efficiency, scalability, and acceptable delay in scenarios with a moderate number of nodes. Figure 4: Throughput and network load for PnV consensus protocol (\(N_{b}=4\)).