Protocol Level changes to the EPOS system POLL and DISCUSSION

Governance Validator DAO
1

A poll of proposals to enfranchise validator network expansion and limit the possibility of 33 percent attack against any one shard.

Currently we have two proposals aimed at expanding the validator pool.

HIP 11: HIP 11: Decentralization Support Meter

This proposal was written with the intention of informing the delegators about validator bidding practices as a way of promoting a more efficient use of keys.

HIP 16: HIP 16: reducing BLS keys - #45 by Maffaz

This proposal was written with the intention of reducing the size of larger validators by limiting the number of keys.

Within this proposal came about several suggested alternatives.

*Max delegation

*Max keys per node

*Max delegation per wallet

*Max keys per node and max nodes per validator with shard balancing

*Rewards rate slashing for the lower bound affecting validators with more than 5 keys

There was an additional idea presented today; like HIP 11 it provides information to delegators and allows them to decide. It provides a cutoff line and a warning to delegators that delegating to validators above this line could result in a possible network takeover. We will identify this as 33 percent line.

stake line
stake line1011×853 35.5 KB

There is huge demand for change at the protocol level. Most will agree that while the protocol allows it, whether profitable or not, validators will consume additional keys. The only difference of opinion is on what is the best possible solution to this issue at the protocol level.

I would like to gain feedback and a general consensus on what the majority of validators believe will net positive change while causing the least harm to validators and delegators.

The end state is to write a formal HIP proposal that has buy in from the validator community.

Debating the merits of each approach is highly encouraged. However, at the end of the day please choose an option on the poll so that we may move forward on creating a proposal that has enough support to pass a governance vote.

  • Key bid efficiency meter
  • Max delegation
  • Max keys per node
  • Max delegation per wallet
  • Max keys per node and max nodes per validator with shard balancing
  • Rewards rate slashing for the lower bound affecting validators with more than 5 keys
  • 33 percent line warning

0 voters

5 Likes
2

My vote is for max of 4 keys per node. This requires more expensive infrastructure and incentivizes the most efficient use of keys while possibly opening up slots for the validator pool to grow. This will also increase the number of nodes on the network making it more secure.

1 Like
3

I do think there is a possibility of implementing the two or three of the proposal as here.

The 33% line warning is really needed as well as the rewards rate slashing for the lower bound for validators with more than 5 keys.

2 Likes
4

I do like the 4 max key idea but I don’t think the demand of validators is at the level yet. I think it will be a good think to implement once we start having more validators join (around the 600-700).

I decided on reward slashing for Validators that use more than 5 keys then they already have. I feel like it will limit them but still allow them to expand a bit more if they chose too. There shouldn’t be any reason why they should have over 5 in the first place but we all know that they do whats best for the numbers they want to put out.

2 Likes
5

Thank you for bringing this up :+1:

Voting for 33 percent line warning

An initial harmonious step. This has already proven to be helpful for other chains so to give some level of justice to Decentralization. This is not a perfect step but an initial harmonious step!

Delegates would be knowledgable to decide who to openly stake, as eventually ALL the validators would have same Uptime, ER over time as continuous improvement, optimizations, feature enhancements are being made on the network. This would provide equally inclusive opportunity to ALL the validators and delegators.

A greater choice will be made ensuring delegations shouldn’t be bound and decided by the factors such as Uptime, ER and engagements.

Kratos would see a greater value add as this would give a pathway to onboard close to (218-120) = 98 NEW potential validators (based on the current epoch 679). As of now, the 98 validators have been awaiting and has been paying the infrastructure fee so to get harmoniously elected.

They would be really motivated if they get a good chance to get elect. We believe, motivation embarks positive engagements.

Thus, this is going to massively scale the election process in favor of as many validators to be elected

More example:
218 individual validator(s) are always better than current (120). For Instance: Imagine if ONE of the TOP validator holding 80+ validator keys slots goes down, then the impact will be directly on the finality of the network due to degradation ( due to partial outage).

Nice Read on "What Does It Mean to Be “Decentralized”? @ What Does It Mean to Be “Decentralized”? | by Samuel Harrison | Harmony | Medium by Samuel Harrison :clap:

Regards,
Kratos
ONE vision, ONE team

8 Likes
6

I no longer have a validator so I will leave this 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 crummy 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:

  1. If you have more than 10 keys the system won’t let you bid past 600 or 3/4 line when Validators expand so the number is flexible.

  2. 0% fee for 50 epochs
    5-100 million mandatory 5% fee
    100-200 million mandatory 6% fee
    200 million above mandatory 7% fee

  3. Eliminate lower bound

  4. Change from 7 epochs back to 1 liquidity is king

7

I don’t think anything that relies on human intervention / descion making should be implemented.

Other chains may have similar issues but that does not mean we should follow.

Imagine if Harmony is the first chain that does not allow any validator to be in any position to take down the network (limit keys per node / assess recent uptime %) and instead of the focus being on stake weight, we focus on stable infrastructure.

We have the benefit of experience from Harmony and many other chains and the solution imo is to build it into the protocol so that no single validator can be in a position to screw things up, maliciously or unintentionally.

I don’t see why we have to ‘punish’ anyone OR allow someone to have enough power to actually take the network down.

The protocol should not allow this to happen.

Random assignment, proof of uptime / syncing and no-human intervention should allow validators to focus on community and infrastructure rather than the ‘game’ of bidding for election.

There are some good proposals above but I believe that there is also a combo option that could work.

It is clear that fairness for ALL validators, decentralisation and attracting new members is something that everyone can agree on and will benefit the whole community.

I would ask @sophoah @lij @rongjian what the options / limitations are and maybe propose some sort of solution that is feasible to reach this goal.

3 Likes
8

As a delegator and not a validator. I would vote for limiting the amount of validators who can bully the validators I’m supporting in their quest for election.

Protocol growth and adoption is the goal. Won’t happen if new validators can’t be elected. If the people who’s coins they are holding can’t get returns. This will force people to pull coins and also a validator to throw in the towel. This impacts protocol stability potentially down the road. This hinders a new audience from that validator in his approach to marketing.

4 Likes
9

I do like the 4 max key idea but I don’t think the demand of validators is at the level yet. I think it will be a good think to implement once we start having more validators join (around the 600-700).

I decided on reward slashing for Validators that use more than 5 keys then they already have. I feel like it will limit them but still allow them to expand a bit more if they chose too. There shouldn’t be any reason why they should have over 5 in the first place but we all know that they do whats best for the numbers they want to put out.

I’m with you on this one :+1::blue_heart:

1 Like
10

I do like this idea, but I’m not sure that we are ready for that just yet. That’s going to cause a chain reaction of things and we don’t always have enough help available to handle the influx of inquiries and support requests from new users and newly elected validators, and other things such as this. And it’s hard to say how many of these validators that have been sitting idle will actually sign when elected. Who knows what kind of headache that could cause for Harmony period. All of us lol. This is a great idea though :thinking:

1 Like