# Distributed democracy

This document contains information on how to use the `Voting` module in the `Kotlin-IPv8` application as created by the Delft Blockchain Lab.

Furthermore, design choices that have been made will be elaborated upon, as well as the current drawbacks in terms of security that should be accounted for when using the Voting application.

###### tags: `DAO` `Voting` `Distributed Democracy` `TrustChain`

## Functionality and API

### Propose vote
When a vote is started a single central proposer broadcasts a voting block to all members of the community. This broadcast is put into operation by calling the propose_vote(subject) function. This function takes a vote subject as argument and sends a half block to all peers in the community.
The call ends with a self-signed block that represent the end of the vote.

fun startVote(voteSubject: String) {
        val peers = getVotingCommunity().getPeers()
        val voteList = JSONArray(peers.map { it.publicKey.toString() })

        // Create a JSON object containing the vote subject
        val voteJSON = JSONObject()
            .put("VOTE_SUBJECT", voteSubject)
            .put("VOTE_LIST", voteList)

        // Put the JSON string in the transaction's 'message' field.
        val transaction = mapOf("message" to voteJSON.toString())

        // Loop through all peers in the voting community and send a proposal.
        for (peer in peers) {
            trustchain.createVoteProposalBlock(
                peer.publicKey.keyToBin(),
                transaction,
                "voting_block"
            )
        }

        // Update the JSON to include a VOTE_END message.
        voteJSON.put("VOTE_END", "True")
        val endTransaction = mapOf("message" to voteJSON.toString())

        // Add the VOTE_END transaction to the proposer's chain and self-sign it.
        trustchain.createVoteProposalBlock(
            myPeer.publicKey.keyToBin(),
            endTransaction, "voting_block"
        )
    }

### Vote
After a voting block has been received by the participant, it should be possible to cast a vote. As for now, the only options are `YES` and `NO`. Naturally, this implies that the participant either agrees or disagrees with the vote subject.

A vote can be casted upon receival of a proposal. A prompt will be displayed, where the user can select either yes or no, or simply refrain by exiting the prompt. Under the hood, the following function is called:

    fun respondToVote(voteName: String, vote: Boolean, proposalBlock: TrustChainBlock) {
        // Reply to the vote with YES or NO.
        val voteReply = if (vote) "YES" else "NO"

        // Create a JSON object containing the vote subject and the reply.
        val voteJSON = JSONObject()
            .put("VOTE_SUBJECT", voteName)
            .put("VOTE_REPLY", voteReply)

        // Put the JSON string in the transaction's 'message' field.
        val transaction = mapOf("message" to voteJSON.toString())

        trustchain.createAgreementBlock(proposalBlock, transaction)
    }

