Open Staking: Improvement Proposals

Hey Nick,

  1. This one is good. however I don’t agree with bigger validator taking fewer seat. It will all depends on the economical game play. they can purposely targetting on taking more slot to eject more small validator. Reason being is that with the current EPOS logic, as long as your total bid for all your keys are in the range of median stake x 0,85 and median stake x 1.15, your overall earning shouldn’t change too much. So they have no incentives to minimize the number of slot taken.

What if we could introduce an incentives for using less key as possible among that range (15% or 30%) ? For instance keys near the 0.85 would earn much lower reward than those near the 1.15.

I know it is already like that today since their effective stake in between would be different, however I am talking here about adding another layer of logic to increase/decrease the final effective stake and the voting power (derived from the effective stake).

Here is in illustration what I am thinking: let’s assume between the range 0.85 - 1.15 we create 3 sub range:
1/ 0.85 - 0.95
2/ 0-95 - 1.05
3/ 1.05 - 1.15

for each sub range, we applied a new logic to incentivized keys in 3rd bucket ie :
1/ would have 10% of their effective stake being taken away/slashed
2/ nothing will happen for them
3/ the 10% taken away from 1) will be equally distributed to keys in bucket 3)

like this validator will be incentivized to use less key and hence free more slot for small validator.

  1. I have the feeling that it won’t change anything without the proposal above

  2. this is definitely something we have to work on, POPS can surely help the small validator, and P2P issue really need to have a fix applied, SOON !

  3. no added value for me. just a hassle for small validator whenever they hit the new limit, because big validator can just create up new validator and move their delegation around, for small validator, we’ll have to let our delegator know, (please undelegate and lose 10 days of reward, and plese delegate to that new validator …, that is a hassle) unless the re-delegation (wihout undelegation) is existing As you mentioned, it is just cosmetic at the end.

  4. definitely a must to do and should be one of the most prioritized item

  5. definitely a must as well, however, I would as well encourage small validator to combine their fund and unite forces. @Samuel | RoboValidator.com proposed for that a solution I like a lot so I would just copy paste here but credit goes to him:

5 Likes

Nick,

I like these suggestions, and I will suggest another. The maximum stake a validator can receive could be limited by the protocol. The validator can chose less than the protocol assigned maximum, but the ceiling is set by the protocol to ensure a smoother stake distribution curve.

On another note, and this might not be the proper thread for this, but if

“We can remove open some of our 680 nodes to the public, but keep our voting power at 68% for safety.”
actually meant to say
“We can open some of our 680 nodes to the public, but keep our voting power at 68% for safety.”

I have to ask, how is that even possible? If voting power doesn’t follow node or stake distribution, what does it follow?

1 Like

hey @Gaia the proposal you are making is the same thing as limiting the number of keys per validator. Whale can still move those fund under a different validator they manage, so it is just a cosmetic improvement here.

Regarding allowing more keys for external validator, it just a different logic that can be implemented, ie here internal slot would keep the same voting power, but each slot for external validator could be half what they have now.

so let me give you an example:
today we have 680 (internal) / 320 (external), but this is assuming all slot has the same weightage
in the future it could be 680 (internal) / 640 (external), the only difference is that now the weightage for the external slot are halved.

hope that helps.

2 Likes

Increasing number of slots, limiting the amount to be stake and increasing the range from the median, people will look to support other validators if the big ones are already full

4 Likes

Another recommendation that you could assess is:

  • Cap the max limit of delegation to a validator based on their self stake. I understand that this will not be a trivial effort because of the way most validators are setup but it certainly does put a cap on the max delegations one can receive and limits centralization to a fair degree. One of the formula that I see being used successfully elsewhere is, if self stake is 1, total delegation can be 100 (100 * self stake).

I realize it is a disruptive change given that the network is live. Just noting this down here more for awareness of such an option.

3 Likes

Excellent! Maybe some of these ideas could be interesting. Airplane Method - a Harmony Improvement Proposal

Much have been said. Adding my 2 cents here:

2 - Increase the number of public slots from 320 - this will definitely help, but I think we should release the hounds and let the network carry the weight of signing / voting as well, sooner than later. Give them the responsibility to learn to crawl before they run. The UX for the Staking Dashboard is completely separate from the core protocol and can be tweaked to de-emphasize some things (like Uptime) in the early days, and emphasize others (promotions of newly elected validators) at different times

