Reputation Voting

[kronosapiens]

Closes #80
Closes #81
Closes #82
Closes #83
Closes #84
Closes #85
Closes #86
Closes #87
Closes #88
Closes #89

Depends on #757, #760, #771, #845

Implementation references:

https://blog.colony.io/towards-better-ethereum-voting-protocols-7e54cb5a0119/
https://blog.colony.io/token-weighted-voting-implementation-part-1-72f836b5423b/
https://blog.colony.io/token-weighted-voting-implementation-part-2-13e490fe1b8a/

Initially I started working on both reputation and token weighted voting, but token voting ended up requiring some more problem-solving w.r.t. managing vote secrets and communicating with the token locking contract, so in the spirit of hitting OKRs it's going to wait until QX.

Features

• Creating new binary polls
• Reputation voting rate & reveal
• Defining the actions votes will determine 💪
• Poll lifecycle management
• Tests w/ 100% code coverage for new contracts 🎉
• Vote power thresholds
• Staking / spam prevention
• Stake redistribution
• Events
• Handle voter compensation (& any unpaid surplus)
• Escalation flow
• Arbitrary targets

Design choices:

• Actions are defined as bytes arrays and invoked using the call opcode pointed at the colony. An optional target allows for transactions to be executed against any contract, not just the colony.

• Two classes of poll -- rootPoll and domainPoll. Root polls accept arbitrary bytes32 which can be executed by the extensions -- the simpler and more powerful implementation, with the limitation what all polls go to the entirety of the colony. Domain polls, on the other hand, can be held at, you guessed it, any domain in the colony, and can execute authDomain-ed functions only. Domain polls infer the "domain of action" by parsing the bytes32 action directly -- leveraging our convenient convention that the first two arguments of any domain-level permissioned function is (permissionDomainId, childSkillIndex), which means we can uniquely infer the domain from the action. With the domain of action, we can check that the domain of vote is in the inheritance hierarchy.

• Escalation is implemented very simply as the requirement that new votes over the same variable have more "vote power" (total reputation) voting on it. Since (domain) reputation always aggregates up the tree, this has the nice property of allowing "escalation" to be either a re-vote in the original domain with higher turnout, or a vote in a parent domain, which by definition has more reputation in total. This requirement is restricted to votes on the setExpenditureState function, which is the general-purpose arbitration state change function (see Arbitration State Changes #760).

• Staking occurs using the new stake-management system (see Add support for stake management #757).

• One thing I am quite happy about is how the rate/reveal flow eliminates the need for a hasVoted mapping. A user can update their secret as many times as they want during the voting period, but since the secret can only be revealed once, there's no way to double-vote.

• Stakers can stake on both sides if they choose. It is unlikely they will, of course, but the point is that it is not explicitly restricted.

• Winning stakers get their entire stake back, plus a proportion of the loser's stake. Losing stakers pay the voter fees, and then get a proportion of their stake back. The proportion is a function of how close the vote was (e.g. winning with 60% of the vote gets you 20% of the losing side's stake, 120 - 100 = 20).

• Any unspent voter compensation is returned back to stakers proportional to their contribution.