EIP-1202 Voting Interface Discussion Thread

EIPs
, ,
1

Starting a discussion thread for EIP-1202. The original discussion occurs on ERC-1202 Voting Standard · Issue #1202 · ethereum/EIPs · GitHub

A series of efforts were put forward to support general voting standard.

  1. EIP-5247 Proposal Interface and its discussion
  2. EIP-5732 Commit Interface and its discussion
  3. EIP-5453 Endorsement Interface and its discussion
  4. ERC-5805: Voting with delegation

Roadmap

  1. Get the right group of ppl, summarize state of art
  2. draft 1st version with 1 prototype
  3. run hackathon and grants for more implementations
  4. draft 2st version.

Key Questions

  1. What function name and parameter to “vote”
  2. What’s a proposal represented

Participation of discussion

Reference Projects

2

Please comment here if you like to collaborate: authoring, implementing reference implementations, adoptionz

1 Like
3

I am interested in the standardization of voting and look forward to implementing it in a project.

Specifically, the governance I envision involves the following stages (which may require a new EIP):

First, determine the issue,
Second, spontaneously set the motion,
Third, cast votes,
Fourth, make the vote public,
Fifth, generate governance decisions,
Sixth, execute the decision.

In the third step,
We want the voting process and the voting results to be privacy-protected,
Because the voting incentives in the sixth step are related to the specific content of the vote.
The specific implementation process is as follows:
the state data stored on the blockchain is obtained by users using an encrypted passphrase for hashing,
and after the public phase, users can reveal their encrypted passphrase.

I wonder if the requirements for the third step can be reflected in the interface?

1 Like
4

@bl2 hi!
There are several ways to enable privacy I can think of.

  1. commit reveal, which takes 2 casts, can be batched across many voters
  2. optimistic proxy: a trusted party submit the votes on voter’s behalf given a voter-signed commitments from each, voter can submit challenge, in which case the trusted party will reveal the signed commitments pre-image so they can avoid fraud challenge. if they fail to counter challenge, they get slashed.
  3. zk-proof-based: use ZKP to prove of correct tally amongst a group of voters while no one’s identity is revealed.

All of these implementations can be supported if we properly design the interface.

5

I am unsure whether ZKP is the appropriate model because I want the total number of votes to be hidden, and it is not important whether the voting address is hidden or not. and after the reveal phase, all data should be verifiable.

The first strategy maybe acceptable.

Additionally, we would like each proposal to come with two default functions:
One is the function to execute the proposal itself,
The other is the function to incentivize addresses that participate in the voting (the supporters of the selected proposal need to give fair compensation to the supporters of the failed proposal), and the specific incentives are entirely determined by the voting results.

So, I would like to know if the existing proposal (ERC-5247) can support this idea.