The following is a comprehensive proposal that aims to:
- Reduce the Inflation given out as NNS rewards
- Reduce the visibility of offensive/attention/in-actionable proposals in the NNS
- Eliminate the financial incentive for spam proposals while maintaining the ability to weight proposals to incentives participation.
Action 1. Convert from a system-based rewards model to a voter-based reward model.
The current system determines a reward rate, total supply, and then determines the total reward to give each day by multiplying the (reward rate * the total_supply)/day. The total rewards are then handed out based on each neuron’s share of the total voting weight for the day.
The new system will determine the reward rate and multiply the rate by the weighted vote-completion percentage and bonus rate of each voting neuron.
A result of this proposal will be the reduction in total inflation of ICP due to the fact that some voters do no vote on all proposals or follow a voter for all proposals. The following illustration shows the handing out of rewards in the old vs new system.
Spam is neutralized because additional proposals will not affect the ability of a neuron to gain rewards. Any neuron’s maximum reward for the day is generated by Reward Rate *(Actual Vote Weight/Possible Vote Weight) * Age Bonus. Adding extra, superfluous heavy weighted votes only increase the Possible Vote denominator and thus does not increase the number of rewards handed out in a day.
Weights can remain in the calculations to encourage participation due to the fact that each voter is only competing against themselves to achieve 100% voting for the day.
This scheme can be easily implemented in the existing code by manipulating the distribute_rewards function to iterate over all considered_proposals, finding the weight of each proposal and creating a target sum. Instead of creating a map of voters_to_used_voting_rights, the map will also need to keep track of each vote’s absolute weight. The reward function on ic/governance.rs at 73983e05ebbab239ce39492a05fb39a83ce5dce5 · dfinity/ic · GitHub will need to be adjusted to be used_voting_rights * (total absolute vote weight/target vote weight). The used_voting_rights has the age and lock bonuses built in. (Note - The reward function is mapping twice as much data, so performance may be an issue here).
A worked example:
4 proposals are eligible for rewards on a day. The reward rate is 15%.
Proposal 1 - XDR Exchange Rate - Weight 0.01
Proposal 2 - Subnet management - Weight 1
Proposal 3 - Node Rewards - Weight 1
Proposal 4 - Governance Proposal - Weight 20
Total Possible Vote weight: 22.01.
Voter 1 - Passive whale votes with 10,000 voting reward on proposals 1-3. Total executed weight is 2.01. Thus the reward is 10,000 * (.15/365) *(2.01/22.01 = 0.3752 ICP(~1.3%)
Voter 2 - Active holder votes with 100 voting reward on proposals 1-4. Total executed weight is 22.01. Thus the reward is 100 * (.15/365) *(22.01/22.01 = 0.041 ICP (~15%)
Action 2 - Restrict reward qualification to a Threshold and implement an “accept quorum” for proposals.
This proposal was previously discussed at Proposal to restrict rewards qualification to a threshold - #43 by skilesare?
It was not voted on because it was pointed out that whales may purposely vote yes on a proposal to get it past the quorum. Since Action 1 eliminates this incentive it is repurposed to implement this solution quickly while other more involved and complex proposals are considered. It only requires changes to a few lines of code. It achieves much of the desired outcome of Multi-stage Governance Proposals, Starting w/ Stage 0 and Stage 1 and [Proposal] Introduce an incubation period and minimum support threshold for governance proposals but without increased complexity:
Objectives:
- Decrease incentives to submit attention/offensive spam governance proposals
- Protect the NNS from censorship, and preserve the current accessibility of submitting NNS governance proposals (i.e. does not increase the cost or difficulty of submitting an NNS proposal).
- Allow NNS voters to ignore spam
Note : In this post, all references to “proposal” refer to all proposals, those could be restricted to governance proposals, but I don’t think that is necessary.
Solution
Update the NNS canister to skip rewarding proposals that have not received at least the Minimum threshold of Yes votes required to pass threshold of Yes votes(currently 3%).
Update the NNS canister to extend the end date to match the initial voting period when the proposal passes threshold of Yes votes required to pass Yes vote proposal.
Implementation for Proposed Solution
After line 6027( https: //github.com/dfinity/ic/blob/79bbd3177f6532037eb29d62b3e52a364a8103ee/rs/nns/governance/src/governance.rs#L6027 ) add the equivalent Rust code to the pseudocode below:
if( proposal.tally.yes/proposal.tally.total < MIN_NUMBER_VOTES_FOR_PROPOSAL_RATIO){continue;}
After line 5274(ic/governance.rs at 35acac6c1113a23e2cb92329f1431c5254567e6e · dfinity/ic · GitHub) add the equivalent Rust code to the pseudo code below:
let oldYesRatio = proposal.tally.yes / proposal.tally.total;
After line 5284(ic/governance.rs at 35acac6c1113a23e2cb92329f1431c5254567e6e · dfinity/ic · GitHub) add the equivalent Rust code to the pseudo code below:
if (proposal.tally.yes / proposal.tally.total >= {MIN_YES_THRESHOLD} and oldYesRatio < {MIN_YES_THRESHOLD}){proposal.deadline_timestamp_seconds = deadline_timestamp_seconds + (now() - proposal.proposal_time_stamp_seonds);
This proposal is put forward to complement https: //forum.dfinity.org/t/proposal-introduce-an-incubation-period-and-minimum-support-threshold-for-governance-proposals/12220/14 which is a longer-term solution. This implementation could be created much more quickly.
Action 3. Reduce the ICP proposal Rejection cost back to 1.
This proposal moves the Rejection cost back to 1 ICP so that almost everyone can afford to participate in submitting proposals to the NNS without undue fear of rejection.
Action 4. Affirm the utility of passive voting in a liquid democracy.
Finally, this proposal affirms the following patterns for consideration in future proposals:
- Active voting has a negative utility for the network when voters who do not understand a proposal vote on it manually.
- Passive assignment has positive utility for the network when voters assign their votes to knowledgeable and active voters.
- Short-term network security depends on maximum participation in non-governance topics and thus resetting of neuron following has a negative utility on the network.
- Zombie neurons have a negative long-term effect on the network and thus some consideration should be given to auto-starting dissolving neurons after a certain period with no activity. For example, if a neuron does not vote, change followees, merge maturity, spawn a neuron, or take some other proactive action, it will begin to dissolve after 1 year of inactivity.
- Decentralization of the network has long-term positive utility and thus a system for measuring the diversification and overall voting power of a Neuron’s followee’s should be explored and the network should consider reward bonuses or restrictions on neurons that over-centralize their neuron following graph.