Add client-diversity page to /developer/docs

[jmcook1186]

Description

Adds new page to src/content/developers/docs/nodes-and-clients. Page describes current client diversity including newly drawn figure showing proportional representation of execution and consensus clients, explains why client diversity is an important issue and suggests some steps for remediation.

Related Issue

Closes #5194

[gatsby-cloud]

Gatsby Cloud Build Report

ethereum-org-website-dev

🎉 Your build was successful! See the Deploy preview here.

Build Details

View the build logs here.

🕐 Build time: 5m

Performance

Lighthouse report

Metric	Score
Performance	🔶 17
Accessibility	💚 97
Best Practices	💚 93
SEO	🔶 85

🔗 View full report

[minimalsm]

Thanks @jmcook1186, just jumping into a few calls before finishing up for the day but I'll give this a read tomorrow 😀

[jmcook1186]

Also I have just seen this new resource that monitors client diversity on the consensus layer (released today I think). Flagging it for inclusion here until I can commit an update later.

https://clientdiversity.org/

p.s. notice that clientdiversity.org exposes a rest api that could be used to embed up-to-date data for the consensus layer. If there is appetite for this it's probably best done by someone with more web-dev chops than me!

https://migalabs.es/api/v1/client-distribution

[minimalsm]

Hey @jmcook1186, this is great!

I've made a few suggestions (largely UX writing).

The biggest open questions I have:

• Does it make sense for this to live in the docs? Or should it be its own page outside of the docs?
• Where would this have the biggest impact?

[wackerow]

@jmcook1186 Dope! Thanks for putting this together! Definitely a very important topic and in my opinion, the sooner we get content like this up the better.

@minimalsm Agree with your concerns over maintainability here. I think if we move that one section lower then the top majority of the page will still be usable in the future, and we can update the stats periodically as the numbers change (hopefully for the better)

But yeah, in general I think this is great. Left some comments, thoughts and suggestions. Let me know what you think

[wackerow]

To emphasize the point of "why", may be worth making a general note here that if a network has one client and there is a bug, this could be catastrophic, while a bug in one client out of many would likely be insignificant.

[wackerow]

Yeah, I guess I have some hesitation in sticking a "Current client diversity" section in the middle of this explainer.

Client diversity as a topic is important in general... feel like we should focus on the broader topic at first, then get into this further down. Perhaps move this section just above the "Use a minority client" section below? This could help organize the page into the info that changes less or more frequently, so it's easier to maintain in the future.

[wackerow]

Would argue this is one of the more threatening pieces here, and one of the most important points as to why consensus layer client diversity specifically is so important.

To sum this up, if there is a bug in a supermajority client, then over 2/3 of the network are at risk of slashing and losing 100% of their staked ETH, which at today's levels would be a loss of about $15 billion.

Guess my point is, wondering how we could highlight this comment a little more. Anyone running a validator should be aware that it's not in their best interest to be running the majority client. As in the above scenario, those running a minority client would be unaffected, and a similar bug in a minority client would result in negligible lose by comparison.

Maybe as simple as breaking this line out and adding a 🚨?

Suggested change

	### 3) Proof-of-stake finality
	Ethereum has had 100% uptime since the network began. After the merge, the risks caused by poor client diversity become more alarming. A critical bug in a consensus client with over 33% of the Ethereum nodes could prevent the Beacon Chain from finalizing, causing Ethereum to go offline. Worse still, a critical bug in a client with a two-thirds majority could cause the chain to [incorrectly split and finalize](https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/), leading to a large set of validators getting stuck on an invalid chain. If they want to rejoin the correct chain, these validators face slashing or a slow and expensive voluntary withdrawal and reactivation. The magnitude of a slashing scales with the number of culpable nodes with a two-thirds majority slashed maximally (32 ETH).
	### 3) Proof-of-stake finality
	Ethereum has had 100% uptime since the network began. After the merge, the risks caused by poor client diversity become more alarming. A critical bug in a consensus client with over 33% of the Ethereum nodes could prevent the Beacon Chain from finalizing, causing Ethereum to go offline.
	<Emoji text="🚨" mr="1rem" /> Worse still, a critical bug in a client with a two-thirds majority could cause the chain to [incorrectly split and finalize](https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/), leading to a large set of validators getting stuck on an invalid chain. If they want to rejoin the correct chain, these validators face slashing or a slow and expensive voluntary withdrawal and reactivation. The magnitude of a slashing scales with the number of culpable nodes with a two-thirds majority slashed maximally (32 ETH).

[minimalsm]

We can't add an emoji inline as it breaks the subsequent markdown in this paragraph.

But agree with your point that we could bring more attention to this. One option might be to have a callout to this point in the intro paragraph? Not sure if that would be too much without the context laid out here.

[wackerow]

Ah right... so you can, you just need to use an html anchor tag instead of markdown for the link. We do this on our history page quite a bit.

I'm gonna add this back and keep it simple for now. Overall structure looks good as is, think we can discuss if we want to pull this into a callout in the future.

[minimalsm]

I agree with this. It makes the page more maintainable and makes more sense to me from an information architecture point of view.

1. High-level understanding: Why are there multiple clients?
2. Potential problems: Why is client diversity important?
3. The state of play: Current client diversity
4. This solution: Use a minority client

In the current structure, points 2 and 3 are reversed which means people are reading about the current state of play without really understanding why this might be bad.

[wackerow]

This looks great @jmcook1186, thanks a lot for your work on this. Gonna commit two small adjustments then bring this in =) 🎉