# PnV: An Efficient Parallel Consensus Protocol Integrating Proof and Voting
## 4 PnV Consensus Protocol
### Three-Phase Consensus Process
However, an insufficient number of legal blocks have been collected._

In Case 1, the generation of the block group header signifies the completion of consensus. The insufficiency in receiving legal blocks could potentially be attributed to network failure. Consequently, it becomes imperative to solicit the missing blocks from alternative nodes. **Case 2**. : _The legal block group header has not been received._

In Case 2, the absence of block group header generation may be attributed to a bookkeeper or leader failure. In such circumstances, it is necessary to proceed with the following steps:

Step 1. All nodes initiate a request to obtain the blockchain height from all voters and maintain an updated record of each voter's online status. In the event that there exists a voter whose blockchain height surpasses that of the local blockchain, a request is made to acquire block groups from said voter while simultaneously ceasing timeout handling. Conversely, if no such voter with a higher blockchain height is found, proceed with Steps 2-4. Step 2. Promptly execute the voting operation by all voters. In case a block has been received, proceed with the conventional voting process. Otherwise, assign a value of 0 (indicating no opinion), and set the hash value as nil. Subsequently, transmit the vote to the leader of the subsequent epoch. Step 3. Upon receiving more than \(2N_{v}/3\) votes, the leader proceeds to tally the votes for each block within the block group, thereby generating a statistical result. At this juncture, if a block accumulates over \(N_{v}/3\) votes for any given hash value, it is deemed a valid block and assigned a vote result of 1; otherwise, it is classified as an invalid block with a corresponding vote result of \(-1\). Step 4. If \(N_{epoch}>1\), indicating multiple occurrences of timeout, it becomes imperative to replace the leader. Assuming the bookkeeper number prior to this timeout to be denoted by \(n\), the subsequent leader's number shall be determined by \((n+1)\%\)\(N_{b}\). These steps ensure the eventual generation of a legal block group in a consensus round. Consequently, the timeout handling mechanism serves as a crucial supplement and enhancement to the PnV consensus protocol, thereby enhancing robustness and enabling normal blockchain operation even under abnormal conditions. ## 5 Theoretical Analysis

### Resistance to Conflict Transactions

Let us consider a conflict transaction problem in the context of parallel and distributed block generation by multiple bookkeepers in PnV. In this scenario, if there exist conflict transactions within pools of bookkeepers, it raises the question of whether these conflict transactions will be stored in separate blocks within the final block group. Let us suppose that there are two bookkeepers participating in a consensus round, publishing blocks \(A\) and \(A\prime\), respectively, containing conflicting transactions. As per the requirement for voters to verify all blocks within this block group height, they can only vote for one of the blocks while voting against the other. Consequently, if block \(A\prime\) receives more than half of the votes as a valid block, it follows that block \(A\prime\) will receive less than half of the votes and thus be deemed invalid. Henceforth, it is impossible for two conflict transactions to coexist within the same block group. ### Performance Analysis

In terms of efficiency, PnV optimizes block generation through the implementation of parallel processing, where multiple bookkeepers assume responsibility for producing blocks simultaneously. This allows transaction processing to occur while awaiting the block group header, effectively utilizing idle computing resources within each node and enhancing transaction packaging speed. Consequently, this protocol significantly improves overall throughput. On the other hand, in terms of cost, the issue of transaction competition can be fundamentally resolved due to each bookkeeper solely accepting and packaging a portion of transactions.