Note that Nimbus tends towards privacy by default making it harder for crawlers to detect it - nevertheless, the magnitude of the skewed client distribution in the above image still stands
Last week we saw a small incident occur on the Beacon Chain (see here for a more complete write-up). Many users, across all clients, reported a noticeable increase in missed attestations, and participation rate was down a few percentage points.
The root of the issue was traced to a staking provider running too many validators on one machine with the same client.
While it didn't drastically affect the health of the network, the potential implications are concerning.
In particular, the issue would have been much less pronounced under a more even client distribution.
While in this case there was no threat to finality or normal operation of the Beacon Chain, the fragility it exposed remains. Next time we might not be so lucky.
If there's one metric we need to be paying close attention to in the run up to the merge, it's the distribution of clients across the network.
As it stands, if something serious were to go wrong with the Prysm client the Ethereum network post-merge could be prevented from finalising (note that this is true for any client with > 33% share).
This is especially important in the context of the merge, since the current model of joining eth1 (execution layer) and eth2 (consensus layer) means we'll have a significantly greater amount of complexity to deal with.
To put it simply, more complexity means more room for things to go wrong.
Whether you are an exchange, a staking provider, or an individual staker, if you care about the future of Ethereum, then it is your duty, at this stage, to facilitate and promote the use of minority clients.
P.S. If you'd like to give Nimbus a try, either as an individual, or as part of staking pool or provider, please get in touch with us on discord. The team will be more than happy to answer questions you may have, and help you get set up.