Why Ethereum 2.0 client diversity is so important

source|Ethereum Blog

source|

Author | Carl Beekhuizen

Disclaimer: This article does not target any client. We need to know that each client and even each specification may contain deficiencies and loopholes. Not to mention, Eth2 is a very complex protocol, and its implementers are mere mortals. The purpose of this article is to highlight how and why to reduce risk.

After the Medalla testnet is released, we encourage everyone to use different clients to participate in the testnet. On the day the testnet was created, it showed us the importance of multi-clients: the nodes running on the Nimbus and Lodestar clients could not handle the work of the entire testnet, so they did not keep up with the progress of the synchronization nodes. As a result, Medalla didn't start finalizing half an hour after launch.

On August 14th, the Prysm nodes had a time error because one of the time servers they were referencing suddenly jumped to a future time. As a result, these nodes start proposing future blocks and validating future proofs. However, after the node's clock is calibrated (by updating the client version, or because the time server has adjusted the correct time), the node that canceled the slash protection earlier finds that its pledged assets have been slashed.This whole process is happening in a bit of a delicate way, and I highly recommend reading。 

Raul Jordan's retrospective essay on the incident

When Prysm nodes start time travel, they account for approximately 62% of the network. This means that the minimum criteria for finalizing a block (>2/3 active validators on-chain) cannot be met. To make matters worse, these nodes can't find the chain they expect (a 4-hour gap appears on the timeline, they all go to a slightly different time in the future), so they predict the "missing" data by short The fork flooded the entire network.

image description

source:ethernodes.org

source:

Then at this point, the network is flooded with different predictions for the chain head, so all clients start to deal with more and more work-determine which chain head is valid. This leads to nodes falling behind, needing to sync, running out of memory, and other forms of chaos, all of which exacerbate the problem.

Overall, this event was good, as it not only allowed us to fix a fundamental problem related to clocks, but it also allowed us to stress test the client under heavy node failures and network load. In other words, this failure tells us that the network cannot be too extreme, and the culprit of this incident is that Prysm nodes account for most of the network

Help decentralization—Part 1, benefit eth2As in this seriesArticles of the second issue

As discussed in , according to the asynchronous Byzantine fault tolerance algorithm, 1/3 is a magic number to ensure network security. If more than 1/3 of validators are offline, epochs can no longer be finalized. So while the chain is still growing at this point, it is no longer possible to finalize a block and guarantee that it is part of the canonical chain.

Facilitating decentralization—Part 2, benefiting validators

To a large extent, validators are motivated to do things that are good for the network, not because everyone thinks it is the right thing to do.

If more than 1/3 of the nodes are offline, then the penalty for offline nodes starts to increase, which is the so-called "inaction" penalty.

This means that a validator wants to try to ensure that if its own node is forced offline, it is impossible to force other nodes offline at the same time.

The same goes for forfeiting. However, there is always the possibility of a validator being slashed due to an error/bug in the specification or software, with a single slash being "only" 1 ETH.However, if many validators are slashed at the same time, the penalty rises to 32 ETH. And this magic number, when more than 1/3 of validators are slashed, 32 ETH will be slashed.

[About the reasons for the above situation can be found here]

These incentives are called liveness anticorrelations and security anticorrelations respectively, and are an intentional aspect of eth2. Anticorrelation mechanisms incentivize validators to make decisions that are in the best interest of the network by tying individual penalties to the degree of influence each validator has on the network.

Facilitate decentralization—Part 3, data displayA number of independent teams are implementing Eth2, each based on a document written primarily by the Eth2 research teamCanonical development of independent clients

. This ensures that there are multiple beacon node and validator client implementations, with each team making different decisions about the technologies, languages, optimizations, tradeoffs, etc. required to build an eth2 client. In this way, when a bug occurs in any layer of the system, it will only affect the user running a specific client, rather than the entire network.

If only 20% of eth2 nodes were running on client Prysm and 85% of validators were online at the time of this Medalla Prysm bug, then Prysm nodes would suffer no "inaction" penalty, and only a small penalty And a few sleepless nights from the developers will do the trick.

Instead, 3,500 to 5,000 validators were slashed in a very short period of time due to too many validators running the same client (many of which had slash protection removed).

*High correlation means that these validators have a slash penalty of ~16 ETH because they are using a common client.

*As of this writing, slashing is still coming in, so no final numbers yet.

Now it's time to use a different client to participate in the test, find a client that a small number of verifiers are using (you can clickhereView distribution).Lighthouse、Teku、Nimbusas well asPrysmas well asLodestarAt this time, the operation is relatively stable, but the

Most importantly, try out the new client! We can try to build a healthier node distribution on Medalla to prepare for the decentralized main network.

Disclaimer: ECN's translation work aims to deliver high-quality information and learning resources for the Chinese Ethereum community. The copyright of the article belongs to the original author. Reprints must indicate the source of the original text and ethereum.cn. For long-term reprints, please contact ethereumcn@gmail.com Authorize.