my personal thoughts on decentralisation is the simple answer to the question why everyone assumes BTC or ETH chains the most decentralised comparing to others?
let’s not re-invent a wheel - as a whole validators community we should plan on how to migrate from VPSs/VDSs (AWS, Vultr, Contabo, etc) to the physical machines and achieve true decentralisation we all dream about
I know, currently this movement might not get popularity because of a strong disadvantage - the expensiveness of servers (whether it’s a co-hosted or a home server), but this is what we should focus on to reach decentralisation
In the meantime, use of physical machines will def limit opportunities to add bls keys easily, as you’ll need more hardware for that.
ps: I say no to the proposal as I don’t think it can solve the raised issue of decentralisation
how that indicators can stop validators playing with keys in order to increase their returns?
I don’t think any mandated reduction of keys is good for the system but I do believe showing who is finding the balance between productivity and network expansion is healthy.
Delegates have the power to vote for a validator that espouses their core values. I do believe giving them the ability to see who they align with cannot hurt.
The cost of servers is definitely going up leaps and bounds with transactions. I know back in April the Dev team was looking at reducing storage space needs to run a node. That would definitely help a lot of people out especially seeing how almost every day this week someone has stopped signing because they have run out of storage space.
I don’t think any mandated reduction of keys is good for the system but I do believe showing who is finding the balance between productivity and network expansion.
for me this sounds reasonable and I will always follow the the idea that we’d better to build staking culture when everyone respects others. Balance - sounds really fantastic, but people are behind tech have different perception for that, so the culture and spirit first
Delegates have the power to vote for a validator that espouses their core values. I do believe giving them the ability to see who they align with cannot hurt
it will come when delegators become more involved in what is going with staking
my vision on a decision-making - everyone holder is the only source of power on governance
holders are validators and delegators in terms of the vdao must be equal in the rights
The only way we propagate awareness is by putting it front and center, we tell people ER is important and up time is important, it is on the front page. If we believe expanding the network is equally important, why not put it on the front page up there with everything else?
Working overtime to change your vote
Nothing but love!
The problem with this proposal is it will only penalize community nodes and do nothing to prevent validators with only a few large wallets/delegates that don’t rely on community delegates from adding extra keys.
With a wallet like Binance that controls 2 billion in stake or an exchange like Kucoin being the largest validator by stake, but with only 30 unique delegates, a decentralization meter is irrelevant to them. That’s half of the network stake that will ignore the meter since it won’t put their stake at risk. This creates a situation where a proposal only applies to half the network, which so happens to be the half that’s already more decentralized than the other half that won’t be affected by this proposal.
We need proposals that help community nodes, not hurt them, and it’s hard to see how this proposal achieves that. If anything, it would achieve the opposite effect by limiting validators that rely on community delegates and giving an advantage to validators that don’t rely on community delegates.
One item to add is there’s already disincentivizes in place that discourages validators from adding extra keys and that’s the increased infrastructure costs. More keys means more CPU power, higher bandwidth usage, extra key management, etc. It’s beneficial to a validator to limit keys since the effect on ER from adding extra keys is usually negligible unless a validator is going below the lower bound, which has already been dropped from 0.85xEMS to 0.65xEMS in recent proposals, thus making it more difficult to obtain those high ERs and reducing the incentive to add extra keys.
There is nothing we can do about KuCoin and Binance at least they sit at the bottom of the list consuming close to as low a key count as possible. Binance even sits in the lower bound endlessly .
There will be no negative effect on the system but will help onboard new validators expanding the network without dictating anything to anyone. It will only provide information, the more information we have as a community the better off in the long run we will be.
The information is already on the staking.harmony.one portal. Delegators can see number of keys and bid position. What it looks like your trying to do with the meter is add a subjective measure that’ll only hurt community nodes who rely on community delegates. Perhaps if the idea was more developed to provide greater context (see my earlier posts about context/risk), we’d see more benefit to it.
Its almost guaranteed there will be a situation where a community node will show “Red” on your meter (or whatever color is “bad”) and lose delegates over it when that validator may have had those extra keys to no fault of their own. For example, they could lose a large delegate which drops their bid to the lower bound and in the time it takes them to adjust keys, they will lose more delegates because the meter will show they’re not “decentralized” enough. You know who will undelegate first? Not Binance and it’s 2B stake. It’ll be the community delegators who stake 1,000 - 1M with independent validators who’ll be watching it most closely.
Or what if a validator knows they’ll be unable to adjust keys for a few hours/days and bids in the middle, ie slot 400, to ensure they don’t lose election or bid inefficiently. Now they’ll need to worry about a decentralization meter every second of the day? You need to keep in mind that not every validator uses an autobidder that adjusts keys instantly and many independent validators lead lives outside of Harmony with events such as vacations, child births, family emergencies, etc.
Independent validator operators on Harmony without teams of 2+ already have a lot to manage with EPOS’ daily elections and shard assignments, and adding a subjective meter to the mix will only cause additional burden on those independent validators and make it harder for new validators to grow.
For many newer/small validators, low bids / higher ER is the only way they can compete with larger validators and a meter will take away that opportunity from them due to fear of it being perceived negatively, even though they’re trying to decentralize the network by giving incentive for delegates to move from larger validators to them through higher earnings.
If you can elaborate more on how this meter will judge what’s good from bad, maybe we can support it, but it’s hard to see how it grows the ecosystem as-is. All it looks like it will do is shift delegates around causing instability and additional burden on validators.
We will have to agree to disagree. I don’t believe the exceptions out weigh the rule. All of the key holding to release at the last minute so we try and get folks in for 1 epoch is noble but should be unnecessary. We need more stability so people can plan and not worry about the great key shuffle everyday.
Will there be an innocent victim? I am sure, just the same way people’s nodes are filling up everyday now and they stop signing, it kills their up time. Things are are always going to happen we fix them and move on but on the day to day broad base overview, it will stabilize keys and open up more slots regularly that I have no doubt about.
We can always set the changing of the color to the median bid that way it will not effect newer validators trying to get that most difficult 2nd key, that was a great point. Thank you for that!
I am ok with this proposal at the condition we do one modification. My concern is I think we should have a delay to adjust the keys in consequences.
For example a 20M validator on 3 keys is loosing 7M in one day, he will bid too low (if not using the autobidder) but I don’t want him to be affected right away by a yellow/red flag.
The color of the flag could change after 3 epochs in a row in the “wrong zone” for example.
I like the idea of encouraging the use of keys in a responsible manner, but I’m not in favor of this proposal primarily because it lacks the detail needed to ensure its own success. My secondary reason for being against this proposal aligns with a concern noted by another validator above – it seems to mainly single out validators who participate in elections while having no impact on the large validators who do not participate.
Perfect example is a situation which occurred today:
KuCoin created 10 additional keys, bringing them from 40 to 50 keys, slot 700, and impacting a number of validators below them. They will not care yet they have the biggest negative impact on the exact thing this proposal is trying to help fix.
To elaborate further on my primary concern:
“If a validator is holding the proper amount of keys they would have their indicator light be (green).”
I may have missed it, but what formula are you proposing to use to determine the proper amount of keys? Is this key based or bid based? How will this be calculated and how will that calculation not punish validators who are between the 1-4 BLS where it can be difficult to stay within median?
I really like the idea of encouraging a responsible means of managing BLS keys, but I feel this proposal would need more fleshing out in order for me to feel confident enough to vote in favor. I also like the idea of providing delegates with more information on validators and how they operate; perhaps this can be one of a number of metrics that are summarized on the staking portal.
I think a focused discussion around the topic of key and bid management can be very productive - see what ideas validators come up with, hash them out, determine flaws in the logic, etc. Though, in its current form, I don’t think I can vote in favor of the proposal.
Correct me if I am wrong @Cook8523 but from my understanding here is an example of how it is supposed to work :
The high bound is 7.3M and the low bound is 3.5M.
A validator has 50M and 10 keys, so his effective bid is 5M.
=> This validator can drop a maximum of 3 keys and still bid under the higher bound (50/7 = 7.14M)
So this validator has 3 more keys than necessary = yellow flag.
We can add the number of unnecessary keys to show more details.
Hey ONE4All and thanks for the response. I understand the concept, but I cannot cast a vote on a high level concept. Unfortunately there is no clear definition in the proposal on the key threshold and how that’s calculated, whether this applies to all validators or some over a certain size and how that would be calculated as well, etc.
I know you mentioned three keys but that appears to only be an example [edit: and the proposal doesn’t mention why that’s the ideal range]. These are some of the details that would need to be ironed out, otherwise I would be voting for something that’s completely up for interpretation. Doing that seems very risky and rushed in my opinion.
Personally, I think we need to have a more in depth discussion before something like this gets put to a vote. The discussion would be to determine if this is the best path for promoting responsible key usage and how the mechanics would work, documented and explained in a clear and detailed manner that leaves nothing for interpretation.
I’d love to participate in that discussion but in the meantime I’ll have to vote no on this proposal.
@Cook8523 you ignored my last comment. Currently we have rules on how the proposal should be made on the snapshot page. Please redo it again so that it follow those said rules. Posting proposals is great ofc, but lets adhere to the current rules so that we have some structure to everything. Thanks.
I can see that the intent here is in the spirit of holding Validators accountable for managing their keys properly into the assigned slots. If there there are any (BLS) key mismanagement, then delegators need to be alerted. And the definition of “proper” here is quite vague.
In my opinion, I fear the methodology has quite a lot of gaps:
When there are significant changes in delegation, most Validators usually have an automated way to rebalance their keys by adding/removing keys to be ready for the next epoch. If this support meter does not take into account for that, then this could temporarily skew their key assignment for the current epoch, could miscommunicate their good intent of key balancing as a “mismanaged” Validator.
Validators should be the ones alerted via some mechanism if they have keys assigned incorrectly in their Validator midway through an epoch. Sure, delegators can get a sense of who’s performing well, but if they’re not looking at the dashboards, how do we hold validators accountable for the outage (disclaimer: our validator included)?
BLS key (mis)management is just one facet of things. There are also indicators such as the frequency of missing blocks, etc. This will affect the ER. Color coding a validator based on just key management is severely undermining what goes on underneath the hood in running validators. There’s a lot more than that I think this yet again is a part of the KPI (key performance indicator) for “uptime” that needs to be evaluated, as part of the whole picture, rather than just BLS key management.
Aside from that, anyone can submit a pull request to the Harmony Staking Dashboard GitHub repository to add some form of indicator, rather than using a governance model here.
I’d abstain from voting on this. I do support the spirit of this. The methodology requires a larger scope to give current and future delegators a sense of what their expected returns are/will be.
I no longer have a validator so I will leave that for you guys to decide. I wish we could just have a wide open protocol and just be better humans or we are no better than the greedy bankers we wish to supplant. The protocol allows it is a shitty reason to cut someone else’s throat. That said hard restrictions on keys seems to be the talk of the town. Here is what I would propose:
If you have more than 10 keys the system won’t let you bid past 600 or 3/4 line so when Validators expand the number is flexible.
0% fee for 50 epochs
5-100 million mandatory 5% fee
100-200 million mandatory 6% fee
200 million above mandatory 7% fee
I see a lot of comments over here regarding right and wrong, but I think this proposal is more a user experience thing than anything else. I say this because the information this proposal is proposing to show is already available on the [staking.harmony.one] website, just like ValidatorONE said.
That being said, I still want this to go ahead because, as I said, this illustrates information that is currently not explicated and that requires interpretation.
I also agree that community validators like KuCoin may not care about this feature, but I don’t think this is for them at all. This feature further pushes the responsibility on other validators (besides validators like KuCoin) to add keys more responsibly.
P.S: I think the debate should be more around when would someone get green, orange or red traffic light. As that is the incomplete bit in this proposal. It needs to be more concrete. Once this is better defined, I think this proposal can go ahead.
I agree with the first comment on the thread. Enough said IMO. An informed community is not only best but absolutely essential to success in a market such as a blockchain technology where there is already so much FUD (Fear, Uncertainty, and Doubt) to begin with. Transparency and teaching the community about Harmony are key.
I agree, any information displayed in an easier manner for delegates is a good thing. We want them to be informed but we need to discuss any negative impacts this could have if we do not properly display green, yellow and red light and come up with solutions to these issues so that everyone feels comfortable voting yes. There could also be other solutions that better tackle the issue in the case that too many complications arise during the discussions.
.