ERC-1202 Voting Standard

[xinbenlv]

The draft is actively work-in-progress, please see the latest here.

Please leave comments in this Github issue below.

[xinbenlv]

Request for review~

[evbots]

Hey @xinbenlv, thanks for making this issue. I've been doing some thinking on a voting standard and share many of the same questions that you have outlined in this ERC. I've committed some initial thoughts about modeling a voting contract here. A voting standard could be modeled with the following primary considerations: (1) choices presented to voters (2) rules for casting votes (3) outcome logic. I've provided some further thoughts on those three points in the link provided above. I'll respond to your "Early Feedback Questions" questions below:

1. I don't think you've duplicated any efforts in this repo. I am aware of a project called CarbonVote that was created during the DAO hardfork and I'm curious why a discussion around a voting standard did not evolve from that.
2. I imagine that a simple standard would be a single use design, but I'm open to other ideas on this.
3. I think proxy voting is pretty important, but this could be achieved outside the standard. By this I mean one could combine a voting standard with a third-party proxy contract to achieve proxy voting. I don't think the standard itself should make any mention of migrating or upgrading contracts.
4. I think there are an infinite number of ways that a voting system could be designed. Therefore I think it's important that a standard be limited in scope and leave advanced implementations to projects to implement themselves.
5. I don't have much of an opinion there. In theory this would be helpful.

[xinbenlv]

Thank you Evan(@evbots) for the response and it's very inspiring. I will look into the example you provided and start to come up with a few implementation samples.

[evbots]

No problem! I'm excited to collaborate on this. I've considered a few things that might make sense for a voting standard. In the process of voting, distributed parties probably need to be able to do the following things in a consistent manner:

• query options for voting (read)
• cast a vote (write)
• query for the outcome of a vote (read)

The data passed and returned from the above methods should probably also be standardized, so that applications know how to structure payloads for voting and display voting outcomes (although given the vast number of ways an outcome could be determined, this might be challenging).

I think the methodology by which the outcome is determined (how the votes are counted) could probably fall outside the scope of a standard since those parties participating in an election or poll don't need to interact with those methods. Only the owner of the election contract has to determine and implement the outcome methodology.

A simple standard like above would allow dApp developers, wallet developers, and exchanges (just to name a few) to build simple voting interfaces for contracts requesting votes from arbitrary accounts or token holders.

I think there are probably other methods that could be considered for a standard as well, such as methods for determining who can vote or who can't vote. Interested to read your and other's thoughts on the matter.

[xinbenlv]

We kindly request the community for comments, in particular, the following ERC and projects related authors:

• ERC-20: @frozeman, @vbuterin
• ERC-721: @fulldecent, Dieter Shirley, Jacob Evans, Nastassia Sachs
• Carbon Vote: @lgn21st, @Aaaaaashu Your comments and suggestions will be greatly appreciated.

[xinbenlv]

Usage for discussion and call for example(I will try to write some too)

