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

Image for post
Image for post

Story Time

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

  • noncustodial onboarding of voters
  • access voting trends in (real) time

Voting Mechanism Requirements

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

Payment-based Voting Mechanism

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

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

Image for post
Image for post

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

Image for post
Image for post
  • 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

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

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

Image for post
Image for post

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)

Image for post
Image for post

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 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

Image for post
Image for post

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

  • 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?

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.

Written by

Building bricks for the World Computer #ethereum #Pipeline #dType #EIP1900 https://github.com/loredanacirstea, https://www.youtube.com/c/LoredanaCirstea

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store