Part 2: Technical Overview
The Building Blocks
- In each committee, a subset of validators is selected to perform aggregation of the committee's messages. This improves scaling.
- Selection of aggregators is probabilistic based on BLS signatures.
- This selection method preserves both secrecy and easy verifiability of the identity of the aggregators.
In both beacon committees and sync committees validators create and sign their own votes (
SyncCommitteeMessages respectively). These votes must be aggregated into a much smaller number of aggregate signed votes, ideally into a single aggregate signature over a single vote, before being included in beacon blocks.
The goals of aggregation are three-fold: to reduce the signature verification load on the next block proposer, to reduce the network load on the global gossip channel, and to reduce the amount of block space required to store the signatures.
In the current beacon chain design, voting is done in committees with the goal of getting a majority of committee members to sign off on the same vote, although in practice there might be a number of different votes depending on the network views of the individual committee members. In any case, members of different committees are signing different data that cannot be aggregated across committees.
The process of aggregation is as follows:
- Committee members sign their votes (
SyncCommitteeMessages depending on which type of committee we are considering) and broadcast them to a peer-to-peer subnet that the whole committee is subscribed to.
- A subset of the committee is selected to be aggregators for that committee.
- The aggregators listen on the subnet for votes, then aggregate all the votes they receive that agree with their own view of the network into a single aggregate vote (aggregate
- Each aggregator wraps its aggregate vote with a proof that it was indeed an aggregator for that committee, and it signs the resulting data (
- Finally, the aggregator broadcasts its aggregated vote and proof to a global channel to be received by the next block proposer.
This section is concerned with steps 2 and 4: how the aggregators are selected for duty, and how they prove that they were indeed selected.
Aggregator selection desiderata
Aggregator selection has been designed with three properties in mind.
First, the size of the resulting aggregator set. With very high probability we want a small, non-empty subset of the committee to be selected in order that we have a very high chance of selecting at least one honest, well-connected aggregator. It doesn't matter too much if our set of aggregators is slightly on the large side, but we really want to avoid having no aggregators at all. Bearing in mind that there's a chance of validators being down or malicious, selecting only one or two aggregators is also risky.
Second, secrecy. We'd prefer that nobody be able to calculate who the aggregators are until after they have broadcast their aggregations. This helps to avoid denial of service (DoS) attacks. Disrupting consensus would be much simpler via a network DoS attack against a small number of aggregators than against a whole committee. The secrecy property prevents this.
Third, verifiability. We want it to be easy to verify a claim that a particular validator was selected to be an aggregator. The rationale for this is explained in the p2p spec. Basically, without verifiability it would be a good strategy for all the validators in the committee to make and broadcast aggregate attestations to ensure that at least one aggregate includes their own attestation. This would destroy the benefits of the whole aggregator scheme.
Aggregator selection details
The current aggregation strategy was introduced in PR 1440 and is described in the Honest Validator specs for beacon committees and sync committees.
It turns out that we can straightforwardly satisfy our three desirable properties of size, secrecy, and verifiability using BLS signatures. Each validator in the committee generates a signature over the current slot number using its secret signing key. If that signature modulo a given number is zero then it is an aggregator, otherwise it is not an aggregator.
The following are the spec functions for determining which validators are the aggregators in beacon committees.
def get_slot_signature(state: BeaconState, slot: Slot, privkey: int) -> BLSSignature: domain = get_domain(state, DOMAIN_SELECTION_PROOF, compute_epoch_at_slot(slot)) signing_root = compute_signing_root(slot, domain) return bls.Sign(privkey, signing_root)
def is_aggregator(state: BeaconState, slot: Slot, index: CommitteeIndex, slot_signature: BLSSignature) -> bool: committee = get_beacon_committee(state, slot, index) modulo = max(1, len(committee) // TARGET_AGGREGATORS_PER_COMMITTEE) return bytes_to_uint64(hash(slot_signature)[0:8]) % modulo == 0
This approach provides secrecy since it relies on the validator's secret key: no-one else can determine whether or not I am an aggregator until after I have published the proof. And it provides verifiability since, once the proof is published, it is easy to check the validity of the signature using the validator's public key.
What about the size criterion?
Beacon committee aggregators
Assuming that BLS signatures are uniformly random, then in a committee of size each validator will have a probability of being selected of
/ (ignoring the integer arithmetic). So in expectation we will have
TARGET_AGGREGATORS_PER_COMMITTEE (16) aggregators per committee.
The probability of having zero aggregators is . For the minimum target committee size of this is 1 in 26 million, and for the maximum committee size of , 1 in 9.5 million. So we would expect to see a beacon committee with no aggregators about once every 13,000 epochs (8 weeks) in the former case and once every 5000 epochs (3 weeks) in the latter. Each committee comprises only a fraction of the total validator set, so occasionally having no aggregator is insignificant for the protocol, but it is unfortunate for those in that committee who will most likely not have their attestations included in a block as a result.
Sync committee aggregators
Sync committees operate similarly. Each committee has 512 members that are divided across four independent subnets. The target is to have 16 aggregators per subnet as above, with the aggregators changing in each slot.
TARGET_AGGREGATORS_PER_SYNC_SUBCOMMITTEE value was increased from 4 to 16 ahead of the implementation of sync committees. This was based on an analysis showing that, by targeting only four aggregators, there would be an unacceptably high chance of having no aggregators on a sync committee subnet.
Aggregators are not directly incentivised by the protocol: there are no explicit rewards or penalties for performing or not performing aggregation duties.
However, there are implicit incentives. For one, if I produce a high quality aggregate signature it helps to ensure that my own signature is included in a block (there's a chance that someone else's aggregate may not include my signature). For another, since overall attestation rewards scale in proportion to participation (inclusion of attestations in blocks), aggregators benefit alongside all the other validators from slightly higher rewards when they make high quality aggregates that include many votes.
Hsiao-Wei Wang has documented the original research around aggregator selection.
This aggregation strategy presents a difficulty for building distributed validator technology (DVT). One approach to implementing DVT is for the multiple validators representing a single validator to operate independently, alongside a middleware that combines their signed attestations. This works because BLS signatures are additive: each validator has part of the key, and the signed attestations can be combined with a threshold signature scheme into a signature from the full key. However, the process of hashing the (combined) signature can't be done in a distributed way, so it is difficult for the individual validators to determine whether the collective validator has been selected to be an aggregator or not. Oisín Kyne's ethresear.ch article explores this problem and suggests a solution, which appears (slightly modified) in the proposed addition of two endpoints to the Beacon API spec.