We present OVOTE: Offchain Voting with Onchain Trustless Execution

2022-07-05 by arnaucube

We present OVOTE (v0.5): Offchain Voting with Onchain Trustless Execution.

TL;DR: OVOTE is a L2 design for voting using validity-proofs (zkSNARK proofs), which is similar to zkRollups. The main idea is that the votes are aggregated offchain, and proved onchain through a zkSNARK proof, resulting in constant gas costs while scaling up to thousands of voters through a single Ethereum transaction. We present the technical document together with the implementation of the zk circuits, smart contracts and backend node.

OVOTE technical document

Context

This is a project that we started 4 months ago in the Aragon ZK Research guild, continuing the ideas that we’ve been discussing in Vocdoni for the past year, with the aim to be a contribution to the Aragon ecosystem.

OVOTE (v0.5) is a short-term project with a specific scope, with the aim to be a first practical step towards a future of high scalablility & privacy preserving voting systems for DAOs using zkSNARKs. This forum post presents the high level idea, the full design can be found at the OVOTE technical document.

Introduction

The main idea is that the computation and verification of the votes (vote + signature + censusProof), is computed off-chain. Then, a zkSNARK proof (validity-proof) is sent to the Smart Contract which verifies that everything is correct, similar to a zkRollup (Validium), but instead of economic transactions updating the Rollup state, with votes aggregated into a Result.

With this design, we can have thousands of users voting offchain, triggering onchain execution in a trustless way. This is done with constant gas costs without needing Oracles or optimistic multisigs.

How it works

Votes are computed offchain, and a zkSNARK proof (validity-proof) is verified onchain which proves that votes aggregation result is correct and that includes votes issued by each user belonging to the census.

Status of the project

We have implemented the zk circuits, the smart contracts, clientlib and the backend node (see next subsection with the links to the repos). We have almost an usable version of OVOTE which we hope to finish during next weeks, with the idea that can be used to build a product for the Aragon ecosystem.

In the following subsection we list the different components that we have implemented.

Components implemented

Properties

Properties covered for this initial version.

Use cases

The aim of this project is to be a first step towards the usage of zkSNARKs technology for DAOs tooling. In the following sub-sections we describe some of the inmediate use cases that can be done with the current implementation, some other use cases that we plan to implement, and some further research that we will do.

Aragon DAOs integration

Tokenomics

Tokenomics are not in the scope of this project, but we identified some places where the usage of ANT would be useful: - To pay the prover-server costs: Aragon could have servers that DAOs can use to compute the zkSNARK proofs, these are powerful (and a expensive) machines. There could be a fee in ANT that needs to be paid to the prover-server when publishing the results + proof on the Smart Contract. - This could be achieved by putting the prover-server ethereum address as a public input of the circuit, so the Smart Contract needs to know it to verify the proof, thus the contract can require sending ANT to that address, in the results publishing (& verification) transaction call.

We aim to do more research about possible other uses of ANT tokens in the context of OVOTE.

Direct use cases (short term, available with the current implementation)

Use cases available with the current implementation:

Future mid-term use case - OVOTE-DAO (~zkDAO)

An interesting idea to build on top of OVOTE, is to set up a Smart Contract that builds a Census Tree, where users can deposit ETH or any ERC20 token, and when the deposit is done, the contract adds a new leaf in the Census Tree with a weight value corresponding to the amount of tokens deposited by the user. In this way, the contract maintains the Census Tree, based on the deposits of tokens of the users, and the users can vote on proposals to spend the deposited tokens by using the same approach than the OVOTE. This could be managed by a contract on top of the OVOTE contract.

In short words, this would be a kind of ‘offchain DAO with onchain validity-proofs’, where users make token deposits to the DAO contract, and then they vote offchain based on the weight of their deposited tokens, and the results with a zkSNARK proof is published to the DAO contract, which if correct, proves the correctness of the results and triggers a transaction execution (which, can be DAO funds movement).

In one line: a DAO where the census is built by the tokens deposited in the contract, where the members vote based on their deposited tokens through OVOTE, and the results are published onchain together with the OVOTE zkSNARK proofs, to triger the funds movement.

This is our next step once OVOTE is implemented, as for having an initial version of OVOTE-DAO we could reuse the same zk-circuit that we implemented for OVOTE, and most of the needed implementation would be for the contract that gathers the user’s deposits onchain and build the CensusTree.

Long term research

Regarding the project name

OVOTE (Offchain Voting with Onchain Trustless Execution) is the research project name. Aragon could build a product using OVOTE, and this product could have a more user-friendly name such as zkMultisig, zkGov, gaslessVoting, etc.

More details

Technical paper (draft): https://research.aragon.org/docs/ovote

A forum version of this post can be found at: https://forum.aragon.org/t/we-present-ovote-offchain-voting-with-onchain-trustless-execution/3603