Implement selections Beacon API endpoints to support DVT middleware

[chong-he]

Issue Addressed

• DVT Compatibility #6610

Proposed Changes

• Add beacon_committee_selections endpoint
• Test beacon committee aggregator and confirmed working
• Add sync_committee_selections endpoint
• Test sync committee aggregator and confirmed working

Additional Info

Thank you @michaelsproul and @macladson for the help and guidance

[chong-he]

With the commit 8b2f058 where VC sends partial signatures in parallel for all validators for a slot, I believe the aggregated attestations are successful (during testing) now, thank you @michaelsproul !

Lighthouse VC logs:

{"log":"Mar 20 06:36:24.046 INFO Successfully published attestation      type: aggregated, slot: 37, committee_index: 0, head_block: 0xdb186315afecb3d1134d03eb2d5b04b83a21ede56be6563e3bff304b103bf4b6, signatures: 24, aggregator: 58, service: attestation\n","stream":"stderr","time":"2025-03-20T06:36:24.04690072Z"}

for every slot now

Charon logs:

{"log":"06:36:24.074 INFO bcast      Successfully submitted attestation aggregations to beacon node {\"delay\": \"8.074945477s\", \"duty\": \"37/aggregator\", \"peer\": \"twinkling-pen\", \"protocol\": \"/charon/parsigex/2.0.0\"}\n","stream":"stderr","time":"2025-03-20T06:36:24.074999639Z"}

for every slot now too

@KaloyanTanev could you give it a try and confirm that the beacon committee selection endpoint is working as intended?

Thanks

[dknopik]

Thanks! I've added a few notes.

[mergify]

This pull request has merge conflicts. Could you please resolve them @chong-he? 🙏

[chong-he]

Thanks! I've added a few notes.

Thank you so much for the review and help. All revised accordingly, let me know if further changes required.

[dknopik]

Do you know why this is needed (here and above)? It seems weird to me to compute the proof for the previous slot.

[chong-he]

I honestly don't know why. @michaelsproul might have an answer for this.

In the distributed mode, I follow the same logic to also compute slot - 1

[michaelsproul]

@dknopik Sync committee messages have a confusing number of offsets from the current slot built in, but I think what we have now is correct.

From: https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/validator.md#prepare-sync-committee-message

If a validator is in the current sync committee (i.e. is_assigned_to_sync_committee() above returns True), then for every slot in the current sync committee period, the validator should prepare a SyncCommitteeMessage for the previous slot (slot - 1) according to the logic in get_sync_committee_message as soon as they have determined the head block of slot - 1. This means that when assigned to slot a SyncCommitteeMessage is prepared and broadcast in slot-1 instead of slot.

And then in the aggregate verification, we have another offset to deal with the fact that sync contributions and aggregates are for the previous slot (https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/p2p-interface.md#sync_committee_contribution_and_proof):

# Committees assigned to `slot` sign for `slot - 1`
# This creates the exceptional logic below when transitioning between sync committee periods

This is super confusing to reason about though, so I think we should definitely add a test (maybe in the simulator) to assert that we don't mess up the contribution at the period boundary.

[dknopik]

Ah, ok, thanks. I understand that we are treating slot as the duty slot, and proof_slot (= slot - 1) as the slot in which we have to actually sign the head root (SyncCommitteeMassage) and, if we are an aggregator, the contribution. However, in the context of this code, we start iterating over the slots to (pre-)compute selection proofs for starting at SlotClock::now() (let's call that slot X). However, for slot X, everything to do was done already, as we sign the SyncCommitteeMessage at (X-1)+4s and the contribution at (X-1)+8s. So there is no need at all to compute the selection proof for duty at slot X anymore.

So I guess the fix is to iterate from X + 1 to pre_compute_slot + 1 instead of from X to pre_compute_slot. Which is almost equivalent to removing let proof_slot = slot - 1;, except for one check and logging.

[michaelsproul]

Oh yeah I think you are right. I think we should raise a PR with a test for this separate to this PR

[dknopik]

I am still confused about the slot - 1. But when removing it, this PR looks good to me from the perspective of the functionality needed by Anchor. @michaelsproul do you know why that is there? By my understanding of the Altair spec, the proof for the previous slot is not at all relevant for the current slot.