1. Joint Wallet contract approval process(multiple voter vote, when qurem reached, trasnfer token/approve
2. Voting for Ranking (getTopOptions)
3. Secret Vote
4. Token re-issue
5. Multi-Input Oracle Mechanism, select source of output or value of output based on voting ...

[yingogobot]

Hi @xinbenlv thanks for making this issue. I think this issue is definitely helpful for Blockchain and DAOs governance. We have been working on a project that is a blockchain dispute resolution protocol, also using voting as the primary function of our jury community. So we have been thinking about Voting for awhile.

I have carefully read all your ideas and great feedbacks from @evbots . Here are some of my suggestions. If possible, I would love to collaborate on this with you guys.

1. Option for setting the vote open time and close time, generally, i think all the votes should be done in certain amount of time, so the result will be useful and valuable.

2. Option for setting the ratio of the winning option. by default, it's 51% vs 49%.

Let's use the example you provided, 'If John Smith should be our new CEO'. In order to have John as our new CEO, company decides we need at least 70% of the votes for YES. So we can set a the winning ratio as 70% when constructing the smart contract.

3. Option for getting the votes each options got.

For instance, when a vote ended, we would like to show how much vote each option got, such as Option A: 555 votes. Option B 420 votes. Option C 1222 votes.

4. this is just an idea related to weight, maybe when weight is not 1, user has to deposit the token into the smart contract for their votes. otherwise the weight is not very secure, since i can cast my vote then transfer all the tokens to my friend and they vote with the same weight again. You can take the reference from the voting for token listing from exchange platforms. so in that case, we might need to have a function which allow user to cast their vote along with their tokens.

5. suggest to add another event called OnWinnerAppears, so some smart contracts or dapps which can be executed continually on this result, such as dispute resolution, can run automatically when they receive this event.

[fulldecent]

" but for secret voting people might not want to disclose a voting for certain issue even exis" is poor rationale for not supporting ERC-165.

Currently the use cases are focused on developer needs. Instead they should be focused on end user needs. We should standardize things because users demand interoperable systems, not because developers want other people to copy their ideas.

A strong EIP should review existing implementations of voting system and analyze how they would be served by this standardization. I have a hunch that actual voting systems will be much too complicated to standardize / or the scope of the standardized part will be very limited.

Also, thanks for the ping.

[xinbenlv]

@fulldecent Thanks for your comment and advice William. I agree with your point that interface design should prioritize user's need of interoperable systems rather than developer's need.

We are thinking that ERC1202 shall be decoupled with ERC165 as whether to support ERC165 (or later if other detection standard mechanism being proposed and passed) is perpendicular to a ERC interface design itself. And I think we are going to recommend supporting ERC165. Question for @fulldecent: In which section in this EIP shall we put the recommendation to implement with ERC165? How about Backward Compatibility? Or we are also thinking about having a separate section of "Interactions With Existing ERCs"

Per your(@fulldecent) suggestion: we added outline to case study and add coding examples for a few existing or commonly used voting systems / rules, stay tuned for our update on these case study and coding examples as they might need take sometime to complete. Thanks for the advice, very valueable. We also hope to hear for other Ethereum community members to remind us of other worth noting voting systems / rules to be included.

And yes, after adding several case study outlines, I started to feel voting system as a standard can become increasingly complex. We like to seek experienced ERC standard authors for advice on how to trade off between simplicity and usability coverage on ward.

Thank you!

[bingen]

This is a very interesting proposal, but as it has been said before, it looks like hard to achieve. There are so many variants in Voting that I don't think we can define a standard that fits them all. E.g., you are defining:

function vote(uint option) external returns (bool success);

but what about PLCR voting, where you need a commitVote function plus a revealVote one? (Btw, I guess, this function is missing a param for the Vote Id, right? Or is it one contract per Vote?) At Aragon we have thought a little bit about it, as we are trying to implement a TCR system where the Voting app can be easily swapped. You can see more details here. So we are going to define a minimum interface that covers these particular needs, but for example we'll leave the way votes are cast out of its scope. Besides, we also have a regular Voting app that implements a forwarding interface to be able to execute actions automatically once the vote has been closed, in case you want to have a look at it (re: comment 5 by @yingogobot ) Anyway I'll keep an eye on this and try to help as much as I can.

[aodhgan]

Of note for private voting

[xinbenlv]

@bingen: Thanks for the response. On a separate thread, @frozeman also mentioned the PLCR voting. I intuitively think about the possibility of doing so, and I will add a coding example to implement a simple PLCR voting. Side note, you asked Or is it one contract per Vote. Please take a look at the advanced version of the spec, which has the "Vote Id"(issueId).

@aodhgan, Thank you! Despite as short as only 5 words, points us to a very interesting paper of privacy-friendly voting with zero knowledge proof. I think we have good candidate for what I called "sealed counting" voting too. There are a few other papers and I think we should do a research summary on what's published in the academia

I plan to prioritize updating the standard with these two advanced voting mechanism. Thank you all

[frozeman]

I would also suggest checking if add claim checks on identities such as #725 and #735 in the voting process. The question here is only does this need to be standardised, or is it enough as an implementation choice.

[ainsleys]

@xinbenlv and @aodhgan we (at Enigma) have also been working on enabling private voting for Ethereum contracts. We are still in testnet but will have a demo of a working secret vote contract in coming weeks. We are glad to follow this standards conversation, thank you for getting it started.

[bingen]

Another interesting source to have a look at is Harbour: https://github.com/HarbourProject/protocol

[xinbenlv]

@frozeman: Thanks, I will add the consideration of interactions with ERC #725 and ERC #735 to the draft.

@ainsleys: Thanks for reaching out. Enigma is a very interesting project. I added the TCR blog post as a reference of the draft. Talk to you tomorrow

@bingen: thanks for the additional reference!

[chaitanyapotti]

Can you also add an option to UnVote?

[xinbenlv]

I think unvote can be supported, to keep it simple, vote can also do the trick. As an interface, the implementer of it can determine how to interpret vote() function. For example, a second vote() call can overwrite the previous vote, or a second vote can add to the previous vote.

[xinbenlv]

@pau1m :

For some reason I couldn't find your comment on the github issue, was it deleted?

Appreciate the discussion, this is very valuable feedback.

Answered in the code

On Sun, Dec 2, 2018 at 9:44 AM pau1m notifications@github.com wrote:

A couple of comments from my experience implementing a contract based on the AdvancedERC1202 draft.

Thanks, do you mind share with me your implementation so I can take a look?

There is no mechanism to add option descriptions for a new issue. In the given examples options are hardcoded in the constructor.

It is possible to create "setIssueDescrption(...)". We didn't put this inside of the 1202 yet because we are not sure if that would be a required interface

I have a specific edge case where the number of votes are allocated based on funds held in a separate vesting contract. Votes are allocated for funds remaining vested at the end time of the poll. This is the only place I had to break the draft interface by adding issuedId as a parameter. Just saying.

Which interface you broke? Is it the vote() function? It has an "issueId".

function vote(uint issueId, uint option) public returns (bool success);

—

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ethereum/EIPs/issues/1202#issuecomment-443525972, or mute the thread https://github.com/notifications/unsubscribe-auth/AAnFRWCnob_H3M8OkwqnCpAjyMfFYFg7ks5u1BFhgaJpZM4VGznz .

[xinbenlv]

Still looking for answers...

[xinbenlv]

I watch "rock paper scissors" today and I am thinking that Commit-Reveal should actually have its own standard.

[xinbenlv]

Hi all, since there is no further comments, we now propose to move this standard to Last Call with PR #2468

[3esmit]

Update to last EIP template, for example, missing security considerations section.

Also, I'm interested in this EIP, but I haven't got time to try it and see what could be improved, if anything.

[xinbenlv]

@3esmit thank you! The latest discussion ends around July 3rd, 2019, which is 6 months ago, so I didn't check the latest mandatory fields, thank you for bringing it to the attention. I will add them soon

[xinbenlv]

We will put on-hold moving to Last Call and conduct several updates then come back.

[github-actions[bot]]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[xinbenlv]

working on revision

On Sat, Dec 4, 2021 at 6:02 PM github-actions[bot] @.***> wrote:

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ethereum/EIPs/issues/1202#issuecomment-986151772, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE4KRJM4FYV62G3KUIDZ7DUPLB2JANCNFSM4FI3HHZQ .

[xinbenlv]

Hi all, I am close to finalizing the interface draft. I like to invite contributors who are interested to participate in building sample contracts. Please let me know if you are interested by replying here. or just send a PR

[MicahZoltu]

Closing this for housekeeping purposes. Feel free to continue using this issue for discussion about EIP-1202.

Note: Before this moves to Review stage, the discussions-to link should be moved over to a thread on Ethereum Magicians.