Why is understanding Ethereum’s client diversity so important?

Ethereum has multiple interoperable clients, developed and maintained by independent teams in different languages. This is a major achievement that provides resiliency to the network by limiting the impact of a vulnerability or attack to the parts of the network that run affected clients. However, this advantage can only be achieved if all users are roughly evenly distributed across the available clients. Currently, the vast majority of Ethereum nodes run a single client, putting unnecessary risk on the network.

Ethereum will soon undergo one of the most significant upgrades to its architecture since its inception — the merger from proof-of-work (PoW) to proof-of-stake (PoS). This will fundamentally change the way the network reaches consensus on the true state of the blockchain and maintains network security. This new architecture will bring security, scalability, and sustainability benefits, but it also magnifies the risks associated with this dominance by a single client. This article will explore why…

Beacon Chain

The Beacon Chain is a PoS blockchain. It currently runs in parallel with the Ethereum mainnet, but the two will soon be ” merged ” together. Following the merger, existing Ethereum mainnet clients (“ execution clients ”) will continue to host the Ethereum Virtual Machine (EVM), and verify and broadcast transactions, but will cease to participate in proof-of-work (PoW) mining and give up Responsibility for consensus on the blockchain head (top block). Instead, this consensus will become the responsibility of the “consensus client “, which is responsible for packaging transactions from the “executing client” into ” beacon blocks ” along with the information needed for consensus. Blocks constitute the beacon chain. “Miners” will be replaced by “validators” who need to deposit ETH into an Ethereum smart contract (a process called ” staking”). The ETH staked by validators will serve as collateral to incentivize them to do the validating work correctly . Validators who fail to perform verification work (eg because they are offline) or engage in malicious behavior will result in a portion of their staked ETH being destroyed. On the other hand, validators will be rewarded with ETH if they behave properly.

1. Responsibilities of Validators

For validators, good behavior means participating in validating beacon blocks received from other validators and voting on the blockchain head. If the block received by the validator is valid, the validator will ” attest ” the block, essentially voting for the block to be added to the blockchain. From time to time, a node will be asked to propose a new block , which other validators will “attest” to. When a blockchain has multiple forks, only the chain that has accumulated the most “attestations” in its history is the correct blockchain.

Validators will also occasionally participate in a sync committee, which is a randomly selected group of 512 validators who will contribute to block headers. Sign so that light clients can retrieve these verified blocks without accessing the entire history chain or the entire validator set.

2. Rationalized & finalized

The beacon chain sets the rhythm for the network. This rhythm is organized into two time units: slot and epoch . A slot is an opportunity to add a block to the beacon chain and occurs every 12 seconds. A slot may not have blocks, but when the system is operating optimally, blocks are added to every available slot. The epoch is in units of 32 slots (about 6.4 minutes). Slots and epochs set the rhythm of the Ethereum blockchain.

During each epoch, the block in the first slot is a checkpoint . Checkpoints are important because they are used to make records on the blockchain ledger permanent and irreversible – a two-stage process: First, if all active validators stake ETH At least 2/3 (i.e. “supermajority”) of the balance has proven the two most recent checkpoints (the current one is called the “target checkpoint” and the previous one is called the “source checkpoint”), then the two The block between checkpoints is ” justified “. “Rationalization” is the first step towards becoming a permanent record on Ethereum ’s authoritative chain . Once a “rationalized” checkpoint is followed by another “rationalized” checkpoint, the previous checkpoint is ” finalized “, even if it is permanent and irreversible ( That is, all records before this checkpoint become permanent and immutable records on the blockchain) .

The ” attestations ” that this process of “rationalization” and “finalization” requires from the verifier are actually more complex than those described above. There are two types of proofs: one is LMD GHOST voting , which is used to prove the chain head of the blockchain (LMD GHOST is the fork choice algorithm); the second is FFG voting , which is used to prove two checkpoints ( FFG is the “finality gadget” that rationalizes and finalizes the blockchain). All validators do FFG votes for each checkpoint , while only a randomly selected subset of validators votes LMD GHOST in each slot .

3. Staking rewards, penalties and slashes for validators

  • award

As mentioned earlier, the ETH staked by the validator is used as “collateral” to incentivize honest behavior of the validator. These staked ETH will increase over time as validators are rewarded for participating in securing the network. Validators receive proof rewards when their LMD-GHOST votes and FFG votes agree with most of the other validators. When a validator is selected as a ” block proposer “, that validator is also rewarded if its proposed block is “finalized”. Block proposers can also increase their own rewards by including proofs of misbehavior by other validators into their proposed blocks. These rewards are “rewards” that encourage validators to act honestly.

  • punish

