Continuing the discussion from Proposal to restrict rewards qualification to a threshold:
Now that we’ve handled incentivized spam, I’m re-proposing this as a quick fix for advertising spam.
I’ve adjusted the percentage down from 3% to 1%. Thanks to @Kyle_Langham 's analysis we think that 0.5% would be safe, but I haven’t gone that low…we can debate the exact number.
We can also discuss if we want the check box to default to checked to hide items that have not qualified for rewards. I think it makes it more powerful and it is hard to argue that a check mark is a huge “gate”. Anyone who wants to be a power user can be by unchecking the box.
Motion Text:
Objectives
-
Decrease incentives to submit 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).
-
Protect NNS voters from advertising or grief governance proposal 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 dApp to not show proposals that have not at least met the 1%(or modified) threshold of Accept votes required to pass unless a user chooses to unhide them.
-
Update the NNS canister to skip rewarding proposals that have not received at least 1%(or modified) threshold of Accept votes.
-
Update the NNS canister to extend the end date to match the initial voting period when the proposal passes the 1%(or modified) Accept vote proposal.
-
Proposals that do not meet the Accept threshold will still have their ICP burned as a reject fee.
Implementation for Proposed Solution
**Note: The NNS dapp has been re-written since the original text was created so the NNS App line source has likely changed, but the concept translates directly to the new app.
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 >= 0.3 and oldYesRatio < 0.3){proposal. deadline_timestamp_seconds = deadline_timestamp_seconds + (now() - proposal.proposal_time_stamp_seonds);
After line 158(nns-dapp/Proposals.svelte at e9dd304d8aaa96f82e91936f23d1bf0c781ae9c5 · dfinity/nns-dapp · GitHub), wrap line 159 in:
{if proposalInfo.tally.yes/ [propsalInfo.tally.no](http://propsalInfo.tally.no) < ($UserConfiguredMinYesThreshold | 0.3)}
Line 159
{/if}
The NNS front app team will need to add a widget to allow for changing the UserConfiguredMinYesThreshold and storing the preferred value in webStorage.
How does this affects me as an NNS voter?
-
Voters have no obligation to vote on a proposal(and will not miss out on rewards) until it reaches a 1% threshold of yes votes.
-
Once the 1% yes threshold is reached, voters should vote or follow a voter to claim rewards(No change)
Why this proposal works
-
NNS Participants only view and vote on spam proposals because they are required to. Not voting results in lost governance rewards, which are then directly split amongst those who do vote on the spam proposal. Introducing an incubation period and minimum support threshold removes the requirement to view and vote on each and every proposal that hits the NNS.
-
Since NNS Voters are no longer required to vote for proposals that can’t meet the threshold, each proposal must reach the 1% yes minimum support threshold on its own merits and value proposition in order to receive attention from the whole community.
-
This proposal does not increase the proposal creation or rejection cost, and therefore does not impose a greater financial burden on NNS Proposal Creators.
-
Extending the time period at the point of crossing the 1% threshold keeps the consideration time the same.
Additional Benefits of this proposal
-
Adding a minimum support threshold allows governance proposals to be visible on the NNS for a longer period of time, ensuring that less active NNS voters have the opportunity to vote for incubated proposals they support.
-
Adding a minimum support threshold encourages NNS proposal creators to advertise, receive feedback, and iterate upon their proposals before submitting in order to ensure they will pass the 1% support threshold and proceed to a live vote on the NNS.
NNS App UI Changes
-
Add a checkbox to allow power users to unhide the proposals that have not met the threshold.
-
Make sure a proposer create can hotlink directly to a vote so they have something to use when they promote their proposal.(I think you can already do this…ie Internet Computer Content Validation Bootstrap, but if you are not authorized you lose your redirect…I think this is an easy fix)
Arguments Against/Potential Issues
- This will not stop the current spammer from submitting NNS Proposals.
Rebuttal to (1) : Looking at one of the recent spam proposals by @ysyms, Internet Computer Network Status, we can see that only 0.2% of the total voting power is voting to accept these NNS proposals. This means that this would never be shown to most people, the vote would fail and the spammer would be charged their 10 ICP. It would not affect rewards
Keep in mind that even for some of the spam NNS proposals that garnered more than 1% of the vote, many of these votes were novelty votes that were only cast because the item was visible. If the proposer had been forced to garner social momentum they likely would not have reached the threshold
- It may be possible that more than 1% of the overall NNS voting power would be interested in advertising spam proposals for financial benefit.
Rebuttal to (2) : If more than 1% of the overall NNS voting power support a spam attack, increasing the proposal cost would have little to no effect. The solution to this would be another proposal that further raise the minimum support threshold for governance proposals.
- As an NNS Proposal submitter, I feel like this minimum support threshold places an additional financial burden on me to submit proposals to the NNS.
Rebuttal to (3) : The proposed solution does not change proposal submission costs for NNS creators. In fact, after this proposal goes live we could lower the proposal cost back to 1 ICP. If someone is submitting a proposal that they do not feel will receive the minimum support threshold by a voluntary vote, then they should advertise their proposal and timeline on the forums and social media (Twitter, DSCVR, Distrikt) to garner the necessary support before submitting a proposal to the NNS. If a proposal cannot reach 1% voluntary support, it’s unlikely that proposal will achieve a majority of voting power and pass when it goes live.
- This is gatekeeping and keeps out NNS proposers that do not have popular support or a network with which to reach the 1% threshold.
Rebuttal to (4) : It is likely important to keep the threshold as low as possible such that it is still effective against spam. This proposal does increase the risk to un-networked proposers that they may lose their proposal stake without their proposal being considered. We would argue that this risk is not insurmountable and that any good faith proposal should be vetted with the community to an extent that it can garner at least the minimum before it is submitted. In short, this proposal does create a low hurdle, but one which is likely a net gain for everyone in the system. Given that time and resources are not unlimited forcing well-thought-out and minimally supported proposals makes governance possible as activity and interest increase.
Vote Accept to:
- Update the NNS dApp to not show proposals that have not at least met the 1%(or modified) threshold of Accept votes required to pass unless a user chooses to unhide them.
- Update the NNS canister to skip rewarding proposals that have not received at least 1%(or modified) threshold of Accept votes.
- Update the NNS canister to extend the end date to match the initial voting period when the proposal passes the 1%(or modified) Accept vote proposal.
- Proposals that do not meet the Accept threshold will still have their ICP burned as a reject fee.
will vote no and it won’t pass the threshold and reach its audience. The likely hood of the spam being produced and the execution of the mechanism occurring is drastically reduced because the mechanism exists.
