We have been busy thinking about what are we going to do in the future. For each election administrator, there are hundred or thousands of voters and even members of the general public that visit the election public page and the election results. The focus is therefore on the final user, as can be seen in the Roadmap. That’s why for example in release 3.3 we plan to work on multiple small public interface improvements and in 3.5 we will make the public election page more advanced. The most exciting part of our plans however is our commitment to explore the benefits of a more distributed architecture for secure voting. This follows our earlier work in 2014 where we proposed a high-level design for a cryptographically secure voting system on the blockchain. In this iteration our aim is to evaluate the use of the blockchain in a more general way, where the blockchain need not host the voting system as a whole, but can be useful component of it. It’s a simple, three step plan:
- Test the viability of web-based distributed architectures in a small project
- Design a highly distributed evoting system architecture
- (If step 2 is successful) Implement a distributed evoting system
One of the benefits of decentralized technologies like the blockchain is a better chance to resist a Distributed Denial of Service (DDoS) attack. This is the most common and cheapest attack and an election is specially vulnerable to DDoS because it’s high-stakes, time-limited and has a high-exposure. An interesting property contributed by the blockchain is the reduced trust required. Instead of trusting a set of defined entities for doing a set of tasks, the assumption is that you trust the majority of the network. This is achieved by the usage of a distributed network together with immutable logs for verifiability. However these technologies do not come without a price. Joining decentralized networks traditionally requires the installation of some software on the user computer, which is an no-go for usability. Latency and scalability issues are also typical drawbacks of highly distributed systems. When you provide a service online, it’s a good practice to provide a status page where users can see the availability status of your web site and all your services. When there’s a downtime, this practice improves communication and provides transparency and ease of mind to your clients and users. Of course, the status page needs to be available even when all your other systems are not – that’s the whole point of it. That’s why there are companies like https://status.io/ whose sole purpose is to provide you with an external and trusted status website.
But that’s the centralized way of doing it. We want to explore a way to provide the same high availability and DDoS resistant properties needed in a status/event log through a P2P network in the 3.5 release. That is the step 1 of our plan. The 3.5 release includes the development of a public event and status log where the event log data is distributed in a web P2P network as an immutable log. The distributed event log will be seamlessly integrated in our software and the web visitors will be part of the distributed network. It will also be an opportunity to test hands-on the feasibility of web-based peer-to-peer latest technology in an isolated environment with a simple target. Step 2 involves the collaboration with cryptographers from academia during approximately 4-6 months to design a highly distributed online voting system architecture. The aim here is to find fundamental primitives used in distributed networks like Bittorrent or Bitcoin that can be useful in secure elections where the vote is private, how can they be best applied, and to write down a detailed development plan. We are currently looking for interested parties for funding this study on decentralized secure evoting, please contact us if you are one. If step 3 is successful, step 2 would be the realisation of the plan devised in step 3.