Implementing a Layer 2 Decentralized Voting Mechanism on Ethereum, with Noncustodial Onboarding

Loredana Cirstea
Mar 15 · 8 min read

Story Time

The scope of DAOs is not limited to the governance of small organizations. We are building governance tools meant to support global decisions and foster the involvement of all people.

We can dream about building an omniscient system, which remembers each and every step that our civilization takes. However, if we take a look at what we know about the Universe, humans have the most complex memory system. Even we need to forget. Our neural pathways are garbage collected each night when we sleep and throughout our lives. While this is not optimal, in terms of efficiency, in terms of survival, we need it. Our processing power is not good enough, our storage is not big enough.

Ethereum and our common household hardware capabilities are in the same state today (and probably for a good while from now on). We are forced to forget the details while retaining the important conclusions. Otherwise, we will bloat our nodes and render them useless.

Therefore, this article is a call to action for everyone doing governance right now: start thinking about feasible Layer 2 governance systems. This article is also a proposal of patterns that can jumpstart this effort.

Voting Mechanism Patterns

  • support an infinite number of users

Voting Mechanism Requirements

  • verifiable voting results

Payment-based Voting Mechanism

The rest of this article will focus on a series of payment-based patterns of voting.

Why? Because Ethereum already has a variety of off-chain and side chain solutions focused on token payments, that are usable now! E.g. payment channels (Raiden Network, µRaiden, Connext Network, Monoplasma), side chains, Plasma implementations and bridges (POA Network, LoomNetwork, Plasma Group, LeapDAO, OmiseGo, Parity Bridge)

As development progresses, it will be interesting to see other implementation patterns emerging.

A caveat to be remembered is that a degree of centralization is needed to compensate for the easy onboarding of the voters (e.g. Originator proxy server example from below). As long as the voting results are verifiable, this is an acceptable compromise at the moment.

Glossary

Survey originator: An organization or individual who asks a question that needs an answer based on voting

Dimension proponent: An organization or individual who proposes an answer to a survey originator question (can be the same as the originator)

Voter: An organization or individual who votes on a proposed dimension, corresponding to a survey

Example:

Survey: “What milestone feature should we focus on next for our project?”

Survey dimensions: “Add support for EthPM packages”, “Add support for customizable UI themes”

High-Level Components

Keep in mind that we are now focusing on patterns and not offering a full-blown implementation or tackling edge cases.

1. Survey smart contract, with the following basic features

Add a survey

struct Survey {
    string name;
    bytes32 descriptionSwarmHash;
    address paymentSource;
    address paymentToken;
    uint256 paymentAmount;
    string votingEndpoint;
    string resultsEndpoint;  // optional
}
  • resource name and description or a pointer to the description (e.g. swarm hash)

Add a survey dimension

struct SurveyDimension {
   string name;
   bytes32 descriptionSwarmHash;
   address paymentTarget;
}
  • proposal name and description or a pointer to the description (e.g. swarm hash)

Register winning dimensions per survey

  • a challenge period is necessary if the results are computed and verified off-chain, as detailed at the end of this section.

2. Dapp client hosted on decentralized infrastructure

  • enables easy browsing through surveys and dimensions (needs a connection to a local or remote Ethereum node, one can be provided by default)

3. Layer 2 payment nodes

Any layer 2 payment solution that has the following features:

  • each payment has a unique payment identifier and/or can have payment metadata attached to it

4. Proxy server

  • validates the voting requests — checks voting period, identity etc.

Voting outcome

When the voting period ends, proponents are incentivized to reveal their incoming payments, to see whether their proposal has won or not. They can either resolve the off-chain payments on chain (e.g. closing the payment channel used for voting) or off-chain — upload the payment logs to a decentralized storage system, such as Swarm, for verification.

The originators also have outgoing payment logs for all proponents and can do the same thing.

Voters have their own proof of vote stored on their computers and it is easy to verify that their vote is included in the payment logs.

If the resolution and verification happen off-chain, a challenge period can be added into the system, along with a way to check if valid votes were included in the initially on-chain registered outcome. Some ideas that might be useful here are:

  • challengers and originators can have a deposit on-chain that can be used to pay for the challenge verification (wrongdoer pays)

Mechanism Patterns

The above system can be used strictly for voting purposes, using small token amounts or tokens without value.

However, it can also act as a direct funding mechanism, if the originator wants to give voters this power (and if he has a good identity layer). In this case, tokens will have value and the amount per vote needs to be correlated with the expected voting quorum.

1.Payment from the survey originator to the dimension proponents

This allows other entities to propose survey answers and to be funded directly through the voting process.

2.Payment from the survey originator to its own controlled nodes (proponents)

This enabled closed governance if needed. It has the same value as a classical poll.

Voters can still verify their proof of vote against the originator’s results

3.Payment from voters to dimension proponents

Payments-as-vote can also work directly from voters. However, there are some additional issues:

  • voters need to run payment nodes themselves — onboarding is harder and there is no abstraction layer over the payment solution that is chosen

Use Cases

  • proposing and voting on DAO governance issues

Implementation using Payment Channels

I recently built a Proof of Poll prototype (https://github.com/loredanacirstea/pow), to be used for measuring audience claps live, while presenting at EthCC in Paris: https://youtu.be/2NqQh_GHAh0?t=268

The scope was to see whether I could build such a polling app using decentralized tools.

This rough implementation skips the SurveyContract and relies too much on centralized infrastructure, even though I was using Raiden Network for the backend payments, but it was a good prototype, that prompted me to think a bit more about what can we build with our existing tools today.

Building a Polling App with Payment Channels

A classical polling app can be built using the second pattern — payment from the survey originator to its own controlled nodes (proponents), where:

  • each survey dimension can be set on a different channel between two originator payment nodes

What did we learn from this?

If we want Ethereum to be used in widespread governance, we need to prepare for low onboarding cost, acceptable latency in seeing results (realtime is always better), verifiable results.

We can look at our existing tools from other perspectives and discover use cases that maybe, project developers have not thought of yet. We may see that with little development effort, a broader range of use cases can be supported.

We may need to think about layer 2 governance tools with limited memory time span for the actual process, but immutable and infinite life span conclusions.