In this post we describe a high-level design for a voting system resulting from combining two protocols, ipfs and nMix. Ipfs is, from wikipedia:

InterPlanetary File System (IPFS) is a protocol designed to create a permanent and decentralized method of storing and sharing files. It is a content-addressable, peer-to-peer hypermedia distribution protocol.

We also have nMix, which is:

A backend for a mixnet-based, cryptographically secure voting system. nMix is based on the univote specification, developed by the e-voting group at the Bern University of Applied Sciences.

The current implementation of nMix uses git as the backbone of the bulletin board, which is a central component of any secure voting system. The main idea in this design is simply to replace git with ipfs. Because nMix has been designed following a data-centric reactive protocol, the voting crypto workflow is decoupled from the bulletin board implementation. Any implementation which satisfies the nMix bulletin board interface can be plugged in, modulo performance and efficiency considerations.

The result of this combination is a voting system that offers the privacy and verifiability guarantees of the nMix protocol together with the decentralization and immutability characteristics of ipfs. Of course, this high level design and needs to be validated with a proof of concept implementation.

Voting System Components

Below, all the components behave as nodes with respect to ipfs. In particular they all have public keys whose hash gives the node’s peerID. The corresponding private keys are used to publish, update and sign information. Data is updated using the ipns api, producing hash-chains for all stages of updated information[1]. Components that need to talk to each other must be aware of their respective public keys and peerIDs. Because the nMix protocol is data-driven and reactive, components talk by reacting to published information, they do not initiate requests or invocations against each other. This simplifies deployments, that are therefore easier to secure.


This component handles the authentication and registration of voters. This design is agnostic with respect to authentication mechanism. We simply assume that there exists some secure authentication method by which voters register for a vote. The Registry is responsible for the electoral roll, which is simply the list of ipfs public keys that are authorized to participate in a vote. Just like any other piece of data, the electoral roll is published in ipfs, by the Registry.

Voting Client

The Voting Client encodes voter choices and encrypts the resulting ballots. These ballots are published onto ipfs with the voter’s public key. After a vote is published, the voting client must asynchronously check for the receipt of the ballot on the ballot list. This ballot list is published by the Ballotbox. Voting clients may be run in browsers if ipfs node implementations (or node clients) are available in javascript. Updating ballots is possible, again with ipns.


The Ballotbox collects votes published by Voting Clients. To do this it resolves peerID’s present in the electoral roll, published by the Registry. It also performs validation on the collected ballots, for example, cryptographic checks on the well formedness of each. The Ballotbox publishes the list of accepted ballots, as well as those that are faulty. This allows notifying the Voting Client of any errors, asynchronously. Once the voting period is over, the ballot list is frozen, ready to be collected by the Bulletin Board.

Bulletin Board

The Bulletin Board maintains the list of information artifacts necessary for the execution of the cryptographic protocol. This includes artifacts related to joint key generation, ballot casting, ballot mixes, and joint decryption, as well as all required mathematical proofs. The Bulletin Board information is maintained by collecting data published and updated by the Ballotbox and Trustees. The trustees in turn retrieve the bulletin board information to execute their part of the protocol. This is done reactively as per the nMix design.


Trustees cooperate to execute the voting protocol such that its privacy and verifiability properties are guaranteed. These properties are inherited from the nMix design, which in turn is based on the univote specification. Trustees are custodians of the private keys that safeguard vote secrecy. When executing the protocol, Trustees retrieve information published and collected by the Bulletin Board.

Example artifacts

A few dummy examples of key artifacts that are published and retrieved during the voting process. The random strings represent ipfs hashes.

Electoral Roll

The electoral is simply a list of public key hashes which serve as peerID’s. The bulletin board can retrieve the ballots using the published electoral roll.


This is an ElGamal encrypted ballot with associated proofs of plaintext knowledge. Ballots are encrypted to protect voter privacy.

Ballot List

The ballot list is maintained by the Ballotbox, collecting and validating votes cast by Vote Clients.

Bulletin board

The bulletin board keeps track of all the files necessary to execute the crypto protocol. These files are published by different agents: the (two) trustees use numbered namespaces, “1” and “2”. The Ballotbox uses ‘bb’, which holds the collected ballots published by individual voters. All published information is signed.

What about blockchains/Tahoe-Lafs/Swarm?

If you’re familiar with blockchains you’ve probably noticed that some of the properties achieved with ipfs are shared with blockchains. Indeed, you could probably take this design and substitute a blockchain in place of ipfs provided it had the correct storage and lookup functionalities. Some of these properties are already present with the git implementation used in nMix, for example auditability and tamper resistance. Adding ipfs or a blockchain is an extra step. See here for more on the potential benefits of blockchains for voting. Note also that this design does not require distributed consensus, the nodes responsible for publishing information artifacts are the authoritative source. This is one of the key differences between using ipfs versus a blockchain as a bulletin board.

Open source

The design described here could be implemented fully in open source, as both ipfs and nMix code fall under that class of license. Go to it!


[1] This may have to be implemented manually, or will exist when ipns includes it, as mentioned here:

In the future, we may have ipns entries work as a git commit chain, with each successive entry pointing back in time to other values.