3 - Helping smaller validators solve signing issues - the docs are well written enough and yet we have seen some newer validators struggle with this. We can introduce a coaching plan of some sort, pairing up some validators with others. Mutual rewards will appear over time. It could be just be a pipe dream.

6 - Marketing promotion for smaller validators - mentioned above, “Let’s do this!”

I have a new one to propose, which is
7 - Introduce the concept of Re-Delegations - to help
a) boost the confidence of delegators to be early adopters with an ability to do-over once every X epochs (say, we could throttle the re-delegation assignments to not allow for more than one re-delegation every 7 epochs for the same amount of tokens secured with the newly redelegated validator)… and
b) hold validators accountable - if validators promote themselves as one and then all of a sudden either run a poorly performing node, or raise fees with no notice, or maybe just leaves the network haphazardly, there is an immediate recourse that’s possible. posted the discussion here as well – Staking Redelegations

Thanks again for pitching in your mindshare here and focusing yet again on making Harmony better and stronger over time!

3 Likes

This sounds like image washing, too late, you had a chance to limit the number of keys from the beginning but you didn’t.

Changing the rules is not fair to the current elected validators and my coins are already delegated.

Make another Open Staking (lite) for small validators but this time limit the keys to 1 so autonode can be used.

2 Likes

Very interesting post, I just want to add something to the point number 4) removing multi-BLS keys will put all validators(big and small) at the same page, with the same tools to compete for a slot. Of course big validators can split the keys into new/several validators, but they will not be able to “ping pong” with keys, that is exactly what is killing small validators each epoch now. Multi-BLS keys create competitive advantages to big validators. This was my sincere opinion from the beginning, multi bls keys should be an option only for internal nodes, external nodes should only use one key. This worked very good in P2

1 Like

True 4/16 keys would have been enough per validator ! They gave to much flexibility to “big players” maybe this was the intention ,I have no idea :thinking:

hey everyone there!

inspired by the word “open” in the name of Harmony product #Open
Staking

I don’t pretend to resolve the issues raised relatively to fairness of election in our openstaking by this one message on the forum, also I’m not really sure how technically difficult to implement the idea i’m sending here, but i’d like to try to deliver my thoughts to all are presented dudes on this thread who are caring about the current situation.

Key problem #1 highlighted by @nickw

  1. Minimum stake - the amount of stake needed to get elected is going up, leaving behind smaller validators to start getting unelected, and over time churn out.

For me #Openstaking means that everyone validator, whether it’s a big staker with lots of bls keys or a single key node should be in equal conditions at the bidding stage when slots are going to be filled by validators. Also I totally support the initial design of Harmony EPoS that mentioned here, see an extract below,

This statement definitely suits our tokenomics that has on its aim to go to 0 issuance and incentivizes stakeholders to stake more assets they have on Harmony staking.
But at the same time this statement caused the issue we have right now - only because of this we have big validator with many BLS keys bidding for numerous slots and get them - there’s no problem with that if it’s not so painful for the small validaotrs.

And here’s my suugeston, that I see could be a good start point for finding the solution. What if earning slots will be distributed randomly among all the eligible validators to get a slot, that are participating in bidding. Randomness it’s always fair game for every applicant, and random selection makes OpenStaking really open for everyone - I’d like to participate, I go there, I create validator and stake on it and I play a slot lottery. I can win or can play again next epoch. And nobody can affect that except an random selector (generator) only. But there should be compliance terms definitely, to avoid cases when 10k ONE stake validator can get elected and earn when median stake is about 3 000 000 ONE.

Let me describe a RANDOM SELECTION for Harmony validators

  1. Not to hurt our EPoS design and tokenomics I suggest to code on the protocol level eligibility to be elected not only for the highest 320 stakes, but for unlimited number of stakes that bounded by the lowest border at 0.7 * effective median, which is 70% of effective median stake. This means that all stakes which are equal or higher than 0.7 * median stake can participate in bidding for slots.

This doesn’t mean to change our median gradation. In opposite this opens validators with stakes as higher than 1.15 median and less then 0.85 median be involved into elected and EPoS will work as it designed for yellow, blue and green zone validators.

  1. The next statement can limit the number of bls keys per validator because I assume that all the keys of validator will get slots if the validator is elected (if not and validator can bid for number of slots accordingly to the number of keys, but gets less slots - there should be no limits for keys).