The possible “punishment” for validators is to destroy a portion of the ETH staked by validators in the form of various mechanisms. Validators are subject to attestation penalties when they fail to submit an FFG vote, submit late, or submit the wrong FFG vote . But if the validator misses the LMD-GHOST vote, they are not penalized, they just miss out on the reward they could have earned by voting on the chain head. Validator balances are slashed by the amount they would have been rewarded if they submitted correct proofs . This means that the biggest penalty for an honest but “lazy” validator for missing a proof is to lose 3/4 of the reward he would have gotten if he had proved in a perfect way. Additionally, when a validator is assigned to a ” sync committee “, if the validator fails to sign a block, he will be penalized equal to the value of ETH he would have received if he had successfully signed the block .

Overall, these penalties are modest, and the continued inactivity of validators will only result in a rather slow slash of their staked ETH.

  • forfeiture

Slashing is a more serious action, which results in validators being forcibly removed from the network and associated loss of ETH collateral. There are three ways that a validator can be slashed , all of which are equivalent to a dishonest block proposal or block proof by the validator:

  1. Propose and sign two different blocks in the same slot;
  2. Proof of another block that “wraps around” a block (actually changes the blockchain history);
  3. By doing “double voting” on two candidate blocks for the same block.

If any of the above actions are detected, the validator will be slashed. This means that the equivalent of 1/64 of their staked ETH (up to 0.5 ETH) will be immediately destroyed, and then a 36-day exit period begins: during this period, the validator’s stake will be gradually reduced ; and at the midpoint of this period ( day 18 ), the validator will also be subject to an additional penalty proportional to the total ETH stake of all slashed validators in the 36 days prior to the slashing event . This means that as more validators are slashed, the magnitude of this slash will increase. The maximum slash is the entire valid balance of all slashed validators (i.e., if a large number of validators are slashed, they may lose their entire collateral). On the other hand, a single, independent slashing event would only destroy a small fraction of the validator’s collateral. This intermediate penalty, which varies with the number of slashed validators, is called the ” correlation penalty”.

  • Inactivity Leak Mechanism

If the beacon chain has not been finalized for more than 4 epochs, an economic mechanism called an ” inactivity leak ” will be activated. The ultimate purpose of the Inactivity leak is to create conditions for the blockchain to resume finalization. As explained above, “finality” requires 2/3 of the total ETH stake to reach a consensus on a “source checkpoint” and a “destination checkpoint”. If more than 1/3 of the validators are offline or fail to submit proof of proof, then it is impossible to have a supermajority of 2/3 of the validators to finalize the checkpoint. At this point, the inactivity leak mechanism will gradually reduce the ETH deposits belonging to these inactive validators until these validators control less than 1/3 of the total deposits in the network, allowing the remaining active validators Finalize the blockchain . Regardless of the number of these inactive validators, the remaining validators will eventually control >2/3 of the total stake. This collateral cut will be a strong incentive for inactive validators to reactivate as soon as possible!

The rewards, penalties, and slashes in the beacon chain design encourage individual validators to do the right thing. However, from these design choices emerges a system that strongly incentivizes an equal distribution of validators among multiple clients and strongly inhibits this dominance by a single client. This is because “supermajority” is very important for the beacon chain, a single malicious validator is quite harmless to the network, but a large number of malicious validators can cause serious damage. Let’s take a look at some potential scenarios…

Risk Scenario

This asset-incentivized consensus client diversity is risky. By distributing validators evenly across multiple clients, the impact of a client-specific attack or vulnerability can be greatly reduced, whereas a single client dominance increases this risk. This risk multiplier effect varies with how much of the network a single dominant client occupies.

We can gain more intuition through some hypothetical (but possibly actual) scenarios. Let’s assume that a bug is accidentally introduced into a consensus client that can either directly cause the client to make an incorrect attestation, or expose a vulnerability that enables a malicious attacker to force the client to make an incorrect attestation . So how does client diversity affect the consequences of such a bug?

Scenario 1: Affected clients control less than 1/3 of the ETH stake

This situation provides the beacon chain with the most resiliency, as there are still 2/3 of the staked ETH still proofing correctly , allowing the beacon chain to finalize normally. Therefore, from a network perspective, the consequences of such a scenario are negligible. Affected validators will be penalized for laziness because they submit incorrect proofs. These losses are relatively small, and affected validators can wait for the client to be fixed or switch to another client . Either way, validators can continue to prove correct with minimal economic consequences and without breaking the beacon chain.

