Logscale consensus power calculation for better decentralized consensus

Conversation
1

Currently power decides 3 important things : rewards / consensus participation / voting rights

So we can say that there are at least 3 important axis of decentralization.

From experience and history, it is not very practical to try economic(rewards) decentralization in crypto-ecosystem. But, it does not mean we have to give up consensus decentralization.

Therefore, I suggest to use different metric when we calculate consensus. For example, we use log(power) for consensus summation. If we adjust this feature, we will have much better decentralization on the axis of blockchain consensus. It improves liveness, censorship risk, manipulation risk, etc.

If big validators get the same rewards and same voting power for governance, why they want to get more “consensus power”? I think there is no economic incentive on this. Therefore big validators will not bother themselves splitting their validators to gain more consensus power.

Please share thoughts and better ideas!

Below is the expected result of consensus power distribution changes when we use log(power) for consensus power share percentage.

image
image727Ă—631 26.7 KB

1 Like
2

I agree with this idea. If the rewards and voting power can be separated, it will help decentralization a lot better. The calculation in log scale looks very good to me. 11 validators take 34% and 30 validators take 67%. I would also want this voting power to be applied to governance as well. Otherwise, many proposals can be easily controlled by, if delegators don’t vote by themselves, only 9 validators now.

3

governance voting right is quite important for big capital. it might cause validator splitting which will depower the effect of this methodology. So I prefer only consensus power calculation change.

Possible side-effect : splitting validators into many small validators cause higher power share than linear power share which can lead to censorship attack.

So unless we can find better mechanism to avoid the side-effect of validator-splitting, I think this methodology is too risky.

1 Like
4

I think it is not a good idea. It incentivize top validator operate several nodes.

1 Like