Reza Arap Oktovian
The Ethereum network, the second-largest blockchain by market capitalization and the backbone for hundreds of billions of dollars in digital assets, is on the cusp of a transformative upgrade. In the coming months, it will transition from its current Proof-of-Work (PoW) consensus mechanism to a more energy-efficient Proof-of-Stake (PoS) system, a monumental undertaking often described as re-engineering an airplane mid-flight. Crucially, Ethereum must maintain its ability to produce valid blocks without interruption throughout this complex process.
Unlike many other prominent blockchains, such as Bitcoin, Ethereum’s developer community, with significant encouragement from the Ethereum Foundation (EF) and key figures within the ecosystem, has embarked on developing multiple client software versions to implement the Proof-of-Stake protocol, often referred to as Ethereum 2.0. These diverse client implementations are distinguished by their programming languages and the distinct development teams behind them, a strategic decision aimed at enhancing network resilience.
The Mechanics of "The Merge": A Separation of Duties
The pivotal event, widely known as "The Merge," will integrate the existing Ethereum network nodes, some of which currently function as miners, with the beacon chain. This separate PoS consensus layer has been operational since December 2020. A fundamental change accompanying The Merge is the division of responsibilities among network nodes. Previously, nodes were responsible for both executing and validating transactions. Post-Merge, this crucial function will be bifurcated.
Two distinct types of nodes will emerge. "Execution nodes" will continue to present the Ethereum Virtual Machine (EVM) to users and smart contracts, facilitating transaction execution. However, these execution nodes will then forward these transactions to "validator nodes" operating on the consensus chain for validation. Essentially, execution nodes will retain their current duties, with the critical validation aspect now handled by the validator nodes on the PoS consensus chain.
While these execution clients share code when developed in the same programming language, and have undergone minor modifications to accommodate The Merge, the core logic of the EVM remains largely reusable. It is anticipated that execution clients will eventually shed the portions of their code dedicated to validating transactions on the current Proof-of-Work chain.
The Merge, therefore, is not a literal amalgamation of two distinct chains into one. Instead, at a predetermined block height, the current PoW nodes will cease their transaction validation duties, which will then be solely undertaken by validators. This architectural shift represents a significant enhancement of network robustness through the logical separation of critical functions into distinct layers.
The Criticality of Client Diversity: A Risk of Centralization
The rationale behind developing multiple client software implementations is to mitigate the impact of potential vulnerabilities. A bug or exploit affecting one client should, in theory, not cripple the entire network, as these clients are built on different codebases and often in different programming languages.
This approach contrasts with Bitcoin, whose protocol and implementations are comparatively simpler. Ethereum, by its very nature as a more complex platform, inherently carries a higher risk of vulnerabilities and a broader attack surface. The success of this multi-client strategy hinges on an even distribution of network participation across these clients.
A critical threshold exists: if any single client commands more than 33% of the network’s staking power, the benefits of client diversity are significantly diminished. If a client is utilized by over 66% of the staking power, the entire premise of having independent code bases becomes largely moot.
The distribution of staking power across clients has profound implications for network stability. A serious bug affecting a client with less than one-third of the staking power would likely cause minimal disruption, with the network continuing to operate smoothly. The bug would be addressed, and normal operations would resume.
If a similar issue impacts a client holding between one-third and one-half of the staking power, the situation becomes more serious, though users might not notice immediate effects due to automatic recovery mechanisms. However, if a bug surfaces in a client controlling more than half the staking power, automatic fail-safes would be triggered, but these would inevitably lead to complications, network disturbances, and user impact.
The most catastrophic scenario arises if a bug affects a client used by more than two-thirds of the staking power. In this instance, the "supermajority" client would possess overwhelming control, and its buggy chain would likely finalize. The only recourse for non-buggy clients would be to either permanently fork the chain, creating two separate Ethereum networks, or to capitulate and join the compromised chain, accepting the consequences of the bug.
Prysm’s Dominance: A Cause for Concern
As of the time of this reporting, a significant portion of the network’s staking power, approximately 66%, is concentrated on the Prysm client implementation, developed by Prysmatic Labs. This concentration is far from ideal, particularly if the Prysm client were to harbor an exploitable bug leading to a consensus failure. While the likelihood of such an event is considered low, it remains a non-zero risk.
Other clients available in the market include Lighthouse, Teku, Nimbus, Grandine, and Loadstar. Grandine and Loadstar currently hold negligible market shares, each below 1%. Notably, Grandine is the sole client operating under a closed-source license.
The distribution of consensus clients, as depicted in accompanying data, reveals Prysm’s substantial lead, though it currently hovers just below the critical two-thirds threshold. Resources such as clientdiversity.org offer up-to-date information on these distributions.
The question naturally arises: why has Prysm achieved such dominance? The answer, according to Ethereum core developer Marius van der Wijden, largely stems from a "first-mover advantage." Prysm was an early prototype implementation of a beacon client, allowing its developers to optimize and build additional tooling and documentation ahead of competitors.
Van der Wijden further highlights the strategic advantage of using Go (Golang) as Prysm’s programming language. Go is known for its performance and ease of development, making it accessible to developers familiar with other Go-based Ethereum clients like Geth. This familiarity facilitates easier auditing and understanding of Prysm’s codebase.
Interestingly, the distribution of Proof-of-Work execution clients presents an even more pronounced imbalance. Geth, at the time of writing, commands over 85% of the market share. However, in the post-Merge era, this concentration is less critical as execution nodes primarily handle transaction processing and do not provide the fundamental security of the network, a role now assumed by consensus clients.
Major Exchanges Fuel Prysm’s Dominance
The uneven client distribution is exacerbated by the practices of large staking services and pools. These entities enable users to stake Ether without requiring the full 32 ETH validator deposit. It is the widespread adoption of Prysm by these major staking services that significantly contributes to the client diversity issue.
Prominent among these services are Coinbase, Kraken, and Binance. Coinbase, with a substantial number of validator nodes, contributes significantly to Prysm’s dominance. A significant percentage of Coinbase’s validators run Prysm, directly impacting the overall client diversity metrics.
When queried about their role in this concentration and their approach to client diversity, Coinbase pointed to a statement emphasizing security as the primary driver for their initial choice of Prysm. They cited Prysm’s support for remote signers as a key factor, a feature that enhances the security of validator keys by storing them in isolated environments. Coinbase also indicated their support for Lighthouse and efforts to integrate remote signer capabilities into it.
Kraken, another major player, also acknowledged Prysm’s initial maturity and stability as reasons for its adoption. However, Kraken has also begun deploying and migrating validators to the Teku client, in collaboration with Staked, to foster greater diversity and offer a more resilient staking service.
Binance did not provide a comment when approached by this publication. Lido, another substantial staking service, while having a significant number of validators, shows a lower percentage of Prysm usage compared to some other major providers, thus contributing less to Prysm’s overall dominance.
Decentralized Alternatives and Collaborative Efforts
In contrast to the major centralized staking services, decentralized staking pools like Rocket Pool demonstrate significantly better client diversity. Rocket Pool exhibits a much lower percentage of validators running Prysm, contributing minimally to the concentration issue.
Despite the current distribution challenges, discussions are ongoing between staking services and the Ethereum Foundation. Core developer Marius van der Wijden describes these discussions as "good," indicating a collaborative effort to address the client diversity imbalance. He notes that large staking pools are actively working on transitioning parts of their infrastructure to alternative clients, a process that may take time due to the need for updating monitoring and metrics systems.
Van der Wijden assures that switching client software is neither risky nor difficult for individual node operators, provided certain precautions are taken. Major client implementations are well-tested, and the primary challenges might arise for larger stakers due to API differences between clients.
Navigating The Merge Amidst Challenges
With The Merge imminent, the Ethereum community is likely to proceed with a less-than-ideal client distribution. The probability of Prysm’s dominance falling below the crucial 33% threshold in the short term appears low. Nevertheless, this situation does not deter Ethereum core developers from advancing with The Merge.
Marius van der Wijden expressed confidence in the safety of pursuing The Merge, citing the robust testing and fuzzing infrastructure in place to identify inter-client discrepancies. He believes that even in the event of a consensus failure, the community possesses the agility to release rapid updates and resolve forks efficiently. Furthermore, he emphasized a strong consensus within the community to not "bail out" stakers who might experience issues due to running a majority client that misbehaves. The successful and secure transition to Proof-of-Stake remains the paramount objective, with ongoing efforts to foster greater decentralization and resilience within the client ecosystem.
