big-dipper-2.0-cosmos icon indicating copy to clipboard operation
big-dipper-2.0-cosmos copied to clipboard

Base: Try to randomise the validator list on first load

Open ryuash opened this issue 3 years ago • 17 comments

Originally discussion now issue:

In order to give every validator a chance at displaying on first load try to find a optimize way to display randomly

ryuash avatar Aug 30 '21 03:08 ryuash

I think some consideration should be given to the overall effect of sorting as it relates to the voting power of validators and the overall decentralisation of the chains who use your code. It is human nature expect a product to be somehow "better" when it is at the top of a sorted list. This in turn results in a concentration voting power to the validators that are at the top of the list and already have a large amount of voting power. It would be more beneficial to all blockchains that use your code to innovate and create a randomised sort of some description such that the ordering does not result in a high frequency of the same group of validators being at the top of the list. Sorry to invade your issues list.

nullmames avatar Aug 31 '21 07:08 nullmames

No you're right. This was one of the reasons why i originally sorted the list by name/ address without the option to sort by amount. Let me come back to this later this week and see if we will set this feature or not.

ryuash avatar Aug 31 '21 07:08 ryuash

Thanks @ryuash i appreciate the consideration. I have invited people to this particular issue ticket just to gage if there is support for such a restructure.

nullmames avatar Aug 31 '21 07:08 nullmames

To solve the problem highlighted by @nullmames, Terra Station sorts the validators by voting power, bust listing first the last 10 validators that joined. This results in the list always having at the top the newest one, and the the other ones based on voting power.

We could ideally also have the list that default to being dynamic: the order of validators changes randomly each time you reload the page. This I think is how the BigDipper 1.0 works

RiccardoM avatar Aug 31 '21 09:08 RiccardoM

Oh actually, This issue was referring to this component inside validator details, I wanted to sort the amount to show who the validator's biggest suport was image

ryuash avatar Aug 31 '21 11:08 ryuash

oh man. so sorry if i went off on a tangent.

i think this issue is still important and needs to be addressed, not only on big dipper, but all explorers.

nullmames avatar Aug 31 '21 11:08 nullmames

100%

You guys are free to open a discussion here but i'm just going to point out this issue was for a different component 😂. Sorry i didn't realise sooner

ryuash avatar Aug 31 '21 11:08 ryuash

thank you @ryuash

nullmames avatar Aug 31 '21 11:08 nullmames

should be requested in keplr, cosmostation wallet 👀 image

giansalex avatar Aug 31 '21 16:08 giansalex

Hey guys i've turned this from a discussion to back to an issue after seeing how the desmos-mainnet stakes are going. I will review and try to find an optimise way to target this.

ryuash avatar Sep 09 '21 00:09 ryuash

hi ryuash. so it has been an issue on desmos-mainnet too?

nullmames avatar Sep 10 '21 06:09 nullmames

@nullmames Not really related but we saw how the stakes were slowly centralising. The Forbole X team will do a new release in how validators are listed to see if the reactions will be different. Internally we decided Big Dipper will not need to randomise the list as we are only showing by name and our idx does not indicate a validator's vp.

Will be putting this issue back on hold but open to discussion for all.

ryuash avatar Sep 10 '21 06:09 ryuash

In longer term, we should also be able to sort the validators with overall ratings which the data can be provided by https://github.com/forbole/bdjuno/issues/63

kwunyeung avatar Sep 22 '21 16:09 kwunyeung

In longer term, we should also be able to sort the validators with overall ratings which the data can be provided by forbole/bdjuno#63

Not sure I agree with that hexagon chart. Why should the self delegation be so high, proportionately? That seems like it'd drastically negatively effect the smaller validators that can't afford to be super high in self-delegation percentile.

dylanschultzie avatar Sep 26 '21 20:09 dylanschultzie

@dylanschultzie what do you mean by "self delegation be so high"? The scale can be in log or so to diminish the differences between super high voting power validators and smaller validators. Also, this is the percentage of self delegation. Usually smaller validators have higher self-delegation percentage. Isn't this figure more benefits to smaller validators?

kwunyeung avatar Oct 04 '21 19:10 kwunyeung

@dylanschultzie what do you mean by "self delegation be so high"? The scale can be in log or so to diminish the differences between super high voting power validators and smaller validators. Also, this is the percentage of self delegation. Usually smaller validators have higher self-delegation percentage. Isn't this figure more benefits to smaller validators?

Hey, you're correct, I forgot to message after I made that statement. I was under a different impression when that statement was made. Apologies for wasting your time!

dylanschultzie avatar Oct 04 '21 19:10 dylanschultzie

I think it would be fun for example to show an idea for allocation:

Consider delegating to both small and big validators for the best network diversity, yet minimized risk.

First consider network diversification to defend against bad actors and attacks:

Delegate 20-40% of your tokens to some smaller validators with proven good uptime and participation in governance: (We value diversification in our ecosystem and wish to grow our smaller validators. Your moderate delegation to our smaller validators may have a higher risk to you, but lowers the ecosystem risk of an attack. This balance is valuable to our ecosystem). [ ] Random from bottom 80-100 (display validators who didn't get anything in 24 hours more often) [ ] Random from bottom 80-100 (display validators who got less than close peers more often) [ ] Random from bottom 80-100 [ ] Random from bottom 50-100 [ ] Random from bottom 31-100

Next consider safety for your tokens.

Delegate 60-80% of your tokens to some well established validators: (Top validators have often previously shown strong stability and community support) [ ] Random from top 1-10 [ ] Random from top 11-20 [ ] Random from top 21-30 [ ] Pick a validator who has previously earned your trust/patronage

The idea is to allow a lot of small but random validation to small validators. They may not have earned any allocation, but it would be good to give them a reason to earn it. Thus give them enough to care, do it right, and do it better.

I don't agree with trying to even out the delegations completely. It should be uneven to some extent because many have earned a larger following.

However, random non-pre-targeted delegations could be spread out a bit to the benefit of the entire blockchain. We're not trying to bring #95 up to #23. Rather, give enough to keep #95 at #95 as long as #95 is playing ball correctly. Give enough to #94 to stay around #94, yet gradually increase the delegations as long as good performance is shown.

I think that pure random will probably be decent. However I've seen some rather large delegations spiking random validators upwards. If intentional, no problem. Otherwise, I'd like to show some smaller folks often enough until they get the validation.

I have a hard time believing that every validator south of the 50% mark sucks just because they are small. There must be a good number of them who are capable of doing the job right. Just need to find out who.

chillyvee avatar Oct 08 '21 17:10 chillyvee