From my reading on the EPoS system, the idea was to reduce the amount of stake centralization by incentivizing low stake validators, and capping off high stake validators.
But it seems like all validators essentially have the same expected returns (more or less)
Adding to that the difficulty for new validators to get elected in the first place.
And by a rough calculation the system today follows a perfect Pareto distribution. (Top 20% of validators holding 80% of all stake) And this I would call a failure, you’d might as well just use regular Deligated Proof of Stake as this ratio naturally develops.
So i am genuinely wondering if I am misunderstanding it, or is the system broken or misconfigured?
In my opinion, EPoS is a great idea that hasn’t been implemented properly.
The original justification (as I understand) was it would be more expensive for large validators as they would need to divide their stake up in to multiple nodes to keep their effective stake below the upper-bound.
But, at some point the multi-BLS feature was cooked up that allowed validators to run more than one BLS key on a single node server. Currently, a validator can run up to 13 BLS keys on a single node. This does very little to stop stake centralisation as adding keys is extremely cheap and when validating the empty shards (1 to 3) there is actually negligible overhead to signing with additional keys on a single node.
However… As there are no detailed implementation details of EPoS anywhere, only a few blog posts and comments… it’s hard to know exactly what they had in mind.
To take this one example with multi-BLS - I don’t think this is well known in the validator community.
So are we saying multi-BLS was for initial cost saving while bootstrapping the network, or was it seen a a permanent solution for cheap keys?
As multi-BLS has no tangible benefit for network resilience (many keys on a single machine) or decentralisation (validators are taking many keys because they are cheap, reducing the elected validator pool) I hope it was meant as temporary solution… but because the protocol designers offered no clarity on this we wasted a lot of time arguing over it and getting nowhere.
No reason to look to the past.
I think we should limit BLS keys as a gradual process considering there are not enough potential validators to fill the seats. Limiting it to 1 key per validator would introduce potential attack risk since only 10 000 One (110$) is needed to start one.
Say if we start with limiting to 10 keys, and gradually limiting it towards 1 key per validator over a period of maybe 2 years. (Could this limitation process be automated so each key limitation to activated at x block?) Giving time for new validators to start, and for people to redeligate.
If we can get a clear understanding of why things are the way they are we have a better chance of convincing the validator community to vote on changes in a specific direction.
There will be a lot of push back on removing the multi-BLS feature from larger validators who will be at a financial disadvantage, but if we know that a single key per server was the original plan and multi-BLS was there to encourage easier on-boarding of validators early on in the project then there is a chance such a change will be excepted.
The problem is we need some of those larger validators to take a financial hit for the betterment of the network and vote for change.
We could also look at adjusting the upper bound to allow more effective stake per BLS key of course which would lesson the pain for larger validators.
Just for clarity: multi-BLS is the enabling of multiple signing keys on a single node server. Validators who reach the upper bound threshold are encouraged to add another key or suffer reduced APR. If multi-BLS is removed, this will ,mean adding another node server to the network rather than simply adding another key to their existing node server.
Sure I expect there to be pushback from validators, all the more reason now rather than later. But at the end of the day, it’s not actually the validators that need to be convinced, it is the stakeholders.
Only validators can vote on governance proposals. Obviously most get their stake from many delegators, but from my experience the majority of delegators are passive and show little interest in governance. I wouldn’t count on many delegators leaving a validator due to voting intentions.
You’ll definitely need to convince the validators.
I was merely pointing out the fact that validators do not actually hold the power here. They are elected politicians to vote on behalf of the people to whom has delegated to him. (And supposed to vote accordingly)
I would argue a large amount of delegators are passive due to the fact they don’t know how the governance system actually works or their delegate not informing them of their decisions (But sure there will always be a certain amount of passive deligators anyway).
Epos has its pro and cons. Take the example of Binance, though they have a lot of token stake, their effective stake and power on the network is not as big as other validator. They could use up to 13 keys per shards (ie taking 52 slots in total but they decided not after we mentioned to them the inherent risk of taking all the available slot their stake size allow them to), I thought to give them a shout out on this. Other validator will sure try to maximize their return by spread their keys as max as possible.
There are some really good discussion on this forum you were involved to incentivized a lower use of slot and disincentivized the high slot taker in the lower bound. We can resume those discussion to finalize the proposal and see how we can fit their implementation into our tight resource right now.
It’s great that Binance haven’t taken all those keys and props to them for thinking of the network over staking rewards, but it highlights the inherent problem with EPoS as it stands - the reliance on goodwill in the validator community.
We need to improve the incentives and disincentives coded into the protocol.
Is there a link to any public discussions on the addition of multi-BLS? I’d really like to get a better understanding of the long term thinking behind multi-BLS (if there was any) before formally proposing anything.