-
Notifications
You must be signed in to change notification settings - Fork 337
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
Comments
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. |
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. |
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. |
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 |
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. |
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 |
thank you @ryuash |
Hey guys i've turned this from a discussion to back to an issue after seeing how the |
hi ryuash. so it has been an issue on |
@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 Will be putting this issue back on hold but open to discussion for all. |
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 |
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 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! |
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: Next consider safety for your tokens. Delegate 60-80% of your tokens to some well established validators: 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. |
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
The text was updated successfully, but these errors were encountered: