Lessons learned on the E-cclesia protocol and Tezos testnet from the first test of the “Universities for e-voting” project

In the context of the “Universities for e-voting” project, Electis is developing and testing the self-tallying e-voting protocol “E-cclesia” together with a network of academics and students from all over the world. The Project is lead by Dr Myrto Arapinis, who invented E-cclesia, and Ivaylo Guenev who is the lead developer on the project. On the 30th of April, the team was ready to test the first version of E-cclesia in a first cross-university vote on Carthagenet (a Tezos test network). The election was held among the universities that are taking part in the project to elect a chairperson for the group of university facilitators.

Prior to the vote, which took place from 5–6 pm UK time on the 30th of April, the participants had to sign up for the vote and were provided with a voter ID that has been generated for this purpose. E-cclesia was installed and opened in a virtual machine on each voter’s computer.

Each voter needed to be on time and online for the full hour as the votes had to be processed on the Tezos blockchain (Carthagenet) at the same time. The voting process contained three different phases:

  1. Login: Input of the Voter ID and processing of the key
  2. Vote: Selection of a candidate from a list and submission of the vote
  3. Opening: The votes are being added to the tally

18 of the network of 22 Universities made it for the election and 15 ended up submitting their votes. Anurag Koyyada from King’s College London was elected to be the chairperson of the network of facilitators. Next to pursuing a degree at KCL he is the director of the King’s College London Blockchain Society and is involved in the modernisation of governance as a Youth Expert on the UN internet governance Forum’s Youth coalition.

E-cclesia at the time of the test vote

E-cclesia at the time of the test election incorporated the following specifications: general architecture and testing functionality, credential generation, voter authorization, ballots submission, time lock encryption, ballot opening and time disjoint phases. It allows for decentralized self-tallying, in a trusted set-up that provides privacy for voters. The user front-end is still basic and key handling and voter registration were processed manually and offline.

Lessons learned

Two kinds of problems appeared that caused the dropout of three voters before entering the first phase. The first was the issue of simply starting the installation process too late: as the vote was strictly timed, the participant couldn’t vote. The other problem was when the voters’ computer was not compatible with the virtual machine used.

The lessons learned in phase 1 of the project relate to the design decisions made at the beginning of the project. Many of those were made with the idea of reducing the time to market in order to get a test vote operational within the deadline but to also keep the parts of the application which are not likely to change decoupled from the delivery system.

The first lesson was the usage of virtual machines for the distribution of software. While this greatly helped the velocity of the project, as development could have easy access to a valid production-like environment, it also encumbered users with having to install virtualisation software and make sure they were set up correctly. This ultimately resulted in a small portion of users not being able to set up in time for the vote, but reduced development overhead greatly, allowing the development team to focus on the product.

Another decision in the design was to separate the interaction for each step of the E-cclesia protocol. That would enable the users to report more accurately on which part of the system was failing during the test vote (if failures were to occur). This level of testability came at the cost of user experience, as each user would have to wait for the time of the next phase to come in order to continue.

The development and test vote were carried out on Carthagenet, as opposed to the main net of Tezos to discourage third parties from using the open-source WIP implementation in production and to circumvent the need to interface with a Tezos wallet utility. Additionally, Tezos faucet accounts were manually created and distributed to users in a form of a trusted setup, which if leaked, could de-anonymize users. Additionally, the system does not force the voters to run a Tezos node themselves, but rather delegates to a public node via a public API, which introduces trust in the system. A balance was struck between pedantically preserving the properties of the protocol and making the trip easier for users in order to make it more likely that they get through the test vote successfully.

Another effect of running the development and election on Carthagenet is the parameters of the protocol being tuned to a network, which has twice the throughput of the main network. A revision of those parameters needs to be made if the system is to be deployed outside of Carthagenet. Those parameters include:

  • Time for each protocol phase — depends on network throughput in tx per second and the number of users participating in the election. In the test election, padding was introduced on top of the disjointness in timezones to remedy last-minute interactions, but with a simpler interaction model, such precautions will be obsolete and can be removed. The code allows for easily refactoring them out of the protocol seamlessly.
  • Computational capacity parameter for the Timelock encryption of the ballots — in the test election it was kept pretty small for performance purposes, but needs to be increased such that it’s resilient to a potential attacker with a top-of-the-line processor. Conversely, this means that the encryption will be harder to break for the honest voters as well.

In conclusion, since the team’s knowledge of E-cclesia was greater than the team’s knowledge of Tezos, the development process was focused on E-cclesia, which implementation-wise wouldn’t change. At the same time, the things that could change as the team’s knowledge grew over the project (e.g. the interface to the Tezos network) were kept decoupled and flexible, so they can be easily substituted in the next phases. This approach facilitated productivity and the opportunity to learn the outlined lessons.