Six years ago, EPFL rolled out an e-voting platform developed by Bryan Ford’s DEDIS lab for its internal elections [2]. The then newly-formed Center for Digital Trust (C4DT) brought this project as one of the first under the umbrella of its Digital-Trust Open Platform, the precursor to what is today the C4DT Factory – a team of research software engineers supporting researchers through software development and deployment expertise. The Factory team is therefore particularly excited to announce that we helped DEDIS get their newest iteration of an e-voting system, D-Voting [3], ready for production use at EPFL. The rollout of this system is an opportunity to revisit the history of e-voting at the school and introducing D-Voting to its community.
What is e-voting?
Wikipedia defines e-voting, or electronic voting, as “voting that uses electronic means to either aid or take care of casting and counting ballots”. It distinguishes between e-voting supervised by electoral authorities, for example via electronic voting machines at polling stations, and unsupervised remote e-voting via Internet [4]. Advocates of e-voting argue that it boosts voter turnout and participation while simultaneously combating fraud and undue influence. Conversely, critics say that the greater attack surface compared to paper-based ballots outweighs the potential benefits [5].
Given the contentious nature of e-voting, one might rightly ask why EPFL is relying on e-voting for its internal elections. Despite the controversy surrounding the topic, there is undeniably a trend towards adopting e-voting in public elections, as for example in Switzerland [6]. As is natural for a leading academic institution, EPFL is at the forefront of such developments. Given that the school’s internal elections present a significantly lower risk profile compared to public elections they are an ideal testing ground for evaluating the security and viability of novel e-voting solutions.
History of e-voting at EPFL
In 2017, the school lacked a dedicated e-voting system. To conduct elections, it relied on Inform, an in-house form management system designed for handling contact and registration forms, creating polls and processing online payments. Since Inform was not built with election security in mind, additional policies had to be put in place to ensure free and fair elections. Recognizing the limitations of this approach, EPFL decided to migrate to a dedicated e-voting platform.
This new dedicated e-voting system, simply named e-voting [7], emerged from Bryan Ford’s DEDIS lab. The development of e-voting drew inspiration from Helios, an early web-based electronic voting platform [8]. DEDIS was particularly interested in its use of cryptographic protocols to ensure auditable elections. However, instead of adopting Helios‘s centralized server architecture and conventional data storage, the lab opted for a decentralized solution based on a Cothority blockchain [9] instead. This decentralized approach not only aimed to improve stability by leaving no single point of failure but also fostered collaboration across EPFL. Each blockchain node was operated by a distinct ‘election overseer’ – be it a school, lab, center, or gnugen, a student association promoting free software.
D-Voting
D-Voting is the successor to e-voting. Just as e-voting was built atop of Cothority, D-Voting uses DELA [11], DEDIS’s newest blockchain solution, under the hood. Initiated as a rewrite of e-voting in 2021, D-Voting is being developed by students under the guidance of DEDIS’s research software engineers. D-Voting is published under the BSD 3-Clause open source software license.
Our contributions
In the follow-up to the 2023 elections, the EPFL’s e-voting team contacted the C4DT’s Factory to discuss switching to D-Voting. After an initial assessment found the project’s maturity level satisfactory, the team agreed to take the necessary steps to move it to production.
We began by setting up a demo environment to rigorously test the project. These tests revealed two critical issues that would need to be addressed before D-Voting could be used in production: improving the blockchain’s performance to scale, and tailoring the user interface to EPFL’s specific requirements. Over the next six months the team addressed these concerns.
We quickly identified a bug in the indexing mechanism that would cause the blockchain to break after 255 transactions. Before addressing the performance, we needed to resolve this critical issue.
The performance issues impacted both ballot casting and election administration. While longer execution times might be acceptable for administrative tasks, the same cannot be said for ballot casting. For a smooth voting experience and a correct election process, users must be able to cast their ballots quickly and, crucially, in a time that is independent of the number of cast ballots. The team pinpointed several parts of DELA which needed to be improved for a bigger election: the syncing mechanism between the nodes, appending new transactions to the blockchain, and correctly ordering transactions. After optimization, casting a ballot now takes a constant 120 milliseconds instead of 5.5 seconds for the 1000th ballot in the previous version. The total time for shuffling, decrypting and combining the ballots is down to 17 minutes for 10’000 ballots.
| 1’000 Ballots | 2’000 Ballots | 10’000 Ballots | |
| Cast ballot | 100-120 ms | 100-120 ms | 100-120 ms |
| Close election | immediate | n/a | 2 s |
| Shuffle ballots | 56 s | 5 m | 11 m |
| Decrypt ballots | 5 s | 2 m | 5 m |
| Combine ballots | 1 s | 2 m | 1 m |
Benchmarks in the demo environment after optimization.
In the frontend, three key areas required attention: minor bugs, user experience and aligning with EPFL’s design guidelines. To efficiently tackle these areas, we added automated front-end testing using Playwright [12]. Furthermore, the demo environment facilitated exchanges with the EPFL e-voting team on user experience and design questions.
To deploy D-Voting, its components were packaged in three Docker images: one for the front-end interface, another for the backend, and a third for a DELA blockchain node. This facilitates automated deployments while preserving the logical separation between components, allowing updates to one without impacting the others.
Additionally, we modified DELA’s SSL/TLS setup to also be able to handle termination on a proxy (e.g. Traefik), which allows for integrating the nodes into a broader range of network setups.
Future
The C4DT’s Factory continues its close collaboration with the DEDIS lab to develop and maintain the D-Voting project.
Presently, we are co-supervising two semester projects in this context. One project is improving D-Voting‘s resilience by eliminating a potential single point of failure originating in its permission management. The other project enhances D-Voting‘s underlying tech stack by migrating DELA‘s network overlay to a more stable solution.
Through these and similar future collaborations, we are looking forward to continuing our involvement in a project that combines student-driven development, research software expertise, open source software and digital trust.
References
[1] https://github.com/dedis/d-voting/blob/main/docs/assets/logo.png
[2] https://actu.epfl.ch/news/epfl-uses-blockchain-technology-to-secure-e-voti-3/
[3] https://github.com/dedis/d-voting
[4] https://en.wikipedia.org/wiki/Electronic_voting
[5] https://people.csail.mit.edu/rivest/pubs/PSNR20.pdf
[6] https://www.bk.admin.ch/bk/en/home/politische-rechte/e-voting.html
[7] https://github.com/dedis/cothority/tree/evoting-many-candidates/evoting
[8] https://vote.heliosvoting.org/
[9] https://github.com/dedis/cothority/
[10] https://github.com/dedis/cothority/blob/evoting-many-candidates/evoting/system.png
[11] https://dedis.github.io/dela/#/
[13] https://github.com/dedis/d-voting/blob/main/docs/assets/system.png
