DAOrayaki Research |Vocdoni：A Decentralized Self-Sovereign Governance System

21 min readJun 15, 2021

DAOrayaki DAO Research Grant：

Fund Address: 0xCd7da526f5C943126fa9E6f63b7774fA89E88d71

Voting Result：DAO Committee /7 Yes

Grant Amount：200 USDC

Category: (Vocdoni, Aragon, Ethereum, Election, Decentralized Voting (Vochain), Ballot, InterPlanetary File System(IPFS), zero-knowledge Proof (zk-Snark), Tendermint, Gateways)

Contributor：Jones @Daorayaki，Julie @Daorayaki

Launch date: According to the aragon project which is currently the official owner of Vocdoni, the release date presumed to be on May,2021.

Brief Overview about Vocdoni

Vocdoni is a universally verifiable, censorship-resistant and anonymous governance system, designed to be scalable and easy to use on modest devices. The goal is to provide the foundation to run national elections, general shareholders meetings, assemblies, etc. It mainly concentrates on providing a trust-less voting system, where people can speak their voice and everything can be audited.

I.Background

Born out of the 2017 Catalan independence movement, Devote Labs’ the official staff of Vocdoni project mostly consists of Catalans who experienced the suppression of a democratic vote firsthand. At the time, Catalonia tried to secede from Spain, which was deemed illegal. The vote ultimately fell flat after police suppression, riots and high-profile arrests.

Simply put, Vocdoni combines decentralized infrastructure such as the InterPlanetary File System (IPFS) with bleeding-edge zero-knowledge proofs (zk-SNKARKs) in an effort to bring democracy into the 21st century. The project, while not crypt-first, uses the Tendermint consensus mechanism also employed by the Cosmos blockchain. Later on, in December, 2020, Aragon Association, the stewards of a protocol that makes for the easy creation of decentralized autonomous organizations (DAOs) has announced its acquisition of voting project Vocdoni from Estonia-based Dvote Labs Oü. The purchase was completed for an undisclosed price, where Vocdoni team members received an undisclosed amount of ANT, the native token of the Aragon network, as part of the acquisition, according to Vocdoni CFO JOAN Arús in a phone interview with CoinDesk.

II.Team, Affiliates & Partners:

On December, 2020, The Aragon Association announced its acquisition of Dvote Labs OÜ, which aims to build the most secure and anonymous voting system using decentralized technologies such as Vocdoni, their team comprises nine developers, in addition to supporting personnel.

II.1. Executive Team:

- Xavier Vives — Co-founder, Product Lead: For the most part, Xavier work involves making sure that the gears of Vocdoni are woking smoothly. As the project has grown. His focus centered on the role of product lead for the Vocdoni Platform designing it and creating an achievable go-to-market strategy. Throughout his career, he sought various holistic approaches, making him working at all levels of product development in startups across North America, Asia, and Europe.

- Pau Escrich — Co-Founder & CTO: Pau is the Lead Engineer of Vocdoni, mainly expert on mesh networking, distributed systems, security and blockchain integrations. Previously, he co-founded and worked for several years on various projects such as qmp.cat, libremesh.org, and was one the architects and developers behind the EU FP7 research projects CONFINE and Community.

- Joan Arùs — COO & CFO: Joan main role as a COO and CFO is to help Vocdoni grow from a concept and idea into a scalable business, securing the resources to achieve that and leading the strategic planning, with a solid background in science and business, he founded several companies in the internet and food industries. Besides that, he is also the co-founder of the Digital Chamber of Commerce of Barcelona and advisor to the Center Blockchain Catalunya.

II.2. Tech Team:

- Jordi Moraleda — Developer: Jordi is a full stack developer, used to integrating components all across the platform. He is known for his scaffolding for new projects, research new frameworks, test the viability of prototypes and document the protocol. Jordi also co-founded three companies, and as a crypto developer he stated off by winning his first ever hackathon as a single competitor.

- Abel Boldy — Developer: Abel is a DevOps engineer, with expertise in decentralized infrastructure, Linux, networking, security, monitoring, and all things related to systems. He worked with DAppNode for 2 years.

