Votechain - Status of project

gistfile1.txt

Status of the Project

Ever since the project began, I made several decisions that I hadn't predicted. In the beginning, 
I started out basing my project on another project called Naivechain (https://github.com/lhartikk/naivechain),
which is a short 200 line Blockchain implementation in Javascript. 
That decision brought both good and bad consequences. Because of it, I wasn't too scared of implementing a blockchain 
for voting with Javascript and had a good basis from which to build upon.
The downside, however, is that it uses sort of a centralized approach (there is a reason why it is called Naivechain), 
in which all communications go through a central node in order to be distributed to other nodes. 
That approach can also be seen in this project, and while it isn't necessarily a bad thing, most people familiar 
with cryptocurrencies will soon notice the lack of proof-of-work or proof-of-stake algorithms, which may cause some 
raised eyebrows. Despite being somehow centralized, the way I decided to implement makes it easier for full 
decentralization: The central node mostly resembles a torrent file in the BitTorrent protocol, 
as it contains references to other nodes interested in that file. Similarly, the central node on Votechain 
merely keeps a list of connected sockets and organizes communications, but never interferes with the voting
procedure itself. Of course, it represents a rather latent vulnerability, since anyone that takes control of 
the central node may interfere with the election as a whole. What happened  is that I focused much more on the 
Blockchain-implementation part of the project (instead of using a readily available network such as Bitcoin, 
Ethereum and the such) instead of the voting part itself. The reason I did that is that by the time I began
the project, I believed cryptocurrencies introduce a lot of overhead for non-financial related tasks: 
other projects related to voting on Bitcoin need to use a very limited text field to persist votes,
which doesn't seem to me as an optimal solution. 
That limitation notwithstanding, one has also to worry about paying for each vote to be cast on an AltCoin
network. Considering that Bitcoin has seen a tremendous increase in value over the last few months (and years),
a country-wide election could impose a huge cost to interested companies, governments and so on. 
For those reasons and some others I won't get into in this text, I decided to implement my own Blockchain, 
which is a decision that, again, brings good and bad consequences. I had a lot of fun (and also some headaches)
developing a protocol for client's communications over sockets that work as I had envisioned it: It allows anyone,
anywhere, to create a distributed election and have people (and machines) to cast votes on it anonymously 
(unless you choose to share your identity with someone) and as soon as that election is over, 
recounting votes is a simple matter of inspecting a JSON file. That, in itself, represents a major advance over 
current electronic voting methods: recounting votes is still one of the major issues of elections around the globe, 
and we can't have a truly transparent election if votes can't be recounted by independent 3rd parties. 
Bad consequences, however, is that the voting interface (although I think it looks OK UI-UX wise) could use some more work,
as well as the Election creation/Voter Registration API. It lacks user authentication 
(which is a matter I've debated myself with for months now: should we create the PirateBay of distributed 
elections or a private platform that allows authentication?) and will be simplified in the future 
(I plan on having 100% Promises-based I/O on mongoose and get rid of the Async library). 
I believe the bad consequences, however, only require some more work to get corrected, 
while the good ones could potentially guarantee stronger democratic societies for many people out there. 
From a software engineering standpoint, I believe that I made a lot of advances to the project 
(well, I created it from scratch, so there's that) and to my own knowledge. Javascript seems now to me 
as a somehow bittersweet beauty: It is just like a little kitten who will joyfully play with its owner 
until he/she does something wrong and takes a bite in response (personally experienced this). 
I tried to use design patterns and test-driven development as much as I could, but I do have to admit that several parts of the code still 
need to be refactored in order to meet best practices. 
All in all, it was a memorable summer and very fun to work on my GSoC project.