Feature Request: Granular NNS Voting

[EnzoPlayer0ne]

NNS feature request: allow neurons to vote granularly.

In a previous thread, @infu raised a valid point regarding WaterNeuron’s way of casting vote. Let me re-explain the overall idea here.

For the sake of our example the WTN DAO has 1% of the VP on the NNS. Imagine a scenario where everyone has voted on the network expect WaterNeuron, resulting in a close race where the tally stands at 49.9% for the yes and 49.1% for the no.

At the WTN level, the vote is not tight, the no wins with 80% and the yes looses out with 20%. With the current set-up, the whole of WaterNeuron staked ICP votes yes. Which means 1% of the NNS VP votes no, which puts the no at 50.1% and the yes at 49.9%.

However this does not correctly represent the outcome at the WaterNeuron level, if we had more granularity the vote would have ended up differently. If the DAO had casted 20% of its VP in the yes, and 80% in the no. The final tally would be 50.1% for the yes and 49.9% for the no.

A possible fix (as @infu suggested) is to split the neurons into x chunks and have each neuron trigger whenever a proposal reaches a certain threshold. However managing a large fleet of neurons is impractical, and does not scale as WaterNeuron grows, given NNS neurons cannot be merged together.

I propose a better feature, which would benefit the entire IC not just WaterNeuron, is to split the VP of each neurons. Users should be able to cast VP cast 20% of their VP to yes, and 80% to no. cc @lara @aterga

[skilesare]

I’m sorry…I couldn’t resist.

But also, this is a feature you only need when and if canisters can control neurons. We are currently in the experimental phase of that and it will be considered when/if too much VP is acquired(this is a nice resolution if the vp is honored by the neuron aggregator…it becomes a kind of no-op..but it also seems a bit illogical…but it als solves the abstain question rather nicely. Just 50/50 it…maybe I like it)

[marcio]

Seers would likely use this feature if implemented, so we’re in favor of it.

[Lorimer]

@borovan

The whole point about changing WaterNeuron is to make it so that people’s VP aren’t taken by a group of insiders, which is currently the case.

At least one of the challenges is that followers are too inclined to follow brands that they recognise, even when that neuron isn’t actually the one reviewing the proposals.

Expand dear reader, if you're willing to indulge some context

There are a handful of WTN neurons that advertise themselves for following. I’m one of them.

Unfortunately decentralisation efforts are easily dashed when you have an already super popular neuron intentionally engulfing other known neurons.

^ This, despite the stark contrast to Wenzel’s much earlier comments (back when I was a member of CodeGov).

---

Unfortunately some known neurons are in favour of ‘decentralisation’ only in so far as it’s an argument that can be used to help them acquire a larger following. Wenzel has also heavily attacked efforts to help decentralise WaterNeuron, again, in a way that is in stark contrast to the way he manages his own neuron (CodeGov).

[wpb]

@Lorimer

Expand dear reader, if you’re willing to indulge some context

Perhaps you should be truthful when you provide context. It’s important to snip the entire explanation instead of cherry picking a fragment that supports your false narrative…

Your beloved D-QUORUM neuron follows CodeGov on several proposals topics, yet you never asked for permission. Both your D-QUORUM and your CO.DELTA neurons follow DFINITY on many topics, yet you never asked permission. Why did you not ask permission? Because you don’t have to and you shouldn’t need to. You know they are reliable and you are trying to achieve a design philosophy for how you want each of those neurons configured. More power to you. Stop falsifying the design intent and control strategy of other known neurons when you do the exact same thing yourself. It’s called liquid democracy and we are all entitled to choose who we follow for whatever reason we choose to follow them. At least I clearly describe my design philosophy on our codegov.org website. Your strategy is to mislead the community in multiple ways on how D-QUORUM is configured. D-QUORUM WTN neuron is following the WTN team on every single topic and has been bricked so it can never be changed, yet you want to call it an SNS controlled neuron that represents the will of the SNS. The D-QUORUM NNS known neuron has the NNS governance canister configured as a controller, and yet it’s impossible for the NNS to actually control the neuron. You would rather lead people to think that D-QUORUM represents the will of the NNS when in reality D-QUORUM represents the will of the 15 people that you configured as Followees for the Neuron Management proposal topic. Talk about false narratives…you need to look at yourself in the mirror and stop kidding yourself.

[Lorimer]

You can’t see past your own spin.

Expand dear reader, if you don't mind reading

1. D-QUORUM is not controlled by an individual (unlike CodeGov, in fact it’s the very antithesis).
   • The controller for D-QUORUM neurons is the DAO itself that the neuron operates within (facilitating representative democracy)
   • The whole point of a D-QUORUM neuron is to address the weakness that a neuron like CodeGov can market itself as a decentralised group and garner a huge following, while actually all the VP is being accumulated by an individual who can do with it as they please (under ‘trust me bro’ pretences).
   • When D-QUORUM follows another neuron, it does not represent an individual wrapping themselves around that neuron and engulfing it for their own gain

