draft beacon GET registrations endpoint

[ciaranmcveigh5]

What does this PR do?

This PR adds a GET request endpoint of "/eth/v1/beacon/validator_registrations" (endpoint still TBD).

The need for this endpoint is to enable distributed validators to efficiently integrate with the builder api.

Currently a validator registers to the builder network via a POST call with a SignedValidatorRegistrationV1 payload. Within SignedValidatorRegistrationV1 is ValidatorRegistrationV1.

class ValidatorRegistrationV1(Container):
    fee_recipient: ExecutionAddress
    gas_limit: uint64
    timestamp: uint64
    pubkey: BLSPubkey

One key field in this payload is the pubkey. In the consensus clients, this pubkey field is automatically set to the validator key. While this is fine in a normal validator set up it isn't with distributed validators.

This is because the validator key is a pubkeyshare of the aggregate pubkey the network will see.

This poses 2 problems say we have a 2 of 3 Distibuted validator with pubkeyshares 0xa, 0xb, 0xc and an aggregate pubkey 0xf.

For DV middlewares to aggregate the pubkeyshare signature the signed payloads must be identicial. In the above scenario they won't be, one will have pubkey=0xa, another pubkey=0xb etc.

Even if we were able to get them to agree on signing a specific payload with pubkey=0xa this would still be an issue. The pubkey 0xa is not what the Ethereum network sees when a registration is sent. It instead see signatures from the aggregate pubkey 0xf. The relays do some verification against the signature and the pubkey in the payload to verify a registration is valid.

The relay would see a signature from 0xf but within the payload the pubkey would be set to 0xa.

As a result we need all registration payloads to use the aggregate pubkey as the pubkey field.

A simple way to achieve this is via a GET endpoint for validator registrations where beacon can take note of all the validators it has access to and generate an array of ValidatorRegistrationV1. This is return to the Validator client which signs it and sends it to the network.

(something about what corver said in terms of this aligning with the current relationship between VC's and beacons ie that a beacon is a trusted data source for the VC)

If Consensus clients don't want to implement this a the default method to return network load it can be enabled with a --get-registrations-from-beacon flag

(Do we mention the current work arounds?) proposerConfig.json validator_definitions.yml - non standard, only possible with VC's that enable configuring individual validators with registration overrides

[ciaranmcveigh5]

I was thinking about making this a specific endpoint with /$validator at the end however all the clients submit the registrations in one big bundle so I thought it made sense to just return an array of registrations for all validators associated with that beacon

[ciaranmcveigh5]

Where should this endpoint be, don't know if it fits well into pool

could create a new folder called builder and it would be

/eth/v1/beacon/builder/validator_registration

depends on what the eth guys want

[ciaranmcveigh5]

registrations rather than registration

used ValidatorRegistrationV1 since it's the exact spec name

[ciaranmcveigh5]

same here registration or registrations

[ciaranmcveigh5]

schema already exists in registration.yaml

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication