The Ethereum story continues: Clients after The Merge [Part 2]

Ethereum Clients:

In computer science, a client is any software downloaded onto a computer that allows interaction with another software program or service provided by a server. 

Ethereum is a decentralised peer-to-peer network sustained by a globally distributed collection of nodes where each node runs a client to interact with the Ethereum blockchain to broadcast and verify transactions, execute smart contract functions, or reach consensus on the blockchain state.

Given the existence of two distinct networks following The Merge, two clients are required to access these layers:

• Execution Client → Existing Eth1 clients will continue to execute transactions.
  • Listen to new transactions and add them to the mempool.
  • Receive new transactions and gossip them to other execution clients .
  • Bundle transactions into a block, execute them in EVM and generate a block hash.
  • Store and sync state.
• Consensus Client → Beacon Chain clients will continue to execute the PoS consensus algorithm to reach consensus based on the validated data provided by the execution client.
  • Add the block hash and transactions from the execution client to the beacon block. 
  • Gossip the beacon block to other consensus clients
  • Attest (validate) blocks.
  • Track the last finalized block by adding attested blocks to the head of the chain.
  • Receive validator rewards.

After The Merge, nodes will be required to simultaneously run both clients, each with a different role. The execution clients gossip transactions over their P2P network, allowing them to manage their local mempool, whereas the consensus clients gossip blocks over their P2P network, enabling consensus and the finality of blocks. 

The two-client structure can only work correctly if both clients can communicate: 

• Consensus clients must send transaction bundles to execution clients in order to be executed in the EVM. 
• If the node is chosen as a block producer, the consensus client must be able to request transaction bundles from the Execution client to include in the new block.

The Engine API introduces new JSON RPC endpoints to facilitate communication between the consensus and execution layers.  These two clients use a JWT (JSON Web Token) secret based authentication to share encrypted communications with each other. JWT is an open standard for securely transmitting information between parties using a JSON object digitally signed. Nodes can either store the authentication secret as a file or pass it as a CLI parameter. If node owners do not specify a JWT secret, then execution clients usually  automatically generate one. The same secret has to be specified on the Consensus client since clients can only communicate if they share the same JWT secret.

Why a Multi-Client Architecture?

Ethereum has chosen a multi-client architecture to guarantee its security and vitality. Suppose a defect is isolated to a single client. In that case, the network can continue to operate because other nodes running unaffected clients will manage the network while the impacted nodes switch to an unaffected client. 

However, some obstacles are associated with migrating to a Proof of Stake system. Optimal client diversity must be achieved to establish a fair distribution of client software on network nodes, meaning that no client should power more than 33 percent of nodes. A scenario in which most nodes run the malicious software could result in single points of failure and significantly impact the network.

Let us explore two instances of attacks on Ethereum in which a majority client was targeted:

• Shanghai DoS Attacks, 2016 → This attack took Geth nodes offline, and the network had to rely on Parity Ethereum to handle the load.

• Medalla (Beacon Chain testnet) Crash, 2020 → Prysm client, which at the time hosted the majority of staked ETH, had a clock bug, and all nodes went offline, blocking the chain from finalizing. This issue may have been avoided if most nodes had used different clients.

If the Ethereum network had only one client, these attacks would have brought the entire network down. Redundancy is critical to Ethereum’s high availability.

Picking the Minority Client:

Each client has specific use cases, and advantages, and users can select clients depending on their interests. Some actions were taken to encourage the community to diversify their client setups and pick a less popular one to stake their ETH:

• Anti-correlation penalties → Increasing the penalty when multiple validators make mistakes around the same time. 
• Quadratic Inactivity Leak mechanism → Inactivity penalties are usually low but more drastic measures are required when the chain’s viability is threatened by the absence of more than 33% (1/3) of validators, implying that the chain cannot finalize. As a result, inactivity fees will quadratically increase until offline validators’ stakes are reduced to less than 1/3 of the network, allowing the network to finalize again by allowing remaining validators to create the required two-thirds supermajority. 

The Beacon Node: 

Once the execution layer reaches the specified TTD, further blocks will be generated and validated by the Beacon Chain’s stakers. 

Beacon Nodes will connect with its execution client and request that it generate or verify Execution Payloads. After the merge, these payloads are identical to Eth1 blocks. As with the existing blocks, they provide details such as the hash of the parent block, the state root, the base fee, and a list of transactions to execute, as you can see on the picture bellow. Once these have been generated or validated, the Beacon Node will broadcast them to other nodes within the P2P consensus network. 

PoS is designed to be resource efficient and run on consumer-grade hardware from mobile phones to devices like Raspberry Pi. Consensus clients need an Ethereum address to collect the rewards from block production.

The Execution Engine:

After The Merge, consensus and gossip block-related responsibility is removed from these clients.  Their primary focus is network state management, processing transactions, and maintaining transaction pools. 

Executions clients require more memory when compared to Consensus clients since they need to store the entire Ethereum world state locally on their machines.  Syncinc Execution Clients to mainnet is quite challenging in time and disk space. Solo stakers cannot use a traditional hard drive because the nodes database are too IOPS-heavy (input/output operations per second). It’s highly recommended to use SSD instead of HDD. Even if Execution clients were able to sync using HDD, they would possibly working with outdated data and submitting wrong attestations. However, developers working on Ethereum Clients are already trying to improve the syncinc process. 

Go aims to simplify development, whereas Rust solves C++’s memory safety issues while maintaining its incredible performance. Rust is designed to allow you to squeeze performance while Go performs admirably right out of the box. Rust’s improved performance, however, comes at the expense of increased complexity. When compared to traditional languages, Go and Rust are currently performing much better.

ETH Clients Diversity:

The following two graphs illustrate the present client diversity for the execution and consensus layers (at the time of writing in September 2022). 

Geth dominates the execution layer, accounting for more than 80% of the network, followed by Erigon, Besu, and Nethermind, with other clients accounting for less than 1%. 

Prysm is the most popular consensus layer client, accounting for more than 44% of the network, or more than one-third. Lighthouse and Teku account for 33% and 17% of the total. 

When we change the data provider in clientdiversity.org, the data for the consensus layer changes dramatically, with Lighthouse taking first place with 40.25 percent and Prysm taking second place with 39.2 percent. Clients on the Beacon Chain do not always leave clear traces used to identify them, making it more difficult to obtain accurate data. However, it is essential to note that more client diversity is required, as one client currently owns more than two-thirds of the network in the execution layer and more than one-third in the consensus layer.

As previously stated, running a majority client entails more significant risks, and Ethereum has already implemented measures to encourage stakers preference for minority clients.

Closing Thoughts

The Ethereum Foundation has been pushing for more awareness on this for good reason, as more client diversity is certainly required since one execution client is currently accounting for more than 80% of the network, and one consensus client accounting for  more than one-third of the network.

I for one am eagerly following the development of this client distribution and hopefully post merge we will see an increased volume of Ethereum being staked with minority clients.