In this post, we analyze Lido operators’ client diversity in the Ethereum consensus layer over time, observing the number of blocks proposed using each client starting from genesis until now. We also give an introduction to what client diversity is, what Lido is, how diversity can be studied, and last but not least, we present our findings on Lido operators.
🔗 All data can be accessed here 🔗
The Ethereum blockchain is made of thousands of nodes running across the world and controlled by multiple entities, ranging from companies to individuals. Each node follows a set of common rules that make all of them interoperable. These rules are defined in the so-called specifications and are split into execution and consensus specifications.
But note that the Ethereum Foundation does not provide the software per se, it just provides the rules that must be respected. Anyone is free to implement their software (referred to as client from now on) in the programming language they prefer and join the network.
Currently, there are 4 different software implementing the execution layer specifications, and 5 implementing the consensus layer:
Clients implementing the execution specifications: geth, erigon, besu, and nethermind.
Clients implementing the consensus specifications: lighthouse, teku, prysm, nimbus, and lodestar.
So each node of the network can run the combination execution/consensus that they prefer: geth/nimbus, erigon/prysm, etc. Note that in this post, we focus on consensus diversity.
Let’s say that the Ethereum network has 5000 beacon nodes. Ideally, we would like that each client has a 20% share of the network so that 1000 nodes run lighthouse, 1000 teku, 1000 prysm, 1000 nimbus and 1000 lodestar.
However, this is not the case. Anyone is free to pick the client they want, and some clients are over-represented in the network. Now you may wonder, why that many software implementations of Ethereum. There are multiple reasons behind this, but the main ones are:
They are written in different programming languages with different use cases in mind
If a software bug affects a given client, the network can continue working. This adds a new level of redundancy, similar to avionics systems in the aerospace industry.
It’s important to highlight that diversity can be studied from two different perspectives: beacon vs validator.
As a quick recap, the beacon node is the software that takes care of following the chain, staying in sync with the latest block, and constantly asking other nodes what’s their view of the chain.
On the other hand, a validator represents a staked position of 32 Eth, linked to a pair of public/private keys, that can create blocks and attestations when it’s its turn. Validators do not directly interact with the chain, they use the beacon node to send their blocks/attestations. So multiple validators can use the same beacon node.
So we can estimate client diversity from two perspectives:
From a beacon-node perspective, estimating which client each node runs. According to migalabs, there are around 6000 beacon nodes (21st November 2022)
From a validator perspective, estimating the client each validator runs. According to beaconchain, there are 472.000 validators (21st November 2022) and each one of them runs a given client.
You can find more on client diversity at clientdiversity.org, both on beacon node and validator level. Unfortunately, both metrics are aggregated for the whole network, so we don’t know the share for specific entities like exchanges, pools, or whales.
In this post, we go one step forward, studying Lido’s client diversity over time since genesis, on a validator level.
Lido is a company that offers liquid staking solutions for different blockchains, including Ethereum. One of the benefits of liquid staking is that you can unstake at any time, and of course, you don’t need to run your validators.
Currently, Lido contains 29 operators that are in charge of running the validators that hold all user’s funds. Since all keys controlled by these 29 operators are publicly known and recognized by Lido, we can query the beacon chain with these keys and hold them accountable for what they do. In this post, we focus on client diversity, but you can refer to ethereumpools.info for their performance.
Note that Lido and its operators currently control around 30% of the Ethereum network (21 November 2022) so if you are thinking about staking, we recommend you to either solo stake (run your node) or use more decentralized solutions with less representation like RocketPool.
For this study we focus on validator client diversity rather than beacon diversity, since for estimating the latter we would need to know the beacon nodes that Lido runs, and that’s not an easy task.
Lido publicly recognizes the validator indexes that they run. And fortunately, sigmaprime developed a tool called blockprint that estimates the client that a given validator uses. Without going into details, it uses a machine learning classification algorithim that classifies the validators using subtle differences in how blocks are proposed.
Disclaimer and Limitations
:
It’s impossible to estimate the client a validator uses with 100% accuracy. Blockprint is not perfect and in some cases, it can mislabel the client.
The client type a given validator runs can only be estimated after a successful block proposal. In other words, we can’t know the client of a validator that hasn’t proposed any blocks.
Lido has acknowledged that some of their operators run vouch, a software developed by Attestant that sits between the beacon node and signer and proposes “the best block” coming from any of the clients, which adds another dimension for diversity.
In the next section you can find all plots backing our conclusions, but if you want something more interactive, you can find the data here. Let’s see what happened from genesis until November 2022:
DSRV, Figment, Chorusone, and Bridgetower are starting to use Nimbus. All of them have used Lighthouse for the whole time but a few weeks before The Merge they started using some Nimbus validators.
We see that Stakely, Nethermind, Simplystaking, CryptoManufaktur, and StakingFacilities are very diverse. They have used most of the clients over time, which makes us think they are using Vouch.
On the other hand Blockscape used to be very diverse, but right now they heavily rely on Lighthouse.
Everstake, Hashquark and RockX are not diverse right now, relying only on Prysm client.
Some operators like RockX massively decreased its Nimbus usage prior The Merge, perhaps they thought it was risky to run a minority client. But its been proven that they perform just like the others, and are well integrated with tools like mev-boost.
Rockx, Skillz, Everstake, Hashquark, Infstones, Blockdaemon, Anyblockanalytics have a high usage of Prysm.
Stakin and Allnodes have a high usage of Teku.
Chainsafe run 100% of Lodestar validators, perhaps expected since its the company behind Lodestar client.
SigmaPrime operator runs a high percent of Lighthouse, expected since its the company behind that client, but we can see that they recently started using Nimbus.
PrysmaticLabs run only of Prysm, expected since its the company behind that client. Note that the are a few blocks labeled as Nimbus, but looks like an outlier, which can be due to a blockprint misslabel.
Rockx, Skillz, Stakely, Everstake, Hashquark, Infstones, Certusone, Anyblockanalyitcs, P2Porg decreased their Nimbus usage before the merge.
We like epoch-based timestamps, but if you still measure time in days, months and years, here’s some help. Data can be accessed interactively here.
Epch 0: Dec 2020.
Epoch 60k: August 2021.
Epoch 100k: February 2022.
Epoch 120k: May 2022.
Epoch 140k: August 2022.
Epoch 146k: The Merge 🐼, September 2022
Before the merge they had a good split beetween Prysm, Nimbys and Teku, but after the merge they almost stopped using Nimbus.
We suspect they use vouch.
From the begining they always had a very diverse set of validators, proposing blocks with all of them but Lodestar.
Started with a really high usage of Nibus client, but really decreased after June 2022.
After the merge, they practically stopped using Prysm validators.
We suspect they use vouch.
They started using Prysm and Nimbus, but its Nimbus usage suddenly decreased few months before the merge.
Currently they heavily rely on just Prysm.
Very similar pattern to hashquark operator. Started with Prysm and Nimbus with a decrease in Nimbus validators few months before the merge.
We suspect infstones and hashquark are running the exact same setup, since the diversity over time exactly matches.
Started using only Lighthouse but started to use Teku few months before the merge. Interesting to see the massive drop in Teku usage few weeks before the merge.
Few months before the merge, they started using some Nimbus client, but still with a low share.
During almost the first year they used only lighthouse, but after that we can see that their setup was very diverse.
However, after the merge they went back to heavily rely on Lighthouse.
We suspect they use vouch, which justifies some spikes in client type.
Started using Prysm and Lighthouse.
Had an increase in Nimbus validators, but they stopped using it before the merge.
Lighthouse is the majority client but we can see some validators running Teku.
Their diversity is quite stable, and didn’t change much with the merge.
In Q2 2022 they started using some Nimbus clients.
Fairly new Lido operator, started with Lighthouse.
After the merge they started using Teku for most of the blocks, and more recently Prysm.
We suspect they use vouch.
Very dependant on Lighthouse.
Started using some Nimbus validators a bit before the merge.
Fairly new Lido operator.
High Lighhouse usage, which is expected since Sigma Prime is the company building Lighthouse.
We can see some Nimbus validators.
They started proposing blocks quite recently, few weeks after the merge.
High usage of Prysm client, which is expected since its the company behind this client.
We can one Nimbus block, but looks like an outlayer value, which might be due to blockprint misslabeling proposals.
Few weeks before the merge they changed from using only Lighthouse to having a more diverse setup, with Teku and Nimbus.
More recently, they started using also Prysm.
Had a huge drop in Nimbus usage around the merge.
They currently use only Prysm and Lighthouse, with very few blocks using Nimbus.
They mainly use Teku and Lighthouse but we can also see some blocks being proposed with Nimbus.
We suspect they are using vouch.
During the first year and a half, they only used Lighthouse.
Over 2022 they started using a more diverse setup, perhaps using vouch.
Its Prysm and Nimbus usage decreased after the merge.
High usage of Prysm.
Nimbus usage was increasing over 2022 but almost went to zero around the merge.
Currently, it mainly relies on Prysm and Lighthouse.
For more on real-time Ethereum validator monitoring:
Al. Rev.