# PnV: An Efficient Parallel Consensus Protocol Integrating Proof and Voting
## 4 PnV Consensus Protocol
### Three-Phase Consensus Process
: _If a timeout occurs, the leader must gather votes exceeding \(2N_{\text{v}}/3\) for each block within the block group and generate statistical results. In this scenario, a block is deemed legal only if it possesses a hash value that receives more than \(N_{\text{v}}/3\) approval votes._

### Transaction Allocation Mechanism

In a blockchain network, nodes typically broadcast their transactions to multiple bookkeepers in order to increase the likelihood of their transactions being included in a block. Consequently, there tends to be a significant number of identical transactions present in the pools of different bookkeepers. In our proposed PnV protocol, multiple bookkeepers simultaneously generate blocks. However, if these transactions are not filtered properly, it is possible for the same transaction to be stored in multiple blocks within the same block group. To address this issue, we introduce a transaction allocation mechanism wherein each transaction \(T_{x}\) is assigned an identifier \(j(j=0,1,2,\ldots,N_{b}-1)\). The transaction identifier \(j\) is computed as

\[j=Hash(digest(T_{x}))mod(N_{b}). \tag{2}\]

Subsequently, only transactions whose identifiers as calculated in Equation (2) match a bookkeeper's identifier are allowed to be included in blocks generated by that bookkeeper. This ensures that there is no intersection between the transactions contained within different blocks. In addition to mitigating the issue of duplicate transaction storage, this can significantly enhance efficiency by constraining transaction packaging. For any user, as all bookkeepers concurrently generate blocks, there is no necessity to transmit the transaction to every bookkeeper for expediting transaction processing. Furthermore, even if a transaction is dispatched to another bookkeeper, it will be disregarded. ### Timeout Handling Mechanism

Due to the inherent volatility of real networks and potential machine malfunctions, the blockchain system may experience stagnation or timeouts. To address this issue, we

Figure 3: PnV consensus process in three phases. propose a timeout handling mechanism. In order to comprehensively analyze the impact on the consensus process, we first focus on examining timeout failures related to three key node roles: voter, bookkeeper, and leader. 1. Voter failure: The determination of the legality or illegality of blocks generated by bookkeepers relies on the voting process conducted by voters. In case of voter failure, both positive and negative votes for a block may fall below the threshold, resulting in an inability to generate statistical results. Consequently, the leader will persistently await the fulfillment of statistical conditions, while other nodes will also experience prolonged waiting periods for the block group header. 2. Bookkeeper failure: Given that voters are required to receive all blocks from every bookkeeper prior to voting, any failure on the part of a bookkeeper will result in prolonged waiting times for voters as they await the arrival of these blocks. 3. Leader failure: In the event of a leader's failure, all nodes will enter a state of waiting for the block group header. To address the failure of these nodes, we propose a timeout handling mechanism. Assuming that an epoch represents the smallest unit of a consensus round, denoted by \(t_{0}\) for its start time and \(T_{cut}\) for its duration, \(N_{epoch}\) signifies the number of epochs elapsed from time \(t_{0}\) to the current time, \(t\):

\[N_{epoch}=(t-t_{0})\%T_{cut}. \tag{3}\]

In a consensus round, the termination conditions for achieving consensus are as follows:

**Condition 1**. : _Receive the block group header._

**Condition 2**. : _Receive all legal blocks passed by voting._

If both conditions cannot be met during an epoch, the consensus process will surpass the time limit and require timeout handling, which can be classified into two distinct cases. **Case 1**. : _The legal block group header has been received.