Improve nakamoto coefficient

[Reecepbcups]

For later development

per Jake's Commonwealth Thread

Easiest actual technical implementation is to do it as a Tax so we don't have to deal with Inflation parameter changes. Osmosis is super into this as well, idea is to do it as a custom EndBlocker tax

So tax rank 1 Validator more than rank 150, thus 150 has a higher APR

Allow changes via Gov to tweak rates / formula for the tax amounts as that is all game theory work

Goal:
get CoEff >15 (currently 10), likely non linear but what ever is easiest first

Considerations
Delegations DAO also needs to find ways to support at home / colocated servers out of large data centers like OVH / Hetzner - higher coeff doesn't matter if 60% are all in Germany/Finland

[JakeHartnell]

Probably best to pass a signaling prop before we actually begin work on this.

[faddat]

Have at times found the prop to go better with sample code.

Do you think this is the one?

@JakeHartnell -- have chased solutions to this for a long time now. Compared to the risk pricing work we did on osmosis, I do think this is the better approach because We could do something very important, make it a little exponential or such so that really really large validators pay really really high taxes. The only thing is that to some degree, it interferes with governance. Maybe validator x grew really huge because they're governance positions are popular and people want them with them much vote power. Then again, when people want stuff they're usually happy to pay for it.

[kopeboy]

I could help designing the formulas/economics of a proposal on this. Basic idea of mine is to adjust the voting power by an exponent between 0 and 1, ideally proportional to and scaling with the Gini coefficient (the more centralized the more you adjust, with an optional target for no adjustment). This way you never change the rankings, but reduce the differences/distances.

Adjusting the monetary value instead (ie. directly moving native tokens with a "tax") can lead to (legal) problems, is basically the same theft traditional governments do, and can make big investors angry or scared to join: if instead they keep their assets and profits but are limited in the (governance) harm they can do to the network, we can all claim to be fair, more democratic.

[JakeHartnell]

I could help designing the formulas/economics of a proposal on this. Basic idea of mine is to adjust the voting power by an exponent between 0 and 1, ideally proportional to and scaling with the Gini coefficient (the more centralized the more you adjust, with an optional target for no adjustment). This way you never change the rankings, but reduce the differences/distances.

This is a really cool idea.

[Reecepbcups]

what if we did this for gov voting power too? (up the set)

[kopeboy]

If it isn't it too heavy to compute the Gini coefficient among all Juno stakers and then apply it as an exponent to all of them..
Maybe you can update the coefficient only once every new gov proposal start, and use that to calculate the voting power of each account when it stakes/unstakes and when a new prop comes?

[kopeboy]

I prepared an example model here: https://docs.google.com/spreadsheets/d/1RvcFh7Ww9aKGiBdjuef7u7Hh8aT5D0FduglQkNNpCTg/edit?usp=sharing

It generates a random log-normal distribution of stakes, calculates the Gini coefficient and the voting power by adjusting the stake { Voting power = Stake ^ [ e^(-Gini)] }, effectively obtaining a lower Gini on voting power (less concentration of power).

I suggest adjusting by (e ^ -Gini), instead of just Gini, because this way you automatically adjust more when Gini is higher (more concentration) and less when is lower. To keep this behaviour but make it parametrizable, we could use a base X (higher than 1) instead of e (euler's number ~ 2.72).
You can play by changing the yellow cells (a std.dev. around 1.6 achieves a distribution similar to that of current validators).

Note that I simulated with 307 entities, ie. the number of max validators, because if you apply this logic to all staking wallets, the voting power could be easily manipulated: the more you would split your stake into many smaller wallets, the more voting power you would gain. To avoid this, I would apply voting power adjustment to validators only, ie. only until delegators don't vote themselves.

The Δ Voting power % column shows how small validators would be favoured when delegators don't vote.
If all delegators vote, nothing should change. I will try to simulate some scenarios about this.

I would keep the quorum based on non-adjusted-stake to avoid unnecessary complications.

Notes on implementation

Every time the adjusted voting powers need to be calculated, these are the required computations:

(as per the simplified expression from https://en.wikipedia.org/wiki/Gini_coefficient)

1. get the stake of each validator = S
2. count the validators = C
2. calculate (C+1)/C = D
3. sum validators' stakes = T, ie. total stakes
4. sort them
5. multiply each by its rank
6. sum the multiplied stakes = M
7. calculate [2 x M / (T x S)] - D = G
8. calculate S ^ (e^(-G)) = P, ie. the adjusted voting power of each validator

But I'm still not sure how often we should do this (or part of it)..
For example, what happens when:

• a delegator votes after his validator had voted
• a validator's delegations change during a vote

Finally, given the title of this issue, I'm not sure if this adjustment should be applied to anything other than tallys of governance proposals' votes. Also, this doesn't directly address the problem of common/cheap hosting providers (but it would help indirectly): to solve that I think wallet apps & explorers have to show validators' server info.