V2 prepareBeaconCommitteeSubnet

[OisinKyne]

What does this PR do?

This PR adds a version 2 endpoint of /eth/v1/validator/beacon_committee_subscriptions.

The difference between this version and the previous version of the endpoint is that in V1, a validator client would just set a boolean value of is_aggregator to true, in their request to a beacon node to inform the BN that the VC has been selected to aggregate. This required the BN to begin aggregating attestations for a given subnet, in anticipation of being asked for an aggregation to sign later in the slot.

In this version, a validator must instead supply its slot_signature value instead of this is_aggregator boolean, which is used by the beacon client to determine whether a validator is required to aggregate 'server-side' so to speak.

This change is being introduced in an effort to facilitate a middleware based distributed validator architecture. Currently, validators with a subset of the private key calculate their occasion to aggregate incorrectly. With the introduction of this endpoint, a validator client could ask its beacon node whether it should aggregate or not. This allows a middleware distributed validator client like charon to intercept and aggregate a threshold of slot_signatures before hashing them to determine whether the DV must aggregate, at which point it would resolve the hanging requests to this new endpoint as [{"is_aggregator":"true"}] telling the validator client that it should ask for an aggregation object to sign at the appropriate time.

Things to note

• There is an issue with the linter atm, I see open discussion about a change of linter so no action taken here.
• Is the object {"is_aggregator":boolean} superfluous? Would an array of booleans [true,false,...] be sufficient or be too unclear?

[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? https://github.com/ethereum/beacon-APIs/pull/285.

[rolfyone]

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

[arnetheduck]

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