So yesterday I went live with my new project, Solon, which aims to implement cryptographically secure e-voting for delegated democracy platforms, starting with Liquid Feedback.

How delegated voting works in Liquid Feedback

To create a cryptographic algorithm for Liquid Feedback, we must start with understanding how the current (plaintext) voting works in Liquid Feedback. The concept is known as delegated voting.

In the above graph Alice, Bob and their well known friends vote on an issue where 3 competing initiatives have been proposed. They use delegated voting. (Note that while Liquid Feedback uses a fairly complex preferential voting method, in this example we keep it simple and each of them only votes on a single initiative, also known as 1-out-of-n voting.)

• Bob, Carol, Dave and Fred are actively involved in the issue and well familiar with the details of each initiative. So they have voted directly on the issue itself. These are shown in green. Bob votes for initiative #1, Carol and Dave for #3 and Fred for #2.
• The others are not so active in this issue, or maybe not that active politically at all. So they have chosen to delegate their vote to another voter that they trust or at least whose opinions they are aligned with. These are shown in blue.
• The delegated votes are transitive, so they form a graph where votes are accumulated until they reach the direct voter. So in this case Harry has delegated his vote to Gary - this means that Gary now has 2 votes to use. Gary further delegates to Fred, as does Eve. As a result Fred is worth 4 votes: his own plus 3 delegated votes.
• Not shown in the picture: Votes can be delegated ahead of time, or just for this issue specifically. In Liquid Feedback, you are part of a unit (ie Pirate Party chapter of Duckburg) and issues are further organized into topics (ie Financial, Civil Liberties, Environmental... this is known as area in Liquid Feedback). If you are lazy, you can just choose one person whom you delegate all your votes to in the entire unit. On the other hand you can also delegate your vote to a different person in each area. And you can delegate to a different person per issue. (Latter of course always overrides former.)

The last point really underlines the power of delegated democracy.

First, delegating by unit is very similar to how you vote for a single politician to represent you in parliament, with the difference that you can change your decision at any time, not just every 4 years. Delegating by area is a further refinement: There really isn't a valid reason why I should only be allowed to choose only one person to represent me for everything.

As an example, imagine a Finnish voter who's political alignment is as follows:

• For digital civil rights
• For free market capitalism / against socialism
• For nuclear power plants as a source of electricity

There doesn't exist a single party in Finland that would share all those political views. So you have to vote for someone who will only represent your views on some topics but not all - or just give up and not vote at all. But when you can delegate your vote per topic, then you can choose the best fit for all three topics!

Finally, delegating per issue could be used if you want to override your normal delegation just for this single time. Of course, then you could also choose to become a direct voter for that issue.

There is a demo instance of Liquid Feedback that you can sign up for if you want to play with delegated voting hands on. (The system decides on policy issues for the Solar System :-)

Combining delegated voting with secret voting

Let's now extend this system so that we can use a cryptographically secure voting method. This implies that everyone’s vote is secret. But that is then a problem for the delegation mechanism - how can we delegate a vote, or count that vote, when we don't know how anyone voted?

The answer is to split voting into two parts: everyone has a public vote and a private (aka secret) vote.

• Each user can cast a private and a public vote. They needn't be identical. (Even if that's the case in the above picture, it's only for simplicity.)
• The public votes are used only for delegation, but they do not count as actual votes. The private votes count as one vote each. In the above picture, each black circle counts as one vote. The blue and green paths are used to find out to which initiative the delegated vote should be counted into, but the blue and green circles do not count as votes.
• Both public and private votes can be either directly on the issue or a delegated vote.
• A user may choose not to cast a public vote at all. In this case it is not possible for others to delegate to this user / such delegated votes would be lost.
• A user could also just cast a public vote and no private vote. Note that the users public vote doesn't count as a vote, it is only used if others delegate their votes to this user.
• Like before, users can delegate their vote to another user ahead of time (ie all issues for a unit or per topic). Both public and private votes. For private votes this turns out to be a complicated requirement on the cryptographic algorithm used. I believe the Acquisti algorithm can handle it though. I will discuss that in a future post.

UPDATE: It is worth pointing out that in addition to being a technical necessity, the split into public and private votes is considered a feature in itself. It mirrors how we vote in modern elections too: In an election, my vote is secret. But the politician who represents me in parliament does his work, including the voting, in public. This is so that I can hold him accountable and know how he has used my voting powers, that I had delegated to him.

In the liquid_feedback_patch/ I've done for the Solon project, the public votes are simply the same voting mechanism that is already used by Liquid Feedback. But while they are stored in the database as before, there is a stop at the moment counting happens - they are not counted as part of the voting result. Instead they are only used for lookups to determine the results for delegated votes. The private votes otoh are stored against an external system. (...which is yet to be implemented, but you can play with a mockup user interface.) This external system caculates the result of the voting and then stores it back into Liquid Feedback. (The Schulze ranking is then applied as usual, there's no cryptography needed for that part.)

Preferential voting

The voting method used (ie how votes are counted and a winner determined) affects people's voting behaviour greatly. For instance in Anglo-American countries a winner-takes-all system is often used and this effectively leads to a two party system. For instance in the US presidential elections there is no point in voting for the Green candidate, because he can't win anyway so it's the same as not voting at all. (...which is exactly what many people choose to do in these countries, they usually have much lower voter turnout.) In other countries other voting methods are used (Finland uses d'Hondt system) but the same problem persists to a lesser degree.

To make a delegated democracy system as fair and inclusive as possible, it should use some modern preferential voting method instead of the traditional methods we are used to. Liquid Feedback uses the Schulze ranking method. (What a coincidence, it's creator is German too!)

In the above pictures we simply voted for one of the available alternatives. In a preferential voting system the voters will instead make an ordered list of the alternatives: "I prefer #3 the most, then #1 and I like #2 the least."

I should note that in Liquid Feedback: a) it is also possible to list two alternatives as equally preferred, and b) they always include one alternative as "Status quo", which just means "I prefer we do nothing over the alternatives that are lower than this in my list". The first detail just makes the amount of possible permutations larger, and the status quo alternative can be handled as just another alternative, there's really nothing special about it in this context.

Unfortunately most, if not all, cryptographically secure e-voting systems have been created with traditional elections in mind. So they may not be suitable for preferential voting.

One way to use such algorithms for preferential voting methods would be simply to map all possible permutations of this ordered list to a value that the user could vote for. Ie if you want to vote for the list "#3 #2 #1" then vote "1", if you want to vote for "#3 #1 #2" then vote "2", etc... Unfortunately if there are many initiatives this mapping will quickly grow very long and it would make the cryptographic computations more expensive. As noted, the fact that Liquid Feedback also allows initiatives to be ranked as equals also increases the amount of permutations needed.

The Acquisti algorithm provides for a way to enable write-in votes in section 5.2. I believe it can also be used to enable the algorithm to be used for preferential voting. This way it is possible to create a mapping for the preference-lists that voters actually want to vote on, without having to create a mapping for all possible permutations, most of which nobody is going to vote for.