Why is it so important to understand the client diversity of Ethereum?
Author: Joseph Cook
Original compilation: Nanfeng, Unitimes
Ethereum has multiple interoperable clients, developed and maintained by independent teams in different languages. This is a significant achievement that provides resiliency to the network by limiting the impact of a breach or attack to the portion of the network running the affected client. However, this advantage can only be realized if all users are roughly evenly distributed across the available clients. Currently, the vast majority of Ethereum nodes run a single client, introducing unnecessary risk to the network.
beacon chain
beacon chain
The beacon chain is a PoS blockchain. It currently runs in parallel to the Ethereum mainnet, but the two will soon be "merged" together. Post-merger, existing Ethereum mainnet clients (“Execution Clients”) will continue to host the Ethereum Virtual Machine (EVM) and verify and broadcast transactions, but will stop participating in Proof-of-Work (PoW) mining and forgo Responsibility for consensus on the blockchain head (top block).
Instead, this consensus will be the responsibility of the "consensus client", which is responsible for packaging transactions from the "execution client" together with the information required for consensus into "beacon blocks". The blocks form 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 be used as collateral to incentivize them to complete the verification work correctly. Validators who do not perform validation work (for example, because they are offline) or perform malicious behavior will cause a portion of their pledged ETH to be destroyed. On the other hand, if validators behave well, they will be rewarded with ETH.
1. Responsibilities of validators
For a validator, 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, effectively 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 "prove". When a blockchain has multiple forks, only the one that has accumulated the most "attestations" in its history is the correct one.
Verifiers will also participate in a sync committee from time to time. The sync committee is a group of 512 randomly selected verifiers. These randomly selected verifiers will check the block headers. Signing so that light clients can retrieve these verified blocks without access to the entire history chain or the entire set of validators.
2. Rationalized & finalized
The beacon chain sets the pace for the network. This rhythm is organized into two units of time: slot and epoch. A slot is an opportunity to add a block to the beacon chain and occurs every 12 seconds. A slot may have no blocks, but when the system is performing optimally, blocks are added to every available slot. The unit of epoch is 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 checkpoints are used to make records on the blockchain ledger permanent and irreversible — a two-stage process: First, if all active validators have staked ETH If at least 2/3 of the balance (i.e. the "supermajority") attests to the last two 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 another "rationalized" checkpoint appears after a "rationalized" checkpoint, the previous checkpoint is "finalized", that is, it has permanent and irreversible ( That is, all records before this checkpoint have become permanent and immutable records on the blockchain).
This "rationalization" and "finalization" process requires verifiers to perform "attestations" that are actually more complex than those explained above. There are two types of proofs: one is the LMD GHOST vote, which is used to prove the chain head of the blockchain (LMD GHOST is a fork selection algorithm); the second is the FFG vote used to prove the two checkpoints ( FFG is a "finality gadget" that rationalizes and finalizes the blockchain). All validators vote FFG for each checkpoint, while only a randomly selected subset of validators vote for LMD GHOST per slot.
award
award
As mentioned earlier, the ETH pledged by the validator is used as "collateral" to incentivize the honest behavior of the validator. This staked ETH will increase over time as validators are rewarded for participating in securing the network. When the LMD-GHOST vote and FFG vote made by the validator are consistent with the majority of other validators, then the validator will get the proof reward. When a validator is selected as a "block proposer", if the block it proposes is "finalized", the validator will also be rewarded. Block proposers can also increase their own rewards by including proof of misbehavior by other validators in their proposed blocks. These rewards are "rewards" that encourage validators to act honestly.
punish
The "punishment" that the verifier may receive is to destroy a part of the ETH pledged by the verifier in the form of various mechanisms. Attestation penalties are imposed when a validator fails to submit an FFG vote, submits late, or submits the wrong FFG vote. However, if the verifier misses the LMD-GHOST vote, he will not be punished, but will miss the reward that could have been obtained by voting for the chain head. Validator balances are slashed by an amount equal to the reward they would have received had they submitted correct proofs.
This means that the maximum penalty for an honest but "lazy" verifier for missing a proof is to lose 3/4 of the amount of reward he would have received had he done the proof in a perfect manner. 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 mild, and validators' continued inactivity only results in a fairly slow cut to their staked ETH.
confiscated
A more serious action is slashing, which results in a validator being forcibly removed from the network and associated loss of ETH deposits. There are three ways a validator can be slashed, all of which are equivalent to a validator making a dishonest block proposal or block proof:
- Propose and sign two different blocks in the same slot;
- Attestation to another block that "surrounds" a block (actually changing the blockchain history);
- By "double voting" on two candidate blocks of the same block.
If these actions are detected, the validator will be slashed. This means that 1/64th of their staked ETH (up to 0.5 ETH) will be destroyed immediately, 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 receive an additional penalty proportional to the total amount of ETH pledged by all slashed validators in the 36 days before the slashing event .
This means that as more validators are slashed, the magnitude of the slash will increase. The maximum slash is the entire effective balance of all slashed validators (i.e., if a large number of validators are slashed, they could lose their entire stake). On the other hand, a single, independent slashing event would only destroy a small portion of the validator's stake. This intermediate penalty, which varies with the number of slashed validators, is called a "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 inactivity leak is to create conditions for the blockchain to resume finalization. As explained above, "finality" requires 2/3 of the total ETH deposit to reach a consensus on the "source checkpoint" and "destination checkpoint". If more than 1/3 of the validators are offline or fail to submit a proof of proof, then it is impossible for a 2/3 supermajority of validators to finalize the checkpoint.
At this point, the Inactivity leak mechanism will gradually reduce the ETH deposits belonging to these inactive validators until the deposits controlled by these validators are less than 1/3 of the total deposits in the network, allowing the remaining active validators to Finalize the blockchain. Regardless of the number of these inactive validators, the remaining validators will eventually control >2/3 of the total stake. This staking cut will be a strong incentive for inactive validators to reactivate as soon as possible!
Rewards, penalties, and slashing 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 disincentivizes this dominance by a single client. This is because the "absolute majority system" is very important to the beacon chain. A single malicious validator is quite harmless to the network, but a large number of malicious validators may cause serious damage. Let's take a look at some potential scenarios...
risk scenario
This asset incentive consensus client diversity is risky. By evenly distributing validators across multiple clients, the impact of client-specific attacks or vulnerabilities can be greatly reduced, while single-client dominance increases the risk. This risk multiplier effect varies with the share of the network that a single dominant client takes.
We can gain more intuition by going through some hypothetical (but likely actual) scenarios. Let us assume that a bug is accidentally introduced into a consensus client that either directly causes the client to make incorrect attestations, or exposes a vulnerability that allows a malicious attacker to force the client to make incorrect attestations. So how does client diversity affect the consequences of this bug?
Scenario 1: Affected clients control less than 1/3 of all ETH deposits
This situation provides the greatest resilience for the Beacon Chain, as 2/3 of the staked ETH is still attesting correctly, allowing the Beacon Chain to finalize normally. Therefore, from a network point of view, the consequences of this scenario are negligible. Affected validators will be penalized for being lazy because they submitted 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 proceed to attest correctness with minimal economic consequences and without breaking the beacon chain.
Scenario 2: Affected client controls more than 1/3 of all ETH deposits
This case is much more problematic because less than 2/3 of the ETH stake is left to attest correctly, i.e. there is no supermajority 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 affected the entire network. For exchanges and Dapps (decentralized applications) built on Ethereum, the finality of the blockchain is crucial. If the blockchain cannot be finalized, then there is no guarantee that the transaction will be permanent Sexuality and immutability.
For individual validators using this affected client, the associated penalties are much more severe, because the activation of the Inactivity Leak mechanism means that the ETH pledged by individual validators will be gradually destroyed until the client affected by the bug Controls less than 1/3 of the total ETH stake, and only then will the beacon chain resume finalization. This burning of ETH may actually continue for some time after the beacon chain is restored, providing a buffer for smaller changes in the number of validators. The finalization of the beacon chain is only in jeopardy if a single affected client controls more than 1/3 of the total ETH staked.
In this scenario, validators running other alternative clients will not receive any rewards while the Inactivity Leak mechanism is active. This is a safety mechanism to prevent an attacker from intentionally launching an Inactivity Leak mechanism that increases the total reward for other correctly behaving validators controlled by the attacker. These are small penalties, but the point is that no one can escape the negative consequences of a consensus bug with a client controlling more than 1/3 of total ETH staked.
Scenario 3: The affected client controls 1/2 of the ETH deposit
This situation could lead to an unrecoverable fork in the beacon chain. If the client with the consensus bug forks to its own chain, neither the original chain nor the new forked chain can achieve finalization, because both the old and new chains are missing about half of the validators, and both will activate Inactivity Leak mechanism. At this time, the ETH deposits of the missing verifiers on the two chains will be gradually destroyed until the deposits they control are less than 1/3 of the total network ETH deposits. Finalization can begin again. This process takes the same amount of time on both chains, since an equal amount of ETH needs to be burned to restore finalization.
The two chains will use different checkpoints to complete finalization independently. These two chains may never merge into a single "authoritative chain". A solution would require the Ethereum community to reach a consensus on which chain is the "authoritative chain", a process that would certainly be politically difficult and cause disagreements, resulting in the economic loss of half the community due to switching blockchains (this is still Excluding possible depreciation of ETH). Perhaps worse, the community may just continue to split (similar to The DAO incident leading to Ethereum Classic).
To avoid a permanent split of the beacon chain, validators using affected clients will have to race against the Inactivity Leak to switch clients, or fix their clients before the blockchain begins finalizing. There may be 3-4 weeks during which developers will scramble to save Ethereum. In this scenario, for a large number of validators, significant economic losses cannot be avoided.
Scenario 4: Affected client controls more than 2/3 of all ETH deposits
This is a nightmarish situation for the beacon chain, as affected clients control a supermajority of validators and are able to finalize their own chain. In this way, there is a high probability that incorrect information will be permanently fixed in Ethereum’s history. Before the blockchain begins finalizing illegal blocks, the client team will have about 13 minutes to identify the consensus bug, fix it, and broadcast the client update to affected validators.
For this situation, the only viable mitigation is for the affected validators to withdraw their staked ETH and withdraw from the blockchain. If after the bug is fixed, these affected validators try to rejoin the correct blockchain, they will be slashed due to the "collusion penalty", because they now prove the same checkpoint as they previously proved. Checkpointing is contradictory, and doing so en masse. The Inactivity Leak mechanism will be activated due to a large number of validators leaving, which means that these affected validators will continue to lose their ETH deposits while they wait for withdrawals (exit). With a large number of validators exiting, the waiting lines 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 intended behavior of the Ethereum consensus layer from now on. This would go against the core tenets of the staking community and be extremely divisive. These minority clients will be penalized for being lazy on the new chain, even if they behaved properly.
other risks
other risks
reverse finality
If a single client controls more than 2/3 of the total ETH staked, then the developer of that client has the ability to choose which version of the blockchain history is correct. For example, if the developers of this 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 ETH that does not contain this The chain version of the spend transaction replaces the current finalized chain.
This is a "double spend" because the client controls a majority of validators enabling it to reverse finality and rewrite history. At the same time, the honest few validators are penalized for their inconsistent proofs. A malicious attacker who controls a supermajority of total ETH deposits could also threaten to do so and take control of the network to demand a ransom. Even a malicious party controlling 1/3 of the total ETH deposits can threaten to stop chain finalization and activate the Inactivity Leak mechanism.
shared responsibility
centralized
centralized
politics
politics
Social recovery of an honest chain is a politically fraught problem. Ethereum's consensus mechanism should be determined based on the rules encoded into its clients - this is its main goal. Interfering with this process could lead to a split in the Ethereum community, leading to different users having a variety of philosophical, ethical, and technical views on mitigating a consensus bug/attack on a major client. Governance decisions will be unwieldy, disruptive, and likely 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 integrity of any client team. However, these scenarios are not purely hypothetical either. There have been real examples where client diversity saved the Ethereum mainnet from being permanently damaged, and some consensus bugs have also broken the Ethereum testnet. Some examples of these are described below.
Shanghai attack
In September 2016, during the DevCon conference in Shanghai, hackers attacked Ethereum, exploiting several vulnerabilities in the client software, causing the network to slow down significantly. Attackers persevere, rapidly deploying new, similar attacks, while client developers race to reverse engineer and patch these attacks. Ultimately, attackers discovered an unpatchable vulnerability in the Geth client, making the hard fork inevitable. Even after the hard fork upgrade, the attackers discovered a denial of service vulnerability that exploited the bloated state caused by the previous attack, forcing clients to perform tens of thousands of slow disk I/O operations per block. Client diversity won, because while developers worked to fix the vulnerability in Geth, Ethereum was able to move on to an alternative Parity client, which did not suffer from the same vulnerability.
The Shanghai attack is recoverable due to multiple clients, but the situation could be very different if a similar bug affected a majority of consensus clients. If a "consensus client" had the same dominant position as when Geth was attacked, then the Ethereum amount would not be finalized, because the majority of validators would not be able to attest to the block at this time. The Inactivity Leak will be activated because less than 1/3 of the ETH stake will be available for attestation.
Insecure chain
The feasibility of "remote attacks" was recently demonstrated on the Pyrmont testnet. The idea is to build a set of validators to attest to an alternate blockchain history. These validators are then used to trick new validators into joining this dishonest "Insecura" chain, gradually increasing the number of affected validators, eventually reaching the point of interrupting blockchain finalization, activating the Inactivity Leak, and depleting honesty The extent of the ETH stake for the majority of validators. Ultimately, this could lead to affected clients finalizing their own version of the blockchain. While the required investment of time and money makes this behavior an unlikely attack vector, a similar dynamic could lead to a bug in a dominant consensus client infecting a large portion of the network.
Medalla Testnet
Previously, due to a clock problem in the Prysm client, the number of active validators on the Medalla testnet suddenly dropped. The chain cannot be finalized because so many validators have dropped out of the network that 2/3 of the vast majority of staked ETH is no longer available for attestation. Its recovery is gradual, as it relies on validators switching clients from Prysm to a handful of other clients. Then, the real time is caught 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 experienced huge state bloat due to suddenly processing large numbers of proofs. If Prysm was the only client on the Medalla testnet, the entire network would have stalled; if Prysm clients controlled less than 1/3 of the total ETH deposits, a lot of chaos could have been avoided.
Prysm deposit root bug
In early 2021, the Prysm client encountered a bug related to Eth1 deposit root verification. At the time, the Prysm client was able to generate an invalid deposit root and pass it on to other Prysm nodes. Because Prysm has such a large validator share, such invalid stubs spread quickly across the network, and since Prysm follows a majority voting mechanism rather than explicitly validating stubs every block, this is accelerated its spread.
Although the impact of this bug was minimal, it did not interrupt the finalization of the beacon chain, and it did not bring significant financial penalties to validators, this incident proved the importance of client diversity in two ways: First, if If the Prysm client has a small validator share, it will limit the spread of the bug throughout the network and reduce its impact; second, the post-event analysis article describes how to use alternative client implementations as a Personnel quickly identified and fixed the bug. Obviously, this wouldn't be possible without multiple actively maintained clients.
image description
The figure above shows the current diversity of Ethereum clients: the proportion of execution clients is on the left, and the proportion of consensus clients is on the right.
The two pie charts above show a snapshot of the current client diversity of Ethereum's execution and consensus layers (as of this writing, January 2022): the execution layer is dominated by Geth clients, with OpenEthereum clients coming in a distant second Second, the Erigon client ranks third, Nethermind ranks fourth, and other clients account for less than 1% of the network. The most used client on the consensus layer, Prysm, while not as dominant as the Geth client on the execution layer, still owns over 60% of the network, with Lighthouse and Teku at 20% and 14% respectively, and few others use.
Execution layer data from Ethernodes website (ethernodes.org/) on January 23, 2022; consensus client data 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 misleads a small number of clients. However, it is clear that the majority of network nodes in the consensus layer are running Prysm. The dominance of Prysm was sometimes higher, exceeding 68%. Although only a snapshot, the percentages in the graph provide a good overall sense 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 The execution payload will be the core component of the beacon block.
Individual Stakers & Staking Pools
Addressing the imbalanced client allocation will require action from 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 building a small number of clients can be found in thisclientdiversity.orgpage found.
For stakers who hold less than 32 ETH or do not want to take on the responsibility of running a validator, there are some staking service providers available. Some major centralized exchanges provide ETH staking services, but the distribution of clients in their staking pools is usually hidden, and the tradability of the ETH staking Tokens provided by these exchanges is limited. For these and other reasons, the use of these centralized providers is not recommended.
Summarize
Summarize
Original link