- Jordi Pinyana Paga — Developer: Jordi Pinyana is a blockchain backend developer with a lot of experience in Ethereum and Tendermint. He mainly focuses in the development of Vochain (the first blockchain for ballot processing and accounting) using Golang. Also, he is a blockchain professor at the Polytechnic Unviersity of Catalonia.

- Emmanouil Dimogerontakis — Developer: Emmanouil is a decentralized networks engineer. His role consists of designing and implementing middleware and backend systems. As an area of expertise, he analyzes decentralized netowrks, which mainly was focus on grassroots mesh network during his phd. Over the last couple of years, Emmanouil focuses on the application of blockchain technologies together with decentralized networks.

- Òscar Casajuana — Developer: A senior full-stack developer who mainly focused on Vocdoni’s frontend client apps, like the manager and the blockchain explorer. He has created apps and built infrastructures of many kinds over the last 10 years for multiple companies, armed with all the important insights about web-development from top to bottom.

- Nathaniel Williams — Developer: A junior full-stack developer, focusing on building a Block Explorer for Vocdoni’s voting Blockchain as well as the Vocdoni mobile application. He is Vocdoni’s latest full-time hire and a recent university graduate who joined the team first as an intern in the summer of 2019.

II.3. Communication Team:

- Ferran Reyes — Communication Lead: Ferran manages communications for Vocdoni, with an emphasis on partnerships, social media communication, and promotin grassroots movements. Outside of Vocdoni, he is a board member of Som Connexiò, the largest telecommunications cooperative in Spain.

III.The ideas behind Vocdoni:

The core innovation of the Vocdoni core protocol, part of the Aragon stack, is in implementing the first ever decentralized, censorship-resistant, and anonymous online voting protocol. But on top of these technical aspirations, the Protocol enables compatibility with a wide range of democratic processes. Vocdoni achieves this partly with our versatile specification for vote ballots.

III.1. Voting Process:

In Vocdoni’s architecture, each organisation maintains a list of public keys from their potential voters, either in a database or in a public ledger. Down below are the steps in which a voting process using Vocdoni is divided:

1. Creation of the Voting process: The organiser collates a list of those keys belonging to eligible voters to create a census (for example, members over 16 years old). They hash them using a ZK-Snark friendly hash function (Poseidon) and create a Merkle tree. This data structure, so-called Census, is distributed through a decentralized file-system (IPFS) and the process metadata (including the Merkle root of the census and a process public key for vote encryption) is published on the Ethereum blockchain.

2. Casting of votes: Once the process has begun, users can vote. To this aim they will need to provide a valid ‘franchise proof’ in order to demonstrate their eligibility.

1. Without anonymity: Each user will compute its Merkle proof which can be used by the prover to compute the Merkle root of the voting process and thus verify they are part of the census.‌‌

2. With anonymity: To satisfy uniqueness and anonymity requirements, each user wraps her ballot in an envelope using a zero-knowledge proof (ZK-Snark).‌‌The ZK-Snark proof (franchise proof) is an easy-to-verify method for proving the eligibility of a voter without revealing their identity. That is to say, the method allows a user to convince a third party verifier that it is part of the census and they have not voted twice, without revealing any information about the voter or the vote itself.

3. Validation of votes: A custom Tendermint based blockchain is responsible for validating the voting envelope and the franchise proof, to store and account valid ballots. This is referred to as the Voting Chain (Vochain). A ballot is mainly composed of three parts:

- Election/process ID.

- Encrypted or unencrypted vote content.

Franchise Proff.

III.2. Data availability:

Usually data availability is provided by the so-called cloud, which in reality means a centralization of our digital information, gathered by a small set of very powerful companies. Vocdoni aims to be a self-sovereign ecosystem, so we try to enforce the decentralization and distribution of all the non-sensitive data.

Currently, Vocdoni relies on the ‘InterPlanetary File System’ (IPFS) for storing information. In a voting process a reference to the text (question, description and options), complementary images, and the census (that can be formed by public keys or user claims). This data doesn’t have to be permanent and its expensive to keep it around, so it’s uploaded to IPFS until it can be discarded, and since Vocdoni design is modular, more incorporation for data layers in the future such as Etherphere Swarm, DAT or STORj is required.

