---
# System prepended metadata

title: EPF Cohort 3 Dev Update 2 (pavignol)

---

# EPF Cohort 3 Dev Update 2 (pavignol)

I didn't get a chance to write an update last week because I was deep into reading and familiarizing myself with the prysm repository, but a lot happened since then!

## Creation of the design document

After discussing with the Prysm mentors and the other fellows working on the Prysm client, we came up with 2 possible goals that we could focus on for this cohort:

- Validator refactoring to use the Beacon API REST APIs
- Switching to EIP-2335 and EIP-2386 for Key Management

Everyone agreed that the validator refactoring should be the main goal, but there's also a possibility to work on the Key Management improvements if there's time or if people are interested!

With those 2 goals in mind, I went ahead and created a [design document](https://hackmd.io/@pavignol/SJh-plvNo) outlining what was discussed in the discord chat. The most important part of this document is the equivalence table between the gRPC endpoints that Prysm currently uses to query the beacon node, and the REST API endpoints that want to migrate to in order to be compatible with other beacon nodes and reduce the maintenance burden.

## My first PR against the Prysm repo

After having a good idea of how the refactoring should look like, I went ahead and made [my first PR](https://github.com/prysmaticlabs/prysm/pull/11612) against the prysm repository! The PR has been approved and only a few linting errors need to be resolved before it gets merged.

The goal of this PR is to prepare the repository for further Beacon API work for the Prysm validator. It adds a `use_beacon_api` flag that makes sure that work in progress won't disrupt the day-to-day Prysm development work and won't make it into the release binaries by mistakes. This reduces risk as much as possible while allowing us to incrementally merge our changes as they are ready. The PR also adds empty stubs for all REST API function calls that we need to make to replace the current gRPC usage.

Once this PR gets merged, it will be relatively straightforward to implement the different endpoints without changing the behavior of the current gRPC validator client. It also has the advantage of automatically leveraging the existing tests (including the end-to-end tests), which will put the REST API quality bar at the same height as the gRPC quality bar.