So let’s imagine the model when each validator has 4 bls keys max allowed. this time RANDOM SELECTION comes on the scene and the lottery will choose 320 lucky slot winners. It means that all the validators with stakes from the highest and to the last 0.7*median stake will participate in bidding, but slots will be distributed randomly (4 per validator max in our case).

So, in our case we can reach the desired situation when even 1000 of validators can participate in bidding and get elected. Only 320 keys will win. Next epoch it will be other 320 keys (based on random selection)

You can say that big stakers can create more 4 keys validators and share their stake on them, but it doesn’t mean their newly created validators 100% be elected, because of the random selection.

You can say that median won’t grow, but it’s not true, because in this particular case big stakers are more likely to delegate their stake shares to other validators than to spin up more new nodes. Why? - because more validators for them means more paid instances - more expenses, but doesn’t guarantee their validators to be elected every epoch. So, those who doesn’t want to spend money for extra instances will delegate to other and hope for getting income from different validators.

Quote thoughts “I’m not elected now, but couple of shares I delegated to other validator this epoch could be elected and earn for me.”

As a result you can see how simple randomness election for validating slots makes everyone stakeholder to share their stakes among maximimum possible number of validators, because if they don’t do that their stakes won’t earn oftenly.

No more for stake centralization!

Is not randomness a fair choice for OpenStaking?

Guys, share your thoughts below and comment, probably this solution has hidden stones, that are not obvious for me yet.

Thanks in advance

1 Like

What I think it should be necessary is the unlock period to set adequately when those small validators would come play.
It could be like betting.
High returns but inestable nodes vs low returns but reliable, failover nodes. There would be no point to delegate in small ones if the returns and probs to be elected are equal than bigger ones. It could be tilted so that the delegator has risky vs stable options to stake.

Hey @nickw :wave: ,

  1. With a fewer seats for big players ,I guess most of them will disagree, they are not here for peanuts !

  2. Even if you open more external seats , like i’ve said in the last hangouts meeting ,having 106 keys allowed per validator ,these seats it will be “swallowed” precisely by the same big players that will add more keys to their validator ! P.S. HashKey Capital & HashQuark have atm 48/48 slots/keys with 270M tokens staked…What it will them stop to not add more keys if they still have space until 106 ?!? Because at the moment we see so many keys ,not because others don’t wanna be validators ,we see this battle because most of this giants want as much as possible better returns and they cant achive this “higher returns” only by having the flexibility of adjusting lots of keys per validator/node !

  3. Here there is an issue ,because wasn’t nowhere written specification about what are the minimum specs recommended for VPS to run the node “especially having keys in shard 0” and from here we’ve seen those users with uptime/signing issues most of them having keys in shard 0 !

  4. In my opinion reducing the keys allowed per validator ,it means also that we no longer encourage validators to run few nodes with many keys and winning lots of slots with less costs. They will think twice if it is worth to deploy another server and create another validator ,because in this case the delegations will have another impact if the validator has no more flexibility to play with the keys. Of course the risk to see validators with only 4keys allowed and max delegation set it will still exist. But this can be somehow enforced in the protocol for example with: 100M per validator minimum lower cap ,you cant have a lower max delegation cap than 100M , is an idea !

Example:

  • Validator 1 “Giant” has 200M tokens , 4 keys allowed per node.
  • Create validator with minimum delegation cap 100M ( cant be lower than 100M ).
  • Having “–min-lower-delegation” can’t be less than 100M or 50M …

Even If the validator decide to start more nodes and to create more validators, having the lower cap enforced in validator creation and only 4/16 keys allowed per node/validator he will be forced to delegate those tokens/spread them on his validator or anyone else validator and delegations will play a huge role now in this case if there will be no more flexibility to play on a single node/validator and of course there will be no more issues with “giants” receiving only them delegations ,because they will not be able to adjust so easily the staked amount with only 4/16keys allowed per validator and a lower cap that cant be controled by “Validator’s Creator”.

So my suggestion here is 4/16 keys per node max and “–min-lower-delegation 50M/100M” to give majority of the decision to delegators ,if in case the user/entity/partner decides to start multiple nodes/validators because he will be limited by 4/16 keys and having a big bag, wanting to win more slots he will see an opportunity in running more nodes/validators but of course with the minimum cap this it will be somehow filled by someone else if not by himself.
Therefore, the free will “delegators” will dictate in this way the game and not the user/entity/partner with their tons of keys !!!

