Attestation and Sync Committee aggregation selection

[OisinKyne]

Problem this PR intends to address

Distributed Validator Technology is the idea that a number of independent validator clients can operate together as one or more logical 32 ether validators using BLS signature aggregation. The proof of stake spec has been designed with the intention of being MPC friendly.

There is however an issue with the assignment of aggregation duties. These duties are determined by the hash of a slot_signature. In a distributed validator, each individual validator has a different BLS private key, so they all individually produce different slot_signatures that hash differently, so all attempt to aggregate at different incorrect occasions.

What does this PR do?

This PR adds two new endpoints:

/eth/v1/validator/beacon_committee_selections
/eth/v1/validator/sync_committee_selections

These endpoints are optional for a consensus client, and are designed to be opt-in for validator clients (when something like a --distributed mode is enabled). These endpoints are implemented by the distributed validator middleware that intercepts this API.

When a validator is configured to run as part of a distributed validator cluster, at the start of an epoch (slot for sync committee) the validator client will determine its attestation duties then calculate a slot signature for that slot to determine whether it must also aggregate. In the distributed flow, it will send this slot_signature to the beacon client, and take the signature returned as a response as the one to use to calculate is_aggregator(). If this test returns true, and the validator must produce an aggregate attestation (or sync contribution), the combined signature (not the partial) must also be included in the AggregateAndProof object.

This extra step can be visualised in the aggregation flow like so:

Things to note

• This proposal has been changed from a /v2/ of another endpoint to its own /v1/ endpoint (along with a second for sync aggregations).
• This endpoint need not be implemented on the CL side. Once a validator client is aware of it and able to use it when a feature flag is turned on, the intercepting middleware can handle and swallow the request. I suggest a CL either returns:
  • 501 Not Implemented
  • 400 Bad Request. To indicate to the user that they either have --distributed turned on for a non DV use case, or they have a distributed validator private key wired directly to a consensus client without any middleware in between.
• Not implementing this would mean distributed validators do not aggregate as required (though there is no direct punishment for not aggregating currently), and the overall network effectiveness would be harmed.
• The pros and cons and previous designs of this change can be read in more detail here.

[corverroos]

Could we maybe add validator_index here so it is explicit which validator is the aggregator? The implicit mapping using request array indexes feels brittle.

[xenowits]

I agree. So, the response would instead look like:

[
  { "validator_index": 7, "is_aggregator": false},
  { "validator_index": 1, "is_aggregator": false},
  { "validator_index": 13, "is_aggregator": true}
]

[corverroos]

The summary and description probably need to be updated to reflect the new flow. VCs do not "signal" the BN anymore, but rather "VC provides data to maybe signal and BN responds with wether it was signalled".

[rolfyone]

I'm curious why the validator isn't passing is_aggregator, but rather the signature? If the validator passes is_aggregator for the indices that are aggregating, then the middleware could read the post body...

Is there another need for the signature to be passed? If you have is_aggregator in the request, then the request body would have all the details that the middleware might need...

Not sure if this is covered elsewhere, but this is basically a sticky session kind of deal - if the request goes to 1 BN, the aggregate request would need to go to that same BN, otherwise likely wouldn't get a usable aggregate... or send the request to all (or subset and track) BN...
Posting the signed aggregate could land anywhere, it's just the request for the aggregate which would be sticky

[ajsutton]

Is there another need for the signature to be passed? If you have is_aggregator in the request, then the request body would have all the details that the middleware might need...

The actual validator key is an aggregate of multiple different keys, each running in its own validator client. The middleware needs to capture the actual signature from each vc and aggregate them to get the signature for the validator that's actually on chain, then use that signature to determine if aggregation should be performed or not.

[OisinKyne]

Hi @rolfyone :)

As mentioned by Adrian, we can't have a VC send a boolean of whether it should aggregate because right now each validator is hashing the wrong signature to correctly determine whether it should aggregate. For us to correctly figure out if a validator should aggregate, we need to combine a threshold of these signatures together to get the real slot_signature for the validator, which then gets hashed and modulo'd here to dictate whether or not you are a selected to aggregate.

In practice, this endpoint is designed to be intercepted, and might not need to ever be implemented on the beacon node side if the client teams don't want to. A middleware client intercepting these V2 requests and calculating the aggregation selection could subsequently call the CL's /V1/ endpoint with true/false. It would be the validator side of things that would need to be aware of this endpoint, and be able to use it when a feature flag is enabled.

Posting the signed aggregate could land anywhere, it's just the request for the aggregate which would be sticky

Correct it is important that all CLs get notified to prepare for an aggregate once it has been determined. The distributed validator clients come to consensus on what aggregate to present to the connected VCs for signing, so they should be tolerant to a subset of CLs not returning a meaningful aggregation to sign.

[mcdee]

A middleware client intercepting these V2 requests and calculating the aggregation selection could subsequently call the CL's /V1/ endpoint ...

To date the V2 of an endpoint causes the deprecation of the V1 endpoint. If these endpoints are meant to co-exist (even if one is only used by the beacon node and the other by the middleware) then this should be a separate endpoint, not V2 of the existing endpoint.

[OisinKyne]

To date the V2 of an endpoint causes the deprecation of the V1 endpoint. If these endpoints are meant to co-exist (even if one is only used by the beacon node and the other by the middleware) then this should be a separate endpoint, not V2 of the existing endpoint.

Hi @mcdee good to hear from you. We chatted as a team today and agree. We think this endpoint as proposed is arguably doing two jobs (telling the VC if it should aggregate, and telling the upstream BN to announce and listen on the topic, and begin preparing an aggregate), we think maybe we can make things more simple.

We are thinking we might re-work this PR, and change it to an independent v1 endpoint used only for returning an aggregate slot signature, to allow the VC to determine if they are an aggregator. (we will have a second almost identical endpoint for the sync committee aggregate). Then the flow would be:

• If validator is in "distributed mode";
• send slot_signatures to /eth/v1/validator/beacon_committee_selections
• wait for a returned signature
• check if selected to aggregate (sha(signature) mod 8 == 0)
• if yes or no, VC calls /eth/v1/validator/beacon_committee_subscriptions as normal and uses the boolean to indicate aggregation
• if yes, asks BN for an aggregate attestation at 2/3rds of the slot

So basically if the VC enables this mode they are taking the hit of making a blocking network call to know whether it should aggregate, but this is needed to allow DVs to aggregate such that we don't negatively impact attestation density network wide if DVT sees adoption.

P.S. We just added tentative support for vouch :)

[OisinKyne]

Hey @michaelsproul, was there a reason to dismiss the previous approval on this PR? :) It showed as stale as I keep rebasing this PR as more commits go onto main. @rkapka 's request changes is from a much older version of this PR, so that one can probably be also marked resolved if he doesn't get a chance to look at it, had been planning to give him a week before chasing, though opting to tag now while I'm posting this.

Cheers.

[michaelsproul]

Hey @OisinKyne not sure what happened there sorry, I didn't mean to do that. I think sometimes reviews get marked stale when a conflict happens, I'm not sure why my name was associated with it. Maybe because I merged this unrelated PR? #285.

[rolfyone]

I wonder if we should have a new tag, either Distributed Validator or something, to allow people to easily see what distributed validators are implementing...

[rolfyone]

This looks pretty good, have a stab at adding to the top level CHANGES.md too :)

my mistake

[rolfyone]

As far as i can tell this was approved. marking so.

[arnetheduck]

Is there any implementation of this PR? Any test cases?