# Ethereum Protocol Fellowship - The Third Cohort (Update 7)

## Long term topic I'm working on
Rewrite the validator client code to be compatible with the Beacon API instead of prysmaticlabs' internal API.

Ticket [here](https://github.com/prysmaticlabs/prysm/issues/11580).

## Actions done
- Merged this [pull request](https://github.com/prysmaticlabs/prysm/pull/11786) to replace usage of `eth/v1alpha1/validator/statuses` gRPC API in Prysm by the equivalent in Beacon API. `statuses` is useful when the Validator Client needs to know the status of multiple validator keys.
- Published this [pull request](https://github.com/prysmaticlabs/prysm/pull/11827) to replace usage of `eth/v1/beacon/pool/sync_committees` gRPC API in Prysm by the equivalent in Beacon API. This API is used when a validator wants to publish a sync committee message.
- Published this [pull request](https://github.com/prysmaticlabs/prysm/pull/11835), which implement the doppelganger detection in the Prysm Validator Client.

## More details about doppelganger
The doppelganger detection is a mechanism which, for a given validator key:
1. Check when the validator client last performed an action (attestation / block proposal...) for this given validator key.
2. Check onchain if the given validator key has been seen alive during the last 2 epochs.

If, for a given validator key, no action has be done by the validator client during the last 2 epochs AND if this validator key has been seen alive during the last 2 epochs, it means somebody is validating for this key somewhere ==> This is a doppelganger, the validator client won't start.

Using gRPC API, this logic is implemented in the beacon node, with direct access to the beacon state. The validator client asks to the beacon node if there is a doppelganger for a given key. If the beacon node answers "yes", then the validator client won't start to avoid any slashing risk.

Using Beacon API, this logic has to be implemented in the validator client.
The validator client has access to its local antislashing database, which fulfill point `1.`.

However, the validator client does not have a direct access to the beacon state. So to fulfill point `2.`, I chose to use the newsly defined [liveness API](https://ethereum.github.io/beacon-APIs/?urls.primaryName=dev#/Validator/getLiveness). This API requests the beacon node to indicate if a validator has been observed to be live in a given epoch.