# PnV: An Efficient Parallel Consensus Protocol Integrating Proof and Voting
## 4 PnV Consensus Protocol
### Three-Phase Consensus Process  
The consensus process of a block group can be divided into three phases: propose, vote, and commit, as shown in Figure 3.  
Each bookkeeper selects a limited number of transactions from their memory pools based on the transaction allocation mechanism (Section 4.2) and generates a block. Subsequently, bookkeepers disseminate their respective blocks to the network. All nodes within the network, including users, will receive and store these blocks. The detailed pseudocode of the propose phase is in Algorithm 1. ```
1:ifdo_propose = true do
2:\(h\)=getBlockChainHeight() + 1;
3:\(gen\_block\_group\_num\)\(\leftarrow\)\(h\)%(\(


```
1:ifdo_route = truedo
2:received_block_num\(\leftarrow\)getLen(received_block_set);
3:Nw\(\leftarrow\)getBookeeperAmount();
4:ifreceived_block_num\(<\) Nw and Nepoch = 0 do
5:return
6:endif
7:Initial Vote_Ticket to a list with Nw [null, 0] elements;
8:forblock in received_block_set do
9:block_num\(\leftarrow\)getBlockNum(block);
10:header\(\leftarrow\)getHeader(block);
11:hshs\(\leftarrow\)getHash(block);
12:opinion\(\leftarrow\)VerifiedBlock(block);
13:Vote_Ticket[block_num]\(\leftarrow\)Pair(hash,opinion);
14:endfor
15:Msg_Vote\(\leftarrow\)getVoteMsg(Vote_Ticket);
16:node\(\leftarrow\)getLeaderNode();
17:sendMessage(node,Msg_Vote);
18:do_vote = false;
19:endif
20:return
```
**Algorithm 2**Vote phase. ## 3 Commit Phase

The leader gathers the votes cast by all voters and stores them in \(VoteList=<VoteTicket_{1}\), \(VoteTicket_{2}\ldots>\). Once all votes are received or a timeout (Section 4.3) occurs, a voting statistical rule is employed to generate the vote result, denoted as \(VoteResult\). Subsequently, the vote list and result are encapsulated within the block group header before being disseminated across the network. The detailed pseudocode of the commit phase is in Algorithm 3. ```
1:ifdo_commit = truedo
2:Can_Generated_Result, Result_List\(\leftarrow\)VoteListStatistic(Vote_List);
3:ifCan_Generated_Result = falsedo
4:return
5:endif
6:block_group_header\(\leftarrow\)GenerateBlockGroupHeader(Vote_List, Result_List);
7:Msg_Block_Group_Header\(\leftarrow\)getBlockGroupHeaderMsg(block_group_header);
8:fornode in node_listdo
9:sendMessage(node,Msg_Block_Group_Header);
10:endfor
11:do_commit = false;
12:endif
13:return
```

**Algorithm 3**Commit phase. Specifically, the voting statistical rule is as follows: The leader generates a final voting result of length \(N_{b}\), which corresponds to the number of bookkeepers. This result includes the hash value of each numbered block and its corresponding approval, objection, or no-opinion votes denoted by 1, \(-1\), and 0, respectively. As malicious nodes may distribute different blocks to various voters, it is possible for a specific block number to have distinct hash values in each vote. Assume that the vote for block \(p\) consists of \(m\) diverse hash values, which are sequentially numbered as \(\{1,2,3,\ldots,m\}\). To represent the combination of the \(i\)-th hash value and its corresponding count of votes for approval, objection, and no opinion, we employ a triple \((hash_{i},a_{i},b_{i})\). Before a timeout occurs, a voter is limited to voting either in favor of or against a block, and there is no option for abstaining. Therefore, if any of the following conditions is met with respect to block \(p\), a vote outcome will be generated for it:

**Condition 1**. : _If \(\underset{i}{max}b_{i}>N_{\text{v}}/2\), block \(p\) will be marked as \(-1\) to indicate objection._

**Condition 2**. : _If \(\underset{i}{max}a_{i}>N_{\text{v}}/2\), block \(p\) will be marked as \(1\), indicating approval for generating the block corresponding to the hash value with the number \(\underset{i}{argmax}a_{i}\)._

**Condition 3**. : _If the aforementioned two conditions are not met, block \(p\) will be marked as 0, indicating an inability to generate a valid block._

**Condition 4**.