If you prefer pictures to words

2. The fact that the WTN D-QUORUM neuron isn’t yet configurable by the DAO has been heavily influenced by your attempts to kill the initiative.

   • The WTN D-QUORUM neuron doesn’t follow CodeGov in its initial configuration (you may recall that you asked for it not to)

3. I (nor nobody else) stands to gain or hoard power via D-QUORUM, while you stand to lose power, which is why you’re attacking it voraciously.

4. My post above is pointing out your recurring hypocrisy, where you frequently say one thing when it suits you, then say another thing when it suits you. Here’s another example of that.

[lara]

Hi Enzo and others,

such a change would make the governance code more complex and, maybe even more importantly, make it harder for users to understand how governance works. Let me try to make this more concrete:

• Currently, a ballot represents a yes/no choice from one neuron that represents one governance participant / voter. This is similar to a ballot in real live. Adding a percentage vote would make this concept much harder to understand for users. For example, it could be unclear what it means if a neuron votes “60% yes” vs. a neuron voting “70% yes” or “fully yes”. It is also unclear what it would meant to vote 50% yes and basically abstain - something that can be discussed but is not considered in the current design and might have unexpected effects to incentives.
• The effects on the overall governance design are unclear. Especially, it is unclear how vote delegation / following would work. If a neuron voted a certain percentage yes, would its follower vote the same percentage? If a neurons follows multiple other neurons, how would the neuron vote? Of course all of this could be defined, but this again adds further complexity and makes it harder for users to understand the already complex delegation / following mechanism and how to best choose their settings.

In general, we think it is great that different teams are trying out new ways of voting and interacting with governance.
However, we think such things should, as much as possible, be implemented in code outside the core governance canister.

1. This ensures that the governance code does not have unnecessary complexity. Often new special cases are the cause for bugs.
2. This keeps the main governance functionality simpler - which is a prerequisite for users to understand and trust the governance system. I think we sometimes underestimate how complex our governance already is and should aim to make it simpler rather than more complex.

[marcio]

It could be made opaque to any non-canister-owned neuron, so I don’t think it would meaningfully affect regular users. That said, the added code complexity is a valid reason to avoid implementing it. On the upside, with the rise of AI, this kind of need might become more common.

[infu]

NNS change will also break all apps, scripts, canisters currently querying it. All of them will need to be changed. NNS is governing everything and such change will need long expensive audits. It will take a lot of time. Feels like asking for the mountain to go to Muhammad. Change in WTN voting system could get things to work in a week or two and won’t be breaking anything.

[1eo]

Hey Lara, thanks for giving more context, I agree that this change might introduce more complexity to the governance canister, which is already complex enough as it is.

[icme]

Hey @EnzoPlayer0ne and @1eo, have you considered a binary representation of neuron weights?

It is definitely more complex, but you can represent all fixed % distributions (no decimals) of voting power between 0 and 100 with just 7 neurons, of weights 1, 2, 4, 8, 16, 32, and 37.

The first 6 neurons (1, 2, 4, 8, 16, 32) are powers of 2, which let you represent any number from 1 to 63 via binary combinations, and then 37 rounds things out to be able to reach 100.

Likewise, if you wanted to add a decimal of precision (i.e. 0.1% or 99.9%), it would take just 10 neurons.

The 8 year and 6 month (soon 3 month?) dynamic complicate this a bit, so you might end up needing to split both the 8 year and x month neuron both into 7 (14 neurons total?). The good news though is that the maturity minted from each would follow similar logic and keep everything in proportion. New deposits and withdrawals complicate this a bit, but those problems seem solvable.

I definitely empathize with how simple and clean the current design for WTN is, but thought I’d offer this suggestion in the context of providing a more granular voting abstraction.

[Lorimer]

This is an interesting idea. Certainly seems like an elegant way of getting more granularity out of fewer neurons.

I would add that I think the 8yr neuron’s VP is actually tiny in terms of its stake (it gets its VP mostly from followers as it’s a popular known neuron). The 8yr stake is not going to significantly grow in the future (unlike the 6mo neuron). The 6mo neuron is where the vast majority of WaterNeurons direct VP will come from as is grows (ignoring follower-based VP, but people will follow who they follow).

I personally don’t see any advantage to touching the 8yr neuron. I would suggest keeping it voting in line with the majority (there’s not really anything else it can do, without creating a sea of WaterNeuron known neurons).

I think the 6mo neuron is the only sensible target for achieving better proportional representation on the NNS. In fact, you could factor in the VP of the 8yr neuron when establishing how the 6mo neurons should vote (to achieve the most proportional yes/no outcome on the NNS, based on the SNS outcome).

