Reasonable, sure. Will it solve all our problems? I don’t think so. Protecting smaller stakers from consensus bugs is good, and we should do it. Penalising correlated downtime is good, and we should do it. Lowering the operational cost of staking is good, and we should do it (except at the cost of hindering our ability to scale). These changes however will not overcome the illiquidity penalty of native staking, nor do i expect them to overcome the economies of scale of centralised staking as service (though help on the margins doesn’t hurt). I also doubt the benefit of bringing particularly threshold signing in protocol outweighs the opportunity cost of other EIPs core devs could choose (like EIP-7716). (Though i do support keeping threshold signing in Lean)
If we don’t want Ethereum to be captured, we need to stop the degradation of its fork choice nakamoto coefficient and withdrawal credential gini index. We need to protect two things, 1) the diversity and sovereignty of the validator sets withdrawal credentials, and 2) the diversity and sovereignty of its signing keys.
Validators overwhelmingly point at a handful of custodial (or third-party upgradeable) withdrawal credentials, the validator set has a gini index of 0.94 and climbing before we look at factory contracts like upgradeable eigenpods, so in practice its even higher. This risks the theft of a large part of the validator set. Something that wouldn’t harm Ethereum directly, but could be extremely socially destructive as well as bad for the price of ether (and thus its ‘economic security’ by second order effect). A protocolised path to exit liquidity would help mitigate this ongoing centralisation.
The hot keys are more difficult to discern, due to the specialty of StaaS providers ensuring their nodes aren’t easily doxxed and clustered (speaking from personal experience running a double digit % of the network and landing in the ‘unknown’ tab on explorers, one should assume most keys in the unidentified section of staking breakdowns to be centralised without other data). With the marginal rate for delegated staking close to and regularly 0% or negative, it is very difficult to see how the delegated staking market will improve without a black swan massive correlated slashing, which we cannot just cause. Hoping that a large % of stake will begin to solo stake is admirable, but not credible in my eyes. A more attainable hope is that delegated parties are not single points of control nor failure in fork choice. Having groups of entities running stake together on behalf of delegators is more trust minimised than having single parties run the stake. A group of 4/7 operators are less likely to collude to do something untoward with that stake. Imagine putting a plan in writing and sending it to the other operators to get their buy in to defect. Multi-operator distributed validators shifts the burden of coordination onto defectors, which makes defection more difficult.
Compare the staking set to the execution layer by analogy. Would we think the EL, L2s, and DeFi are healthy, if the vast majority of eth are in upgradeable smart contracts or opaque EOAs? no. If you are a retail CEX user, are you safer if your eth sits in a metamask that the CEO can access? or a multisig controlled by the team, or better yet, multiple teams? To date we haven’t held the staking set up to a standard near those of DeFi, L2s, nor wallets, and Ethereum’s security and decentralisation is worse for it. Improving the UX of high availabilty staking can help on the margin, but will it change the set radically? I don’t think so. A price to exit, correlated downtime penalties, and a ValidatorBeat are more worthwhile initiatives than taking DVs in protocol for the supposed DevOps benefit imo.