Open Staking: Improvement Proposals

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!

How about, every validators who already KYC in westart and have validator running during testnet are guaranty elected for 1 slot/validator in mainnet.
If the validator want to have more slot in mainnet, then the next slot will depend on bid.

I will make it simple.

All points that require hard fork: NO. :::::::::: points 1-4 :::::::::::::::
At this point it has no sense hardforking, it would be a mess, leave a bad taste and it would sound like rejecting founding principles of the net. It wont solve anything because as it said, there are easy workarounds.

Number 2… it would probably hurt rewards too much for everyone… I’d say No.

All other points YES.
They are all reasonable and easy to implement points.

Final thoughts:
People joined, invested, moved funds, created validators based on rules, mechanics and REWARDS known and planned for months.
Making big rushed changes just because a “guy with 10k ONEs and his 5 friends” can’t run a validator forever and at the same time hurting the incomes of people or entities that managed to gather attention, enthusiasm and big amounts of funds staked and removed from the circulation, IS THE WORST THING harmony could do.

1 Like

Hey Guildo, in the tezos model, the big validator/delegator will have more tickets right ? hence those ticket would also more chance to be picked. so again here tezos solution doesn’t solve the issue of the rich get richer.

However, I do agree with you, with a lottery system, small validator/delegator has at least a chance (though very small here if you have 1 ticket vs 10 000 or even 100 000 other).

You can’t avoid that who has more coins gets more rewards in absolute value; that would be countereconomical

But you can avoid that the richer gets more than his fair share as posted above.

Simple math

Model without lottery

A got 66
B got 17
C got 17

3 seats available, each with a reward of 1.
A will simply “bid” 22 per seat getting 100% of the rewards. Therefore, he gets 3 as rewards

Lottery
A gets 66 tickets
B gets 17 tickets
C gets 17 tickets

In this scenario, A wins 66% of the seats in the long run. So he gets 1,98 as rewards in the long run, B and C will get 0,51 each

That’s the fair share that in the “bidding” model the big stack can totally beat

1 Like

Hi, SmartStake:

Thanks for the feedback. I agree with all of your assessment on the solutions. They are all mitigations, the decentralization issue won’t be solved completely, it needs a comprehensive system of optimization and changes to achieve it. By nature, centralization will always be the trend in a free market, and all we can do is to add rules and mechanism to push back that tendency.

RJ

1 Like

Hi, Mhevo24:

Agreed with the part that we need to make the node running process as simple as possible to lower the barrier for more small validators to participate. And I see that’s the main factor which can promote more decentralization. As long there is large amount of open slots which keeps the median relatively low, the barrier for entry in terms of stake is not that high for a small validator to enter.

And as the staking percentage grows, opening up more slots to open is the main approach to keep the median stake at a low level. And that’s what we plan to do next.

RJ

Hi, Gaia:

Thanks for the suggestion. What kind of protocol-enforced upper limit on delegation do you recommend? I would imagine with such stake limit, it will just force big stakers to create multiple validator record to circumvent the limit. It may create some hassle to big stakers, but it won’t fully solve the problem.

For the voting power distribution, currently Harmony nodes possess 68% of the voting power to ensure network safety. So the number of nodes that covers the 68% power can be adjusted to smaller number. This way, the external open slots can be increased without increasing the overall network size.

The rewards can be distributed to each of nodes with a small specific number of tokens like 200k, then the remaining rewards will go proportionally to the higher stakes if anything was left.

1 Like

I think it’s vital that we act fast. Many people will write this blockchain off as centralized like what we saw with NEO and EOS. Because of that, I suggest option 2 so that we can implement it swiftly. Along with that, I suggest we rework the validator page to show smaller validators first and also have the “All” page displayed instead of the “Elected”.

1 Like

Another idea maybe is that you had to vote on small delegators to get fully rewards. So that staking in only one validator would reduce your rewards proportionally.
For instance you’d have a voting power of 320 and voting only 1 will get you a very small reward.
This way the voting / staking process I think it’d be more decentralized.

As people have already mentioned, it’d be a good idea to both implement redelegation and expand the slots. However, would expanding the number of slots further shrink the current APR? Wasn’t sure on that.

The goal should definitely be to have as many nodes as possible. That’s what decentralization is all about.

1 Like

this is the only post that makes sense to me in the thread. in any case, drastic change is needed: cosmetic ones will not solve the issue

2 Likes

@sophoah I think this may be modified a bit. It may be better to increase the rewards within the median range as you state but what about the lower bound boost to new validators? Would they receive nothing or be hurt?
How about lowering the rewards for nodes with > 1 key on a shard bidding below 0.65*EMS on said shard? That way new, smaller nodes may benefit from the ER boost and not be penalized all while keeping away low diving nodes from diminishing the lower bounds?

I think this is a good idea to also penalize folks adding more keys aiming for the lower bound.

1 Like

Awesome, once we can get voting working again (hopefully) this would be an excellent candidate for an HIP imo.

I think the solution is to go with the original plan.

The idea of encouraging validators to divide their stake over multiple keys using an upper and lower bound is sound, but the original design required validators to spin up another node to support these additional keys.

This had two advantages:

  • Cost would discourage a validator to get too large with their being a point where the economics of running additional servers verses taking a hit on APR above the upper bound would reach a tipping point
  • The network is supported by a larger number of physical machines, thus greater resilience.

The problem as I see it is at some point the MultiBLS feature was implemented which completely bypassed the server overhead that discourages large validators from taking large numbers of keys. This has also resulted in large validators running up to 13 keys (since HIP 16) on a single physical machine, thus creating single points of failure and loosing the benefit of increased resilience envisioned in the original EPoS design.

My preference would be to see the MultiBLS feature phased out so the true benefit of EPoS can be realised.

Simply put, the MultiBLS feature has nullified the original argument for EPoS.

So lets go back to basics and implement EPoS as it was intended.

@rongjian @sophoah

1 Like

There could be a path towards a situation where MultiBLS with a single node is totally disabled. But quess it cannot be done all of sudden, because it would lead into situation where some validators have to spin up 20+ new nodes and handle them all.

A scheduled plan to reduce max-allowed keys / node could be a possibility to give current validators time to prepare? If current hard limit is 13 because of HIP-16 and 4 shards, it could decrease 3/every quarter. In a year we would be in a situation when there are no MultiBLS external nodes.

This would prepare validators also for a leader rotation. Quess it would need a lot of resources for a node to operate simultaneously as a leader and a validator.

2 Likes