Ethereum Protocol Fellowship - The Third Cohort (Update 8)

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.

Actions done

• My pull request, which implement the doppelganger detection in the Prysm Validator Client was finally merged.
• Working on a pull request which replace the GetFeeRecipientByPubKey gRPC request from the Prysm validator client to the Prysm beacon node by an equivalent implementation using only the REST beacon API.

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. This API requests the beacon node to indicate if a validator has been observed to be live in a given epoch.

Also, before running a doppelganger check, the validator client has to ensure that the beacon node is correctly synced.