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

## 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
##### `DELETE /eth/v1/validator/{pubkey}/feerecipient` endpoint
Wrote [this ticket](https://github.com/prysmaticlabs/prysm/issues/11943): When calling `DELETE /eth/v1/validator/{pubkey}/feerecipient` with a body, we get:

(There is no need to provide a body with `DELETE /eth/v1/validator/{pubkey}/feerecipient`, but if we do we get this runtime error.)

Wrote [this PR](https://github.com/prysmaticlabs/prysm/pull/11944) fixing the previously defined ticket.


##### `GetFeeRecipientByPubKey` gRPC API function
Currently, Prysm validator client communicates with Prysm beacon node via dedicated gRPC API. This API defines a `GetFeeRecipientByPubKey` route, which let the validator client a way to query the beacon node, given a pubkey, for the corresponding fee recipient.

There is no (direct or indirect) equivalent of `GetFeeRecipientByPubKey` defined in Beacon API.
Validator client cannot ask to beacon node for the fee recipient corresponding for a pubkey.

The [KeyManager API](https://ethereum.github.io/keymanager-APIs/) (exposed by the validator client), has this route: `GET /eth/v1/validator/{pubkey}/feerecipient`. For all couples pubkey/feerecipient directly in the validator client, there is no issue.

However, if the validator client manages a pubkey **without** any fee recipient defined, the response of `GET /eth/v1/validator/{pubkey}/feerecipient` is unclear in specification, and differs depending of validator clients implementations:

**Lighthouse:**
Lighthouse response is

{
"code": 500,
"message": "INTERNAL_SERVER_ERROR: no fee recipient set",
"stacktraces": []
}

(Note: [sigp/lighthouse#3507](https://github.com/sigp/lighthouse/issues/3507) is open about error code)

**Teku:**
Teku does not allow to start a validator client without setting a fee recipient.
At start, Teku validator client logs are:

2023-01-30 12:53:28.336 FATAL - Invalid configuration. --validators-proposer-default-fee-recipient or --validators-proposer-config must be specified when Bellatrix milestone is active

then Teku validator client quits.

==> A user cannot query `GET /eth/v1/validator/{pubkey}/feerecipient` on a Teku validator client if no (at least default) fee recipient is registered for {pubkey}.

**Prysm:**
Because it currently has its dedicated `GetFeeRecipientByPubKey` gRPC route, Prysm validator client requests the default fee recipient defined to the beacon node and returns it.
However, it won't be possible any more if Prysm only uses HTTP Beacon API.

The Ethereum specification is unclear concerning the behaviour to adopt in such a case. I opened a discussion about it in [Ethereum specifications](https://github.com/ethereum/keymanager-APIs/issues/55).

Currently, Prysm validator client uses dedicated gRPC `GetFeeRecipientByPubKey` route in 3 handlers of KeyManager API:
- https://ethereum.github.io/keymanager-APIs/#/Fee%20Recipient/listFeeRecipient handler
- https://ethereum.github.io/keymanager-APIs/#/Fee%20Recipient/setFeeRecipient handler
- https://ethereum.github.io/keymanager-APIs/#/Gas%20Limit/deleteGasLimit handler

[This PR](https://github.com/prysmaticlabs/prysm/pull/11970) removes the usage of dedicated gRPC `GetFeeRecipientByPubKey` route for `deleteGasLimit` and `setFeeRecipient`.

Also, the PR solves [this issue](https://github.com/prysmaticlabs/prysm/issues/11948), where, in some case specific case, the fee recipients is set to... `0x0000....` which is the burn address.

A next PR will handle the usage of dedicated gRPC `GetFeeRecipientByPubKey` route for `listFeeRecipient`.