Scenario 2: Affected clients control more than 1/3 of the ETH stake

This situation is much more problematic as less than 2/3 of the ETH stake is left to certify correctly, i.e. there is no absolute majority of validators to reach consensus correctly. This means that the beacon chain cannot be finalized and the Inactivity Leak mechanism will be activated . At this point, the bug affects the entire network. For exchanges and Dapps (decentralized applications) built on top of Ethereum, the finality of the blockchain is crucial. If the blockchain cannot be finalized, there is no guarantee that the transaction is permanent. Sexual and immutable. For individual validators who use the affected client, the associated penalties are much more severe , because the activation of the Inactivity Leak mechanism means that the ETH staked by individual validators will be gradually destroyed until the bug-affected client is used. Controlled less than 1/3 of the total ETH deposit, and only then will the beacon chain resume finalization. This ETH burn may actually continue for some time after the beacon chain is restored, providing a buffer against smaller changes in the number of validators. Beacon chain finalization is only in jeopardy if an affected client controls more than 1/3 of the total ETH stake.

In this scenario, validators running other alternative clients normally do not receive any rewards while the Inactivity Leak mechanism is activated. This is a safety mechanism to prevent an attacker from deliberately initiating the Inactivity Leak mechanism, thereby increasing the total reward for other validators controlled by the attacker that behave in the correct way. These are small penalties, but the point is that no one can escape the negative consequences of a consensus bug with a client that controls more than 1/3 of the total ETH stake .

Scenario 3: Affected clients control 1/2 of the ETH stake

This situation could lead to an unrecoverable fork in the beacon chain . If a client with a consensus bug forks to its own chain, neither the original chain nor the new forked chain can be finalized because both the old and new chains are missing about half of their validators and both will activate Inactivity Leak mechanism. At this point, the ETH deposits of the missing validators on the two chains will be gradually destroyed until they control less than 1/3 of the total network ETH deposits, at which point the validators on each chain will be destroyed. Finalization can begin again. This process takes the same amount of time on both chains because the amount of ETH that needs to be destroyed to restore finalization is equal. The two chains will use different checkpoints to finalize independently. The two chains may never merge into a single “authoritative chain”. The solution will require the Ethereum community to reach a consensus on which chain is the “authoritative chain”, a process that is sure to be politically difficult and divisive, resulting in the economic loss of half the community due to switching blockchains (which also Excluding possible depreciation of ETH). Perhaps worse, the community may just continue to split (similar to The DAO incident that led to Ethereum Classic).

To avoid a permanent split of the beacon chain, validators using affected clients will have to race the Inactivity Leak to switch clients, or fix their clients before the blockchain begins to be finalized. There could be a 3-4 week period during which developers will scramble to save Ethereum. In this scenario, for a large number of validators, there is no way to escape significant economic losses .

Scenario 4: Affected clients control more than 2/3 of ETH staked

This is a nightmare situation for the beacon chain , as affected clients control a supermajority of validators and are able to finalize their own chains. In this way, there is a good chance that incorrect information will be permanently fixed in Ethereum’s history. The client team will have approximately 13 minutes to identify the consensus bug, fix it, and broadcast the client update to affected validators before the blockchain starts hammering out illegal blocks.

The only viable mitigation for this situation is for affected validators to withdraw their staked ETH and withdraw from the blockchain. If, after the bug is fixed, these affected validators try to rejoin that correct blockchain, they will be slashed for a “collusive penalty” because the checkpoints they are proving at this point are the same as what they were proving before Checkpointing contradicts and does so collectively . The Inactivity Leak mechanism will be activated due to the departure of a large number of validators, which means that these affected validators will continue to lose their ETH collateral while they wait to withdraw (exit). With a large number of validators to exit, the waiting queue will be long, slow and expensive.

The only other option is for the remaining unaffected clients to accept the bug, join the new chain, and agree that the bug is the expected behavior of the Ethereum consensus layer from now on. This would run counter to the core tenets of the staking community and would be extremely divisive. These few clients will be penalized for laziness on the new chain, even if they behave properly.

Neither option is a good one. The former option is very expensive for affected validators and logically difficult to correct. The latter option would seriously undermine trust in Ethereum and lead us to accept a permanently tainted chain.

other risks

  • reverse finality

If a single client controls more than 2/3 of the total ETH stake, the developer of that client has the ability to choose which version of the blockchain history is correct . For example, if the developers of that client become malicious, they can spend some ETH (such as cashing out through an exchange, or bridging to another blockchain network), and then these developers collectively vote to use another The chain version of the spending transaction replaces the current finalized chain. This is a “double spend” because the client controls the vast majority of validators enabling it to reverse finality and rewrite history. At the same time, the honest minority of validators are penalized for their inconsistent proofs. An attacker who maliciously controls the absolute majority of the total ETH deposit can also threaten to do so and control the network to demand a ransom. Even a malicious team controlling 1/3 of the total ETH deposit could threaten to stop the chain finalization and activate the Inactivity Leak mechanism.

  • shared responsibility

The previous point is a bit pessimistic about client development teams, not because it’s reasonable, but because malicious behavior is possible and therefore needs to be guarded against. However, these developers will most likely always be the good guys, and they themselves need to resist single client dominance, not just because they are likely to be Ethereum users (and ETH holders or stakers), but also because of network security The responsibility should not be concentrated on the shoulders of a small team. The actions of developers have a huge impact on the health of Ethereum as a whole, and their stress and mental health are the real cost. Client diversity avoids this by sharing responsibility among multiple independent teams .

  • centralized

Even if the client-side development team is made up of completely well-intentioned developers, they retain undue power over how Ethereum operates when they control most of the ETH collateral. Decentralization is a core tenet of Ethereum, and this must include the decentralization of developers, users, and custodians. The decentralization of development teams across multiple clients limits their influence on the direction of Ethereum’s philosophy by evenly distributing ETH collateral, thus limiting individual client teams from making critical decisions such as what and when to fork . Client diversity ensures decentralized decisions are made at the developer level .

  • politics

Social recovery  of an honest chain is a politically charged issue. Ethereum’s consensus mechanism should be determined based on rules encoded into its clients – this is its main goal. Interfering with this process could lead to a split in the Ethereum community, resulting in different users having various philosophical, ethical, and technical views on mitigating a consensus bug/attack on a major client. Governance decisions will be unwieldy, disruptive, and may be too slow for maximum effectiveness.

real example

The probability of the above scenario happening is relatively low. The developers are meticulous in researching and testing every update to their software, and there is no reason to doubt the professional ethics of any client team. However, these scenarios are not purely hypothetical either. There have been real-world examples of client diversity saving the Ethereum mainnet from permanent damage, and some consensus bugs also breaking the Ethereum testnet. Some of these examples are presented below.

Shanghai attack

In September 2016, during the Shanghai DevCon conference, hackers attacked Ethereum, exploiting several vulnerabilities in the client software, causing the network to slow down significantly. Attackers persevered, rapidly deploying new similar attacks, while client-side developers raced to reverse engineer and patch them. Ultimately, attackers discovered an unpatchable vulnerability in the Geth client , making the hard fork inevitable. Even after the hard fork upgrade, attackers discovered a denial of service vulnerability that exploited the bloated state caused by previous attacks to force clients to perform tens of thousands of slow disk I/O operations per block. Client diversity won out because while developers worked to fix the vulnerability in Geth, Ethereum was able to continue using an alternative Parity client that didn’t suffer from the same vulnerability.

With multiple clients, the Shanghai attack is recoverable, but if a similar bug affected a majority of consensus clients, the situation could be very different. If a ” consensus client ” had the same dominance as when Geth was attacked, the amount of ether would not be finalized, as most validators would not be able to attest to blocks. Inactivity Leak will be activated as less than 1/3 of the ETH stake is available for proof.

Insecura chain

The viability of a “remote attack” was recently demonstrated on the Pyrmont testnet. The idea is to establish a set of validators to attest to an alternate blockchain history. These validators are then used to trick new validators into joining the dishonest “Insecura” chain, thereby gradually increasing the number of affected validators to the point of disrupting blockchain finalization, activating Inactivity Leak, and draining honesty The amount of ETH staked by the majority of validators. Ultimately, this could lead affected clients to finalize their own version of the blockchain. While the investment of time and money required makes this behavior unlikely to be an attack vector, similar dynamics could lead to a bug in a dominant consensus client infecting large parts of the network.

Medalla Testnet

The number of active validators on the Medalla testnet has dropped suddenly due to a clock issue with the Prysm client. The chain cannot be finalized because so many validators have dropped out of the network that 2/3 of the vast majority of ETH staked is no longer available for proof. Its recovery is gradual, as it relies on validators to switch clients from Prysm to a small number of other clients. Then, the real time catches up with the wrong clock time of the Prysm client, and the previously invalid proof suddenly becomes valid. This caused the Prysm client to stall, while the Teku and Lighthouse clients also suffered huge state bloat from suddenly processing a large number of proofs. If Prysm was the only client on the Medalla testnet, the entire network would have ground to a halt; if Prysm clients controlled less than 1/3 of the total ETH stake, much of the confusion could have been avoided.

