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

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
• noncustodial onboarding of voters
• access voting trends in (real) time

Voting Mechanism Requirements

• verifiable voting results
• storing final voting results in an immutable way, on-chain

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)
• the Ethereum address corresponding to the source of the payments
• Ethereum address of the token used in the voting process
• the token amount to be sent as payment when voting occurs
• HTTP endpoint for the proxy used to validate and trigger voting payments
• optional HTTP endpoint for getting real-time results

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)
• Ethereum address corresponding to the target of the payments
• based on the implementation, we might need additional identifiers — e.g. channel identifier for payment channels

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)
• can have an additional identity layer, where the user is asked to sign a message (Ethereum-compatible or another digital identity signature)
• allows people to vote by sending an HTTP request on the endpoint found in the SurveyContract with the target address, corresponding to the chosen proposal (identity-related data can also be sent)
• returns the vote proof also containing a timestamp and a vote identifier, which can be stored in the browser’s local storage

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
• ideally, the voting results for each proponent should be registered on-chain (e.g. in case of payment channels, this can be done by closing the channel; however, if the payment is routed through the network, results are compromised). A solution based on uploading the payment logs to a decentralized storage service and then verifying the results off-chain can be considered.
• allowing multiple payment channels to exist between the same participants, at a small setup cost, can enable scaling for the proposed voting patterns

4. Proxy server

• validates the voting requests — checks voting period, identity etc.
• forwards valid payment requests to the originator’s layer 2 payment node, triggering a payment from the originator’s address to the proponent’s address
• returns a voting/payment proof to the voter

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)
• each payment log contains signatures from all three parties: originator, proponent, voter

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
• proponents might have a harder time to figure out what payments are correlated with the actual proposal and provide proof
• of course, this can be great for direct (maybe even anonymous) funding, but not so much for storing the conclusions on-chain

Use Cases

• proposing and voting on DAO governance issues
• proposing and funding a project’s GitHub issues (use case inspired by my recent EthParis hackathon collab https://devpost.com/software/gitviction)
• presenters paid by an audience’s digital claps, from the account of the business that is contracting them

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
• if the survey dimension has a binary answer (e.g. yes/no), we can consider using the payment direction
• the channel identifier is also stored in the SurveyContract
• if using a direct channel, the poll results are stored on chain when closing the channel

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.