III.3. Data Synchronization:

IPFS does the job, but if no one “pins” it when data is uploaded, it will only be available from the origin. To ensure the availability and resilience of the data, a cluster of IPFS nodes pinning the same content should be created. For that, creators start using “ipfs-cluster”, but some incompatibilities were found with our architecture. For that reason, they developed a new component named “ipfs-sync”. Following a KISS approach, “IPFS-sync” enables the creation of IPFS clusters in a very quick and easy way. The only required input to create your own cluster is a shared secret, which will be used as a symmetric key to encrypt, authenticate and find other cluster nodes. The current implementation can work either with libp2p/rendezvous and swarm/pss for the p2p transport messaging layer.

Every ipfs-sync node aggregates the list of locally pinned files in a deterministic Merkle tree. The root is broadcaster via the DHT network to those nodes which share the same secret. When a new root is found, the node asks the originator of the message for its list of pins. Thus, all nodes will end up with the same list of files and with the same Merkle tree. In addition to the data synchronisation, the nodes also announce their Multiadress via the DHT, so other cluster nodes can directly connect via IPFS.

III.4. Data integrity and main coordination:

One might call this component “the Bible” but its name is actually “Ethereum”. Ethereum is where all main and most important information is stored, though the creators try to use it as little as possible for scalability reasons. At the moment, Vocdoni is using the Goerli tesnet, but developers plan to move the infrastructure to Mainnet once Vocdoni consolidates.

Vocdoni has deployed two smart contracts:

1- Entity resolver smart contract, which contains the meta data of the Entities using Vocdoni. The Ethereum Name Service (ENS) used to address this contract is “entity-resolver.vocdoni.eth”.

The resolver contract indexes the origin or URI of the entity metadata, among other information. Furthermore, the record “vnd.vocdoni.eth” under the key “entity-id” will return the URI (usually IPFS) where the entity description can be found, in JSON format. In addition, some other records are allowed, such as “vnd.vocdoni.boot-nodes” that indicated which boot nodes should be used to reach the rest of the components. If none are specified by the entity, Vocdoni’s default boot nodes will be used.

2- Process management smart contract, used by the entities to publish and manage election process. One an entity (identified by an Ethereum address) wants to create a new process, the entity can send a transaction to this contract containing the basic information required to create it, such as:

- Election type (poll, snarks, etc).

- Start and end block number.

- URI metadata with the election data information (a JSON file stored on IPFS).

- Census Root hash and URI.

This contract is monitored by one or many Oracles, the component which makes the bridge between Ethereum and the Vochain.

III.5. Identity:

Voting correctness cannot be guaranteed unless keys really belong to the targeted user. In our identity model the user generates the keys on their device. For this reason, when it comes to identity, self-sovereign identity is chosen. Through side channels, the users prove to the organization their eligibility for voting and the ownership of the generated keys. Vocdoni’s design is agnostic to how voters are validated, and organizations can choose their own requirements. At the current stage of, Vocdoni uses the well-known plain ECDSA public/private key pairs. As a result, for the time being a user or an entity is globally identified by a public key.

III.6. Census:

The entity has the responsibility of keeping a list of public user keys up-to-date. To this end, Vocdoni provides a Census service, which enables a “REST API backend” to manage the census in a convient manner. The main idea behind the API is allowing the entities to own and manage their private infrastructure. Usually, a database would be storing the real user data such as names, email addresses, and phone numbers. But Vocdoni also provides a very simple, unified web-based solution that can be freely used by any entity. In Vocdoni design, the census is a list of ECDSA public keys from eligible voters, aggregated on a Merkle tree using Poseidon hashes (which are ZK-Snarks friendly) based on the “iden3 implementation”.

1. Why using a Merkle Tree as a census date structure?

1- The whole data structure can be summarized as a single hash.

2- A user can provide a Merkle proof to demonstrate that its identity is part of the census. For instance, in the example above, the owner of the left-side Pubkey only needs to send its Pubkey + Hash4 + Hash2 (named siblings) to allow a third party to reconstruct the root hash. The prover does not need to have access to the whole data structure, just to the root (32 bytes).

