Why is client diversity so important in ETH2.0
Disclaimer: This article is not for any particular client. Be aware that every client and even every specification may contain deficiencies and vulnerabilities. Not to mention, Eth2 is a complex protocol implemented by only human beings. The purpose of writing this article is to highlight how and why risk reduction is needed.
Source: Ethereum Blog
Carl Beekhuizen
After the release of The Medalla test network, we encourage people to participate in the test network with different clients. On the day of the creation of the test network, the importance of multiple clients was shown to us: the nodes run by Nimbus and Lodestar clients could not handle the work of the whole test network, so they did not keep up with the progress of synchronous nodes. As a result, finalization started half an hour after Medalla was released.
On 14 August, Prysm node caused a time error because one of the time servers they referenced suddenly jumped to the future time. As a result, these nodes start proposing future blocks and verifying future proofs.
However, after the node's clock has been calibrated (either by updating the client version, or because the time server has been brought back to the correct time), nodes that had previously cancelled their forfeiture have found their pledged assets forfeited.
The whole process is a bit subtle, and I highly recommend that you read Raul Jordan's retrospective on the incident.
Clock error - deteriorating situation
When the Prysm node started time travel, they accounted for about 62% of the network share. This means that the minimum criteria for the final block cannot be met (there must be & GT; 2/3 active validators on the chain). To make matters worse, the nodes were unable to find their desired chain (there was a four-hour interval on the timeline, and they all went to slightly different times in the future), so they flooded the entire network with short forks in their predictions of "lost" data.
Figure Prysm accounts for 82% of the Total Medalla node currently
Source: ethernodes.org
At this point, then, the network is flooded with different predictions for the head, so all clients start to cope with more and more work - determining which head is valid. This leads to backward nodes, the need for synchronization, out of memory, and other forms of confusion, all of which exacerbate the problem.
Overall, this event is a good one, as it not only allows us to fix the underlying clock-related issues, but also allows us to stress test the client in the event of a large number of node failures and network loads. In other words, the failure tells us that the network cannot be too extreme, and the culprit of this event is that Prysm's nodes account for most of the network.
Help decentralize
Benefit for eth2
As discussed in the second article in this series, 1/3 is the magic number for network security, according to asynchronous Byzantine fault-tolerant algorithms. Epochs can no longer be finalized if more than one-third of verifiers are offline. So even though the chain is still growing, you can no longer identify the block, and make sure it's part of the standard chain.
Benefit verifier
For the most part, validators are motivated to do what's good for the network, not because they think it's the right thing to do.
If more than a third of the nodes are offline, the penalty for offline nodes starts to increase, which is called the "inaction" penalty.
This means that a verifier wants to try to ensure that if one node is forced to go offline, it is impossible to force others to go offline at the same time.
It's the same thing with penalties. However, due to errors/bugs in the specification or software, it is always possible for the verifier to be forfeited, with a single forfeit "only" 1 ETH.
However, if many verifiers are forfeited at the same time, the penalty rises to 32 ETH. And this magic number, when more than a third of the verifiers are forfeited, produces 32 ETH forfeits.
These incentives, known as reactive and safety inverse correlations respectively, are an intentional aspect of Eth2. The anti-correlation mechanism incentivizes the verifier to make a decision in the best interest of the network by tying individual punishment to the degree of influence each verifier has on the network.
Presentation of data
Eth2 is being implemented by a number of independent teams, each developing a separate client based on specifications written primarily by the Eth2 research team. This ensures that there are multiple beacon nodes and verifier client implementations, with each team making different decisions about the technologies, languages, optimizations, trade-offs, and so on needed to build the Eth2 client. This way, a bug in any layer of the system will only affect the user running a particular client, not the entire network.
If only 20% eth2 node is running on the client Prysm and 85% verifier is online in the Medalla Prysm timing bug, Prysm will not suffer a "ysm" punishment and will solve the problem with a little penalty and a few developer's awake nights.
Instead, 3,500 to 5,000 validators were forfeited in a very short period of time because there were so many validators running on the same client (many of whom had forfeited protection).
* The high correlation means that these verifiers forfeit about 16 ETH because they use a more common client.
* At the time of this writing, forfeiture continues to crop up, so final Numbers are not yet available.
Use the new client
Now it's time to test with a different client, one with a small number of validators (see distribution here). Lighthouse, Teku, Nimbus and Prysm is all running relatively stable at this time, while Lodestar is rapidly catching up.
Most importantly, try a new client! We can try to build a healthier node distribution on Medalla to prepare for decentralizing the main network.
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
Related Articles
