Committee Aggregations with Distributed Validators

Basic principles of committee aggregations

Today, we want to talk about the two aggregation duties in Ethereum proof of stake and how distributed validator middlewares such as Charon can support them.

The Ethereum protocol has two kinds of committees: beacon committees and sync committees. Committees are subsets of the full set of active validators that are used to distribute the overall workload.

Beacon committees manage attestations for the consensus protocol whereas sync committees allow light clients to quickly and trustlessly determine the head of the beacon chain.

Validators that are part of a committee need to perform two types of duties, a standard and an aggregate duty. The standard duty consists of fetching data, signing it, and then submitting the signed message back to the beacon chain.

Aggregation duties involve combining (aggregating) multiple standard duty messages into a single Aggregate And Proof message. This aggregation is enabled by the BLS signature scheme used in Ethereum, which has allowed the proof of stake beacon chain to scale to hundreds of thousands of validators.

These aggregation duties are more complex than standard duties. First, each validator in the committee must generate a selection proof, which is a BLS signature. The selection proof is passed to an IsAggregator function which determines whether that validator is an aggregator for that slot or not. If the validator is an aggregator, it informs its consensus client to subscribe to the associated committee subnet, which listens for messages to aggregate. Some time later, it will then fetch an aggregate of the collected messages and combine it with the selection proof into a message called an Aggregate and Proof (A&P). The validator then signs the A&P and submits it to the beacon chain. Important to note is that the signed Aggregate and Proof is a nested signature containing the selection proof within it.

Current problem in performing committee aggregations with distributed validators

For DVT middleware architecture such as that of Obol, each validator client (VC) in the cluster only has access to a private key share, not the full private key. In the context of DVT, the signature that a private key shares generates is called a partial signature. DVT combines a quorum of these partial signatures using BLS threshold aggregation into the final signature that is submitted to the beacon chain, which is called the combined signature.

That means the selection proof that a DVT VC generates is a partial selection proof. Using a partial selection proof in the IsAggregator function produces incorrect results, so the VC cannot correctly determine if it is an aggregator or not. Additionally, combining a partial selection proof in the signed aggregate and proof message produces different results that cannot be threshold aggregated by the middleware DVT client.

The VC therefore needs to somehow get access to a complete combined selection proof in order to perform its aggregation duties.

Proposed solution

We have been working with key consensus layer stakeholders (1,2) to come up with a non-intrusive, non-breaking addition to the beacon API by adding two new endpoints that allow VCs to ask the middleware client (Charon) for a combined selection proof by providing a partial selection proof.

VCs that support middleware DVT MUST call these endpoints at the START of the slot to fetch a combined selection proof for use in committee aggregator duties (both beacon committee and sync committee).

The server side of these endpoints only need to be implemented by DVT middleware, not by any consensus clients (beacon nodes).

The client side of these endpoints only need to be implemented by validator clients that aim to support middleware DVT. It should be enabled by an opt-in feature feature flag like: `--distributed-validator`.

Validator flow

Let’s see how this works for the attestation aggregation flow.

• At the start of the slot where a validator has an attestation to make, the VC generates a partial selection proof.
• It immediately calls the new POST /eth/v1/validator/beacon_committee_selections endpoint with this signature, which returns the combined selection proof once a quorum of partial signatures have been received and combined to create the valid aggregate.
• Using the combined selection proof response, VC calculates if it is an attestation aggregator for the slot using is_aggregator function.
• If the VC is not an aggregator, it exits this flow. Otherwise;
• The VC calls POST /eth/v1/validator/beacon_committee_subscriptions with the IsAggregator=true value, this informs a beacon client to begin preparing an aggregate attestation to sign.
• Two thirds into the slot, the VC calls GET /eth/v1/validator/aggregate_attestation. This fetches the combined attestation from the beacon node.
• The combined attestation is combined with aggregated selection proof into a Aggregate And Proof message.
• Finally, the VC signs the Aggregate and Proof message and calls POST /eth/v1/validator/aggregate_and_proofs . This publishes the signed aggregate attestation. 🎉
• Note this final signed aggregate and proof is itself a partial aggregate and proof. But since it contains the combined selection proof, the DVT middleware is able to threshold aggregate it into a combined signed aggregate and proof which is submitted to the beacon chain.

It is noteworthy that only one additional new endpoint is needed to support attestation aggregations without altering any other existing APIs and the flow remains mostly unchanged. This same approach works to support sync contribution aggregations as well.

Conclusion

This article outlines how we can add high availability to existing validators on Ethereum with some minor extensions to the consensus API specification and some opt-in behaviour for a validator client. We believe making DVT an additive feature that all clients can utilise is better for decentralisation than making a custom validator client capable of signing arbitrary messages, similar to how mev-geth was replaced by mev-boost in part to reduce the client centralisation force it posed.

This post is designed to source feedback, concerns and support for middleware based distributed validators and the addition to the beacon API and opt-in modified validator client behaviour we are proposing. The next step for this proposal is to bring it to the consensus implementers call once feedback can be incorporated.

Thanks for reading!

Appendix

API Structure

SSZ Containers