Client diversity is a critical metric for LSTs in order to be protected from any potential bug or exploit of a specific client, which could lead to a correlated slashing of all validators using it. This slashing would be even bigger if the affected client is a majority one.
At the same time, it’s also a relevant matter to measure Ethereum network health, as if a supermajority client exceeding 2/3 had such a bug, it could have fatal consequences for those using that client, and, consequently, for the entire network.
I am - and surely many other Ethereum users and protocols interested in ETHx - interested in being able to see Stader’s client distribution to evaluate the risks and protection ETHx has against any of these black swan events regarding clients. Also this data would allow the Stader community to:
Develop client diversity initiatives to advocate for people to avoid majority clients for the sake of the network and their own in case of a majority client bug.
Push for Stader’s client diversity among new permissionless NOs and also among those willing to switch their clients for this initiative
It’s also true that this metric has been quite difficult to track, as the clients been used by each node does not reflect directly on-chain, and it’s yet to be find the best way to do it, but an approximation is already good for people to evaluate which clients to choose.
My intention with this post is to understand team’s perspective on this and if they have already something planned to track and show this data. Also wanted to gather some community feedback on which is their approach to client diversity and if anyone has more insights on how the data could be tracked.
Yes, I fully agree to this. That the importance of client diversity is not just hypothetical has been shown last month when Geth 1.13.0 shipped with a critical bug that could cause blocks being rendered invalid and thus the chain stalled on the affected server. I’ve witnessed this first hand on one of our Goerli nodes. Good thing was that a revert to an older version of Geth solved the issue and this is maybe why we haven’t seen greater damage on mainnet. And a bug fix was also released rather quickly.
What I love about Stader in this regard:
To what I’ve observed so far, all client releases are thoroughly tested before they make it into a Stader release, so Stader was not affected by the bug I described above.
Although permissionless operators can select their preferred clients during setup, the default is that clients are selected at random, ensuring client diversity from the start.
Strongly agree with this post. I believe that having a good and diversified client distribution, specially keeping low the majority clients, is a core metric of an LST. This makes it resilient and protected from any client bug or exploit as @Marc-Blockshard has pointed.
My main concern around this topic is that Allnodes x Stader combination has been a blast, as the lower bond has made running a validator possible for many people who couldn’t do it before. This has lead to a big chunk of validators to be on Allnodes, who run all of them in Geth & Teku (also being Geth a supermajority client according to https://clientdiversity.org/), which likely would make Stader’s client distribution not as good as it should.
I hope that Allnodes’ performance tests with other clients suceed and they offer people the possibility to run different clients when setting up their node, so that would partially solve the issue.
Also there has been some ETH influx to the permissioned pool lately, so asking these permissioned NOs to avoid both Geth and Teku would help balance the client distribution.
This is something to take into account, but while finding the best way to track it more accurately, even a roughly approximation with Allnodes weight + Permissioned pool, showing the rest as “unknown”, would work in the meantime.
That Client Distribution Dashboard would allow the most proactive members to show more visually other NOs why they should be switching to minority clients not only from the network itself, but also from Stader client distribution.
Thank you for raising this important point and for your keen interest in enhancing our network’s resilience and security. Client diversity is indeed a crucial metric in ensuring the reliability and robustness of the Ethereum ecosystem.
We are happy to inform you that tracking client diversity is already on our feature backlog radar, and it is a feature slated to be addressed in our future development efforts, with a targeted feasibility testing in Q1-2024.
Currently, our focus is on rolling out priority features that cater to enhancing the overall user experience, expanding the node network, and bolstering security. Understanding and measuring client diversity can be complex, as it doesn’t always directly reflect on-chain activity. We will actively explore ways to provide an accurate and valuable approximation of this metric for the community. We’ll also keep the community informed about our progress when we start scoping this feature early next year.
Thank you once again for bringing this to our attention, and we look forward to your continued engagement and feedback as we work towards strengthening the Ethereum network together.