-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MvP Elections extension #439
Comments
Steps:
|
@ethanfrey Some questions came up during design phase:
{
"governance":{
"electorate": [],
"rules":[]
}
} WDYT? |
@alpe Good questions. Many of these will be refined over various issues, but let's get a good start.
Great idea.
Yes, it should be a duration. Resolution in hours is good.
No opinion here. 255 is okay. so is 2^16-1. If you have no strong opinion, let's do 65535
Both are available in the transaction, but yeah, they will likely be needed often by the client. Sure, add the author (Address) and created_at (from the block_header)
List non-expired proposals... open to yet-to-be-started.
Proposed format seems fine to group all the different elements. |
@alpe I thought a bit more on testing, and I think we will make quite a few breaking API changes in the next few weeks. Until we have a clear final design, let's just stick with module level tests, and not integrate it with bnsd or bcpd. That means no scenario/unit tests. We add them once we know what the final design is, so as not to waste time testing apis that will change 3 times in 3 weeks. Let's just stick with happy path and major error cases (cannot vote before start, cannot vote after end, cannot tally before end, cannot vote twice, etc..) don't spend time covering everything or validation logic yet. |
For the model validation I would need some concrete rules. This includes the following:
I have added some to https://github.com/iov-one/weave/pull/462/files#diff-564f72cccc6d5b2346f4b14a8cf2793c as a proposal |
I added feedback on the above as PR comments. |
I implement the votes as the first message to address the count updates. Simplest solution that comes into my mind to move the passed flag to the proposal type, so that we can collect vote counts in the result model instead. This would make it an intermediate result until the voting period has ended. |
Is your feature request related to a problem? Please describe.
In #419 we define an elections extension we need for on-chain governance, given hacking this off chain using multi-sig is not viable.
Describe the solution you'd like
We define a super minimal elections process with only "text proposals", which provide proof of agreement, but don't trigger any on-chain action. For this, I see three basic components, which we can extend later for more functionality: Electorate, Election Rules, and Proposal.
Electorate
defines who may vote in an election. This same group will be used in many elections and we should store it for re-use. It can be of the form of[]multisig.Participant
or similar data, containing addresses and weights for each participant.Election Rules
defines how an election is run. A proposal must be voted upon via a pre-defined ruleset (majority of the senate, 60% of all residents of foo city, etc.). This also includes election length. Here are the basic fields to start with now.Proposal
can currently be created by anyone and triggers an election (we will have to refine this quite a bit later). eg. we will need a type field, and text is only present for text proposals. Control who can create a proposal, and which election rules can be used.Initialization
For this first round, electorate and election rules are set in the genesis file with Initializers. We do not yet support creating them with Transactions.
Transactions
CreateProposal
will create a new proposal, must have validate reference to election rulesVote(proposal_id, decision)
will vote yes/no/abstain for a given proposal. It will first check:Tally(proposal_id)
can only be executed after the election period is over and will update the proposal in the store with:We assume the election rules and electorate are fixed and cannot change during the course of a running election.
Tally stores information on chain for reference (what was the vote), as well as a passed boolean that is based on the threshold from the rules, so we can filter for passed proposals. In a future iteration, this "passed" flag may trigger an automatic action.
Also, we may consider automatic vote tallying at the end of the period, but that is a different story, let's get the basic pieces together here.
Note: there is request for Acceptance Tests on this. Please add to
bcpd
application then (not bnsd) as this is quite experimental and internal format may/will change without warning. (TODO: future issue)The text was updated successfully, but these errors were encountered: