RΞCAP: Ethereum Client Diversity (2024)

Whilst the Solana ecosystem has been frothy in recent weeks, getting hyped up over the new Saga phone, Solana-based memecoins like $BONK, as well as a number of airdrops that have been promised to users across the network, the Ethereum community has been taking some time to reflect on how it can ensure it is one of the most resilient chains and maintain its position as the leading smart contract blockchain. Despite being the dominant public blockchain that has supported smart contract functionality, since 2015, in light of the growing competition from newer Layer 1s, such as Solana, Ethereum is still far from perfect - with a number of significant milestones that are still to be reached on its busy roadmap.

One of the areas that has bubbled to the surface and received more attention recently has been the state of Ethereum's client diversity or the lack of it (spoilers, it's still pretty good). For those that aren't super familiar with how the Ethereum network operates, this article will be a crash course in this, as well as dive into the detail of the client diversity debate.

Let's get started!

TLDR: Ethereum Has Client Diversity - But, It Could Be Better.

WTF Is Ethereum 2.0?

Before diving into the detail of client diversity, it is important to have a good grasp of Ethereum's new architecture following the Merge - one of the most significant milestones in Ethereum's evolution - with the network transitioning from Proof of Work (PoW) to Proof of Stake (PoS).

As a blockchain, there needs to be a trustless and secure way for the distributed ledger to be constantly updated in a way which is resilient to fraud and different attacks that could look to disrupt it. As such, a set of rules is needed to goven the network and ensure that this is the case. Due to there being no centralised actor to enforce these rules and ensure that only net-positive actions take place, the network itself needs to do this; so blockchains rely on consensus mechanisms so all of the parties that constitute the network can come to an agreement through a set of rules that is baked into the network's code itself. It is through these consensus mechanisms that everyone can agree on the state of the network and any updates to the ledger.

Historically, Ethereum, like Bitcoin, relied on a PoW consensus mechanism, whereby miners used computational power to solve complex cryptographic puzzles to validate transactions and create new blocks. The Merge (September 15th 2022) transitioned Ethereum to a PoS consensus mechanism, which eliminates the need for energy-intensive mining. In PoS, validators stake $ETH as collateral to participate in transaction validation and block creation.

The Merge

Whilst mainnet continued, albeit with modifications (thereby still acting as the execution layer), an additional chain that had been running in parallel to mainnet was merged with this. It was this mechanism that was used to transition Ethereum to PoS, with Beacon Chain acting as the new consensus layer - thereby taking over as the main consensus mechanism for the entire network, retiring the energy-intensive PoW model.

This transition enabled:

• Enhanced security, with $69bn in economic security (thanks to staking).

• Strong foundations for a more scalable network (thanks to Beacon Chain being the base infrastructure that unlocks the potential of sharding in the near future).

• Further decentralisation, through a more inclusive validator ecosystem (thanks to liquid staking).

Looking Under The Hood - Layers, Nodes, & Clients

Layers

The transition of Ethereum to Ethereum 2.0 has meant that mainnet now has two separate layers - the execution layer and the consensus layer, which both work together to sync the Ethereum state - and these have their own respective nodes (as represented by the different coloured blocks in the diagram above).

The Execution Layer (Ethereum mainnet): This layer is responsible for handling transactions, smart contracts, and the overall state of the blockchain.

Whilst previously existing as the mainnet of the previous iteration of Ethereum, the execution layer is still a vital part of Ethereum networking stack. In simple terms, the client software creates blocks of transactions (putting "block" into "blockchain") and executes smart contracts.

Nodes on this layer will be focused on:

• Implementing EVM (Ethereum Virtual Machine) - this is the sandboxed virtual stack embedded within each node (perform block-by-block validation of the chain). Executes bytecode and ensures that smart contracts are executed in an isolated environment.
• Communicating - with other execution nodes and its local beacon node.

• Transaction Processing - receiving, validating, and executing transactions.
• Smart Contract Execution - handles the computation required to carry out the instructions defined in smart contacts.
• State Management - maintaining a record of all accounts balances, code, and smart contract storage. The execution layer updates this with each new block.

The Consensus Layer (formerly Beacon Chain): Introduced before The Merge, the Beacon Chain ran in parallel with the Ethereum mainnet, operating a PoS consensus mechanism without handling mainnet's transactions or smart contracts.

This layer runs in parallel to the execution layer and nodes on this layer will be focused on:

• Implementing the PoS consensus algorithm of the network - enabling it to reach an agreement based on data (transactions and blocks) that has been validated by the execution clients.
• Communicating - with other beacon nodes, and its local execution node.
• Block Proposals - consensus clients help nodes propose blocks of transactions that need to be added.
• Checking Proposed Blocks - ensuring blocks are correct and follow the protocol rules.
• Agreement - ensuring that the network can come to an agreement, determining the next valid block in the blockchain (aka "consensus") as well as preventing any disagreements/clearing up any confusion.
• Ensuring Order - consensus clients also help track the correct order of events on-chain as blocks get added.

Nodes

So where can these layers and their respective nodes be found?

As these layers represent two different software layers of the Ethereum network, we need to look at the software and hardware that allows these layers to function. This is where we need to take a look at nodes. By node, we are referring to hardware that runs an Ethereum client (software that lets users interact with the Ethereum blockchain), as well as facilitating:

• Block-by-block validation of the blockchain
• Storing the blockchain's data
• Serving the network and providing data on request.

As seen in the diagram above, the execution layer and consensus layer have their own clients that enables the layers to function. But before taking a look at these, it is helpful to understand the role nodes play in maintaining the Ethereum network.

Full Nodes

• Functionality: download and validate every block and transaction in the Ethereum blockchain. They independently verify all the rules of the Ethereum protocol.
• Storage Requirements: Require significant storage space as they store the entire Ethereum blockchain history.
• Network Role: Act as the backbone of the Ethereum network, maintaining the network's security and integrity by ensuring consensus. Without staking $ETH, a full node participates in the network by verifying and relaying transactions and blocks, ensuring the integrity and availability of the blockchain data.

Light Nodes

• Functionality: Light nodes download only the headers of the blocks in the Ethereum blockchain and request additional data from full nodes as needed. This allows them to verify the validity of the data without needing the entire blockchain. They verify transactions (whether correctly formed and signed), but do not execute them, as they are reliant on full nodes for this.
• Storage Requirements: Require much less storage space compared to full clients, making them suitable for devices with limited resources, such as mobile phones or laptops.
• Network Role: Enhance the network's accessibility and scalability by allowing more users to participate without needing the resources to run a full client, as well as ensuring that transactions are propagated to other nodes, such as full nodes.

So, although many refer to nodes as singular entities, there are technically different compositions of nodes within the network, due to the two layers of the Ethereum blockchain that need to be interacted with via execution nodes and beacon nodes and their clients.

What should be noted here is that only full nodes can be validators as they require both execution and beacon nodes to secure the network effectively. For proposing, creating, and agreeing on new blocks, validators are rewarded for their efforts, but at a cost. Not only are there the operational costs of the hardware to consider (which are much lower than when the network ran on PoS, as seen earlier in the article) it does it cost 32 $ETH (a deposit that can be withdrawn at a future point in time) to set-up a validator on a node. There are also penalty-related costs for any actions that harm the network's best interests (see more on slashing).

For more on validators and staking, feel free to check out a previous WΞB3 RΞCAP article:

Clients

And finally, we come to the crux of the matter - clients. We've mentioned these above, but what are they?

Whilst closely related to nodes, clients are simply software applications that power their respective nodes, implementing the Ethereum protocol and can broadly be categorised into two categories based on the aforementioned layers: execution clients (that handle the execution of transactions and smart contracts) and consensus clients (that are responsible for PoS-related activities). N.b. validator clients are only needed if running a validator.

The node itself is ultimately controlled by the client software it runs, meaning that this software plays a vital role in underpinning the Ethereum network.

Execution Clients:

• Geth (Go Ethereum): Written in Go, Geth is the most widely used Ethereum execution client.
• OpenEthereum (formerly Parity Ethereum): Written in Rust, focused on speed and efficiency.
• Nethermind: A .NET-based client known for its fast syncing and enterprise features.
• Besu: An Enterprise-grade Ethereum client written in Java, compatible with both public and private networks.
• Erigon (formerly Turbo-Geth): A Geth fork that focuses on performance and scalability, with reduced storage requirements.