Adding to point 4:

Median stake 1.5M

C7 Creator 100M tokens available

V1 created 1 node / 4keys with self stake 10K and delegate from other wallet 6M split on 4 keys, he stays in median with bidding for slots and in better returns with good APR ,has space left for delegations but he decide to set --max-total-delegation for V1 to 6M and it will keep adjusting this with more tokens available because it cant adjust it from keys. So ,he creates another validator V2 with same requirements.

V2 created 1 node / 4keys self stake 10k delegate from other wallet 6M split on 4 keys, he stays in median with bidding for slots and in better returns with good APR ,has space left for delegations but he decide again to set --max-total-delegation for V2 to 6M and to not allow more delegation and it will keep adjusting this with more tokens available because it can’t adjust it from keys.

So, how can we avoid this ? Simple !!! By enforcing in validator’s creation “minimum lower delegation” meaning that your max total delegation allowed can’t be less than 50M/100M let’s say, and in this case even if the Creator starts another node and creates another validator ,on previously validators created he will not be able to have the node running only with his own delegations and set it to max delegation for holding multiple validators capped on his desired delegation setted and not allowing other delegations from delegators, adjusting his tokens to stay in median and of course winning more slots with different validators.

We can avoid this with “minimum lower delegation” set to 50M/100M and only 4 maximum 16keys allowed per validator, because the space left it will be filled by other delegators if not by himself and a single delegation made ,let’s say 500k tokens ,can change his APR and next delegators seeing this will move on another validator with better APR and so one , until at some point without a huge flexibility with lots of keys to be able to stay always in median it will create a balance among validators and similar APR for most of them. Therefore no problems for smaller validators because most of delegators look only for “Giants” who has lots of keys for better returns. The dynamic it will change a lot if we lower the number of keys per validator and enforce the max total delegation to not be less than 50M/100M letting to much space for Creators to create lots of validators if they can’t play anymore from keys !!!

  1. Tbh nobody cares about “Uptime” only the validators…Delegators will always look after better APR ,but implementing what I have specified on 4th point can change very much the game if the user/entity/partner who controls the validator it will no more have so much flexibility with tons of keys. The delegations will have a huge impact on APR in this case ! Also I see very dynamic the APR changing and then delegators will definitely look and on other validators , because those with higher stake ( 4 keys only ) at some point will go above median and others will look on smaller one’s until the APR stabilize for everyone :wink:.

  2. Of course we can encourage and promote them , I don’t see a good idea in creating “pools for them” if this is the idea but yes more improvements can be done here !

  3. This is own observation ! “Lukas Drama” is actually “Delegators Drama” because the tokens of this users especially now when we have almost 2 days lasting 1 Epoch and 7 Epoch unbounding period ( 12-14 days at the moment ) are the most screwed and this because, maybe we should have “KYC” for kids or somehow a bigger minimum amount self stake required to create validator , a warranty “longer unbounding period for the amount required for creating validator” maybe pegged to usdt pair because someone said: why minimum 10k tokens ,what if the token price goes to 1$ , so let’s say ONE worth 500 $ to create validator , tokens blocked for 30/60 days idk ,something what can avoid what we have seen with Lukas. Because tbh most of the user/entity/partner has 1 wallet with 10k tokens for validator creation and makes delegations from different wallet/s and when this “dramas” occur being so lower this amount required for creating validator ,maniacs/users/entities/partners don’t give :poop: on those 10k blocked for 7 epoch ,but delegators suffer a lot from this.

  4. We really need “Re-Delegate” with effect from next epoch to avoid “Lukas Drama” and delegators having tokens blocked for weeks bcoz of kids/maniacs/users when it will no worth anymore to be validator if we don’t get out of mud and earned rewards/costs exceed the profitability !!!

  5. I wonder if we can vote for this in the community :thinking: or among validators/delegators…

A) . Do not allow max delegation lower than 50m/100m
B) . Max keys allowed per validator 4/16 depends what we set at point (1) 50/100.

P.S. If anything else comes in my mind ,I will continue to edit this post !!!

Thanks to all of those who will read this :beers:

3 Likes

How about to reduce undelegate from 7 epoch to 1 epoch. And give a change to new validator to be guaranty elected in next epoch after creating validator. With new validator being elected in the next epoch, delegator can see the new validator APR and they can delegate. After that, the new validator will be still elected or not elected depend on total stake vs median stake.

