Changes Coming in Prysm V2 Stakers Need to Know
In the coming month or months, Prysmatic Labs will be releasing a major version bump of the Prysm Eth2 client, v2.0.0. This is the first major version bump to our software since we released the mainnet-ready version of the client back in December 1st, 2020. Since then, we have maintained the promise of not introducing breaking changes. This document highlights all the expected changes for v2 and action items Prysm users need to be aware of.
Key Points
- Update your nodes in preparation for the Altair hard fork. Prysm v2.0.0 will be available at least a week in advance
- If developing with Prysm, some package import paths will change, and we will notify you of those changes in the v2.0.0 release changelog ahead of time
- Slasher will be deleted and instead become a feature enabled via a flag in the beacon node
- We will be deleting deprecated flags and code, so if you are using any deprecated flags in your setup, you will need to remove them for v2.0.0. We will notify everyone of the list of deleted flags ahead of time
Altair Hard Fork
In the coming month or months, we anticipate the mainnet release of the Altair hard fork. This is the first hard fork of the Ethereum beacon chain, requiring all node operators to update their software in preparation.
Altair is a long awaited set of optimizations to the core consensus of the beacon chain, including some exciting features such as light client support on Eth2. To read more about the specific changes coming in Altair at a high-level, news publications such as Coindesk have published articles here.
Altair is currently being tested by all client teams and requires validators to have their software up-to-date. Prysm v2 will be compliant with the Altair hard fork, and updating is all users need to do. We plan on getting v2 ready at least a week before the Altair hard fork on mainnet.
Action Items for Users
- Update your software to Prysm v2.0.0 ahead of time of the Altair hard fork. Prysm v2 will be released at least a week in advance of the hard fork, so you will have time to plan accordingly
- Ask about any questions or concerns in our Discord server or post a Github issue if you have any problems ahead of time
New Slasher and Deleting the Old One
Prysm currently ships with a slasher program that runs as a separate binary from the beacon node and validator client. Although many users have tried out slasher, we have long believed it was not the best implementation we could have produced, and it suffers from several bugs in its design. As such, we have spent time trying to produce the best possible slasher we could, and decided to bake it in as a feature inside the beacon node itself.
Starting in v2, you can run a slasher by simply adding the --slasher flag to your beacon node. The current slasher implementation is deprecated and will be deleted in v2. Even though we are very happy with this new version of slasher, it is a rewrite of the software from scratch, so there will likely be new bugs as we improve it further. We wish to thank all users of our software for working with us on improving, and every feedback we receive is instrumental in writing more robust applications.
Action Items for Users
- If you are running the current Prysm slasher, pre-v2, we recommend you stop your slasher and await the v2 version
- Slasher in v2 is not a separate binary, but rather a feature in the beacon node, so all you need to do is to add a
--slasherflag to your beacon node - The new slasher, although more efficient, will not be perfect at launch. By helping us run a slasher, you will aid us in identifying bugs and helping us make it a much more robust piece of software
Better Support for the Eth2 Standard API
Eth2 has a canonical REST API maintained in ethereum/eth2.0-apis. All client teams are expected to support this standard, and Prysm is no exception. We have lagged behind on supporting this API as Prysm uses its own internal one, but over time, we plan to migrate fully to the standard. In the meantime, Prysm does support the standard API to some capacity, but you will not be able to run a Prysm validator with an infura beacon node, for example. Prysm v2 will have good support for the standard API and you will be able to interact with all endpoints.
Action Items for Users
- You will be able to query Prysm beacon nodes for API data using the standard API endpoints in Prysm v2 with both gRPC and HTTP JSON requests. No other action is needed
Documentation Versioning
A best practice we will adopt in Prysm v2 is documentation versioning. This means our documentation portal, docs.prylabs.network will display the docs for the latest software version and offer a dropdown menu to navigate to previous versions of the documentation. We have had many instances where the documentation does not align to the latest release, or vice-versa, and we believe documentation versioning will improve the experience for Prysm users.
Action Items for Users
- None! We are confident users will have a better experience with more consistent documentation
Removing Deprecated Flags and Types
Prysm has a lot of command-line flags, allowing all kinds of customization and used internally by our team to enable some features we deem as experimental until enough testing validates them. Once a flag is enabled by default, we mark it as deprecated in the Prysm repository, meaning a user can still specify it, but it will have no impact. In Prysm v2, we are deleting all deprecated flags. This means operators that were using such flags will need to remove them from their setup. The whole list of deleted flags will be specified in release notes ahead of time.
Action Items for Users
- Review the list of deleted flags from the Prysm v2 release notes and delete them from your setup
Big Repository Restructuring
After “The Merge”, Prysm will have a lot more eyes on it, including new developers, more stakers, and even new projects building off Prysm forks. Over the years, we have designed our project with maintainability in mind, but it is time to step it up and improve the developer experience to further align with best practices. As such, we have decided to restructure the folder organization of our project to make things easier for ourselves and incoming contributors. This is an important change because it can break existing projects that import Prysm Go packages, as the paths of those packages may be different in Prysm v2.
Two major problems solved by having a great structure for an open source code repository are:
- Maintainability: the simpler the repository is structured, the easier it is to refactor, to create new features, and for new developers to become productive and find things in the repo
- Developer Experience: many contributors and/or projects will choose to build on Prysm, import packages from Prysm as third-party dependencies, extend Prysm, and more. Making sane decisions about how to structure things pays off in the long-run, and makes our repository a role model for other Go projects
We believe these are worthwhile goals and the right time to talk about them as we are still on the verge of launching Prysm v2.0.0 and before the merge of Ethereum with the Beacon Chain.
Here are some of the changes we are thinking about:
Moving Internal Packages Into an Internal Folder
The internal/ directory is enforced by the Go compiler as code that cannot be imported by external callers. Eli Bendersky from Google writes the following regarding internal/:
If you’re wondering whether some package belongs in internal, it’s prudent to begin by answering “yes”. It’s easy to take an internal API and export it to users — just a quick renaming/refactoring commit. It’s very painful to take an external API and un-export it (user code may depend on it); at stable module versions (v1 and beyond), this requires a major version bump to break compatibility [2].
I really like to put as much as possible in internal, not only private Go packages needed by my module. For example, if the repository contains the source code of the website of the project, I’d place that in internal/website. The same goes for internal tools/scripts needed to work on the project. The idea is that the root directory of a project should be minimal and clear to users. In a way, it’s self-documentation. A user looking at my project’s GitHub page should get an immediate sense of where the things they need are located. Since users don’t typically really need the stuff I use to develop the project, hiding it in internal makes sense.
That is, most of our beacon node and validator code should go in internal. We need to then decide what we want to export, and anything outside of internal is fair game to use by third-party callers. There is little controversy on this front.
Semantic Grouping of Packages
Instead of throwing a bunch of utility packages into a shared/ folder, we instead think carefully about how code fits together, and opt for semantic grouping of packages. That is, maybe some group of related functionality can all live under the same package instead of being in two separates ones. For example:
trieutil/
merkle_trie.go
powchain/
deposits.goThe powchain package uses trieutil extensively, so why don’t we instead group them? If another package wants to use the stuff in trieutil, we expose those functions and they can import a single package instead.
Some examples of popular Go projects with semantic grouping are:
Most notably, the Go source code itself follows this convention. Everything is neatly organized by functionality.
Moving of Tools/ Folder to a Periphery Repo
In Prysm v2.0.0, we have a lot of extra tools and binaries in the Prysm repository that only serve us as a team. Instead, we plan on moving most things in the tools/ folder in Prysm to prysmaticlabs/periphery. Those packages will not exist in the Prysm repo as of v2.0.0
Action Items for User
- None if you are a user of Prysm and not interacting with the actual codebase
- If you are a developer using Prysm, we will have a changelog of packages that will be restructured so you have enough time to change import paths of Prysm packages in your application. We will not do this package restructuring again, so it will be a one time pain
Interested in Contributing?
We are always looking for devs interested in helping us out. If you know Go or Angular and want to contribute to the forefront of research on Ethereum, please drop us a line and we’d be more than happy to help onboard you.
Check out our contributing guidelines and our open projects on Github. Each task and issue is grouped into the Phase 0 milestone along with a specific project it belongs to.
As always, follow us on Twitter or join our Discord server and let us know what you want to help with.
Official, Prysmatic Labs Ether Donation Address
0x9B984D5a03980D8dc0a24506c968465424c81DbE
Official, Prysmatic Labs ENS Name
prysmatic.eth
