I absolutely think that we should throw out an idea because it is easy to circumvent.
The entire point of a blockchain is to not require any trust. That anything should be provable with facts.
If you introduce metrics that are game-able, you put at a disadvantage the validators that have the integrity to not exploit these metrics. In other words, the scummy validators become favored.
You also make comparing validators more difficult, because now nominators have to figure out whether or not the validators are hijacking the metrics that are being presented.
This makes selecting validators more complex and opaque.
It is very easy for anyone to obtain an IP address from any country that they want, and this is thus also easily exploitable.
I assume that most validators donât actually run a server in their basement but instead simply rent one from a data center. Servers like these can be moved throughout the world in two clicks.
You seem very strongly opposed to any type of solution to the problem. Iâm not sure why, but hey, you are entitled to your opinion.
I think it is a problem that a large percentage of the validators are operated by a small group of entities. This poses a serious security risk and a stability risk. Just today we see Kusama having issues because there are a significant number of operators that are not maintaining their validators and they either are running old code or have not set beefy keys (which were implemented months ago). The Jaco nodes are among the ones on the ânaughtyâ list.
I think giving users of the dashboard an option to exclude duplicates would be a valuable addition. I donât think itâs something that is going to be so impactful that validators are going try to cheat a single option on one staking dashboard. If they do, I have confidence they will be discovered and called out for it.
I also think giving users the option to see the location of the validators and chose a geographically diverse set is a good idea. Your argument that operators can simply rent a server in a faraway location is just proof that this is a good idea â if they do so that will increase the geographic diversity of the validators which is the goal. I operate 3 validators (2 KSM and 1 DOT), and all 3 are in different locations. No datacenter outage will take out all 3 of my validators at the same time, because they are not in the same datacenter. Nominators should want a diverse set themselves, to ensure they can still earn rewards if a datacenter goes offline.
Another potential idea would be to add a 1KV icon next to validators that are part of 1KV. I donât think they should be explicitly promoted over others, but there status should be visible for those who are interested.
Thereâs a community page on the dashboard which, according to ross, validators can add themselves to, but despite my asking (both in this thread and privately), no instructions have been provided on how to do so. Other places have files in a github repo so a pull request can be submitted. I see there is a github repo for the dashboard, but if there is a file there to add ourselves to, I have not found it. If this is really meant to be representative of the community, there should be public information on how validator operators can join. Simply providing that information publicly would be yet another simple way to improve the dashboard.
Generally any time you are providing a filtering service like the staking dashboard, more ways to filter / select is better, not worse.
Its absolutely 100% NOT EQUAL , from my point of view:
if you have full nomination set you are in favor to get more nominations - is it equal?
if you have 10+ nodes you are more visible it bring you more nominations - is it equal?
Dashboard recommend those who are already have full nomination and ignore who are in waiting list - is it equal?
We have 200M+ nominations in Polkadot recent months , my validator get 0 from this 200M nominations from dashboard or polkadot.js. I personally invite several big nominations , but itâs not enough. I have unique location, good hardware, I promote validator as much as I can for 2 + YEARS. You all see our activity. - Is it equal?
NO, its the DESIGN that need to be corrected in the name of ecosystem prosperity and diversity.
At least giving people the option to filter out âduplicatesâ seems like a common sense idea.
Filtering validators of the same name is trivial, but anyone could set an identity of their validator to, for example, P2P.org, even though they are not representing the actual P2P.org entity. To achieve this we will need logic of a validator operator on chain.
As a middle ground we could leverage the validator community data and filter the validator list based on that. But there is no guarantee the validator list is 100% accurate or up to date.
Thereâs a community page on the dashboard which, according to ross, validators can add themselves to, but despite my asking (both in this thread and privately), no instructions have been provided on how to do so.
My apologies, where did you reach out? The staking dashboard README contains a link to the repo you need to update - the data is now hosted on polkadot cloud.
This poses a serious security risk and a stability risk. Just today we see Kusama having issues because there are a significant number of operators that are not maintaining their validators and they either are running old code or have not set beefy keys (which were implemented months ago). The Jaco nodes are among the ones on the ânaughtyâ list
It would be useful to be able to flag in UIs whether validators are not running the latest node version, and warn users if that is the case. Weâd need to determine the best way to retrieve the validatorâs node version - this is not simply querying storage, but I imagine, querying the JSON RPC of a validator node directly. If anyone has insights on how this could be done Iâd be very interested to hear.
The dashboard and PolkadotJS treat all validators are equal.
@tomaka is correct - era points are the main metric that affects a validators rank and position in the initial validator list. Fwiw the validator list in staking dashboard is always shuffled by default to remove bias; it is the default âperformanceâ ordering method that then orders them by how many era points - and this obviously favours those who are always active.
I agree that if we hard-coded 1KV exposure into the UI we would then be favouring one set of validators over another; this is not an optimal solution IMO.
A proper decentralized way to do this, conceptually, would be to query the Polkadot DHT to obtain the IP address and PeerId of validators, then connect to these validators and use the âidentifyâ protocol to query their version.
Smoldot (or anything else for that regards) canât do that yet, but itâs in the realm of possibilities.
However, when it comes to the peer-to-peer layer, validators, being a sensitive part of the network, by default intentionally do not accept connections from web pages, in order to protect them from spam attacks.
Using JSON-RPC for this is strictly more complicated: you have no decentralized (or pratical) way to know the IP+port of the validatorsâ JSON-RPC server, and if we were to require validators to have to expose their JSON-RPC server publicly, which runs the exact same risks of spam attack and is in general less resilient than the peer-to-peer code, then we might as well require them to expose their peer-to-peer socket instead.
There is no need for ârocket scienceâ here , here is 3 points to solve this problem:
1.To add new category to section Nominate: 1KV Validators Participants of Web3Foundation 1KV Program. Choose to support the decentralization.
2.In âOptimal selectionâ include 5 validators from 1KV Program for example who are in active set now, or other criteria, but including 1KV participants. There are 264 participants of the 1KV program and about 1000 total validators , I think its fair and long term effective to give 5 of 16 seats in every recommended validators list to 1KV participants.
3.In Polkadot.js/app
Not divide Validators on 2 classes - Active and Waiting , give all of them chance to get nominated by new Stakers, and give the ability to search both lists when nominate!
Is there any progress about 1KV participants, we had really productive discussion recently. I had the impression that the community is proactive about the points I mentioned as a solution.
I also donât see any reason why any validator selection tooling should favor 1KV. This is just giving a bias to operators that are selected by a centralized entity. This doesnât say that this entity has chosen these validators using any decentralized metrics or similar.