And every validator which not elected can use --active true command and will always be elected in the next epoch after --active true. And the next epoch will depend on total stake vs median stake

1 Like

So, here some i think and write on telegram group…

The lottery thing its a good idea, and calculate APR and somehow show this even on not elected with uptime its a good idea too, limited BLS KEYS to 4~16 agree, and 66% of median stake to get a chance of winning a seat would be nice too, but i have a feeling its missing ONE more thing… like to increase the chance of winnig a little bit, by calculate the total staking, like if some validator have more than median stake, betwen 10% more staking, the chances of get elected increase like a 1% more, if have 20% more than median stake, incrase to 2% more chance, maybe create something to calculate the chances of winning of each validator

And, somekind of change to redelegate, instead of 7 epochs, just 1 to redelegate and 7 to withdraw.

Sorry for my English, its not my main language.

Have a good time guys!

how about sport.

3 ligas!

1 high level, 2 middle level 3 low level. .

example - per level maximum slots with value:

1st league 70 slots / condition minimum invest 50 million ones per server
2nd league. 100 slots / 10 million - 50 million ones per server
3rd league 150 slots /100,000 - 10 million per server

in combination with the random principle as with sports betting (only vice versa).
big investors get a worse quotas (1: 100) on a win, smaller investors a chance of winning 1:10 for slots

1 Like

I proposed the same with airplane seats in my previous comment, but it’d work with Leagues too! Good analogy.
What is the point to view a competition between the Barça and the Regional amateur football club?
Pointless don’t you think?

2 Likes

the same in boxing. A 2 meter man with lots of muscles will always win against a 1.50 meter man who is very thin. that’s why there are classes so that they compete with each other and also have a CHANCE to win. an elephant against a mouse is unfair and the elephant will ALWAYS win, no matter what you do.

1 Like

Hi Nick

This is Giulio from Staking Team.
We have 5 years of experience in staking, and 2 in D-Pos (started with Tezos, but experiences since Dash and Decred to give a timeline) and studied about an hundred chains. We have a fair experience i guess.

Most of the problem you are pointing to can’t be resolved by current consensus protocol.
Median range change: will benefit BIG stakers. The lower end of the tail is already chugged.
Number of slots: will benefit for sure everyone, proportionally. This is something good cause 68% in control of Harmony is a bit too much from any perspective, imho
Points 3, 4, 6: no effect in the long run
Changes to dashboard: Uptime is a much better indicator than APR. We pointed out since epoch 1 even if it was strongly in our favor. Low-quality validators had a luck run in the 2nd epoch, bloated the chat, got 30M delegators… and disappeared. Already known story

The most “open” protocol i know is tezos-like that is a Dpos-derivation of the old masternode concept. As long as you meet the criteria, you get 1 “lottery ticket”. Hitting the criteria multiple time will give you more tickets.

To make a long story short (it’s way more complicated), for every block there is a validator that “wins” the lottery and signs (or 2, or 3, or N validators - Decred like)
While a big validator with 1/10 of all the staking gets in the long run 1/10 of the rewards, he actually gets less than in a scenario where 30% of the votes are “wasted” in small, unelected validators. In that scenario he gets 1/7 of the rewards!
Therefore, even a small validator might get enough to get 1 lottery ticket and “win” to sign some blocks every epoch.
You might have hundreds if not thousands of unique delegators this way.

Added data:

  • Min stake should coincide with the cost of 1 lottery ticket. Say 1 ticket=50000 ONEs. Every 50000 you get another one and so on
  • Every block should have more than a signer, in the case that a poor validator wins the lottery. And even if 10 are signing (and splitting the reward) a great amount of “bench validators” should get it in case someone is offline
  • Uptime will become the real important KPI. You might get above 100% if you sign when someone else is offline
  • Missing more than a certain % of the last X blocks (rolling) you should have signed should get a penalty, like a 2-epoch forced inactivity for the validator and a sort of manual reactivation
  • Like in tezos, a fair % of the self-stake should be a must to prevent malicious behaviors from rogue validators. Say at least 1/10 or so; if you have 100K in self stake you can’t get more than 900K more in delegation

That’s the only way to increase the number of validators. In the current scenario, you’ll get less and less cause big guys will get proportionally way more, fostering centralization

My2c

5 Likes

Awesome experience and new fresh ideas!