The economics of staking has been a hot topic lately. @econoar has done a good job putting the incentives in concrete terms for everyone to digest. See his post on Economic Incentives for Validators and @vbuterin’s post on Average-case improvements to reduce validator costs for some background. In this thread, I want to encourage people to explore the improbable worst case scenarios that could cause the protocol to fail.
A plausible scenario
We all want to believe that Ethereum 2 will be wildly successful. One certainty that comes with success is mainstream adoption, institutional investors, new financial products, etc. This is great, but with it comes the very real possibility that entities that hold (or have access to) large sums of ETH will want to earn interest off of it. We know that Coinbase, Binance, etc hold large sums of ETH in their dungeons. It is logical that they will decide that they want to dedicate some percent of the ETH that they are holding to staking. In fact, I am sure they are already talking about it.
That virtually guarantees that we will have a healthy amount of ETH to secure the chain. This sounds great, right?
Not so fast.
The problem
Entities controlling large sums of ETH represent a existential threat.
Wait. Why is this an issue?
This demonstrates a plausible scenario that could compromise the security of the network if one entity controls more than 1/3 of the stake.
Is there any hope?
Of course.
The point I am trying to make is that we should talk through these scenarios and simulate different ingress and egress distributions to see how the protocol is affected.
Final Thoughts
There are a lot of brilliant people working on different aspects of these problems, but I am disturbed at people’s hesitation to share (even on this forum) until they have had their ideas peer reviewed and formally written up. We need to get over this fear of being wrong and be more willing to receive constructive criticism.
On that note…if anyone has already worked out a solution, ( or if I am just flat out wrong ), then please let me know. I am curious to hear the explanation.
Absolutely correct line of thought. Another thing that our small crew of law people is working on are various legal attack vectors that can be used by and/or against validators to essentially lock up staked funds, or otherwise put a cloud on their title. This can have an opposite worst case effect to the one you describe here in that it essentially forces validators to keep their stake, which is sub-optimal from the perspective of the validator.
Relatedly, the same off-chain legal processes that can enjoin validators from removing funds can theoretically be used to force validators to remove staked ETH. The worst case scenario here is a legal removal order (injunction, seizure, forfeiture, choose your poison …) that conflicts with the protocol, which leads to an outright governance conflict. Off-chain governance norms require one thing; on-chain governance protocols require another thing. That’s a disaster waiting to happen. No way to anticipatorily code around it, so the only way to prepare for it is to … prepare for it.
Working on an analytical piece right now, The Legal Structure of PoS Blockchains. The intercourse between exchanges, validators, devs, and users is central to that story, in manifold ways. If there are issues that you think are priority areas that should be addressed, pls share what you think those are.
The worst case scenario here is a legal removal order (injunction, seizure, forfeiture, choose your poison …) that conflicts with the protocol, which leads to an outright governance conflict.
Thank you for sharing this. Good to know that this is being looked at.
Working on an analytical piece right now, The Legal Structure of PoS Blockchains . The intercourse between exchanges, validators, devs, and users is central to that story, in manifold ways.
Brilliant. I would love to read this when you are ready to share.
If there are issues that you think are priority areas that should be addressed, pls share what you think those are.
I will (and hopefully others) think about other issues that need to be considered and post them here. I have to admit that the legal aspect of this caught me off-guard. It sounds obvious now that you mention it, but I just hadn’t entertained that line of reasoning. I will think on this more.
Thank you so much for sharing. Yeah – saw this come across the wire earlier. Will be preparing a response for sure on behalf of the CleanApp Foundation, given the enormity of the stakes. As it comes together, will definitely post drafts and welcome any and all suggestions for improvement.
Another scenario to consider is the possibility of turning the beacon chain, pow chain into microservices. This could become a serious centralization concern. These microservices would be a great value to validators that want a light weight setup. It is also very likely to be implemented by organizations with large amounts of ETH to stake. If they can connect N validators to a single beacon chain or to a reverse proxy that load balances connections to beacon chains, then we are arguably in the same boat we are today with mining pools
I thought the purpose of these delays is to enable us to slash the validator if any malicious activity from the past is detected after she decided to withdraw?
Speaking of the problem of mass validator exits:
If we have 1024 shards, then we need (I believe) ~150,000 validators to be sure the system is secure (under the honest majority model) and operates smoothly. What happens if this number drops to e.g. 50,000? Does the shards just have to wait more to cross-link (something kind of equivalent to PoW main chain clogging), or…?
So currently with the parameters we have in the event of a mass exit, it would take ~3.3 months in the average case for a validator to successfully exit, this should solve any weak subjectivity concerns given that the last finalized checkpoint would most likely be before the validator exits.
The current spec elaborates on it here:
@MihailoBjelic
In that case the committee size would re-adjust to account for the drop in the number of validators. Although with 50,000 validators you would get an average committee size of 50. The minimum safe threshold for committee sizes is 111, so I would guess in an extreme case like this you would have multiple commitees attesting to the state of a shard which would lead to a longer finalization period for crosslinks. Although this case hasn’t been really elaborated elsewhere
I don’t think it makes sense to reduce the committee size below the 111 validators/shard threshold, because committees basically become “useless” then. Instead, I would lock the committees size once they reach the threshold and then start to assign the same committee to multiple shards. That could do the job unless the drop is really extreme (validators hardware requirements are relatively low so we can’t expect the same committee to validate 10 shards at the same moment). This deserves more formal and in-dept analysis IMHO.
Hi – it took much longer than anticipated (and still not done), but here is the first part. You’ll see that it’s laying the groundwork for the next part of the puzzle, which will be analysis of the legal status of bETH (as well as the contract-ish linkages between stakers and other network participants). But hopefully it is constructive and helpful.