III.7. Voting:

Vocdoni aims to scale and support all sized of voting processes and, in the future even national elections with millions of eligible voters. To this end Vocdoni creators implemented their own voting blockchain named Vochain. The design implies a paradigm shift. Instead of relying on centralized counting systems, Vocdoni system allows anyone to audit any voting process and at the same time, visualisation tools could be created. Vocdoni has a basic system for this purpose named “scrutinizer” that anyone can run to verify the correctness of the results.

There are no tokens nor virtual machines on the Vochain; its only purpose is to validate and count votes in a very efficient way. It’s based on “Tendermint”, so currently it’s a weighted Proof-of-Authority. The nodes (miners or validators) allowed to create new blocks on the Vochain are managed and coordinated in an Ethereum smart contract. Once Vocdoni consolidates the next step is to enable a mixed Proof-of-Authority/Proof-of-Stake in order to decentralize the validators.

The oracles are special Vochain identities able to create a set of special transactions. They act as bridge between Ethereum and the Vochain. So for instance, once a new voting process is created in Ethereum the oracles will send an “addProcess” transaction to the Vochain. Although the oracles are trusted components, anyone can verify they are not manipulated or applying any kind of censorship.

Currently, the Vochain allows the following transactions:

- addProcess: Creates a new election process (oracle only).

- cancelProcess: Cancels a current election process (oracle only).

- addVote: sends a new vote for an existing process id (votes).

- addOracle: adds a new oracle identified by a pubKey (miners only).

- removeOracle: removes an existing oracle (miners only).

- addValidator: adds a new miner identified by a pubKey (miners only).

- removeValidator: removes an exsiting miner (miners only).

- addProcessKey: adds an encryption public key for encrypting the votes payload (miners only).

- revelProcessKey: adds an encryption private key for decrypting the votes payload (miners only).

The state of the blockchain represented by three nested Merkle trees summarised in a single root hash (named State hash). All noted and miners must calculate the same hash locally. This mechanism ensures that all blockchain bytes are correct and the consensus works. For example, if a new vote is included on block 123 by the miners, the new root hash will be broadcasted on the p2p network. Then, all nodes of the blockchain will validate the same vote, include it, and check that the calculated state matches (if not they will fork).

The vote types currently implemented and allowed are:

- poll: for non-anonymous voting, the voter must provide a valid Merkle proof to demonstrate its eligibility.

- Snarks: for anonymous voting, the voter must provide a valid ZK-Snark proof (in POC state).

1. How decentralization is achieved in Vocdoni?

Most of Vocdoni’s components are based on decentralized technologies: IPFS, Ethereum, Tendermint, etc. However, all these technologies are very resource-demanding on CPU/Memory and Network. Consequently, running them on a smartphone or in a web environment is not very realistic. To fix this problem a new component named Gateway is created.

Gateways provide an entry point to the P2P networks. They allow clients to reach decentralized services through a WebSocket HTTP(s) API interface. The Gateway code can on the go-dvote repository. Currently, there are five available APIs that can be enabled/disabled at the Gateway owner’s will, they are:

- File api: provides access to IPFS or any other supported filesystem.

- Census api: provides access to the census methods, such as create and publish a new census or generate Merkle proof for an eligible voter.

- Vote api: provides access to the Vochain, for instance to cast a new vote.

- Results api: if enabled, the Vochain scrutinizer will computer the election results and summarize it for the clients.

Web3 api: provides acess to the Ethreum blockchain.

The Gateways could be added by anyone willing to contribute to the Vocdoni ecosystem but it can also be added by a user who does not trust other Gateways and want to have complete control over its communications. Currently, Vocdoni team is working on a Gateway incentivization mechanism to ensure a good health of the Gateways network. One a new Gateway is started it becomes public via a P2P/DHT network (currently libp2p). Bootnodes will check that the Gateway is actually working and will add it to a list. When an APP client needs to reach a Gateway, it will contact the Bootnodes to get this list and choose one (or several). From the other hand, Bootnodes are managed on the entity-resolver smart contract.

