TL;DR: Decentralized networks rely on nodes running a diversity of open standards and applications including peer-to-peer networking protocols, consensus algorithms, APIs, and open-source software. Following the Ethereum Merge and the move to PoS, core functionality powered by execution and consensus clients becomes uniquely critical to the network’s future success. A network leveraging multiple, independent consensus and execution clients ensures Ethereum validator nodes operate effectively, securely, and without disruption.
There are currently over 490,000 validators on the Beacon Chain with some 15 million staked ether. Below we’ll discuss, in detail, how client diversity contributes to a resilient network, protocol incentives for client diversity, and options for consensus and execution clients. We will also touch on new frontiers for diversity considerations and how the community can help build Ethereum following best practices.
The Basics of the Post-Merge Ethereum Virtual Machine Client
Following The Merge, execution and consensus clients operate together to verify the network’s state. Understanding how this software works through nodes to create the Ethereum Virtual Machine (EVM) is essential to understanding why consensus client diversity is critical. Skip down to the next section if you’re set on the basics of how EVM operates.
EVM is a distributed state machine composed of hardware, standards, and applications including but not limited to physical nodes, peer-to-peer networking protocols, consensus algorithms, APIs, and open-source software. Physical disbursement of nodes—electronic connection points in a communications network—is only one, albeit critical, element of decentralization. Nodes operate software to execute EVM functions and transmit cryptographically signed instructions from smart contracts. Post-Merge, nodes use execution and consensus clients to perform these operations.
The execution client listens for new transactions to disseminate network-wide, executing them with EVM parameters and storing current data for future use. The consensus client runs code relevant to the Beacon Chain to enable the network to achieve consensus by validating the transmitted data. A node is an instance of Ethereum client software connected to other computers also running Ethereum software. The “nodes” comprise the EVM and execute smart contracts, running the execution and consensus client software that broadcasts and verifies the transactions, to create a decentralized computational network.
Execution and consensus clients, therefore, play an integral role in the operation of the network. Node operators all over the world ensure geographic decentralization of the network, which is why it’s important for those who can to consider operating a node. However, client diversity ensures the decentralized nature of the entire network by eliminating single points of failure with too many nodes running the same client software.
Client Diversity Basics
Skip down to the next section if you’re set on the basics of consensus client diversity.
There are a variety of production-level Ethereum clients that fall under the separate umbrellas of “execution” or “consensus”. These clients are built to a common spec so that they are interoperable, but developed and maintained by separate teams.Client diversity refers to the idea that, ideally, there is roughly equal representation of various client software in operation across the network’s nodes. The Ethereum Foundation states that “ideally, no consensus client would ever reach a 33% share of the total nodes.” Unfortunately, Ethereum has not yet achieved client diversity. Currently, two consensus clients each have over 33% of market share and a single execution client is responsible for 78% of the execution client market.
Reaching the client diversity goals outlined by the Ethereum Foundation will take time, effort, and community coordination to counteract inertia, particularly in the case of execution clients. Geth developers launched a product in 2014 while Nethermind, Besu, and Erigon launched in 2018, 2019, and 2020 respectively. Geth has history, name recognition, and momentum despite efforts to promote the need for software diversity. Node operators must consciously opt into using minority clients to combat the current reality. The primacy of consensus clients to EVM, on the other hand, only materialized after The Merge in September 2022. As such, diversity in consensus clients shows more promise.
Why Does Ethereum Prioritize Client Diversity?
The underlying software powering blockchain infrastructure contributes, in large part, to the decentralization of the network—or lack thereof. When the software stack has centralized points of failure due to an overconcentration of one code or implementation, the network becomes less secure and potentially unreliable. For this reason, prioritizing client diversity on Ethereum strengthens the network by eliminating the vulnerability of overreliance on any one consensus or execution clients.
Client diversity provides:
Resistance to Bugs
Bugs and exploits can cause software failures of which two forms exist, those that harm the operator and those that harm Ethereum mainnet. For example, nearly 70% of the network currently uses Geth. According to this software developer, the following vulnerabilities would directly impact the network:
- Consensus vulnerabilities, which would cause a chain split,
- Denial-of-service during block processing, whereby a malicious transaction could cause the geth-portion of the network to crash.
- Denial-of-service via p2p networking, whereby portions of the network could be made inaccessible due to crashes or resource consumption.
Because of the potential severity, Geth will sometimes patch and ship fixes without notifying the network and has bug bounties and other security measures in place. However, the network can protect itself from bugs by diversifying the execution clients used, thereby limiting any potential damages to a minority of the network. This essentially creates a backup plan for node operators.
Resilience to Attacks
Client software powers network nodes that transmit smart contracts and power trades making attacks a lucrative and appealing target for bad actors. The open source, transparent nature of blockchains demands development best practices, the use of bug bounty programs, and other security measures, not covered here, to help protect the network from attacks. Client diversity, a method of resilience the network itself can facilitate, allows Ethereumto guard against attacks targeting a specific client.
In 2016, Ethereum experienced a DoS attack targeting Geth clients (we aren’t picking on Geth; as stated earlier, it has significant history with and momentum in the community). Ethereum weathered the attack without needing to pause the chain by leveraging available alternative clients.
Mitigating Risks to PoS Finality
When a blockchain finalizes, committed blocks cannot be reversed, altered, or canceled. Transaction finality gives Ethereum, and other blockchain networks, their "immutable" quality. Users can depend on the fact that committed transactions cannot be changed or deleted..
For the network to function properly, two third of validator nodes need to agree on transaction finality forEthereum’s Beacon Chain to complete this task. A lower rate of consensus puts the system at risk of forking and creating monetary loss to node operators. If no client has over 33% market share, it greatly reduces the risk to PoS finality and chain disruption.
The worst-casesituation for Beacon Chain finality would occur if greater than two thirds of validators experienced a bug impacting consensus. This creates a fork to an incorrect chain. To return to the canonical version of Ethereum, slashed validators must withdraw and re-stake 32 ETH. This situation is outlined below by Ethereum core developer Dankrad Feist:
Prysm clients can't switch to chain B or they will get slashed for surround votes. So they will start draining their balances on B via inactivity leak, until it finalizes. In this case they would lose at least 75% of their stake.
— Dankrad Feist (@dankrad) September 22, 2021
While this scenario is high risk, low probability, it highlights the criticality of Ethereum software diversity.
A Greater Division of Responsibility
Having multiple clients spread across multiple teams eases pressure on developers and allows for collaboration among different groups. This is at the heart of the Ethereum ethos. Rather than having a single team responsible for maintaining the network, client diversity enables multiple teams to contribute to success.
Diversity amongst clients also promotes growth. Having different implementations expands the number of languages available to potential builders, allowing for a larger ecosystem and, ultimately, more innovation.
Protocol Incentives for Client Diversity
The design of Ethereum's PoS reward mechanism inherently disincentives one client from capturing a majority of market share. It does this indirectly via penalties built into the consensus process:
Quadratic Inactivity Leak
If a validator on the Beacon Chain is dishonest or fails to perform their duties, they can be penalized. Standard inactivity penalties are relatively low, but not insignificant, and apply to validators that miss attestation opportunities. Inactivity can prevent the chain from finalizing, because the system requires two thirds validator consensus, which threatens liveness—an essential quality for any distributed system, not just blockchain technology.
If more than one third of network validators come inactive, the Beacon Chain triggers “inactivity leak” mode, draining the balance of inactive validators. This ensures inactive validators no longer represent over one third of the network’s total staked ether, allowing finality to resume.
This penalty is known as a “quadratic inactivity leak” because it grows quadratically marking it extremely harmful to the ETH balances of inactive stakers. If a client with over 33% market share triggered inactivity, all stakers running that client would need to quickly upgrade their validator to avoid penalties.
Correlation Penalties
Slashing represents the most dramatic penalty an Ethereum validator potentially faces. There are three specific actions that can trigger slashing:
- If a proposer signs two different beacon blocks for the same slot;
- If an attester signs an attestation that “surrounds” another one ( an attester contradicts a previously finalized attestation);.
- If an attester signs two different attestations with the same target.
Our guide to Ethereum slashing outlines how and why these penalties are assessed.
If, for example, 10% of network actors commit a slashable offense at the same time, it is far more likely that they are acting in collusion than a single validator committing a one-off slashable offense. In this case, a more severe penalty, known as the correlation penalty, applies. The correlation penalty automatically adjusts the severity of slashing penalties for specific validators based on the number of other validators that committed a slashable offense over the same period.
Correlation penalties increase the potential monetary loss to colluders but it also encourages client diversity. Client bugs that could simultaneously trigger slashable offenses create the potential for correlation penalties to be triggered. Minimizing reliance on majority clients greatly reduces this risk.
Client Diversity Options
Validators should consider running minority consensus and execution clients to contribute to client diversity. Below, we outline the available options for validators. If you are not a solo validator, you can still champion client diversity and contribute to the conversation. If you stake with a third party, research and ask what they are doing to contribute to client diversity.
Consensus Clients
Below are the most popular, available consensus clients. The options listed here compare in terms of their low degrees of risk, maintenance needs, and the ROI they provide for your validator. These clients differ in regard to their architecture, features, and resource requirements. A full comparison of options is available via our guide to Ethereum consensus clients.
Prysm
Prysm is an open-source consensus client that was the original supermajority client for Ethereum consensus. It includes an optional web app UI focused on user experience, documentation, and configurability for both individual users and institutions. (Prysm was also critical in supporting the client diversity movement by championing the use of minority clients.)
Lighthouse
Lighthouse is a consensus client implementation designed to be secure and high-functioning in a wide range of contexts. It has been available since the original launch of the Beacon Chain. Various enterprises, staking pools, and individuals rely on it.
Teku
Teku is an original Beacon Chain consensus client that provides stakers maximum flexibility with its deployment options. The beacon node and validator client can be run together as a single process for solo speakers, or nodes can be run separately for sophisticated staking operations. They focus on creating enterprise-grade clients and tools for Ethereum's core platform.
Nimbus
Nimbus is a reliable and fast client used by both solo-stakers and staking pools. You can run it smoothly on devices with limited resources. For instance, if you are considering running an Ethereum validator on a Raspberry PI, Nimbus is the clear favorite. Nonetheless it is also capable when used via enterprise infrastructure.
Execution Clients
With Geth still dominating the execution client market share, execution client diversity remains a top concern. Validators should consider switching to a minority client. Here is an outline of the available execution client options for validators.
Geth
Go Ethereum (Geth) is the Ethereum protocol’s original client. It has the biggest user base and a wide variety of tools for users and developers.
Erigon
Erigon was created as a fork of Geth with a focus on speed and disk space efficiency. By providing a more modular, faster, and optimized implementation of Ethereum, ERigon generally outperforms Geth when syncing full archival nodes.
Besu
Hyperledger Besu is an enterprise-grade Ethereum client that supports all Ethereum Mainnet features. It runs on public and permissioned networks, has extensive monitoring capabilities, and is developed under the ConsenSys umbrella.
Nethermind
Nethermind is a high-performance Ethereum implementation that runs on all major platforms. It offers features like Prometheus/Grafana dashboards, seq enterprise logging support, JSON RPC tracing, and analytics plugins.
A New Frontier: Relay Diversity
The Ethereum Merge introduced a new factor for software diversity. The switch to PoS introduced the block builder, made possible by a protocol sidecar called MEV-Boost.
MEV-Boost represents the implementation of proto-PBS (Proposer/Builder Separation) on the Ethereum network. MEV relays use MEV-Boost to allow validators to communicate with block builders. Blocknative operates one of the roughly a dozen available relays.
“Relay diversity” represents the idea that validators should be mindful of connecting to as many MEV relays as possible. This ensures that the Ethereum network is not overly reliant on a single team or piece of infrastructure.
Currently, Flashbots relays ~80% of all MEV-Boost blocks. Since MEV-Boost is used by ~80% of the network, that means Flashbots controls ~64% of the total Ethereum blockspace (MEV and non-MEV).
Source: https://transparency.flashbots.net/
Currently, 93% of all relays are running a Flashbots-based implementation which means that if there is a bug in that implementation at least 386K proposers would be badly affected. The situation could be significant enough to potentially cause the Ethereum blockchain to produce several empty slots in a row. It could even become a DOS vector.
To mitigate this risk, improving relay diversity is essential. Network resilience is dependent on having a diversity of software at every level of the stack. Ideally, that diverse software is also open source.
Flashbots was an exemplary community member by ensuring that their relay was open-sourced before the Ethereum Merge date. But since then, Blocknative’s Dreamboatis the only other open source relay implementation. The other relays that are available are either Flashbots forks or relays that have not open-sourced their code to allow for public review vs Flashbots.
Open source code is vital to the web3 mission because it allows anyone in the world the ability to review the code, be inspired, and run their own instances. This creates security at the network level. Open sourcing is always the ideal default status for core Ethereum infrastructure that seeks to increase software diversity.
The call specifically for relay diversity has been echoed throughout the ecosystem with Coinbase and Lido calling for validators to utilize an abundance of relay options:
6/ Specifically, relays must perform their core functions reliably–ensuring that block proposal opportunities aren’t missed and that proposers are always paid the promised amount. We are eager to work with any relay operator that can meet these conditions.
— Coinbase Cloud (@CoinbaseCloud) November 1, 2022
That this has already become a talking point amongst the community is a great sign regarding the potential for relay diversity. Since PoS Ethereum consensus and the process of utilizing MEV-Boost is so new, there is time to adjust the behavior of validators and the network before network actors become stuck in their ways.
If you are a validator, we encourage you to connect to all relays that you feel comfortable utilizing (not just the Blocknative relay). Doing so is a small but meaningful contribution to the overall health of the Ethereum network.
Blocknative’s Commitment to Ethereum’s Software Diversity
Whether you're a solo staker or using a staking service, being mindful of client diversity and promoting the use of multiple MEV relays can help protect against potential attack vectors and increase the resiliency of the network.
To support our world-class pre-chain web3 dev tools, Blocknative operates multiple nodes utilizing a diverse set of clients. Different clients have different characteristics, and behave differently under load. Our client diversity helps ensure that we maintain an accurate view of global mempool conditions while also providing operational redundancy.
We are also looking to support new MEV relay operators and block builders that want to join Ethereum’s proto-PBS ecosystem. If you would like to fork Dreamboat to run an independent relay or have questions about becoming a block builder, we suggest reaching out via our website’s contact form or our Discord.
There’s never been a more fascinating time to collaborate and work on Ethereum’s pre-chain layer. Together, we can achieve the highly secure, highly decentralized, Ethereum of the future.
