status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-23 12:18:16 +00:00
Code Issues Projects Releases Wiki Activity
EIPs/EIPS/eip-1202.md
Micah Zoltu 15f61ed0fd
Adds rule to EIP-1 that references to other EIPs must use relative path format and the first reference must be linked. (#2947) 
I have gone through and updated all existing EIPs to match this rule, including EIP-1.

In some cases, people were using markdown citations, I suspect because the long-form was a bit verbose to inline.  Since the relative path is quite short, I moved these to inline but I wouldn't be opposed to putting them back to citation format if that is desired by the authors.

In doing the migration/cleanup, I found some EIP references to EIPs that don't actually exist.  In these cases I tried to excise the reference from the EIP as best I could.

It is worth noting that the Readme actually already had this rule, it just wasn't expressed properly in EIP-1 and the "Citation Format" section of the readme I think caused people a bit of confusion (when citing externally, you should use the citation format).
2020-09-30 12:22:43 +08:00

148 lines
10 KiB
Markdown
Raw Blame History

---
eip: 1202
title: Voting Standard
author: Zainan Victor Zhou (@xinbenlv), Evan (@evbots), Yin Xu (@yingogobot)
type: Standards Track
category: ERC
status: Draft
created: 2018-07-08
discussions-to: https://github.com/ethereum/EIPs/issues/1202
---
## Simple Summary
Propose a standard interface for voting.
## Abstract
This proposal creates a standard API for implementing voting within smart contract. This standard provides functionalities to voting as well as to view the vote result and set voting status.
## Motivation
Voting is one of the earliest example of EVM programming, and also a key to DAO/organizational governance process. We foresee many DAOs will ultimately need to leverage voting as one of the important part of their governance. By creating a voting standard for smart contract / token, we can have the following benefits
### Benefits
1. Allow general UI and applications to be built on top of a standardized voting to allow more general user to participate, and encourage more DApp and DAO to think about their governance
2. Allow delegate voting / smart contract voting, automatic voting
3. Allow voting results to be recorded on-chain, in a standard way, and allow DAOs and DApps to honor the voting result programmatically.
4. Allow the compatibility with token standard such as [ERC-20](./eip-20.md) or other new standards([EIP-777](./eip-777.md)) and item standard such as [EIP-721](./eip-721.md)
5. Create massive potential for interoperability within Ethereum echo systems and other system.
6. Allow setting voting deadline, allow determine on single or multiple options. Allow requiring voting orders. (trade-off is interface complexity, we might need [ERC-20](./eip-20.md) approach and later a [EIP-777](./eip-777.md) for advanced voting)
7. Recording the voting with weights with token amount.
8. Possibly allow trust-worthy privacy-safe voting and anonymous voting (with either voter address being un-associated with the vote they cast, given a list of randomized/obfuscated voting options).
8
9. Possibly allow result in reward by voting partitipation or voting result
### Use-cases:
1. Determine on issuing new token, issuing more token or issuing sub-token
2. Determine on creating new item under [EIP-721](./eip-721.md)
3. Determine on election on certain person or smart contract to be delegated leader for project or subproject
4. Determine on auditing result ownership allowing migration of smart contract proxy address
## Specifications
```solidity
pragma solidity ^0.5.8;
/**
* - Multiple issue
* - Multiple selection
* - Ordered multiple result
**/
contract ERC1202 {
// Vote with an option. The caller needs to handle success or not
function vote(uint issueId, uint option) public returns (bool success);
function setStatus(uint issueId, bool isOpen) public returns (bool success);
function issueDescription(uint issueId) public view returns (string desc);
function availableOptions(uint issueId) public view returns (uint[] options);
function optionDescription(uint issueId, uint option) public view returns (string desc);
function ballotOf(uint issueId, address addr) public view returns (uint option);
function weightOf(uint issueId, address addr) public view returns (uint weight);
function getStatus(uint issueId) public view returns (bool isOpen);
function weightedVoteCountsOf(uint issueId, uint option) public view returns (uint count);
function topOptions(uint issueId, uint limit) public view returns (uint[] topOptions_);
event OnVote(uint issueId, address indexed _from, uint _value);
event OnStatusChange(uint issueId, bool newIsOpen);
}
```
## Rationale
We made the following design decisions and here are the rationales.
- **Granularity and Anonymity:**: We created a `view` function `ballotOf` primarily making it easier for people to check the vote from certain address. This has the following assumptions:
* It's possible to check someone's vote directly given an address. If implementor don't want to make it so easiy, they can simply reject all calls to this function. We want to make sure that we support both anonymous voting an non-anonymous voting. However since all calls to a smart contract is logged in block history, there is really no secrecy unless done with cryptography tricks. I am not cryptography-savvy enough to comment on the possibility. Please see "Second Feedback Questions 2018" for related topic.
* It's assumes for each individual address, they can only vote for one decision. They can distribute their available voting power into more granular level. If implementor wants allow this, they ask the user to create another wallet address and grant the new address certain power. For example, a token based voting where voting weight is determined by the amount of token held by a voter, a voter who wants to distribute its voting power in two different option(option set) can transfer some of the tokens to the new account and cast the votes from both accounts.
- **Weight**: We assume there are `weight` of votes and can be checked by calling `weightOf(address addr)`, and the weight distribution is either internally determined or determined by constructor. However we have not been considering updating the weight distribution. Please comment on this design decision as we want to learn how likely an implementor would want to be able to update the voting weight distributions.
## Backward Compatibility
There is no backward compatibility issue we are aware of.
## Simple Code Examples
### Example 1: Simplest Version: Single Issue Yes/No Question Per Smart Contract Address Per Non-Weighted Vote
- [Source Code](https://github.com/xinbenlv/eip-1202-draft/blob/master/contracts/simple-version/SimplestVote1202.sol)
- [Deployment (Ropsten)](https://ropsten.etherscan.io/address/0x067e76ddd9c67f7ae606b18d881545512d4b680c#code)
### Example 2: TokenVote with Simple Interface with Weight Assigned by Token and Pre-registered Snapshot of Token-Holders
- [Source Code](https://github.com/xinbenlv/eip-1202-draft/blob/master/contracts/simple-version/TokenVote1202.sol)
- [Deployment (Ropsten)](https://ropsten.etherscan.io/address/0x5bd007a224fe8820b19cc0bce8e241f4752ce74d#code)
### Example 3: TokenVote with Advanced Interface
- [Source Code](https://github.com/xinbenlv/eip-1202-draft/blob/master/contracts/advanced-version/AdvancedTokenVote1202.sol)
- [Deployment (Ropsten)](https://ropsten.etherscan.io/address/0xfd8b3be5f9db4662d1c9269f948345b46e37fd26#code)
## Security Considerations
EIP-1202 is a voting standard. We expect the voting standard to be used in connection with other contracts such as token distributions, conducting actions in consensus or on behalf of an entity, multi-signature wallets, etc.
The major security consideration is to ensure only using the standard interface for performing downstream actions or receiving upstream input (vote casting). We expect future audit tool to be based on standard interfaces.
It's also important to note as discussed in this standard that for the sake of simplicity, EIP-1202 is kept in the very basic form. It can be extended to support many different implementation variations. Such variations might contain different assumptions of the behavior and interpretation of actions. One example would be: What does it mean if someone votes multiple times through `vote`?
- Would that mean the voter is increasing their weight, or
- vote multiple options in the meanwhile, or
- Does the latter vote override the previous vote?
Because of the flexible nature of voting, we expect many subsequent standards need to be created as an extension of EIP-1202. We suggest any extension or implementations of this standard be thoroughly audited before included in large scale or high asset volume applications.
The third consideration is non-trivialness. Some voting applications assume ***anonymity***, ***randomness***, ***time-based deadline***, ***ordering***, etc, these requirements in Ethereum are known to be non-trivial to achieve. We suggest any applications or organizations rely on audited and time-proven shared libraries when these requirements need to be enforced in their applications.
The fourth consideration is potential abuse. When voting is standardized and put on contract, it is possible to write another contract that rewards a voter to vote in a certain way. It creates potential issues of bribery and conflict of interest abuse that is previously hard to implement.
## Bibliography
### Related EIPs
- [EIP-20: ERC-20 Token Standard (a.k.a. ERC-20)](./eip-20.md)
- [EIP-165: Standard Interface Detection](./eip-165.md)
- [EIP-721: Non-Fungible Token Standard(a.k.a. ERC-721)](./eip-721.md)
- [EIP-735: ERC: Claim Holder](https://github.com/ethereum/EIPs/issues/735)
- [EIP-780: ERC: Ethereum Claims Registry](https://github.com/ethereum/EIPs/issues/780)
- [EIP-777: A New Advanced Token Standard](./eip-777.md)
- [EIP-897: ERC DelegateProxy](./eip-897.md)
- [EIP-1155: Crypto Item Standard](./eip-1155.md)
- [EIP-1178: Multi-class Token Standard](./eip-1178.md)
- [EIP-1167: Minimal Proxy Contract](./eip-1167.md)
- [EIP-1203: Multi-class Token Standard(ERC-20 Extension)](./eip-1203.md)
### Worthnoting Projects
- [Ethereum DAO: How to build a DEMOCRACY on the blockchain](https://www.ethereum.org/dao)
- [Carbon Vote](http://carbonvote.com/)
- [Paper: A Smart Contract for Boardroom Voting with Maximum Voter Privacy](https://eprint.iacr.org/2017/110.pdf) - *Suggested by @aodhgan*
- [Private Voting for TCR](https://blog.enigma.co/private-voting-for-tcrs-with-enigma-b441b5d4fa7b)
- [Consensus/PLCR implementation](https://github.com/ConsenSys/PLCRVoting)
- [Aragon Voting App](https://wiki.aragon.org/dev/apps/voting/)
## Acknowledgement
We appreciate Ansley, Andrew, Fred from Enigma, Fan and Raullen from IoTex for sharing us their use cases. we also appreciate the valuable input for designing an EIP from distinguished community members including: @frozeman, @fulldecent, @bingen, @aodhgan.
## Work Directory
The drafting and revision of EIP-1202 is conducted at [GitHub/xinbenlv/eip-1202](https://github.com/xinbenlv/eip-1202)
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
Reference in New Issue View Git Blame Copy Permalink