[infu]

To get that precision, WTN has to cast votes once at the end of the voting period.
With more neurons, it can cast votes more often, also withdrawals wont be a problem.

@Lorimer Why is there a need for people to be following a liquid staking protocol neuron? It hasn’t defined what it stands for and nobody knows who is in control publicly.

[Lorimer]

@infu

Why is there a need for people to be following a liquid staking protocol neuron?

Could this same question not be posed to OpenChat, or TAGGR, or any other dapp that allows its userbase to vote on NNS proposals from the dapp?

It makes the most sense for WaterNeuron, given that it can’t accrue the rewards that drive the liquid staking protocol without voting.

It may not be obvious, but I’m in favour of what you’ve suggested. I think to achieve the proportional representation you’re after, the VP of the 8yr neuron would need to be offset against how the 6mo neuron(s) vote. However the VP of the 8yr neuron varies by topic, and it’s not actually possible to gauge exactly how much VP it will trigger until it triggers it. Do you have suggestions for how to tackle this?

[Lorimer]

Having thought about this further I think it’s useful to decouple the problems we’re trying to address.

Follower-based VP

Follower-based VP is a separate concern, and there are all sorts of solutions to this which sit outside of WaterNeuron itself. More and better quality governance participants for followers to follow is the solution with regard to any potential for centralisation in this respect. Better visibility of how much follower-based VP known neurons already have is another way to significantly improve matters here. There’s another thread discussing that.

Direct VP

Direct VP (based on stake) is what WaterNeuron can actually orchestrate and manage (if followers want to follow WaterNeuron’s prevailing vote that’s their choice, they just need more other good options if this is seen as an issue at this stage).

Known Neuron

WaterNeuron’s known neuron is the 8yr neuron, which actually have very little direct VP (roughly 0.1% I think). It’s also not going to change much. I think it’s sensible to leave the known neuron out of this, and allow it to represent a beacon for followers who wish to follow WaterNeuron’s prevailing vote. This significantly simplifies things without really weakening the proposed solution.

6mo Neuron (the guts of the protocol, where there’s room for improvement)

The 6mo neuron is where WaterNeuron’s VP will keep growing, and this is the neuron that could represent a danger to the NNS in the future (if you’re to assume a bad actor gains 51% control of the WTN DAO).

I think as soon as the 6mo neuron’s stake is roughly equivalent to 0.1% of NNS VP, is would be desirable to consider this neuron ‘cold’ and then create a new ‘hot’ 6mo neuron. Once this neuron reaches 0.1%, the same action is taken again (now 2 cold neurons, and 1 hot neuron), and so on. This allows the VP to become more and more granular as the overall VP grows. Not only does this allow direct VP to be cast in a more granular manner that better represents the WTN community on the NNS, it also allows for a nice age bonus optimisation that I proposed back in January (basically there are a whole host of benefits to doing what @infu has suggested).

Age Bonus Optimisation

Copied from Telegram comments I posted earlier this year

The idea would be to allow the protocol to get much much closer to the max age bonus, as well as growing the age bonus more quickly. The idea starts with the observation that if I stake 10 ICP now (to mint nICP) I just contributed an ICP stake with a 0 age (bringing down the average for the whole neuron). This entitles me to unstake that ICP, but when I do that I’ve taken ICP that actually has a much higher age bonus.

If instead the protocol were able to preferentially dip into staked ICP with a lower age bonus (much closer to the age I had contributed), the bulk of ICP in the protocol can just keep aging with minimal disruption

The idea is basically that rather than having one 6mo neuron, the protocol could have several that are managed using a simple algorithm.

There would always be one hot neuron, and zero or more cold neurons (terminology derived from hot and cold storage when archiving data)

In the background, the oldest cold neurons are unlikely to need touching. Once the oldest one reaches 4 years old (and max age bonus), the next oldest will start catching up with it.

[Basically,] If you segregate your 6mo neuron stakes by age (keeping the oldest together and the youngest together), when someone unstakes you can service their request using the younger ICP

By doing that you actually increase the average age for all 6mo neurons (because the amount of younger ICP has shrunk relative to the amount of older ICP)

At the moment the distinction isn’t drawn, so there’s nothing to negate the age bonus erosion that occurs when you stake. Unstaking doesn’t currently increase the age bonus, but there’s no reason that it can’t

Unstaking can partially negate the age bonus erosion of staking if we design it that way (implementation-wise)

Most importantly there would be no change to how users perceive or interact with the protocol, other than APY that tends to be better than the NNS (6mo-neuron-wise), even in the long term!

Related comments about the security benefits of doing this sort of thing (the very good point that @infu is making).