A suggestion for a long-term solution of governance proposal spam

Hi Dfinity family.

I’ve been in blockchain for a while but just recently joined the Dfinity forum & start playing around with NNS. I have to admit that I am very impressed with the discussions in this forum (and think Dfinity and its community will have a bright future based on what I’m observing here).

At present, I’m very interested in the discussion on “a long-term solution to resolve the governance proposal spam”.

On the one hand, like many of you, I’m very annoyed by these spammed proposals (and fully understand the financial incentives of doing so). I strongly believe that this hurts the eco-system, the dev team, and people of this community who are actively engaging in governance.

On the other hand, I believe the temporary fix to change the governance voting reward weight back to 1 (which was discussed here and passed recently), even though stated as “temporary”, is a huge mistake. Participation in governance is supposed to be the most serious duty & right of those who really care about the IC network and its future. So naturally, voting reward for governance proposal should take a significantly higher weight. By reducing its weight back to 1, the message is loud and clear: we don’t care much about this issue (while still spending time & resource to implement solutions to resolve/avoid tax matters, another issue that I feel strongly against but irrelevant to this discussion).

So I’m just thinking about if the following solution can work:

  1. Set a high voting reward weight for governance proposal (20 as it’s used to be or even higher).
    This is to ensure that governance participation is highly rewarded (which is just a no-brainer IMHO).
  2. Set a limit for the number of governance proposal a neuron can submit/propose (e.g. once a day).
    This is to ensure that a neuron can’t spam several governance proposals within a short period of time (one day in this case). Apparently, people still can by-pass this by using multiple neurons (which let to point (3)).
  3. Set a “time-out” time for each neuron whenever one of its submitted governance proposals is rejected by super-majority (or approved by super-minority).
    For example, a neuron will not be able to submit its next governance proposal in the next 3-day period after one of its submitted governance proposals is rejected by X% of voters (where X is the super-majority level to be decided by the community) or approved by, less say, only 1% of voters.
    This is to ensure that a neuron can’t just put forward a not-so-well-thought governance proposal. I believe that, for any well-thought governance proposal, even though it is eventually rejected, it will still gain enough support from the community to escape that “super-minority approval” level.

One last thing, what I’m proposing here is actually not new and has been widely applied at both government and corporate levels.

Governance is a serious matter for the long-term health and growth of a network. So I really hope that Dfinity & our community can take a much more serious approach and resolve it sooner rather than later.

Thank you for reading this & look forward to your feedback & discussion.

Edited: updated point (3) from “its submitted proposal” to “one of its submitted governance proposals”. Thanks.

4 Likes

Welcome to the community, and thanks for your thoughts on this issue.

The higher the voting rewards for a specific topic, the higher the financial incentive to spam that topic. This issue only exists because governance followees were split from the rest of followees earlier this year.

Creating a neuron is very inexpensive. If I were the spammer (and making over 1k ICP/month from spamming), then I would just create tens or hundreds of neurons and rotate through them for each proposal depending on the cooldown.

I would also recommend looking at this post for some recent context on prioritizing the implementation of 55651, which would boost rewards for active participants. Proposal to Prioritize 55651 (Periodic Confirmation) & 38985 (Manual Voting) over 48623 (Compounding Maturity)

as well as this comment,

Arguably votes on updating the replica (code) are even more important than the governance votes. The more I think about this the less it makes sense to boost rewards for votes on the governance topic.

2 Likes

How do you vote on a replica update? Do you read the code, understand it all, and then make a clear decision to vote Yes or No on the replica update?
I presume you understand what I mean.

I currently just follow DFINITY like everyone else. I don’t think it makes sense for everyone to need to understand the code changes - that would take a considerable amount of time, and be terribly inefficient. Ideally the community will have some input going forward in the future, but who knows how that will end up working out.