Prysm’s deposit root bug

In early 2021, the Prysm client encountered a bug related to Eth1 deposit root verification. At the time, Prysm clients were able to generate invalid deposit roots and pass them to other Prysm nodes. Because Prysm has such a large validator share, this invalid stub quickly propagates across the network, and since Prysm follows a supermajority voting mechanism rather than explicitly validating stubs in every block, it accelerates its spread. Although the impact of the bug was minimal, did not disrupt the finalization of the beacon chain, and did not impose significant economic penalties on validators, the incident demonstrated the importance of client diversity in two ways : First, if The Prysm client has a small validator share, which would limit the spread of the bug across the network and reduce its impact; second, the post-incident analysis article describes how to use alternative client implementations as benchmarks to help developers Personnel quickly identified and fixed the bug. Obviously this is not possible without multiple actively maintained clients.

Current Client Diversity

Why is understanding Ethereum's client diversity so important?

The above picture shows the current diversity of Ethereum clients: the left is the proportion of executing clients , and the right is the proportion of consensus clients .

The two pie charts above show a snapshot of the current client diversity of the Ethereum execution and consensus layers (as of January 2022 writing): the execution layer is dominated by Geth clients, with OpenEthereum clients far behind Second, Erigon client ranks third, Nethermind ranks fourth, and other clients only account for less than 1% of the network. The most commonly used client on the consensus layer , Prysm , although not as dominant as the Geth client on the execution layer, still owns more than 60% of the network, Lighthouse and Teku account for 20% and 14% respectively, and very few other clients use.

Execution layer data was obtained through the Ethernodes website (ethernodes.org/) on January 23, 2022 ; consensus client data was obtained from Michael Sproul (github.com/sigp/blockprint) . Consensus client data is more difficult to obtain because Beacon Chain clients do not always have a clear trail that can be used to identify them. The data is generated using a classification algorithm that sometimes gets a few clients wrong. However, it is clear that most of the network nodes in the consensus layer are running Prysm. Prysm’s advantage was sometimes higher, over 68%. Although only a snapshot, the proportions in the graph provide a good overview of the current state of client diversity.

The client diversity of the execution layer is included in the above figure, because bugs affecting the execution client may also propagate to the consensus layer, because after the merger, the consensus layer and the execution layer will be coupled together and the execution generated by the execution client will be The execution payload will be the core component of the beacon block.

Individual stakers & stake pools

Addressing the problem of imbalanced client distribution requires action by major exchanges and staking pools . However, individual stakers can also play a role by choosing to run a combination of non-Geth/Prysm clients . Instructions for setting up a few clients can be found on this clientdiversity.org page:


For stakers who hold less than 32 ETH or do not want to take on the responsibility of running a validator, there are staking service providers available. Some major centralized exchanges offer ETH staking services, but the distribution of clients in their staking pools is often secretive, and the tradability of ETH-staking tokens offered by these exchanges is limited. For these and other reasons, the use of these centralized service providers is not recommended.

A better option is to use a more decentralized liquidity staking provider such as Lido or Rocketpool. These service providers provide ETH pledge services, and also provide a liquidity token (for example, users who pledge ETH through the Lido protocol will get liquidity stETH tokens), and the value of these liquidity tokens will accumulate with validators. increase in rewards. These tokens can be traded or used to earn DeFi yields. The client distribution of these liquid staking platforms should also be more transparent, for example Lido publishes quarterly updates and Rocketpool now publishes their quarterly updates as well. For users who are unable or unwilling to run their own validators, these services are a way to achieve better client-side diversity.


The reward and punishment protocol of the beacon chain directly incentivizes client diversity. A single client dominance would be a potential threat to Ethereum, invisible when a single dominant client behaves well, but potentially catastrophic when that client has a consensus bug . Having multiple clients is a unique strength of Ethereum and a testament to the hard work of the developer community. However, this effort (of the Ethereum developer community) is undermined when one client controls most of the ETH collateral. Ideally, distribute the ETH stake equally across at least 4 clients, giving each client a maximum of 1/4 of the ETH stake. This is easily achieved by using the production-ready client that is available today.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/why-is-understanding-ethereums-client-diversity-so-important/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-02-16 08:40
Next 2022-02-16 08:46

Related articles