Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Base: Try to randomise the validator list on first load #258

Open
ryuash opened this issue Aug 30, 2021 · 17 comments
Open

Base: Try to randomise the validator list on first load #258

ryuash opened this issue Aug 30, 2021 · 17 comments

Comments

@ryuash
Copy link
Contributor

ryuash commented Aug 30, 2021

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 ryuash added the base label Aug 30, 2021
@ryuash ryuash added this to the base-v1.0.7 milestone Aug 30, 2021
@ryuash ryuash changed the title Update Aug 30, 2021
@nullmames
Copy link

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.

@ryuash ryuash removed this from the base-v1.0.7 milestone Aug 31, 2021
@ryuash
Copy link
Contributor Author

ryuash commented Aug 31, 2021

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.

@nullmames
Copy link

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.

@RiccardoM
Copy link
Contributor

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

@ryuash
Copy link
Contributor Author

ryuash commented Aug 31, 2021

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

@nullmames
Copy link

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.

@ryuash
Copy link
Contributor Author

ryuash commented Aug 31, 2021

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

@nullmames
Copy link

thank you @ryuash

@giansalex
Copy link

should be requested in keplr, cosmostation wallet 👀
image

@ryuash ryuash changed the title Update: Staking component sort order Sep 1, 2021
@ryuash ryuash changed the title Discussion: validator list displaying without in orders not related to voting power Sep 2, 2021
@ryuash ryuash changed the title Discussion: validator list sorting Sep 9, 2021
@ryuash
Copy link
Contributor Author

ryuash commented Sep 9, 2021

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 ryuash added this to the base-v1.1.0 milestone Sep 9, 2021
@ryuash ryuash removed this from the base-v1.1.0 milestone Sep 10, 2021
@nullmames
Copy link

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

@ryuash
Copy link
Contributor Author

ryuash commented Sep 10, 2021

@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.

@kwunyeung
Copy link
Member

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

@dylanschultzie
Copy link

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.

@kwunyeung
Copy link
Member

@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?

@dylanschultzie
Copy link

@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!

@chillyvee
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment