leobragaz
commented
3 years ago I like this approach and I think it could be achieved by slightly modify the x/staking module, probably with an edited version of a function that is call in EndBlocker.
These are my first impressions after taking a look on how the validator set is updated in such module, but it could even not be enough for what we want to achieve, I need to take a deeper look.
We can set up criteria on which validators should be supported, similar to what we are going to do with the 200 validator set.
About this, as a user with some delegated tokens, in the past I struggled to understand WHY I should delegate token to one validator rather than another one.
The first delegations I made was completely random and moved by gut (and commissions % LOL) and later on I felt like I wasn't acting like a crypto-user supposed to and redelegate everything to new and more uncommon validator, but even then, I struggled to understand WHO they are and WHY I should delegate to them.
So I think that, when we set up these criteria, they should widely cover the validator "history", to help where it's possible users to make a good and clever choice for them and the system.
kwunyeung
RiccardoM
We always want to achieve a more fair mechanism for validators. When there is a limit in the validator set in PoS, it will never be fair. Even if the validators will be supported by the foundation, the validators outside of the set will never be selected to the set under PoS. Our first step is to spread the token as distributed as possible and encourage validators to join as many as possible.
One more step to consider is to select different validators at different time. So that even if we have limited number if validator slots, more validators can join. Increasing the validator set won't be a long term solution as it will just increase the block time under the asynchronous voting queue of Tendermint Core.
By introducing epoch, we can reselect validators and also use this as a period for applying the warm up / cool down of voting power issue raised in #194.
Implementation proposal
One issue comes from the random seed. I have discussed this issue with Band Protocol as they use the same method to select a small group of validators for reporting the oracle. Their approach is that the nodes have to calculated the randomized result 3 times to ensure deterministic. They have also audited the code and auditor considered using the block hash is safe.
We have planned the foundation should hold most of the tokens when launch. Then most of the delegations will be coming from the foundation. We can set up criteria on which validators should be supported, similar to what we are going to do with the 200 validator set. This can be done programmatically or by application. We can even delegate to those validators not in the active set as they will be selected in a long run. The total bonded stake holds high but the stake take part in the consensus may not be that much in each epoch.
If we can implement this, the idea will be similar to Polkadot's Nominated PoS and Celo's validator election. The difference is we can control the distribution to be fair at start which won't lead to Polkadot's problem of a single crypto fund split their stake in multiple nodes.