# Week 14

This week I worked on the endpoint [Implement /eth/v1/validator/beacon_committee_selections](https://github.com/ReamLabs/ream/issues/237). I began with research on its purpose and background.

## Background
The endpoint addresses a Distributed Validator Technology (DVT) challenge. In traditional validator setups, validators use their full private key to generate selection proofs that determine if they should aggregate attestations from their beacon committee. However, DVT systems like Obol’s Charon split private keys across multiple validator clients, which hold key shares and produce partial selection proofs that lead to incorrect aggregator determinations.

Obol Network proposed a solution around July 2022, introducing this endpoint so DVT validator clients can submit partial selection proofs and receive properly combined proofs in return. The middleware gathers partial proofs from a quorum of validator clients, combines them via BLS threshold aggregation, and returns the valid combined proof. This lets DVT validators perform aggregation duties without modifying consensus clients or fragmenting client diversity.

## Implementation
I noticed a similar endpoint, [/eth/v1/validator/sync_committee_selections](https://github.com/ReamLabs/ream/issues/239), is already implemented. Based on recent discussions, the Ream team doesn’t plan to support DVT in the near future, so I followed that precedent and implemented the endpoint to return HTTP 501, indicating that Ream does not support DVT at this time.

## Resources
- [Committee Aggregations with Distributed Validators](https://blog.obol.org/committee-aggregations-with-distributed-validators/)
- [Distributed Validator middlewares and the aggregation duty](https://ethresear.ch/t/distributed-validator-middlewares-and-the-aggregation-duty/13044)