# Progress report - Distributed Democracy

We experienced the project and course as quite chaotic. At the start, we didn't realise that the project would be very 'industry-like' in the sense that we had to collaborate with other groups and that working (maybe even hacky) code was favoured over well-written and properly designed code. We only realised this in the final weeks of the project and this made the first few weeks feel as if they had been wasted.

In the sections below, we will highlight the major [issues](#Issues) that we encountered, a [weekly overview](#Week-01-10022020---16022020) of our activities and finally a short summary of the studied [literature](#literature).

## Issues
Thoughout this course it wasn't all smooth sailing unfortunately. During the first half of the course, there have been multiple occassions where a change of direction was required or requested. The following things had the most impact:

- **Initial over-complex voting design**. We have spent quite some time on designing a scheme that was ideally without flaws, to little avail as classic computer science problems (global time etc) have stopped us. However, only after quite a while we came to the realisation that we should take the security drawbacks for granted and implement a simpler system.
- **Currency group opting to use their own voting**. This was an unexpected event, especially as we have been communicating clearly and frequently with this group. As this was destined to be our main purpose, the dissapearing of this task was a major setback. In the final two-three weeks we have created an application to serve as demonstration.
- **Frequent change of plans after weekly meetings**. There have been multiple occurences where the project was required to change course. This has not always been in favour of the progress, as a we have diverged back to our initial plans on a number of occasions.

## Week 01 (10/02/2020 - 16/02/2020)
- Form group and submit project preferences

## Week 02 (17/02/2020 - 23/02/2020)
- First meeting with Dr. Pouwelse and initial project idea
- Had a look at some [literature](#Literature), but we eventually found out it would be quite challenging

## Week 03 (24/02/2020 - 01/03/2020)
- Deep dive into TrustChain code
- Initial setup of voting community in `kotlin-ipv8` within the `DemoCommunity`
- Start vote functionality implemented in basic way

<img src="https://i.imgur.com/KrssQj1.jpg" width="210"> <img src="https://i.imgur.com/qO836J9.jpg" width="210">

## Week 04 (02/03/2020 - 08/03/2020)
- Move functionality from `DemoCommunity` to a new `VotingCommunity`
- We spent a lot of time on moving the functionality to the new module as there were a lot of errors regarding path names and overhead
- Initial tally function
- Did research into voting systems and what a perfect voting system would/should look like

## Week 05 (09/03/2020 - 15/03/2020)
- Finalized tally function
- Started with test implementation
- Had quite some trouble with this as we weren't sure how to implement the tests and mock the required components

## Week 06 (16/03/2020 - 22/03/2020)
- Trying to get tests up and running continued
- Start on [documentation](https://hackmd.io/sII7P2R8QpCkdy6-3xse4g)
- Initiate contact with bitcoin scripting group (Currency II) through shared whatsapp group
- Spent a lot of time this week discussing possible ways of integration. At this point, we had some basic ideas that we could implement.
- Did a refactor of part of the `countVote` code and implemented some extra guards when crawling blocks
- This week we also discussed threshold-voting more in detail

## Week 07 (23/03/2020 - 29/03/2020)
- Have been working on the double voting defense and have implemented that a vote is only counted once.
- Worked on updating the documentation
- We have been in contact with the currency group to merge our stuff with theirs, but figured out that they were not ready yet for merging. We were not aware that they had asked for a deadline extension. We are now specifying our [functions](https://github.com/Tribler/tribler/issues/5145#issuecomment-603820530) so that the integration progress will run more smoothly
- Had a meeting with all the groups together on Friday. Brainstormed about possible ways to integrate with Currency II and/or FOC

## Week 08 (30/03/2020 - 05/04/2020)
- Turned out currency group already created a voting mechanism themselves which meant our API would not be used by them and forced us to create our own module and GUI from scratch.
- This marked a major turning point in the project, as its direction was now to create a module, rather than an API.
- Migrate codebase to superapp
- Updating the API to be more robust
- Improving the documentation of the API in order to improve usability for the other groups

## Week 09 (06/04/2020 - 12/04/2020)
- Lots of bug fixes in the API
- Tried to migrate everything from `kotlin-ipv8` to `trustchain-superapp`, but this proved to be quite a hassle. We eventually spent more than a week on this
- Also encountered a strange bug on Robbert and Pravesh's machines, got sorted out eventually with help of Matt, but basically only half of the team got develop anything
- Improved double vote defense in backend
- Initial UI setup of voting submodule

## Week 10 (13/04/2020 - 19/04/2020)
- Focus on functionality and usability
- Extended test suite
- Merged initial UI to `Tribler:dao` (see [PR](https://github.com/Tribler/trustchain-superapp/pull/10))
- Fixed not working exclusion (see [PR](https://github.com/Tribler/kotlin-ipv8/pull/17))
- Major UI overhaul, demonstrates nearly all functionality.

<img src="https://user-images.githubusercontent.com/23723475/79471728-40e18480-8003-11ea-85df-35e8f8d45c4e.png" width="210"> <img src="https://user-images.githubusercontent.com/23723475/79472482-307dd980-8004-11ea-94a0-f72a3d11a644.png" width="210">

## Week 11 (20/04/2020 - 26/04/2020)
- Threshold voting implemented.
- Meeting with FOC for integration. From this it came forward that it could be done, but mostly "for the sake of it". Only a complete merger of the two apps would prove to be useful
- Implemented progress bar, indicating how many votes left for completion.
- Fixed errors caused by `kotlin-ipv8` update (see [PR](https://github.com/Tribler/trustchain-superapp/pull/20))

## Week 12 (27/04/2020 - 04/05/2020)
- Final tweaks to UI.
- Finalized FOC proof of concept. This required working in the module of FOC. We have opted to only include this in our fork, to not intervene too much with their work in the main dao branch.
- Finalized documentation. Supported with gifs showcasing our functionality.
- Finalized tests and stability of the system.
- Final bug fixes, app is now completely stable.

<img src="https://i.imgur.com/ZGRbm9W.gif" width="210">

# 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.