Obviously, this article claiming that using Geth client staking will lead to asset loss is too alarmist.
The author used the case of Nethermind client failure that caused the node to be Slashed to assume that 84% of the Geth client failure may lead to a bad situation. It can only be said that this is an extreme assumption and an over-interpretation of the Geth client centralization issue. Briefly, my thoughts:
1) Ethereum’s node clients include Geth, Nethrmind, Besu, Erigon, Reth and other clients. These execution clients are just a terminal configuration choice for developers to execute block production rights, and are not directly related to the consensus of the chain, especially issues such as block production rights.
The only difference is that some developers may choose small clients such as Nethermind due to factors such as familiarity or cost, while some developers will follow the trend. Choose Geth. No matter what type of client the developer uses, the probability of the block generation mechanism in POS is only related to the pledged ETH. However, the coverage of the Geth client is high, which gives people an intuitive feeling that most of the block generation rights are in Geth. In fact, it is just because Most nodes use Geth and the amount of ETH pledged on it is large;
2) As for why the Geth client accounts for the proportion 84% have become mainstream clients because of their superior performance, strong compatibility, rich functions, maturity and stability. A positive cycle: Geth has good performance - developers are active - bugs are fixed quickly - it is stable and easy to use - developers are more active - Geth accounts for a larger share. Although the Ethereum Foundation has also increased the proportion of other clients through continuous Grant, the results are of no avail. The consensus of the Geth client is getting stronger and stronger;
Follow the article The author's logic is that since the Geth client accounts for a large proportion, once there is a problem with Geth, Ethereum's block generation will be unstable, causing huge Slash damage to Staking, but it is a false proposition. Because if the Geth client is not easy to use, it cannot account for the largest proportion. Since the large proportion is the result of ease of use, what is the probability of Geth having problems? Even if this assumption is true, what Ethereum faces is not as simple as a node slash, but may involve a hard fork of the chain;
3) Staking and There is a concept of AVS (Activity Validator Set) in Restaking, which requires nodes participating in Staking to ensure the stability of communication connections, software stability and bug repair rate, effective block generation and verification processes, etc.
This means that nodes participating in Staking and Restaking will tend to choose the Geth client, and nodes in the Staking AVS set must continue to participate in Restaking. Try to increase the terminal load level to further improve performance. Therefore, Staking and Restaking will only lead to more competition at the client level, which means that the proportion of Geth clients may be further enlarged.
Therefore, the view that the Geth client accounts for a large proportion of centralization to denigrate the potential risks of Staking and Restaking is obviously untenable.
The centralization problem of Geth client is indeed a problem, especially in the context of decentralized world modeling, a large proportion will always make people feel confused There are hidden concerns, but the client diversity issue is something that the Ethereum Foundation has been looking for ways to optimize. This is not directly related to the explosion of Staking and Restaking. If there is a relationship, it can only be said that the prevalence of Staking and Restaking may intensify Geth. Further centralization of clients. However, it would be unfounded to complain about the risk of Geth client centralization.
Note: The initiative to weigh the potential risks of Geth client centralization and Staking is actually in the hands of large node entities such as Lido. If Lido consciously increases customers End node diversity, sponsoring developers of multiple clients, the problem will be improved accordingly.