Summary: I feel as though depth of network is one of our most powerful tools to achieving a partnership with a company like Visa. The 1000 Validator initiative set out by Harmony is crucial to achieving a connection between DeFi and the real economy.
Background: With that being said “keys” or “slots” a validator holds is a determining factor on on whether new validators are onboarding regularly. We would like to create a metric on the dashboard that highlights Validators that are supporting decentralization.
Motivation: How the “Decentralization Support Meter” would work is:
-If a validator is holding the proper amount of keys they would have their indicator light be (green).
-If a validator is holding 1-3 more keys then they need, that would not affect their expected return, their indicator light would be (yellow).
-If a validator is holding more than 3 keys then is needed, to not affect their expected return for their delegates, their indicator light would be (red).
Specification: If you believe Decentralization is just as important a metric as up time or yield and would like to see as you scroll through the validator list, who is supporting the expansion of the network
(without any mandates) please help us pass this initiative and vote yes on HIP 11.
I think this is good. I would like to hear both sides of the argument but I am for decentralization…I just am wondering who the current 800 validators are…are people blindly delegating? I like to do my due diligence and delegate my coins to someone that is focused on giving me the best return…I like the fact that my delegators look to give me the best return…we are all trying to make money here. Why not just set a lower total cap for validators? Or a max cap to how much you can delegate to one?
This initiative does not mandate anyone to do anything but provide information. It could be a validator doesn’t even know they could drop a key. So it will equally help both sides without telling anyone how to run their operation.
We definitely need more Info on how many keys we need to have to maintain a good APY with the less amount of keys. The more information we have able the better informed we will be to make these kinds of decisions
Correct me if i’m wrong, but a ‘saturated’ validator could just create a new validator instead of adding a bls key. This would incentivice duplicate validators (even pretending to be sb else), which is happening e.g. on cardano.
I don’t think there is any way to stop someone from building a new validator, this proposal will not stop anyone from adding keys it will only display when you are running optimal keys to maximize Expected return with the least amount of network keys. Here is the quote that guided my thought process-
It’s important that bidding is looked at within context of risk. Bidding too high comes with the risk of a large delegation right before election pushing a validator above upper bound and bidding too low comes with the risk of a large undelegation and knocking a validator out of election. For a larger validator, it’s easier to find the “right” bid that balances those risks, but that’s not always possible for validators with a lesser number of keys. If a validator is growing, they may prefer to bid lower as to avoid an inefficient bid and if they’re losing delegates or at flat growth, they may be better off bidding higher.
Unfortunately, the bidding system may need to be improved before we can truly determine what’s an acceptable bid and what’s egregious. Currently, a delegator can delegate/undelegate in the last blocks of an epoch leaving a validator with no time to react. Let’s say we create a decentralization meter or some other limit on keys, a delegator or competing validator could maliciously add/remove delegations knowing the validator is bound by these constraints.
No one knows a validator’s situation better than itself and I doubt many validators, if any, add keys with the intent of kicking out validators. Most of the time I’d say it’s a result of a validator’s own risk assessment.
If we are going to have discussions about keys, it may be a good idea to re-evaluate the bidding system as a whole. Perhaps any delegations made in the last 450 blocks (about 15 minutes) can be counted towards next epoch allowing validators to adjust their bids/keys before the epoch ends. They could opt to remove keys, but can’t add keys, during those 450 blocks as long as they stay elected. Delegators could see which validators opted to remove keys allowing in new validators. This may be too complex of an idea, but it’s an example of how we can make something like the decentralization meter more meaningful in context of risk.
Once we have the additional 100 slots established, the way the bands are set up with the upper gone and the lower dramatically reduced coupled with a maximizing slot to ER system the daily key shuffle will be dramatically reduced.
The only reason I called it the Decentralized support Meter rather than the key optimizer is to put into the consciousness of delegates the importance of adding new validators regularly to help grow the network.
Depth of network will take us to the point where one day we will verify transactions, get paid for it. And be able to open Blits, wave it in front of a credit card machine to pay for groceries. Then the circle will be complete.
I support this proposal on the basis that this seems to be a compromise whilst a better solution is being discussed.
It strikes me though, that if this is an issue that can be quantified and reported as an indicator it’s something that can be written into the protocol by having decentralisation optimisation as a selection criteria.
The plain reality is, however many indicators we think up, the majority of delegators will pick the validator they know by reputation and/or the expected return.
The only real way to promote decentralisation would be to write it into the protocol.
Crypto is already hard enough for new users, so we should be giving people less to think about if we’re aiming for mass adoption in my opinion.
We had a discussion about having a Grace period a few minutes or maybe even an hour before the epoch ends to stop the last minute large delegation/undelegation that has pledged multiple validators. The large delegations puts the validator in a position that if we cannot act fast enough, we can over bid or fall out of election. This time will give us the opportunity to remove keys to stabilize our bidding and not risk getting unelected. I do like the no adding key part about what you said as well. This will keep everyone in check from abuse the grace period. It also provides a unique opportunity to evaluate our validator‘s bidding and remove keys safely to add more validators to the lower bound without risking election. This can be used to help small validators pushing for election.
If it’s allowed by the protocol, there’s no way to get everyone on board. It’s in our nature to take what we want or need to the limit that is set, which we can’t really blame anyone for. It can be frustrating at times, but that’s how it goes. There are a few other proposals that aim to try and make a difference by effecting change in the protocol, which would be more beneficial in my opinion.
I would add that a node should only be allowed X amount of Keys. Will this “solve” the decentralization problem NO… No “one thing” solves any other “one thing”, at least not in the real world of earth LOL. But, it may move things in that direction. I would hope.
@Cook8523 you posted Snapshot right? Could you please follow the guidelines on how to post a proposal? It has to have a form so its easily readable and with clearly listed voting options below etc. Please see how the other proposals were done, that is the way this one should be done.
