Client diversity: crisis or distraction?
Contents:
Introduction
What is a client?
What does client diversity mean?
Tracking client diversity
How is diversity tracked?
Can tracking be improved?
Overview of client diversity currently?
Why is client diversity important?
Should anything be done about it?
What is being done about client diversity?
Introduction
What is a client?
Clients are programs (further categorised either as consensus or execution clients) that validators are required to run on their device(s) to allow for multiple on-chain services on Ethereum as well as the performing of duties in exchange for monetary reward. These services/duties include viewing/proposing/attesting to blocks, fetching transactions in the mempool and sending transactions, among others. Without clients it would not be possible to conduct these operations that are essential to the functioning of Ethereum in a correct manner. Some common execution clients in use currently include Geth, Nethermind and Besu with a more formal list of verified programs here. Consensus clients are also necessary to access the services/duties of a validator, but for the brevity of this article, these won’t be discussed in depth. While each client is written in a different programming language and by different development teams, execution clients are intended to satisfy the requirements of the ‘Yellow Paper’, and consensus clients are intended to satisfy the consensus specifications.
What does client diversity mean?
With each client being produced independently with the intention of satisfying intricate technical requirements, it is readily possible for unintended bugs to be implemented. Any single bug can impact the provision of services to validators required to keep Ethereum functional. As such it can be worth tracking how many validators use which particular clients to be aware of the possible risks. Measuring this would be known as measuring the ‘client diversity’. Clients can be known as a ‘majority client’ if above a certain percentage of validators use that particular client (also known as a ‘supermajority’, the significance of which is discussed further below).
Tracking client diversity
How is diversity tracked?
To track how many validators employ the services of any particular client at any particular time would seem a simple question, but currently, there is little in the way of capability to compile such statistics with any guaranteed accuracy. Ethereum allows for clients to communicate when attempting to map the Ethereum networks around them and through this communication it is possible for a ‘client ID’ to be shared - though this is not enforceable.
There has been little attempt to make such data compulsory to share due to how easy it could be for malicious users to obfuscate or modify this field. However, considering the unlikeliness that malicious users would benefit from such actions, it would be conceivable to rely on this methodology; with the caveat that collecting this data would be a computationally intensive task.
Can tracking be improved?
While possible it must be asked if there are more efficient ways to detect client diversity and where does the prioritisation of this task stand in relation to other Ethereum projects? To the former it can be said that there certainly are lessons that can be learned from polling methodologies employed to assess election chances of democratic leaders across the world. Especially in such a space where malicious or incomplete answers can be provided. While this would reduce the caveat of computational intensity, it would still leave the accuracy aspect to be addressed in a more fulsome sense. Often election polls can remain within a certain breadth of accuracy as populations tend to follow certain patterns of behaviour with politics and results tend to be close. However, when it comes to choices of clients there are no particular patterns that can be relied upon and margins between client choices are much larger.
The inability to remove caveats from our discussions here does highlight the point that the latter question posed - are we measuring a crisis in action or distracting ourselves from the future of Ethereum? It cannot be denied that the effort required to properly assess and resolve any issues of client diversity is immense. This effort would potentially be removed from other projects, including Distributed Validator Technology, Danksharding and Verkle Trees. So, what really is the situation with client diversity and what sort of risks are involved if action isn’t taken?
Overview of client diversity currently
While measuring usage of a client is difficult, out of the execution clients mentioned earlier in the article most statistical methodologies suggest that Geth exists as a majority client with significantly more market share than Nethermind and Besu combined. Somewhere between 70% and 90% is often cited as a figure for the usage of Geth. Therefore any major bug that makes its way into Geth would potentially result in all of these validators being unable to participate in the network for some duration of time.
Such a possibility was recently exemplified in January of 2024 when the Nethermind client was brought down by a bug for a few hours before fixes were pushed. While only 5% to 15% of validators use Nethermind, meaning the consequences to the network ended up being minimal, it was a case-study of how something similar could happen to Geth. The Nethermind bug has brought awareness of these dangers has been brought to the forefront and increasingly questions are being asked about the importance of action.
Why is client diversity important?
Should anything be done about it?
Without action on client diversity the financial risks to validators across the Ethereum network, as well as to the network itself, become arguably unacceptable. When a validator’s client is inactive due to a bug or some other fault in the software not only are they unable to earn income but they are also punished some of their stake for inactivity. The reason for this slashing is that there is a need to discourage inactivity, lest the majority of remaining active users are either malicious or faulty. This is where the aforementioned ‘supermajority’ (more than 66% of clients) definition becomes significant.
With a supermajority inactive or behaving irrationally/maliciously, the chance of the network becoming hijacked for criminal use or hacking increases. Had the recent Nethermind case affected a far larger proportion of users the financial resources required for an attack on Ethereum would have become more viable to achieve and sustain. Even ignoring the worst-case scenarios, several tools have been provided online to calculate an average expected financial loss. It can be roughly calculated based on current Ethereum prices that Geth encountering a major bug could cost users of the network anywhere between 40 Billion and 60 Billion $ (as indicated by this calculator as of 28 February 2024).
Despite the potential risks many node operators have observed that the stability and robustness of Geth and other larger clients cannot be ignored. Deliberately employing clients that might be less stable or less performant to target one risk vector could seem impractical. With all the competing considerations involved centralised consensus on this topic has been delayed.
What is being done about client diversity?
We have previously discussed attempts to measure client diversity as well as the shortfalls involved with these various strategies. We have also considered whether such efforts are worth the costs to other development roadmaps. Overall these discussions can be summarised as asking “what centralised strategy should be incorporated to handle topics of client diversity”. But Ethereum has almost always been driven by decentralised workforces, and there is a growing social consensus to take decentralised action here. Below is a table demonstrating the end goals of transitioning from majority clients for several node operators as an example (informed by these discussions).
These changes would see significant progress towards a more balanced ecosystem of clients. To continue to keep abreast of developments in this space and a generalised snapshot of the state of client diversity a useful resource can be found here.
Considering the strategy of diversifying client usage taken upon by some node operators, it is also worthwhile considering deeper research into fields of program analysis. While AI and its capabilities to discover discrepancies between the specs and output of a program is particularly topical currently this is far from the only area of advancement. Between security audits, dynamic analysis, bug bounties and better informed design patterns, there has been significant progress made since the early days of Ethereum towards stable and robust programs.
In addition, Distributed Validator Technology (DVT) posed earlier in this article as an area competing for resources with Ethereum projects such as client diversity cannot be said to be mutually exclusive with these goals. As considered in a previous article, DVT would allow validators to primarily operate a majority client such as Geth with the knowledge that if this crashed it would be easy to switch to another client such as Nethermind or Besu. As such while argument can be made as to the severity posed by the risks of client diversity, no argument can be made to the availability of action that can be taken by development teams or the wider Ethereum ecosystem.