### Count votes
Counting votes is done as follows: The proposer's chain is traversed and for each block that concerns the current vote, it's transaction is checked for adhering to the correct formatting and if so, the vote reply is extracted and tallied. A Pair of (#yesVotes, #noVotes) is retured as a result.

fun countVotes(voteName: String, proposerKey: ByteArray): Pair<Int, Int> {

        var yesCount = 0
        var noCount = 0

        // Crawl the chain of the proposer.
        for (it in trustchain.getChainByUser(proposerKey)) {

            // Skip all blocks which are not voting blocks
            // and don't have a 'message' field in their transaction.
            if (it.type != "voting_block" || !it.transaction.containsKey("message")) {
                continue
            }

            // Parse the 'message' field as JSON.
            val voteJSON = try {
                JSONObject(it.transaction["message"].toString())
            } catch (e: JSONException) {
                // Assume a malicious vote if it claims to be a vote but does not contain
                // proper JSON.
                handleInvalidVote("Block was a voting block but did not contain " +
                    "proper JSON in its message field: ${it.transaction["message"].toString()}."
                )
                continue
            }

            // Assume a malicious vote if it does not have a VOTE_SUBJECT.
            if (!voteJSON.has("VOTE_SUBJECT")) {
                handleInvalidVote("Block type was a voting block but did not have a VOTE_SUBJECT.")
                continue
            }

            // A block with another VOTE_SUBJECT belongs to another vote.
            if (voteJSON.get("VOTE_SUBJECT") != voteName) {
                // Block belongs to another vote.
                continue
            }

            // A block with the same subject but no reply is the original vote proposal.
            if (!voteJSON.has("VOTE_REPLY")) {
                // Block is the initial vote proposal because it does not have a VOTE_REPLY field.
                continue
            }

            // Add the votes, or assume a malicious vote if it is not YES or NO.
            when (voteJSON.get("VOTE_REPLY")) {
                "YES" -> yesCount++
                "NO" -> noCount++
                else -> handleInvalidVote("Vote was not 'YES' or 'NO' but: '${voteJSON.get("VOTE_REPLY")}'.")
            }
        }

        return Pair(yesCount, noCount)
}

### Potential solution: quorum
An interesting alternative solution is the use of a quorum. A quorum functions as a subset of al the eligible voter set, which is allowed to make decisions on behalf of the entire group. More intuitively, once a predefined amount of eligible voters agree on a vote (i.e. a threshold of voters has been achieved), the vote subject can be considered to be accepted by the community.

When using a quorum, the is no such thing as a `NO` vote. It is either agreeing with the proposal, or refraining from agreeing. Perhaps the biggest benefit of doing so is that it eliminates the question of when the election can be concluded. The only requirement for a proposal vote to be accepted is the amount of people agreeing with it exceeds the threshold. Furthermore, a vote proposal can not be initiated or cut off at moments that suit the proposer best (e.g. when there are still uncast votes, but the current majority agrees with the proposer)

This threshold (or minimal quorum size) should be set by the founder of the community, and those who like to join the community do so knowing that this value is set. Under no circumstances should this value be changed.

## Open questions and future work
At the time of writing, the following questions should be further investigated to improve the security of the voting implementation.

### When to end an election? `YES/NO`
A major issue is the open question of

### Whom to include in an election?

### Veto powers

### Becoming aware of vote after being offline
Currently, a participant that is offline does not receive a vote proposition (as he is not an active peer at the moment). Unfortunately, when the participant does come online there is no resync performed. This is something that we hope to implement in the coming sprints.

`EDIT 24-03-2020`: This issue is out of the scope of the project.

## Security flaws
In this section we will give an explanation of current security threats that we are aware of, and the risk that said threats pose.

### Double voting attack
When receiving a voting block, a participant of the vote is able to respond with multiple aggreement blocks which are then counted as seperate votes. This means that everybody (including the proposer himself) could corrupt the vote.

`EDIT 24-03-2020 13:30`: This issue has been resolved in the back-end. The front end allows for multiple votes from a single participant, however while crawling the chain, only the last vote of a participant will be counted.

### Block hiding attack
When a participant hides his agreement block, his vote becomes invisible. This way a participant could change the outcome of the vote when he learns about the current state. For the same reason could a proposer hide all the voting blocks on its chain if the outcome were to be out of its favour. Block hiding attacks can however always be detected when crawling a chain.

### Stalling attack
If the voting process would end only after everybody has cast their vote, a participant could decide to stall the vote by not voting, if the results are going in the wrong direction from the perspective of this participant.

Through the use of a quorum and cut-off date, which is set by the DAO, the voting process can not be stalled.

## Literature

### Design of Distributed Voting Systems [[link]](https://arxiv.org/pdf/1702.02566.pdf)
This paper lists constraints that are discussed in most literature concerning distributed voting namely, authentication, verification and fairness. The blockchain approach is mostly about problems within consensus protocols, which don't exist in TrustChain.

### Blockchain-based E-Voting System [[link]](https://ieeexplore.ieee.org/abstract/document/8457919)

This paper presents a list of design considerations, we have added our thoughts about them below each consideration:
* (i) An election system should not enable coerced voting.
* Out of scope
* (ii) An election system should allow a method of secure authentication via an identity verification service.
* Done via Trustchain
* (iii) An election system should not allow traceability from votes to respective voters.
* This is unavoidable because traceability is necessary for verification of the voting outcome.
* (iv) An election system should provide transparency, in the form of a verifyable assurance to each voter that their vote was counted, correctly, and without risking the voter’s privacy.
* Everyone is able to count the votes that have been cast
* (v) An election system should prevent any third party from tampering with any vote.
* Tampering is detectable by Trustchain principles
* (vi) An election system should not afford any single entity control over tallying votes and determining the result of an election.
* Single central proposer is used, in accordance with current project goals (see [GitHub ticket](https://github.com/Tribler/tribler/issues/5145#issuecomment-597561146))
* (vii) An election system should only allow eligible individuals to vote in an election
* Only members of the DAO can cast their vote.