Gateways can be attacked, but anyone can set up new ones, so the network scales horizontally, just as any existing blockchain. The integration with DappNode is planned to make Gateways one-click deployable, and as a last resort, on a continued DDOS attack, a Gateway can be added privately and silently. So, groups or communities can share their own private Gateway infrastructure to ensure they can access the Vocdoni platform.

2. How user anonymity is ensured in Vocdoni?

Voting anonymity is achieved by the usage of the Zero-knoledge technology Zk-Snarks. Zk-Snark proofs are a convient methods to prove to third-party verifiers that a voter is within a census and has not voted twice without revealing its identity.

Each Zk-Snark use case requires its own circuit which is shared among provers and verifiers. A circuit is composed mainly by cryptographic operators and indicates, in a strict and deterministic way, if a set of input values is valid or not. Vocdoni team uses a non-standard fork of circom (with some minor modification) to design and implement their circuit. Circm is a project developed and maintained by “iden3”.

Private inputs are those required exclusively when generating a ZK-Snark proof. They are mainly the Merkle proof (that demonstrates a user is part of a census) and the private key (identity of a user). Once the user generates a valid proof for a specific Census Root and ElectionID, it needs to make the Nullifier public together with the Vote package. That nullifier is a unique number that will identify the vote (but not its ownership) thus it will make visible if the same identity is voting twice. On the other side, public inputs are required for validating the Zk-Snark proof, so any prover must have access to these inputs.

- Census Merkle Root.

- Vote package (might be encrypted).

- ElectionID.

- Nullifier.

- Commit Key.

The Commit and Reveal Keys enable a mechanism to mitigate the vote purchase. Once all reveal keys are public anyone can generate a valid Zk-Snark proof for that specific election. So, it makes it impossible for a user to demonstrate he voted for a specific option once the election is over. In addition to that, the commit keys will be generated automatically by the Vochain’s miners once a new election starts and the reveal keys will be published once it finishes. This is one of the weak points of the anonymous voting architecture, but only if all miners agree on tampering with the election results.

3. What about transparency is it possible to enforce it?

Transparency is a key point in order to enable universal election reliability. A process is end-to-end verifiable if anyone can validate the correctness within the system by its own. The way Vocdoni team uses blockchain technology enables the end-to-end verification as, when the voting process are finished, anyone can download and validate the corresponding Vochain, thus, evaluate if the published results are correct or not.

Although Vocdoni aims to maximise transparency in all its components in order to become trust-less as whole, complete transparency is not always totally possible. There are still some private components which, by nature require some trust such as the private census of an entity. However, even if the entity tries to manipulate the census, there are some properties that will mitigate these issues:

- Anyone can scrutinise the results of an election, all the voters information (currently often conveniently obfuscated) are stored in the public and open Vochain blockhain. No personal or sensitive data is updated in the blockhain.

- Anyone can check the size of a census, so if the entity tries to add a relevant amount of fake identities to manipulate an election it might be caught by any observer (i.e if a city council has 1000 inhabitants, a census of 1200 identities would show a red flag).

- If an entity replaces an identity on the census, the replaced user will notice it (the vote annot be sent), so if this happens for a relevant amount of users, the manipulation will be probably discovered.

III.8. Vocdoni Ballot Protocol:

The Vocdoni Ballot Protocol aims to be a very simple yet powerful specification for the representation of ballots and results for a voting process, this latter is made out of one or more fields, each of which represents a single question or an option for a question, depending on the type of process. When voting, eligible voters choose from a set of predefined answers for each field. The allowed number of answers, type of answer also depends on the specific type of process. An eligible voter expresses their choices by casting a ballot.

A ballot is represented as an array (or list) of natural numbers. Each position of the array contains an answer to one of the process’ fields. After that, the results are accumulated in a two-dimension array of natural numbers (a matrix), each arrow of this matrix corresponds to a ballot field, and each column corresponds to one of the possible values for that fields. Any number in the results matrix is simply a count of the votes for the value represented at that index.

In order under to go through the weeds of how a process might be configured, a generic example is represented below. Say we have a process with three fields, A, B, and C, each of which enables 0, 1, and 2 as possible values. We don’t know what these values or fields represent, but that doesn’t matter for now.

