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]

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.

[mergify]

Some required checks have failed. Could you please take a look @chong-he? 🙏

[dknopik]

Now that the off-by-one is fixed, this is good to go from an Anchor point of view :)

Thank you @chong-he!

@michaelsproul can you please take a look when you have time?

[michaelsproul]

I think we could think about re-combining these two cases in future, as the only substantial difference is the usage of FuturesUnordered in the non-distributed case. The non-distributed case is still parallel but it waits for all of the proofs to come in before writing them to the in-memory map. Whereas in the distributed case we add proofs as they become available. FuturesUnordered would likely be fine for both cases, and would save us a lot of duplication of logic.

I've opened an issue:

• De-duplicate sync selection proof logic (distributed vs non-distributed) #7983

[michaelsproul]

I've pushed two commits to address my review comments. The most important change was removing .data[0] which can panic.

• 239160e
• b7d6d2b