Validators on the Beacon Chain can choose from multiple different software clients, but the vast majority currently run Prysm. This is fine while Prysm runs faultlessly but in the event of a bug or attack all the validators on the network would become victims of Prysm’s success. Having validators concentrated on one single client is a risk multiplier for individual validators and Ethereum as a whole. There are two reasons for this:
- More validators on a single client gives a larger vulnerable population that can be infected by a bug or attack.
- The Beacon Chain has built-in punishments for single-client dominance.
Validators come to consensus on the head of the Beacon Chain by voting in favour of valid blocks and then observing which fork of the blockchain has accumulated the most votes in its history. At the same time, validators vote on the validity of pairs of “checkpoint” blocks. If validators representing 2/3 of the total staked ether agree that the checkpoints are valid, that part of the chain is “justified”. Once that justified section has another checkpoint justified on top of it, it becomes “finalized”. Only then can the chain be considered permanent and irreversible.
With this in mind, we can see why single client dominance is a major problem.
If a client that represents more than 1/3 of the total staked ether has a bug affecting how it votes, the Beacon Chain cannot finalize (because the remaining “correct validators” cannot form a 2/3 majority).
There is a severe penalty for this in the form of the “inactivity leak” which gradually drains away ether from the corrupted validators until the correct validators regain a 2/3 majority. Meanwhile, all the apps and exchanges that rely on finality are stuck, unable to operate normally.
A 1/3 share is problematic, a 2/3 share is a nightmare.
A consensus bug in a client with >2/3 share could cause the Beacon Chain to finalize incorrect information, cementing it forever in Ethereum’s history. There are only two outcomes: one is that the remaining clients accept the bug as expected behaviour from then on, or the corrupted validators start a slow and very expensive exit from the chain.
Thankfully, the tools for avoiding this situation are already available in the form of minority clients! The existence of multiple client implementations is a very strong defence against the scenarios outlined above, but only if the validators distribute roughly evenly across them. This means that the best possible course of action to strengthen Ethereum as it moves from proof-of-work to proof-of-stake is to encourage the major exchanges and staking pools to migrate some of their validators to minority clients an even out the client diversity.
Until now, the community has lacked transparency about the distribution of validators across the various clients in these big organizations. This page solves that problem by reporting the validator count for each of the major validator pools and the proportion of their validators running Prysm. The indicator at the top of the page shows Prysm’s overall share of validators. Any value above 33% should be considered danger zone, and above 66% should be considered an emergency.
The indicators to the right show the same values divided by individual validator pool. They are sorted by how much of the total Prysm usage they represent.