The Ethernodes data has been removed.
The data is a representation of what clients are showing free peers and it's not well understood how this correlates to an overall picture of what clients are currently in use. For now, survey data (from execution-diversity.info) is considered the most reliable source of information for the state of execution client diversity.
Based on 73.9% self-reported network coverage with the remaining assumed to be mostly Geth.
Many know client diversity is important for a more resilient network, but they don't understand why or just how essential it is. It's not only important — it's critical. If a single client is used by 2/3rds (66%) of validators, there's a very real risk this can result in disrupting the chain and monetary loss [1, 2] for node operators.
It takes 2/3rds of validators to reach finality. If a client with 66%+ of marketshare has a bug and forks to its own chain, it'll be capable of finalizing. Once the fork finalizes, the validators cannot return to the real chain without being slashed. If 66% of the chain gets slashed simultaneously, the penalty is the whole 32 ETH.
So why is >33% marketshare still undesirable? If a client with >33% marketshare forks, it will prevent the chain from finalizing. That's why <33% marketshare is the goal for all clients.
Execution clients are not immune. The risks mentioned above apply to both consensus clients and execution clients equally.
| Client | Github | Docs | Chat | Status | Support | Language | Donate |
|---|---|---|---|---|---|---|---|
| Caplin (w/Erigon) | stable | Linux, Win, macOS, ARM | Golang | ||||
| Grandine | stable | Linux, macOS, ARM | Rust | ||||
| Lambda | deprecated | Linux, macOS, Win | Elixir | - | |||
| Lighthouse | stable | Linux, Win, macOS, ARM | Rust |
| |||
| Lodestar | stable | Linux, Win, macOS | TypeScript |
| |||
| Nimbus | stable | Linux, Win, macOS, ARM | Nim | - | |||
| Prysm | stable | Linux, Win, macOS, ARM | Golang |
| |||
| Teku | stable | Linux, Win, macOS | Java |
|
Note: Donations made to Protocol Guild are distributed among Ethereum protocol contributors, including client teams. All recipients and splits can be seen here.
| Client | Github | Docs | Chat | Status | Support | Language | Donate |
|---|---|---|---|---|---|---|---|
| Akula | deprecated | - | - | ||||
| Besu | stable | Linux, Win, macOS | Java |
| |||
| Erigon | stable | Linux, Win, macOS, ARM | Golang | ||||
| EthereumJS | deprecated | Linux, Win, macOS | TypeScript | - | |||
| Ethrex | stable | Linux, macOS, ARM | Rust | - | |||
| Geth | stable | Linux, Win, macOS, ARM | Golang |
| |||
| Nethermind | stable | Linux, Win, macOS, ARM | .NET |
| |||
| Nimbus (w/Nimbus CL) | alpha | - | Nim | - | |||
| Reth | stable | Linux, Win, macOS, ARM | Rust | - | |||
| Silkworm | - | pre-alpha | Linux, Win, macOS | C++ |
Note: Donations made to Protocol Guild are distributed among Ethereum protocol contributors, including client teams. All recipients and splits can be seen here.
| Client | Github | Docs | Chat | Status | Language |
|---|---|---|---|---|---|
| ethlambda | - | - | R&D | Rust | |
| gean | - | - | R&D | Go | |
| Lantern | - | - | R&D | C | |
| Lighthouse | R&D | Rust | |||
| Peam | - | - | R&D | Rust | |
| Qlean-mini | - | - | R&D | C++ | |
| Ream | R&D | Rust | |||
| Zeam | - | R&D | Zig |
| Feature / Property | Vero | Vouch |
|---|---|---|
| Attestation Strategies | M of N | M of N, First, Best |
| Signer | Web3Signer | Dirk |
| Distributed Validator Keys | No, uses whole key | Yes, uses sharded keys |
| Active-active Redundancy | Vero Sponsors only | Yes |
| Ethereum Remote Signing API | Yes | No |
| Slashing Protection | Yes | Yes |
| Slashing Detection | Yes | No |
| Ease of Migration | Designed for simple adoption and rollback | More complex setup and integration |
| Eth Docker Support | Yes | Yes |
| Open Source | Yes | Yes |
| Dependency Surface | Minimal codebase and external dependencies; single maintainer | Large/complex codebase (~5x Vero) and external dependencies; creator retired, codebase maintained by Bitwise |
| Typical Use Case | Simple way to protect validators from client consensus bugs | Highly-configurable multi-node validator setups with sharded validator keys |
Multinode validator clients provide protection against client bugs that can cause validators to vote for an invalid fork of the chain. They do so by combining data from multiple consensus and execution clients, requiring M-of-N connected clients to agree before casting their vote.
When one client diverges or behaves inconsistently, the validator client continues operating through the rest of the clients as long as M of them agree on which fork to vote for. This way a defect or downtime in any single client does not disrupt validation activity.
This approach protects both the operator and the Ethereum network by reducing correlated failures, lowering risks during consensus bugs and improving overall resilience.
See the Multinode Clients section to understand if Vero or Vouch is better for you. Under most situations Vero will cover 99% of usecases including institutional staking operations.
For an automated tool (with a GUI) to switch execution clients,
see Accidental-Green's Ethereum Client Switcher
Error: Select both To and From clients.
There are no guides for this migration yet.
Submit Guide