# Changes Coming in Prysm V2 Stakers Need to Know

Near the end of August, 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 release 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 two, we anticipate the mainnet release of the [Altair hard fork](https://github.com/ethereum/annotated-spec/blob/master/altair/beacon-chain.md). 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](https://www.coindesk.com/eth-2-0-validators-can-expect-after-altair-upgrade).

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.

### 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](https://discord.gg/prysmaticlabs) or post a [Github issue](https://github.com/prysmaticlabs/prysm/issues/new) 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 `--slasher` flag 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](https://github.com/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](https://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:

1. 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
2. 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.go

The 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:

- https://github.com/authelia/authelia
- https://github.com/golang/go/tree/master/src

Most notably, the [Go source code](https://github.com/golang/go/tree/master/src) 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](https://github.com/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