In this example, two votes have been cast. The first voter chose the value 2 for field A, 0 for field B, and 1 for field C. The second ballot has the values 0, 0, and 2. You can see in the diagram above how the ballots relate to the results matrix. The index of a value of a ballot determines the field that value belongs to- i.e. the first index of ballot 1 has the value 2, so ballot 1 is assigning the value 2 to field A. Within each field of the results matrix, the value of the vote is represented by its index. We place a 1 at index 2 of field A to represent the one vote for the value 2.

III.9. The Protocol Itself:

The ballot protocol is composed of a set of numeric and Boolean (true/false) variables that restrict the format of a valid ballot.

1. How might the presented example be represented with this protocol?

To start, we know we have three fields, so:

3. maxCout = 3.

We have 0, 1 and 2 as our valid values, so we can set:

4. minValue = 0.

5. maxValue = 2.

The second ballot contains the value 0 for multiple fields. So, in order for this ballot to be valid, we must set:

6. uniqueValues = 0 (0 here represents ‘false’ and 1 represent ‘true’).

There’s no one obvious set of assignments for the next three variables, so let’s add a little more context to our example process. For example, say this process is a single question asking voters to delegate gold coins to different organizations. Each field represents a single organization, and the value assigned to that field is the number of gold coins that voter wants to allocate to that organization.

Based on the minValue and maxValue variables we’ve already set; we know that each user can allocate between 0 and 2 coins to any one organization. But a plausible rule we could add is that voters can only allocate 3 coins in total. And let’s also imagine voters have to allocate at least 1 coin. This adds meaning to the process diagram above; the first ballot allocates 3 total coins (maybe they support organizations A and C, but they like A a little more). The second ballot only allocates 2 of its 3 possible coins (they only support organization C and would rather waste their third coin than give it to A or B). So, to make both ballots valid we can safely set:

7. minTotalCost = 1.

8. maxTotalCost = 3.

The final variable we need to set is costExponent, which pertains to quadratic voting. We won’t dive into this type of voting for now, so let’s just set the default:

9. costExponent = 1.

Again, take a moment to reflect on each of these variables, and see if you can understand how changing any one of them might affect our example voting process.

III.10. Results parsing:

The variables above represent the entirety of the Vocdoni Ballot Protocol, which covers ballot validation and results tabulation as handled by the core infrastructure. But there’s obviously still a lot of missing information when it comes to the human experience. Integrators of the protocol need to decide how to communicate the actual content of a process to voters, as well as how to parse and represent the results matrix. Results parsing is outside the scope of the Ballot Protocol but is relevant to understanding how the Protocol might be used. In its current iteration, Vocdoni defines two results parsing formats: “Index-weighted” and “Discrete values”.

1. Index-weighted

We would use the Index-weighted results interpretation formula for our example process. This schema is suited for single-question processes such as ranked-choice, multiple choice, or participatory budgeting. Each index in a field of the results matrix represents a weighted value, where in this case the weight represents the number of coins allocated to an organization. The sum of the votes, multiplied by their index-weighted values, is the total value for that field.

This interpretation aggregates our example process. Organization A receives 2 coins, organization C receives 3.

2. Discrete Values

Discrete values interpretation is used for processes in which each field is its own question. Here each value represents a single discrete option (i.e. ‘Candidate 2’), rather than a multiplier (i.e. ‘2 points to this option’). As such, this method interprets results by simply reporting which value, if any, received the most votes for each field.

0 is reserved for a tie between options.

These two formats are not intended to be exhaustive. As stated above, the Ballot Protocol itself is agnostic to how results are aggregated, and anyone building their own application layer on top of the protocol can define their own results interpretation.

IV.Contact Information

Official Website: https://aragon.org/vocdoni

Blog: https://blog.aragon.org/vocdoni/

Twitter: https://twitter.com/vocdoni

Discord: discord.gg/x7GYRB8dpp

Telegram: https://t.me/vocdoni

Github: https://github.com/vocdoni?page=1

Welcome to submit your DAO research and send it to this email address:daorayaki@dorafactory.org ,Share the 10,000 USD grant pool!

Welcome to DAOrayaki official website:（daorayaki.org）