Prysmatic Labs’ Statement on Client Diversity
Background
The Ethereum Proof of Stake chain, also known as the beacon chain or consensus chain, has been live since December 1st, 2020 securing double digit billions of dollars worth of ETH. The protocol which defines this blockchain has a common specification, found here, which is open source and free for anyone to contribute to. Conversely, there are various software implementations of the protocol which are used by individuals and institutions alike to run nodes in the network. There is significant evidence showing the implementation created by our team, Prysm, runs a supermajority of staked ETH at the time of writing and also a large amount of nodes in the network. Ethereum proof of stake requires a supermajority (> 2/3rds) of the network’s consensus participants to be, indeed, participating. If there is a consensus failure in the Prysm software, other implementations would believe that < 2/3rds of validators are participating, leading to collective penalties and serious consequences for the blockchain.
Given we have four major implementations of the protocol in production, and a fifth one named Lodestar recently validating on the main network, we should take reasonable steps to reduce this supermajority of Prysm dominance for the sake of Ethereum. Much has been written about the importance of client diversity, and of having a more even distribution of protocol implementations running the Ethereum blockchain. The goal of this statement is to clarify what we intend to do to improve client diversity and also where we stand regarding difficult decisions around the matter.
Our team’s stance is that client diversity should be accomplished by focusing on software interoperability and standardization rather than forcing it on stakers which goes against the ethos of decentralization and free-and-open-source software. Through fair means, we commit to supporting community education and standardization to avoid having a Prysm supermajority.
We know it isn’t enough to just say this issue is important — actions speak louder than words. To show our commitment to addressing the community’s concerns, we’ve decided to outline the concrete steps our team is taking towards improving client interoperability. Here is what our team commits to building to make client diversity easier to achieve and when we will do it:
- Standardized validator API, making it easier to create graphical interfaces that can be used across clients. We plan on working on this over the coming months.
- Fully support the standard Ethereum beacon APIs, allowing use of Prysm beacon nodes with other team’s validator client implementations for easier switching between software. We have been hard at work on this task for a year and will be including full support for the standard Beacon API in our upcoming v2.0.0 release and thanks to Radek from our team and Jim McDee from Attestant testing it, we have high confidence in shipping this feature.
- Adding support for a standard remote signer, such as Web3Signer, for better institutional adoption of client diversity. We plan on doing this over the coming months.
- Continue working on standards where appropriate to create a rich user experience for stakers picking any client implementation. One example is writing EIPs (Ethereum Improvement Proposals) with other teams.
Our responsibility is to make client interoperability easier for the success of Ethereum. However, there are several key values that we stand by and conversely other actions we, as a team, will not support:
We are against any decisions that put down our work, our team, and our mission of creating the best software we can for Ethereum.
Among a few other similar recommendations, it has been suggested to us that Prysmatic Labs should stop offering any community support until the network has a more fair client distribution. Every morning when we get up for work, we are motivated to do our best effort for the community and keep improving Prysm to make it more secure, faster, and feature-rich for our stakers. We would never think of abandoning community support or any other decision that forces us into doing a worse job than we originally set out to do.
We are against any initiative that punishes stakers for running a specific client at the protocol layer.
A protocol is a set of rules of communication to achieve an end result. Ethereum, IP, HTTP are all protocols. The best protocol specifications are abstract on purpose, making no assumptions about whom or how said protocols are being implemented. This helps keep protocol designs future-proof and vendor-independent. As free and open source software, Prysm is simply an implementation of the Ethereum consensus protocol, and all users around the world have free choice in the software they wish to run. New clients can appear and old ones can phase out in the future for extraneous factors outside of users’ control. Just like having in-protocol governance, making the protocol aware of client details is a dangerous proposition as it mixes human and political decision-making with software mechanisms.
EDIT thanks to Dankrad Feist: Today, the beacon chain does have what are known as anti-correlation incentives, which punish slashed validators more and indirectly encourage client diversity. We 100% agree on this design in the protocol today. Anything more than this is overreaching and also hard to enforce.
We are against any initiative that forces client diversity on users, as we believe forceful action is against the ethos of decentralization and free choice of software.
The current open source ecosystem is a free marketplace of software, and all clients have differentiators that lead individuals and institutions to choose them. Each implementation was originally built to have a specific edge targeting different user personas. One example is Nimbus’ focus on staking with low-power devices, important to decentralization. Another example is Prysm exposing a web interface for less technical stakers to participate in the network. Among few of the valid and understandable reasons why a user or institution would pick software over another are the some of the following:
- A company’s entire stack, monitoring, infra are all written and maintained by engineers proficient in X programming language. Maintaining a client written in X programming language is easier, especially instrumenting it and extending it. Supporting a software in a totally foreign programming language for their stack would require hiring more engineers, increasing the difficulty of being on-call for the system, and knowing how to possibly write code in that software. Some companies extend our software to meet their needs, and are extremely comfortable with Go as a popular language for the cloud. Switching incurs significant engineering and execution risk.
- A staker is less technical and requires having some graphical interface for their software, which Prysm provides
- Native windows support
- Institutions using Java for its historical robustness, making Teku an easy choice to adopt, for example
- Developers picking Lighthouse, written in Rust, due to its memory safety and speed as a client of choice
Aside from this short list, there are far more reasons why people run X software over Y, but a migration to a minority client should not be completely forced and even worse, done in a short timeframe.
We are against forcing implementation teams into equality of outcome.
We sincerely believe client competition is critical, as that is one of the drivers behind us constantly seeking to improve our software. No client competition means forcing equality of outcome for all clients, despite each one being originally built to specific strengths. Competition is also a driver for new clients to be written that can improve upon others in unique ways. As a hypothetical, imagine a team X is working hard on a feature they painstakingly created that attracts more stakers and developers to their project, and another team Y, gets the same guaranteed outcome despite not having done the same, there is little motivation for team X to do what they did in the first place.
Forced outcomes mean no competition and therefore few incentives to improve. A good question to ask is how does the community decide which set of clients should receive equal share of the total network if there are incumbents in the future? Knowing the cool optimizations a certain team has done to improve a certain feature is a motivator for us to learn from them and even beat them at that metric. Prysm is where it is today because of our desire to keep improving and doing the best we can for our stakers. We grew from competition and learned from competition to release software we are confident in.
A success story that stems from this spirit of free choice of software and competition is the Erigon client available on the Ethereum proof of work chain today. Erigon, originally known as Turbo-Geth, saw many potential improvements to go-ethereum and in the spirit of decentralization, came to write a new client that improves upon it on many fronts. If, however, Erigon were guaranteed equality of outcome as Geth, both clients would have arguably not been as motivated to do what they have accomplished.
Interoperability is hard. The Ethereum beacon chain is built by at least 5 different implementation teams that work remotely and independently from each other. We do not have a common “boss” and each team has different incentives for why they do what they do. We do not work under the same roof and do not communicate on a daily basis. We are each from different companies and have unique roadmaps, goals, and trajectories, which is what makes this whole endeavor special. It is difficult to have perfectly even performance, feature-sets, and more when we are independent entities without common authority. Balancing motivations and unique edges for each team with client diversity is extremely difficult, and arguably there is no good solution for it that makes all parties happy.
We are against delaying “the merge” as a way to force client diversity as a top-down decision from figures with authority in the community
This idea is another way of forcing equality of outcome on users by leveraging the power core developers and researchers implicitly have over the future of Ethereum. We believe this goes against the core ethos of the Ethereum project unless it comes from the majority of members of the community. This cannot be a top-down decision and is for the entire community to decide. We believe neither us, nor researchers, nor others in positions of authority in the Ethereum community should use our leverage to force this outcome. If the majority of the community does indeed desire this outcome, then we should support it.
We believe reaching a completely even client distribution is unrealistic unless forced, but avoiding a supermajority is a goal we need to pursue via standardization and interoperability.
A perfectly even distribution of clients is unlikely, but we should together strive for preventing a supermajority by education in the community. No blockchain today has client diversity, and we have a unique opportunity to change that. However, the way to change it is via standards and easier software interoperability, not by forcing users and removing their freedom of choice.
Last but not least, we wish to thank all client teams and researchers for being incredibly supportive, rational, and team oriented in these matters. We pledge to support initiatives that improve client diversity via better standards and interoperability, but it is important to clarify where our values stand and what we cannot compromise on.
