# PnV: An Efficient Parallel Consensus Protocol Integrating Proof and Voting
## 3 Node and Data Model
### Role Model  
PnV defines five distinct roles for nodes within the blockchain network: voter, bookkeeper, bookkeeper candidate, leader, and user. Let \(N_{v}\) represent the number of voters, \(N_{b}\) denote the number of bookkeepers, \(N_{bc}\) signify the number of bookkeeper candidates, \(N_{u}\) indicate the number of users, and \(N_{all}\) represent the total count of nodes. With exception of the genesis block group, each subsequent block group is generated by \(N_{b}\) bookkeepers. The term during which a node acts as a bookkeeper is referred to as \(T_{b}\). At the conclusion of a term, the next team of bookkeepers is elected among the pool of bookkeeper candidates. Figure 1 illustrates in detail the specific transition relationship between node roles. All transitions occur through special transactions at any time, which are processed by a three-phase consensus (Section 4), similar to normal transactions such as account creation and money transfer. The responsibilities of each role are described below.  
**Voter:** Voters bear the responsibility of network supervision and are required to meticulously verify each block to ensure the accuracy of the transactions contained within. During a consensus round, each voter casts their vote in favor or against the blocks under consideration. Only blocks that receive more than two-thirds approval can be deemed legitimate. Furthermore, voters are entrusted with the crucial task of electing bookkeepers by thoroughly evaluating their performance scores, thereby determining the next set of bookkeepers once the current term concludes.  
**Bookkeeper:** Bookkeepers are entrusted with the responsibility of conducting bookkeeping activities within the blockchain system. Similarly to voters, there exist multiple bookkeepers in the network. The blocks generated collectively by all bookkeepers during a consensus round constitute a block group. To ensure continuity and efficiency, the bookkeeper team operates under a tenure system whereby they are required to produce a number of block groups within their designated term. Specifically, each bookkeeper gathers relevant transactions from the network and stores them locally in their pool. Subsequently, when a consensus round commences, every bookkeeper assembles a set of transactions into a block and disseminates it across the network for verification purposes.  
**Bookkeeper candidate:** Bookkeeper candidates are not directly involved in the consensus process, but they possess the necessary qualifications to be elected as new bookkeepers by voters. In order to ensure an adequate number of bookkeepers, it is imperative that the number of bookkeeper candidates exceeds or equals that of the existing bookkeepers. Any node has the right to apply for the role of bookkeeper candidate, and such candidates also have the freedom to voluntarily relinquish their roles.  
Figure 1: Role transition relationships.  
**Leader:** During the consensus process, a single leader is selected from bookkeepers to oversee the collection and tallying of block votes generated by voters. Typically, if all blocks receive more than two-thirds of the votes, the leader generates a block group header and disseminate it across the network. At the conclusion of each consensus round, a new leader is randomly chosen based on information contained within the block group header. This approach ensures fair and impartial leadership selection while maintaining transparency throughout the voting process.  
**User:** A newly added node initially lacks the authority to actively engage in any consensus process. However, it can passively receive data from other nodes and publish transactions. This type of node primarily operates as a user within the system, with its joining or exiting having no significant impact on the overall network dynamics.