# PVPBC: Privacy and Verifiability Preserving E-Voting Based on Permissioned Blockchain
## 3 Core of the PVPBC Voting System
### Authentication with Revocable Anonymity  
The PVPBC voting system is based on a brand-new voter-authentication mechanism which preserves voter privacy and enforces the legal requirements of the election service authorities. To verify voters, the PVPBC voting system uses TTP certification along with DL technology and a smart contract. The TTP issues a capability access token for each eligible voter. The DL technology holds the access tokens securely and releases them when certain requirements have been fulfilled. At least five parties participate in the protocol, they are listed now. The TTP is comprised of two parties, the \(T_{A}\), which is a trust body within the organization, and the \(T_{m}\), which is an administrator. The third party is the voter, \(V\). The permissioned DLT is run by two additional parties, an administrator, \(T_{m}\), and several \(T_{A}\)s.  
**Initialisation phase:** Prior to the election, the \(T_{m}\) maintains a list of ID numbers, which belong to eligible voters. It is populated on the DLT by the TTP administrator \(T_{m}\). Once the ID number related to the voter is verified, a profile for the registered voter is created on the DLT by calling the _Register Smart Contract_ (more details are provided in Section 6.1). Each voter profile on the DLT includes the registration information tuples (Voter ID number (VID), Flag--\"Not voted\"). The VID is a unique virtual ID, which is assigned for each registered voter on the DLT.  
**Smart-contract deployment:** A smart contract, which oversees the capability access token for each eligible voter, must be deployed on the DLT by the TTP. The smart contract can securely manage any algorithmically specified protocol, thanks to cryptographic protocols, when it is deployed over the DLT network. The smart contract supplies a deployAction () ABI (smart-contract interaction interface) for this function. The permission to execute this ABI rests with \(T_{m}\). When operating this ABI, the \(T_{m}\) must send a transaction which includes the voter information defined in the previous phase, namely, the initialization phase. After synchronizing the permissioned DLT data, any node in the permissioned network, for example, the \(T_{m}\) or the \(T_{A}\), has the ability to communicate with the smart contract using the contract address provided.  
**Authorization validation:** The authorization-validation process takes place at the election service provider, in response to receiving an authentication request from the voter during the pre-election phase. More precisely, as shown in Figure 2, the election service provider verifies the present condition of the smart contract in the permissioned DLT to obtain the capability token associated with the voter's VID. The smart contract furnishes an accessRequest() ABI for verification of the token. The election service provider can accomplish this ABI by submitting the pertinent information, the voter's VID and the action to be performed using the transaction. The transaction is mined, included into a block and broadcast to the nodes, \(T_{m}\) and \(T_{A}\), in the TTP DLT network. As part of this process, each node that receives the transaction carries out the ABI to check if the voter possesses the necessary access rights. This assures system users that nodes cannot deceive others with false processing results. The result is a robust and trustworthy access-control system. The election service provider will grant access to the ballot to the voter if the access-right policies and conditional constraints are satisfied and also depending on thecapability-token validation and access-authorization-process result. If these conditions are not satisfied, the voting request is denied.