Native DVT for Ethereum staking

[serenita_luca]

An interesting proposal, though it seems to go against the ongoing efforts of:

• reducing consensus overhead (e.g. via validator consolidations) - enshrined virtual DVT identities would cause additional network overhead which is currently contained “in-cluster”. With 2048 staked ETH, n <= 16 and a validator at MAX_EB, this would still be better than 64 x 32ETH validators but it feels like taking a big step back. Instead of consolidating the overhead of 64 validators into one, we’d be “consolidating” into 5, 7 or even 16 - a significant increase from the ideal status quo.
• reducing protocol complexity

With the additional network overhead in mind, maybe this would need to be coupled with something like this in-place - LMD GHOST with ~256 validators and a fast-following finality gadget - #6 by vbuterin (I’m a big fan of that general idea), or perhaps a further MAX_EB increase?

---

I’m doubtful this proposal will have some of the intended desirable effects though.

@vbuterin

Help security-conscious stakers with medium to high amounts of ETH (both individual whales and institutions) stake in a more secure M-of-N setup, instead of relying on a single node (this also makes it trivial to get more gains in client diversity)

This is mostly my skepticism speaking but gains in client diversity have historically been extremely hard to achieve. Even with DVT options available today, we are frequently seeing operators run DVT clusters powered by only 2 different client pairs, protecting validators from downtime while completely failing to protect from the much more dangerous threat – consensus bugs.

@vbuterin

Help such stakers stake on their own instead of parking their coins with staking providers, significantly increasing the measurable decentralization (eg. Herfindahl index, Nakamoto coefficient) of the Ethereum staking distribution.

I don’t believe requiring such stakers to run multiple machines with different client pairs will make this option very attractive compared to what is available today. Such entities are probably quite capable of running out-of-protocol DVT options, Vouch+Dirk or a couple of Vero instances.

I agree something needs to be done about Ethereum’s stake distribution and its centralizing trend. But I don’t think enshrining DVT will help much at all. I’m currently working on an idea that could help a little on this front but I’m 100% sure we will need more ideas to revert the existing trend.

@vbuterin

It also simplifies participation in existing decentralized staking protocols, reducing the client load and devops experience to something equivalent to the most basic form of solo staking, allowing such protocols to become more decentralized and more diverse in their participation.

This I can see happening, and it would be good for decentralized staking protocols, and by extension Ethereum.