Reza Arap Oktovian
The Ethereum network, a cornerstone of the decentralized web and the second-largest blockchain by market capitalization, is on the cusp of a transformative upgrade. Sometime around the middle of this year, Ethereum will transition from its current energy-intensive Proof-of-Work (PoW) consensus mechanism to a significantly more efficient Proof-of-Stake (PoS) model. This monumental undertaking, often likened to "changing the engine of an airplane while flying it," is critical because Ethereum, processing hundreds of billions of dollars in assets, cannot afford to halt block production.
Unlike many other major blockchains, such as Bitcoin, Ethereum’s development community, with strong backing from the Ethereum Foundation (EF) and prominent figures, has embraced a multi-client strategy for its PoS implementation, colloquially referred to as Ethereum 2.0. This approach involves developing diverse client software implementations, written in various programming languages by distinct teams, to enhance network resilience.
The Genesis of The Merge: A Technical Ballet
The core of this transition, dubbed "The Merge," involves the integration of the existing Ethereum network nodes with the "beacon chain," a parallel PoS chain that has been operational since December 2020. This merger signifies a fundamental restructuring of node responsibilities. Currently, Ethereum nodes perform both the execution of transactions and their validation. Post-Merge, these duties will be separated into two distinct types of nodes.
Execution nodes will continue to interact with users and smart contracts, process transactions, and submit them to validator nodes on the consensus chain for validation. Essentially, execution nodes will largely retain their current functions, with the critical validation responsibility shifting to dedicated validator nodes operating on the consensus layer. This separation of concerns is a deliberate enhancement of robustness, creating distinct logical layers for transaction processing and network security.
While these execution clients share some codebase, particularly when developed in the same programming language, they will require only minor adjustments to accommodate the Merge. The Ethereum Virtual Machine (EVM), the computational engine of Ethereum, will largely remain reusable with modifications. Notably, execution clients will eventually shed the parts of their code responsible for validation on the legacy Proof-of-Work chain.
The Merge, therefore, is not a straightforward consolidation of two chains into one. Instead, at a predetermined block height, current nodes will cease their validation duties, which will be fully assumed by validators. This architectural shift is a classic example of improving network resilience through the separation of responsibilities into distinct, specialized layers.
The Imperative of Client Diversity: A Safeguard Against Catastrophe
The strategic decision to develop multiple, independent client software implementations stems from a fundamental principle of distributed systems: diversity breeds resilience. The rationale is that a bug, vulnerability, or fault within one client will not compromise the entire network, as these clients are not built on identical codebases or even necessarily the same programming languages.
This contrasts with the approach of Bitcoin, whose protocol and its primary implementation are considerably simpler. Ethereum, a far more complex ecosystem, inherently carries a higher risk of vulnerabilities and a broader attack surface. The multi-client strategy aims to mitigate this risk.
However, the effectiveness of this diversity strategy hinges on an equitable distribution of network participation across the different clients. A critical threshold exists: if any single client is adopted by more than 33% of the network’s staking power, its resilience benefits diminish significantly. The situation becomes precarious if one client garners over 66% of the staking power, rendering the very concept of code base diversity largely moot.
The implications of an uneven client distribution are profound. If a critical bug emerges in a client used by less than one-third of the staking power, the network can continue operating seamlessly. The bug can be addressed, and normalcy restored without user disruption.
A bug affecting a client with between one-third and one-half of the staking power is more serious but is likely to be managed by automatic network mechanisms without noticeable user impact.
However, if a severe bug impacts a client controlling more than half of the staking power, while automatic recovery mechanisms will eventually resolve the situation, it will inevitably lead to network complications, disturbances, and user-facing issues.
The most catastrophic scenario arises if a bug infiltrates a client utilized by more than two-thirds of the staking power. In this "supermajority" scenario, the buggy clients possess overwhelming control. The flawed chain would finalize, forcing non-buggy clients into a difficult choice: either permanently fork the chain, effectively creating two separate Ethereums, or join the buggy chain and accept the consequences of its compromised state.
Prysm’s Dominance: A Cause for Concern
As of the latest available data, the Prysm client, developed by Prysmatic Labs, commands approximately 48% of the network’s staking power. This concentration of power, while just below the critical two-thirds threshold, represents a significant concern for the network’s overall health and security in the event of a consensus failure. While a consensus failure is considered unlikely, its non-zero probability necessitates careful consideration of client distribution.
Beyond Prysm, other notable consensus clients include Lighthouse, Teku, and Nimbus. Grandine and Loadstar have minimal market shares, each below 1%. Notably, Grandine is the only client currently distributed under a closed-source license, which can limit transparency and community scrutiny.
The distribution of consensus clients, as of recent reports, illustrates Prysm’s significant lead. While it hovers just below the most critical two-thirds mark, its dominance is substantial enough to warrant careful monitoring and proactive measures to encourage greater diversity. Resources such as clientdiversity.org provide up-to-date statistics on this crucial metric.
The Roots of Prysm’s Success: A First-Mover Advantage
The prominent adoption of the Prysm client can be attributed to several key factors, as explained by Marius van der Wijden, an Ethereum core developer working on the Geth client:
"I think the big reasons for Prysm’s success are a first-mover advantage, tooling, and golang," van der Wijden stated. "Prysm was the first prototype implementation of a beacon client. Thus they could start optimizing their client early on and they had more time to create additional tooling (e.g. the Web UI) and good documentation."
He further elaborated on the advantages of its programming language: "Another big advantage is the programming language used by Prysm – golang – which is reasonably performant and very easy to read and develop in. Go-ethereum is also written in golang, thus devs familiar with Geth could also easily understand and audit Prysm."
This ease of understanding and auditing is particularly relevant when considering the execution layer. The distribution of Proof-of-Work execution clients is even more concentrated, with Geth holding over 85% of the market share. However, post-Merge, this concentration poses less of a direct security risk, as execution nodes will primarily focus on transaction processing rather than providing the network’s fundamental security.
"Go-ethereum currently has a supermajority of 85% on the execution layer. It will be a bit better post-merge since stakers can run multiple execution layer clients, with one beacon client, in order to always end up on the correct chain," van der Wijden clarified.
Major Exchanges as Key Prysm Contributors
The concentration of staking power is not uniformly distributed among individual node operators. Staking services and pools, which allow users to stake Ether without the requirement of 32 ETH, wield significant influence. It is largely the reliance of these major staking services on the Prysm client that exacerbates the client diversity issue.
Prominent among these services are Coinbase, Kraken, and Binance. Coinbase, with a substantial 17.5% of all validator nodes, runs Prysm for 92.4% of its validators, contributing approximately 24.3% to the overall Prysm dominance. When approached for comment, Coinbase’s communications department pointed to a February 22nd tweet thread from Coinbase Cloud, emphasizing security as the primary driver for their client choice.
"Coinbase uses multiple eth2 staking providers to maximize security and client distribution," the tweet stated. "When launching eth2 staking, Coinbase evaluated existing clients and providers to maximize these traits, which meant starting with Prysm because it was the only viable client supporting remote signers." The thread further explained that remote signers allow validators to generate and store keys in isolated environments, significantly enhancing security and enabling double-signing protection. Coinbase Cloud has since begun supporting Lighthouse, indicating a move towards greater diversity.
Kraken, with 11% of validator nodes and a 94.9% Prysm usage rate, contributes 15.7% to Prysm’s dominance. Brian Hoffman, Senior Product Manager at Kraken, stated that Prysm was initially chosen for its maturity and stability. However, Kraken, in collaboration with Staked, is now also deploying validators on the Teku client and migrating existing ones, actively working to improve client diversity.
Binance, with 8.7% of validators and 76.6% Prysm usage, contributed 10% to the issue. Binance did not respond to requests for comment.
Lido, a significant staking service with 18% of validators, shows a comparatively lower Prysm usage of 42.8%, contributing 11.5% to Prysm’s overall dominance.
Decentralized Alternatives Lead the Charge in Diversity
In contrast to the large centralized exchanges, decentralized staking pools are demonstrating a stronger commitment to client diversity. Rocket Pool, a notable decentralized staking pool, operates 0.75% of validators, with only 10.6% running Prysm, contributing a mere 0.12% to Prysm’s dominance. This highlights a different strategic approach within the decentralized staking community.
The significant influence of these major staking services means they hold considerable power to rectify the client diversity imbalance. Encouragingly, discussions are ongoing between these services and the Ethereum Foundation, with core developer Marius van der Wijden describing the progression of these talks as "good."
"Yes, there are talks about this, both internally and externally," van der Wijden confirmed. "I think big staking pools are working on switching parts of their infrastructure to other clients. They need to update their metrics and monitoring infrastructure for the new clients, so it might take longer for them to switch than home validators."
Van der Wijden also noted that switching client software is neither inherently risky nor difficult for individual node operators. "All major implementations are pretty well tested and maintained," he explained. "If a user is already staking, they should shut down and persist their slashing database, if they don’t have a slashing database, they should wait for a couple of minutes (> 7 minutes) between shutting down the old client and starting the new client. The only difficulties might arise for bigger stakers as some clients provide different APIs than others."
Navigating the Merge: A Calculated Risk
With The Merge fast approaching, the Ethereum community may have to accept a suboptimal client distribution. The likelihood of Prysm’s dominance falling below the critical 33% threshold in the remaining time is considered low. Nevertheless, this situation does not deter Ethereum’s core developers from proceeding with the Merge.
"I think it’s safe to pursue," van der Wijden asserted. "The chances of a consensus failure happening are very small in my opinion. We have great testing and fuzzing infrastructure that runs permanently to find differences between clients. Even if a consensus failure occurs, we will be able to push out new releases and resolve forks quickly and easily."
He also emphasized a crucial aspect of the network’s governance: "We also have strong consensus that we will not bail out stakers that run a majority client if their clients misbehave." This clear stance underscores the responsibility that lies with node operators to ensure their chosen client software is diverse and robust. The success of The Merge, and indeed the long-term security and decentralization of Ethereum, will depend on the collective efforts to foster a more balanced client ecosystem.
