This is a place holder post to move the discussion from Telegram to open forum on gov.near.org. Here’s the original message: (will transfer post ownership once they join)
Hello, everybody, since there are no onchain solutions for regulating the size of a stake (I hope that it will ever appear and I’ve already posted some ideas which are imlemented in origianl TON elector contract and can describe them as additional topic), we have been discussing for a few days now with @denys4k how we can influence the distribution of stakes between validators with his validators stats on https://near-staking.com/
Current cumulative stake mappings do not help users to distribute their tokens between pools. Humans - creatures subject to herd instincts and will involuntarily always choose the largest clusters, except for a small percentage of individuals who are aware of what is happening or tend to be isolated from society.
Therefore, there was a proposal to direct the flow of people more evenly into pools, at least in the off-chain format of atm.
For example, make the graph of not a cumulative stake, as it is now, where the top validator has “only” 7% of total stake and that is perceived by the subconscious as something completely insignificant, but the gradation from 100% and below, where 100% will be taken the maximum stake, and so all the rest - the percentage of the maximum. Next, all pools from 66 to 100% will be painted red (the color of danger and at the psychological level will repel), plus when there will be a noticeable red figure of 100% is much clearer than the current 7%.
In this way, we will be able, although probably not significantly, to influence the distribution of user stakes until better solutions are available.
We would like to hear the team’s opinion before the implementation
Hello and thank you for deciding to move this post forward.
I believe that now in almost all POS networks there is a problem of stakes centralization and we need an effective on-chain solution that will be more effective than any call for awareness of delegates and all kinds of psychological tricks.
For example create some limitations in elector contract, which will prevent top stake overgrowth (and seatprice as well) and as well as the mechanism to reduce the award of the top validator.
Atm we’ve the oppositve, rewards and paid for every produced block, produced blocks are proportional to taken seats.
And that’s where we get the problem, I’ll try to explain with examples:
For example we’ve a seat price 1mln atm:
top validator have 10.5mln stake, so he’ve 10 seats and 95% of his stake is in work (i.e. getting reward)
bottom validator have 1.8 mln stake and got only 1 seat and only 55% of his stake is in work
so rewards for each near staked in top validator will be higher than in bottom one, and difference can be up to ~90%.
So this example show what if we’ve rewards proportional to the stake amount, not a signed blocks, we’ve one problem less.
By awarding seats proportionally to stake size, there is a strong economic incentive for validators to merge together and centralize. There is no penalty or other disincentive to centralization beyond risk the validator owner makes a mistake that results in slashing. Essentially, the behavior observed is a form of “seat hoarding”, where token holders achieve consistent economic rewards by delegating their stake to a single super-validator who is consistently guaranteed multiple seats each epoch.
I’m sure this has been discussed elsewhere , but the solution seems obvious: a “limit one seat per customer” policy. A large validator can bid as much stake as they wish to increase their odds of getting a seat, but once the seat price is determined, any “surplus” beyond this threshold is not staked or is otherwise ignored. If a validator wishes to stake more some than twice the seat price, they can start a second validator, and incur the “penalty” of the additional operational complexity.
Another variation may be to allow the full amount to be staked and rewarded, but to still only assign one seat, thus ensuring the full target number of seats are filled, subject to minimum quality standards.
Ultimately, the needs of the network for a diverse, decentralized, and independent group of validators must take priority.
An alternative would be to fully “internalize” the cost of centralization into the reward function. One way to do this would be to up-weight any downtime in the your_adjusted_online_ratio by the number of seats held by the validator. Thus if a validator chose to take multiple seats in an epoch, exclude other potential validators in the process, and in doing so made the network overly reliant on their availability, this validator should also assume a proportionate amount of responsibility for their availability.
The key idea here is that risk and reward must always stay in balance. The current system allows a validator to “guarantee” rewards (by taking multiple seats and consolidating the network) without any corresponding increase in risk or accountability.
I’m slightly surprised this was not discussed more during Stake Wars.
I have a few questions around this problem:
What happens to the stake rewards of those who staked after that 1 seat limit was achieved by the validator? Are they ignored and now have to stake with their 2nd/3rd choice? Do they have to wait for someone to unstake so they can rush to fill that spot?
How can we tell the difference between people blindly staking in the biggest ones and those validators actually being the “best” validators (being most transparent, giving most back to the community, voting the way most token holders are aligned with)?
For now I like this solution the most, although I’m slightly concerned does that create a scenario where if that validator misses his expected block amount even by 1, he still gets kicked?
the solution seems obvious: a “limit one seat per customer” policy. … If a validator wishes to stake more some than twice the seat price, they can start a second validator, and incur the “penalty” of the additional operational complexity.
The reason why the current system is rewarding proportional to stake is that it’s “fair” mechanism.
Any non-fair mechanism lead to just more hacks that people will deploy. Specifically if one tries to force validators to have more “nodes”. For example, it’s pretty easy to add to neard right now an option to sign with as many validator keys as one wants. Hence it will look like there are a bunch of validators in the network - but in reality they all run on the same computer.
So we actually not increasing decentralization at all and decreasing transparency.
This still would have centralization of larger capitalized validators but would remove some of the current mechanics around the problem with not having enough stake due to seat price going up all the time.
One way to do this would be to up-weight any downtime in the your_adjusted_online_ratio by the number of seats held by the validator.
This an interesting option. This will need to be paired with more information in explorers around current offline ratio and penalty rate communication.
E.g. something like this validator has 0.99% online rate and is penalized with x10 because of large stake hence effective return rate is X%. Which would allow people to consider this information more when selecting validators.
where if that validator misses his expected block amount even by 1, he still gets kicked?
Kick out ratio doesn’t change as it’s in % missed blocks. So it’s just penalty on returns.
And mostly it will penalize delegators for putting on a large validator that doesn’t deliver 100%
I think one problem with this option in current setup is that validators may not want to accept more capital over some line and right now there is no way to restrict this. But this can be a good addition to the staking-pool contract version.
Ok, understood. Then voting has to be decoupled from delegation, you shouldn’t have to satisfy with 2nd/3rd choice just because your first one doesn’t have the capacity to accept your vote.
Yes, I think that is important lesson from the Phase II that we have discussed on Friday - even though validators in general do have more information but specifically pools are not the best manifestation of it for people to select it.
Also not all validators have time to participate in the at the specifics of the decisions as they are running across many networks. I’ll try to suggest an experiment based on the discussions we had a governance protocol group.