@sophoah, Validator.ONE is in full support of exploring your idea, as you described here: Open Staking: Improvement Proposals - #4 by sophoah. We were considering a similar proposal until you brought your suggestion to our attention.
Our suggested proposal for HIP-16 offers a few modifications to your initial suggestion but shares the same principle, which is to incentivize validators to reduce keys.
As one of the larger validators, Validator.ONE recognizes its responsibilities to exercise responsible key management. We also recognize the immediate gains in available keys when we or any validator reduces their key count. We’ve learned both these lessons through months of self-imposed key limitations and consistently bidding above 1.0x Effective Median Stake (EMS), often as close to 1.35x EMS as possible. We seek opportunities to help unelected validators gain election by holding keys before releasing them near the end of an epoch. The reason we wait until the end of the epoch to remove the held keys brings us to our other lesson learned. We’ve learned through our key management that when we reduce keys, it doesn’t always benefit the unelected validator.
When we reduce any extra keys early in an election for the benefit of an unelected validator, another elected validator typically adds additional keys, thus consuming whatever extra keys we had removed, resulting in zero net benefit to unelected validators. These other validators who consume our forfeited keys range in all key and stake sizes. It is not just larger validators but rather typically small to mid-sized validators who compete for the best expected return (ER) despite limiting the opportunity for unelected validators to become elected. It is a frustrating and discouraging cycle to do your part only to see it benefit an unintended party, especially one who needs no such benefit. Key changes are not fun nor a hobby and require editing our validator, which takes time and effort.
When we spend our time and effort to reduce keys only for them to be consumed by another validator who doesn’t share the common goal of electing more validators, you learn that it’s not just the large validators that need to take responsibility for decentralizing the network, it’s all validators from single key validators and up. For this reason, we strongly reject a hard cap on a validator’s total stake or key count as it does not address the underlying problem, which is the reward system for bids within the lower and upper bound range of 0.65 – 1.35x EMS.
The problem is validators have no disincentive to occupy the lower range (0.65 – 1.0x EMS) other than the chance of non-election, which doesn’t appear to be a concern to those validators based on their actions. Conversely, there is a financial incentive to add keys, which reduces the total network or shard stake for a better expected return. On the flip side, validators are offered no financial incentive to occupy the upper range (1.0 – 1.35x EMS), but rather are presented with the risk of an inefficient bid if the bid exceeds 1.35xEMS and reduces a validator’s earning potential by raising the total network stake, which lowers the network’s average ER. These factors have led us to conclude validators are operating within a system that incentivizes lower bids and disincentivizes higher bids.
To fix the problem, we need to fix the system. Therefore, we consider a system designed to disincentivize lower bids and incentivize higher bids to be the most effective solution towards creating a sustainable, responsible key management solution.
Our solution serves as a credit system. If a validator bids in the upper range (1.05-1.35xEMS), they receive part of a credit funded by validators with 5 or more keys who bid in the lower range (0.95-0.65xEMS). The protocol would fund this credit by slashing a validator’s bid. Validators with elected bids in the 0.95-1.05xEMS range would be unaffected by this proposal as their bid would neither be slashed nor would they receive any of the available credit. Additionally, the normal EPOS rules for bids below 0.65xEMS and above 1.35xEMS would still apply and remain unchanged by our solution. Therefore, this would only adversely affect validators that operate in the 0.65-0.95xEMS range, where the most key mismanagement occurs.
There are certain rules from a logic standpoint that we consider important to include to make this a complete solution:
- Those with 5 keys or less won’t be subject to a slashed bid for operating in the lower range, which provides them with a bidding advantage over validators with more than 5 keys;
- Despite not being subject to lower range bid slashes, validators with 5 keys or less would still be eligible for the additional credit for elected bids in the upper range;
- Validators with more than 5 keys and elected bids in the lower range (0.65-0.95xEMS) would be subject to diminishing rewards the lower they bid with the severity of the reduction in rewards based on the validator’s key count. For example, if there were two validators with the same bid amount in the lower bound, the validator with a higher key count would earn fewer rewards per key than a validator with a lower key count;
- Credits rewarded to those bidding in the upper range diminish based on a validator’s total key count. For example, if two validators with the same bid amount in the upper bound, the validator with a higher key count would earn less of the upper range credit per key than a validator with a lower key count.
Our solution is intended to achieve the following objectives:
- Incentivize all validators to bid as close to 1.35x as possible;
- Disincentivize validators from adding keys to the lower range without cause;
- Minimize key usage without cause by all validators;
- Provide validators an opportunity to gain an ER advantage over validators with higher key counts than their own;
- Minimize disruption to delegators; and
- Incentivize delegators to choose validators who minimize key count.
Our solution ensures that a validator always carries an advantage over a validator with more keys than their own while holding validators of all sizes accountable for responsible key management. Medium-sized validators will hold an advantage over larger validators, and smaller/unelected validators would hold an advantage over medium and large-sized validators. This creates a system where validators are encouraged and incentivized to bid as closely to 1.35xEMS as possible.
We’ve begun modeling a potential reward calculation to provide an example of how the rewards would fluctuate based on bid and key count; however, we think it may be prudent to first obtain feedback on feasibility from a protocol logic standpoint. To that point, we welcome any feedback from those on the team or others who work on the protocol code.
@sophoah, as a member of POPS who presented the initial HIP-16 and presented a similar suggestion, I welcome your thoughts on our suggestion.
As for a max key limit or max total delegation suggested above by others, we feel a solution like ours is a more sustainable approach towards increasing the total unique validator count while also providing an opportunity for all validators who exercise conscious and responsible key management to benefit and only adversely affecting those who don’t. We also believe our suggestion limits the impact to delegators compared to the impact that would be realized by hard capping validator keys or delegator delegations while achieving a greater effect in decentralizing the network.