# EPF Cohort 3 Dev Update 3 (pavignol)

I have been falling behind a bit on my updates as I was deep into coding, so this update will be for the entire moth of November. I'll try to write updates every week or every 2 weeks for the remaining weeks of the cohort.

## Added customizable endpoints for the Validator's REST API

The first feature I worked on during this period was to [add customizable endpoints for the validator's REST API in Prysm](https://github.com/prysmaticlabs/prysm/pull/11633). What this change does is refactoring the entire validator codebase to be able to use the beacon REST API instead of the gRPC one when the validator communicates with the beacon node. This allows us to start testing our REST API endpoints as we add them, even though we're just getting started. When building Prysm with the `--config=beacon_api` flag, the beacon REST API implementation is used; otherwise, the old gRPC implementation is used instead.

## Added a beacon REST API implementation for Validator's WaitForChainStart

`WaitForChainStart` is an endpoint specific to Prysm, but basically all it needs to do is call the `/eth/v1/beacon/genesis` endpoint described in the [Beacon Node API spec](https://ethereum.github.io/beacon-APIs/#/Beacon/getGenesis). A particularity of `WaitForChainStart` is that, unlike `/eth/v1/beacon/genesis`, it should block when it receives an error `404` and only return once it finally receives a successful `200` code or another error code. Alas, to keep the PR concise, I postponed the blocking functionality and implemented it in another PR, a few days later.

## Added a gRPC fallback mode to the Validator beacon REST API

Previously, when Prysm was built with the `--config=beacon_api` and a validator function that didn't have a beacon REST API implementation was called, it simply panicked and exited early. Although it made it clear which functions were implemented and which ones were not, it made it really hard to thoroughly test more complex endpoints since the validator would crash before reaching time. To work around this, I [added a gRPC fallback mode to the Validator beacon REST API](https://github.com/prysmaticlabs/prysm/pull/11679). REST API implementations will be used when they are available, but if they haven't been implemented yet, it will successfully fallback to the gRPC version.

## Onboarded the validator's beacon REST API tests to CI

As we started added more endpoints and unit tests, we realized that the tests were not running during CI because the bazel file was lacking the `gotags = ["use_beacon_api"]` attribute, so [I went ahead and onboarded them](https://github.com/prysmaticlabs/prysm/pull/11682)

## Made the validator REST API's WaitForChainStart blocking

As explained above, the second part of the `WaitForChainStart` function is to stay blocked as long as it's getting `404` errors, and only return once a non-404 error or a `200` status is received. To implement this functionaly, [I simply keep pinging the beacon node with delays of 1 second until it stops returning a `404` error](https://github.com/prysmaticlabs/prysm/pull/11695).