# PnV: An Efficient Parallel Consensus Protocol Integrating Proof and Voting
## 3 Node and Data Model
### Data Structure  
In classic blockchains, a single block serves as the consensus and storage unit within each consensus round. These blocks are interconnected through hash values to form a chain, with each block being assigned a unique height number. To facilitate parallel data consensus and storage, we introduce the concept of a block group as the unit, as depicted in Figure 2. Each consensus round generates a distinct block group comprising multiple blocks, along with a corresponding block group header. The identification of each individual block within a block group is based on the block group height (\(i\)) and block number (\(j\)). According to the distinct transaction functions within block groups, we categorize them into three types: genesis block group, ordinary block group, and special block group.  
**Genesis block group:** Similar to the genesis block in classic blockchains, the genesis block group serves as the initial block group responsible for ensuring the uniformity of the initial variables across all nodes. The genesis block group comprises a single block containing a transaction that typically records the public keys of bookkeepers, bookkeeper candidates, voters, and the leader in the initial state while also establishing system parameters.  
**Ordinary block group:** An ordinary block group comprises a fixed number of blocks containing ordinary transactions, which is equivalent to the number of bookkeepers. Each block is generated by a specific bookkeeper, and its block number corresponds to the respective bookkeeper's number. In other words, an ordinary block group of height \(i\) can be represented as in Equation (1), where \(H_{i}\) is the block group header and \(B_{ij}\) refers to an individual block with number \(j\in\{0,1,2,\ldots,N_{b}-1\}\), with \(N_{b}\) being the total number of bookkeepers.  
\[BG_{i}=\big{\{}H_{i},B_{i0},\ldots,B_{iN_{b}-1}\big{\}}. \tag{1}\]  
**Special block group:** To ensure the robust functioning of the blockchain and facilitate voter oversight, it is imperative for voters to actively participate in electing the subsequent bookkeepers upon the end of the term. The voting result will be securely recorded within a dedicated transaction embedded in the final block group of that term, referred to as a special block group. In other words, the special block group \(BG_{i}=\{H_{i},B_{i0}\}\) with height \(i\) encompasses a block group header \(H_{i}\) and a block \(B_{i0}\).  
Figure 2: Block group composition.  
In particular, although there is no direct connection among blocks within a given block group, these groups are interconnected in an organized structure through hash values to ensure overall serialization. Apart from including the hash value of the previous block group header in the newly generated one, each block also necessitates recording the hash value of its preceding block group header in its own block header. Furthermore, within the block group header, it is essential to include the leader's number for the subsequent block group. It can be obtained randomly by concatenating the hash values of all valid blocks in the voting results and subsequently applying the modulus with respect to bookkeepers' count.