Consensus Clients:

• Prysm: Written in Go, Prysm is a leading Ethereum consensus client designed for the Ethereum 2.0 PoS network.
• Lighthouse: A Rust-based Ethereum 2.0 client focusing on speed, security, and modularity.
• Teku: Developed by ConsenSys, Teku is a Java-based Ethereum 2.0 client designed for enterprise use, supporting both testnets and mainnet.
• Nimbus: Designed with resource-restricted devices in mind, Nimbus is an Ethereum 2.0 client that aims to perform well on embedded systems and personal mobile devices.
• Lodestar: A JavaScript Ethereum 2.0 client, focusing on light clients, developer tooling, and interoperability between different blockchain protocols.

That's An Overview Of The Stack: So, What Is Client Diversity & Why Is It Important?

Client diversity in the context of blockchain networks, refers to the ecosystem supporting multiple software implementations of the network's protocol. These different software clients can be developed by various teams, each with its own codebase, programming language, and optimizations, but all adhere to the same underlying protocol specifications.

In the context of Ethereum, as we can see from the above, there are a number of different clients used across both the execution and consensus layer. Given this, if we look at the current state play regarding client diversity and distribution, we can see that, whilst there is some diversity - there is a clearly dominant force within each category of client:

Although Go Ethereum and Lighthouse are dominant forces in the Ethereum client landscape, Ethereum is someway ahead of its Layer 1 peers with competitors such as Solana being incredibly centralised.

So, why is this such a big issue and why do we need to see more diversity?

The high level reason for this approach is that independently developed and maintained clients ensures that Ethereum is decentralised from the bottom of the stack, upwards.

Go Ethereum highlights what some of these vulnerabilities and risks could be here, highlighting that both software operator and mainnet could be affected.

For the network to be truly decentralised, secure, and even more resilient, we need to see this client diversity increase and their are multiple reasons for this:

Resilience Against Network Failures and Bugs

• Single Point of Failure Mitigation: By having multiple clients, the network is less vulnerable to a bug or exploit affecting a single client. If one client encounters a critical issue, not all nodes will be impacted, and the network can continue to operate smoothly using the unaffected clients, whilst the affected client is patched.

Security Enhancement

• Diverse Defense Mechanisms: Different implementations can lead to varied security features and approaches to threat mitigation. This diversity makes it more difficult for attackers to exploit the entire network since they would need to find vulnerabilities in multiple clients rather than exploiting a single, universal flaw.

Decentralization and Participation

• Broadening Participation: Client diversity allows participants to choose a client that best fits their needs, preferences, or technological constraints. This can lead to a broader, more diverse group of participants in the network, enhancing its decentralised nature.

Innovation and Optimization

• Competitive Innovation: Multiple clients encourage continuous improvement and innovation as teams work to optimize performance, usability, and features.

Whilst this may be the noble quest for Ethereum builders and community members, it isn't without a set of challenges. Things such as interoperability and consensus challenges due to differences in client implementation should be kept front of mind, as well as coordination considerations particularly when the protocol goes through significant upgrades (to enable new features and protocol changes), as if these things are overlooked, there is the risk of things such as chain splits or degraded performance of the blockchain. As with anything, a lack of standardisation can increase the burden on developers and security analysts to ensure that these different implementations are quality assured before deploying.

What is reassuring, however, is that with the continual growth of Ethereum ecosystem developers there has never been more eyes on the Ethereum network. The beauty of Open Source building is that whilst not all of these developers will be working on the low level infra of the Ethereum stack, they will be using it on a regular basis and so sharing their thoughts and feedback with others in the community; it is a joint responsibility of those contributing to the ecosystem that we make Ethereum as robust as possible and as an ecosystem we move forward together.

Given this, all I can say is that I'm doing my bit to help client diversity thanks to Dappnode - running Ethereum at home on my own node:

There are hundreds of other things that I could have mentioned in this newsletter, but it's already pretty long as it is, so I'll save these topics for other articles.

Think I've missed something important? Want to dive into more detail?

Let's chat in the comments!

And feel free to share this article to broaden the discussion.

All comments within this newsletter represent my own opinions and not my employer's. Nothing within this newsletter constitutes financial advice.