Section on aggregator selection

2026-01-09 14:38:08 -05:00 · 2022-06-29 19:48:14 +01:00
parent 5757a55868
commit 60ce24d632
5 changed files with 209 additions and 27 deletions
--- a/bin/build/spellings.txt
+++ b/bin/build/spellings.txt
@@ -242,6 +242,7 @@ mainnet
 masse
 md
 memoised
+middleware
 misbehaviours
 misconfiguration
 modularity
@@ -262,6 +263,7 @@ repo
 reserialise
 roadmap
 scalability
+scalable
 secp
 serialiser
 sharding
@@ -297,6 +299,7 @@ validator
 validator's
 validators
 vals
+verifiability
 verifiably
 verifier
 whistleblower
--- a/src/book.md
+++ b/src/book.md
@@ -1807,7 +1807,7 @@ Say your public key is $pk_1$, and I have a secret key, $sk_2$. But instead of p

 Now, when verifying with my rogue public key and your actual public key, the claim checks out: it looks like you signed the message when you didn't: $e(g1,\sigma)=e(g_1,[sk_2]H(m))=e([sk_2]g_1,H(m))=e(pk_1+pk'_2,H(m))$.

-One relatively simple defence against this &ndash; the one we are using in Ethereum&nbsp;2 &ndash; is to force validators to register a "proof of possession" of the private key corresponding to their claimed public key. You see, the attacker doesn't have and cannot calculate the $sk'_2$ corresponding to $pk'_2$. The proof of possession can be done simply by getting all validators to sign their public keys on registration, that is, when they deposit their stakes in the deposit contract. If the actual signature validates with the claimed public key then all is well.
+One relatively simple defence against this &ndash; the one we are using in Ethereum&nbsp;2 &ndash; is to force validators to register a "proof of possession" of the secret key corresponding to their claimed public key. You see, the attacker doesn't have and cannot calculate the $sk'_2$ corresponding to $pk'_2$. The proof of possession can be done simply by getting all validators to sign their public keys on registration, that is, when they deposit their stakes in the deposit contract. If the actual signature validates with the claimed public key then all is well.

 ##### Threshold signatures

@@ -1842,7 +1842,7 @@ In case someone overnight unveils a sufficiently capable quantum computer, [EIP-
 As a reference, the following are the BLS library functions used in the Ethereum&nbsp;2 [specification](https://github.com/ethereum/consensus-specs/blob/v1.1.1/specs/phase0/beacon-chain.md#bls-signatures). They are named for and defined by the [BLS Signature Standard](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04). Function names link to the definitions in the standard. Since we use the [proof of possession](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04#section-3.3) scheme defined in the standard, our `Sign`, `Verify`, and `AggregateVerify` functions correspond to `CoreSign`, `CoreVerify`, and `CoreAggregateVerify` respectively.

  - `def` [`Sign`](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04#section-2.6)`(privkey: int, message: Bytes) -> BLSSignature`
-    - Sign a message with the validator's private key.
+    - Sign a message with the validator's secret (private) key.
  - `def` [`Verify`](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04#section-2.7)`(pubkey: BLSPubkey, message: Bytes, signature: BLSSignature) -> bool`
    - Verify a signature given the public key and the message.
  - `def` [`Aggregate`](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04#section-2.8)`(signatures: Sequence[BLSSignature]) -> BLSSignature`
@@ -1951,7 +1951,7 @@ This contribution needs to satisfy two properties: it should be unpredictable by

 ##### The new: BLS signatures

-A natural alternative to the hash onion became available when we moved to using [BLS signatures](/part2/building_blocks/signatures) in the protocol. With the BLS scheme every validator already has a closely guarded random value: the private key that it signs blocks and attestations with. As far as anyone knows the signatures produced are uniformly random. Therefore, BLS signatures generated by block proposers are an excellent source of the randomness that we need for updating the RANDAO.
+A natural alternative to the hash onion became available when we moved to using [BLS signatures](/part2/building_blocks/signatures) in the protocol. With the BLS scheme every validator already has a closely guarded random value: the secret key that it signs blocks and attestations with. As far as anyone knows the signatures produced are uniformly random. Therefore, BLS signatures generated by block proposers are an excellent source of the randomness that we need for updating the RANDAO.

 Using signatures rather than the hash onion both simplifies the protocol and provides for multi-party (distributed) validators. The aggregation properties of BLS signatures allow signatures from multiple validators to be combined as a threshold signature so that they can effectively act as a single validator. This valuable property would be very difficult with the hash onion approach.

@@ -1961,7 +1961,7 @@ For these reasons [we now use](https://github.com/ethereum/consensus-specs/pull/

 ##### Where does the entropy come from?

-Evidently the predominant source of randomness in the Ethereum 2 protocol is the private keys of the validators. This amounts to some 85 million bits of entropy with 332,000 validators (assuming, reasonably, that the validators generated their secret keys randomly and uniformly).
+Evidently the predominant source of randomness in the Ethereum 2 protocol is the secret keys of the validators. This amounts to some 85 million bits of entropy with 332,000 validators (assuming, reasonably, that the validators generated their secret keys randomly and uniformly).

 Some other sources of entropy for the RANDAO are noted in [EIP-4399](https://eips.ethereum.org/EIPS/eip-4399).

@@ -1971,7 +1971,7 @@ Some other sources of entropy for the RANDAO are noted in [EIP-4399](https://eip

 #### Updating the RANDAO

-When a validator proposes [a block](/part3/containers/blocks#beaconblockbody), it includes a field `randao_reveal` which has `BLSSignature` type. This is the proposer's signature over the [epoch number](https://github.com/ethereum/consensus-specs/pull/498), using it's normal signing private key.
+When a validator proposes [a block](/part3/containers/blocks#beaconblockbody), it includes a field `randao_reveal` which has `BLSSignature` type. This is the proposer's signature over the [epoch number](https://github.com/ethereum/consensus-specs/pull/498), using it's normal signing secret key.

 The `randao_reveal` is [computed](https://github.com/ethereum/consensus-specs/blob/v1.1.1/specs/phase0/validator.md#randao-reveal) by the proposer as follows, the `privkey` input being the validator's random secret key.

@@ -2587,6 +2587,12 @@ This property is important for light clients. Light clients are observers of the

 #### Introduction

+One of the biggest challenges in building a highly scalable consensus protocol is organising the work involved so as not to overwhelm the network.
+
+One goal of the Ethereum&nbsp;2 Proof of Stake protocol is to achieve economic finality. In the current design (though see [below](#see-also) for discussion of single slot finality) this requires us to gather votes from at least two-thirds of the validators, and we must do this twice. Hence, over the course of an epoch every validator votes for a checkpoint via its "source" and "target" attestations, and over the course of the next epoch every validator confirms that it has seen the others' votes. Thus every validator is involved in the process, which gives a very strong notion of "economic finality". But it takes at least two epochs (13 minutes) to achieve it.
+
+If the whole validator set were to attest simultaneously the amount of work for beacon nodes in validating and processing these attestations would be unmanageable. Therefore the work is divided among subsets of the validator set called committees.
+
 Committees are subsets of the total set of active validators that are used to manage and distribute the overall workload across validators.

 The Altair spec has two types of committees, beacon committees and sync committees, which have quite different functions. We will focus on beacon committees in this section, and deal with sync committees in a [later section](/part2/building_blocks/sync_committees).
@@ -2641,9 +2647,117 @@ HERE

 Beacon committees (which I shall just call committees from now on) feature prominently in the Eth2 specification, but actually have very little purpose in the current design.

-### Aggregator Selection <!-- /part2/building_blocks/aggregator* -->
+#### See also

-TODO
+In his survey article, [Paths toward single-slot finality](https://notes.ethereum.org/@vbuterin/single_slot_finality), Vitalik considers what it would take to introduce a single "super-committee" at each slot to replace the existing beacon committees. The super-committee would be a large enough subset of the whole validator set to achieve a satisfactorily secure level of finality within a single (extended, 16 second) slot.
+
+### Aggregator Selection <!-- /part2/building_blocks/aggregator -->
+
+<div class="summary">
+
+  - A subset of validators is selected in each committee to perform aggregation of the committee's messages. This improves scaling.
+  - The selection method targets a fixed number of aggregators per committee.
+  - The selection method preserves both secrecy and easy verifiability of the identity of the aggregators.
+
+</div>
+
+#### Introduction
+
+In both [beacon committees](/part2/building_blocks/committees) and [sync committees](/part2/building_blocks/sync_committees) validators sign their own votes (`Attestation`s and `SyncCommitteeMessage`s respectively). Before these votes are included in beacon blocks they need to be [aggregated](/part2/building_blocks/signatures#aggregation) into a much smaller number of aggregate signatures, ideally into a single aggregate signature over a single object.
+
+The goal of aggregation is two-fold: to reduce the signature verification load on the next block proposer, 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. However, members of different committees are signing different data that cannot be aggregated.
+
+The process of aggregation is as follows:
+
+1. Committee members sign their votes ([`Attestation`](/part3/containers/operations#attestation)s and [`SyncCommitteeMessage`](https://github.com/ethereum/consensus-specs/blob/v1.1.1/specs/altair/validator.md#synccommitteemessage)s depending on which type of committee we are considering) and broadcast them to a peer-to-peer subnet that they are all subscribed to.
+2. A subset of the committee is selected to be aggregators for that committee.
+3. The aggregators listen on the subnet for votes and aggregate all the ones they receive that agree with their own view of the network into a single aggregate vote (aggregate [`Attestation`](/part3/containers/operations#attestation) or [`SyncCommitteeContribution`](https://github.com/ethereum/consensus-specs/blob/v1.1.1/specs/altair/validator.md#synccommitteecontribution)).
+4. Each aggregator wraps its aggregate vote with a proof that it was indeed an aggregator for that committee, and it signs the resulting data ([`SignedAggregateAndProof`](https://github.com/ethereum/consensus-specs/blob/v1.1.1/specs/phase0/validator.md#signedaggregateandproof) or [`SignedContributionAndProof`](https://github.com/ethereum/consensus-specs/blob/v1.1.1/specs/altair/validator.md#signedcontributionandproof))
+5. 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.
+
+[TODO: insert diagram]::
+
+#### Aggregator selection desiderata
+
+Aggregator selection has been designed with three properties in mind.
+
+First, the size of the aggregator set. With very high probability we want a small, non-empty subset of the committee to be selected. 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. Bear in mind that there's a chance of any given validator being down or malicious.
+
+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. It would be much simpler to halt the chain by mounting 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](https://github.com/ethereum/consensus-specs/blob/v1.1.1/specs/phase0/p2p-interface.md#why-are-aggregate-attestations-broadcast-to-the-global-topic-as-aggregateandproofs-rather-than-just-as-attestations). Basically, without verifiability it would be a good strategy for _all_ the validators in the committee to make aggregate attestations and broadcast them to the global channel to ensure that at least one aggregate includes them. This would subvert the whole aggregator scheme.
+
+#### Aggregator selection details
+
+The current aggregation strategy was introduced in [PR 1440](https://github.com/ethereum/consensus-specs/pull/1440) and is described in the Honest Validator specs for [beacon committees](https://github.com/ethereum/consensus-specs/blob/v1.1.1/specs/phase0/validator.md#attestation-aggregation) and [sync committees](https://github.com/ethereum/consensus-specs/blob/v1.1.1/specs/altair/validator.md#aggregation-selection).
+
+It turns out that we can straightforwardly satisfy our three desirable properties of size, secrecy, and verifiability using [BLS signatures](/part2/building_blocks/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 target is zero then it is an aggregator, if not then it is not an aggregator.
+
+The following are the [spec functions](https://github.com/ethereum/consensus-specs/blob/v1.1.1/specs/phase0/validator.md#aggregation-selection) for determining which validators are the aggregators in beacon committees.
+
+<a id="def_get_slot_signature"></a>
+
+```python
+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)
+```
+
+<a id="def_is_aggregator"></a>
+
+```python
+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 as it relies on the validator's secret key, so 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 $N$ each validator will have a probability of being selected of `TARGET_AGGREGATORS_PER_COMMITTEE` `/` $N$ (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 $(1 - \frac{16}{N})^N$. For the minimum target committee size of $N = 128$ this is 1 in 26 million, and for the maximum committee size $N = 2048$ 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 is only $1/2048$ of the total validator set, so occasionally having no aggregator is no threat at all to 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.
+
+<a id="img_committee_aggregators"></a>
+<div class="image">
+
+![A bar chart showing the probability of different numbers of aggregators in a committee of 256](md/images/charts/committee_aggregators.svg)
+The probability of of having $k$ aggregators in a beacon committee of size 256. The expected number is 16.
+
+</div>
+
+##### 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.
+
+The `TARGET_AGGREGATORS_PER_SYNC_SUBCOMMITTEE` value was [increased from 4 to 16](https://github.com/ethereum/consensus-specs/pull/2514) ahead of the implementation of sync committees. This was based on an [analysis](https://docs.google.com/spreadsheets/d/1C7pBqEWJgzk3_jesLkqJoDTnjZOODnGTOJUrxUMdxMA/edit#gid=1790975994) showing that, by targeting only four aggregators, there would be an unacceptably high chance of having no aggregators on a sync committee subnet.
+
+#### Miscellaneous notes
+
+##### Incentivisation
+
+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 increases my chances of ensuring that my own signature is included in a block. For another, since overall attestation rewards [scale in proportion to participation](/part2/incentives/rewards#rewards-scale-with-participation) (inclusion of attestations in blocks), validators benefit alongside all the other validators from slightly higher rewards when they make high quality aggregates.
+
+##### Interaction with DVT
+
+[TODO: link to DVT when written]::
+
+A possible approach to implementing distributed validator technology (DVT) is for the multiple validators that represent a single validator to operate independently, and for a middleware to combine 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](/part2/building_blocks/signatures#threshold-signatures) scheme into a signature from the full key.
+
+Aggregator selection complicates this. Since each validator has only part of the full key, it cannot calculate when it will be responsible for aggregator duties without collaborating with the other validators in its group. This creates a potentially significant overhead.
+
+We could work round this, for example, by basing aggregator selection on, say, $\mod(i, \frac{N}{16} = 0$, where $i$ is the position of the validator in the (possibly sorted) list of committee members. This is DVT-friendly and easy to verify. It also guarantees exactly 16 aggregators per committee. But it fails to meet the secrecy criterion: anyone could calculate in advance the aggregators for a committee.

 ### SSZ: Simple Serialize <!-- /part2/building_blocks/ssz -->

--- a/src/charts/charts.html
+++ b/src/charts/charts.html
@@ -41,6 +41,21 @@
    font: 'MyGaegu',
  };

+  // Maths utilities
+  const fac = [];
+  fac[0] = 1n;
+  for (var i = 1; i <= 256; i++) {
+    fac[i] = BigInt(i) * fac[i - 1];
+  }
+
+  function choose(n, k) {
+    return fac[n] / fac[k] / fac[n-k];
+  }
+
+  function prob(n, k, p) {
+    return (Math.pow(p, k) * Math.pow((1 - p), (n - k)) * Number(choose(n, k)));
+  }
+
  // Parameters for replacing text with SVG paths
  params = {
    'fontMap': {
@@ -620,7 +635,7 @@
    sum += 32 * Math.pow(r, 32);
    ys[j] = sum;
  }
-  
+
  async function do_randao_tail() {

    const xVals = rs;
@@ -681,14 +696,14 @@
  const rs = [0.05, 0.1, 0.15, 0.2, 0.25, 0.3, 0.35, 0.4, 0.45, 0.5, 0.55, 0.6, 0.65, 0.7, 0.75, 0.8, 0.85, 0.9, 0.95];
  const expected = [[0.05263157894737125, 0.11111111111111083, 0.17647058823529138, 0.2500000000000049, 0.33333333333333326, 0.4285714285714217, 0.5384615384615318, 0.6666666666665445, 0.8181818181752902, 0.9999999997671694, 1.2222222162138612, 1.499999880620087, 1.8571409425663519, 2.3333075633542677, 2.9996986427228354, 3.996830873499423, 5.635425065092333, 8.690968456173678, 15.319481795288468], [0.10275689223057916, 0.21212121212121138, 0.32992327365728136, 0.45833333333334336, 0.5999999999999999, 0.7582417582417407, 0.9373219373219239, 1.142857142856896, 1.382445141052778, 1.6666666662010055, 2.0107526761553265, 2.437499761240182, 2.9826801535317493, 3.705830813100236, 4.713683012705124, 6.215885085150261, 8.66732566477043, 13.12380535945681, 21.729892161223425], [0.19598253427326418, 0.3877423778413869, 0.5808141464366708, 0.7806555004135871, 0.9929038281979446, 1.2237098918505709, 1.4801868954314616, 1.7710412193165848, 2.1075018857114847, 2.504761903830583, 2.9843358775701074, 3.578143279983383, 4.336047775082686, 5.340841805988679, 6.740570710506908, 8.823617894625366, 12.194526020685148, 18.06697710827241, 27.30945443318643], [0.357457634073854, 0.6556487576187894, 0.9253953072072821, 1.1890002122241459, 1.4627554881287206, 1.7593362463239552, 2.0900083182193856, 2.4666653727207892, 2.903847102223588, 3.421077723952938, 4.046149957682172, 4.820512023724713, 5.809092567313668, 7.119776279069851, 8.945022435171106, 11.654537854596414, 15.97559482789839, 22.95835287109394, 30.705436257711355], [0.6012353952311867, 0.9808973344212415, 1.2930878403157218, 1.6037312843548415, 1.938051798135357, 2.3069633205642956, 2.719860142435241, 3.189533805139796, 3.7338436623721054, 4.377377898027468, 5.154936551540501, 6.1181642006895505, 7.347840809459031, 8.978047139132673, 11.246794963292693, 14.599894518642458, 19.811546319027308, 27.189459104613825, 31.856591150431434], [0.8874673968725844, 1.2757423004956023, 1.63318672807726, 2.017740689621008, 2.427855471688538, 2.8716756190689576, 3.365979841885714, 3.9291858046005004, 4.582587744294847, 5.355175837653363, 6.288631674632635, 7.444967910220876, 8.921146136545428, 10.877869841796867, 13.597933765181864, 17.58696089114304, 23.51067995495982, 30.167007768374994, 31.997206004754553], [1.1188923229778278, 1.5423403193077867, 1.9990602229088066, 2.451385156992682, 2.921839857157497, 3.439605310520626, 4.018877246147075, 4.677308590218266, 5.440930349663742, 6.343990319872229, 7.435090224938245, 8.786705267036007, 10.51213149694058, 12.798670994995652, 15.97078628606694, 20.55877218239938, 26.83935402278406, 31.616144380615932, 31.999998193898893], [1.289449239452435, 1.858090371317713, 2.371094481977388, 2.872608856400802, 3.419301235772155, 4.013090872299955, 4.675117157470178, 5.429547001579636, 6.304117371764362, 7.3383760539724365, 8.588006372365996, 10.135996000498631, 12.112017149550038, 14.72947157297657, 18.347474015717555, 23.451461516362283, 29.4938959170579, 31.97391627316921, 31.999999999998657], [1.5063062504841374, 2.177759693598651, 2.7204534857085942, 3.307346311647459, 3.917686615222735, 4.586595194251593, 5.333790973426824, 6.183821851970284, 7.169738674992567, 8.335563484370708, 9.744170158351777, 11.489080145578013, 13.716287611426596, 16.664068867212478, 20.711861433716276, 26.16949478711395, 31.178060451141057, 31.999801306288216, 31.999999999999986], [1.7877700016284033, 2.4506232337692406, 3.0962314783384315, 3.7346897852890892, 4.417164794889404, 5.16162808076439, 5.993090271790841, 6.9392096665169, 8.036577487749835, 9.334155797219028, 10.901961945149434, 12.844055191756928, 15.322573373171457, 18.59810616589354, 23.04200296523629, 28.56019106915315, 31.868888163589663, 31.999999980493957, 31.999999999999986], [2.0498126856597203, 2.7496558622504246, 3.461703175706861, 4.164872052724567, 4.916643037030477, 5.737279377342842, 6.652644996971606, 7.695207448237648, 8.904021418961035, 10.333451524377397, 12.060567665421019, 14.199954110228253, 16.92950104569677, 20.52694777623487, 25.30041702669018, 30.409143249570114, 31.99473298070736, 32.0, 31.999999999999986], [2.2333245303334204, 3.078882807862448, 3.8157250231625013, 4.598411685518677, 5.416630689781794, 6.312070763358907, 7.31293206295597, 8.45143446308306, 9.771764631361728, 11.333099124125944, 13.219578219672066, 15.556269492588834, 18.5360156930344, 22.443416595547802, 27.419904833814446, 31.52173461763725, 31.99998610646656, 32.0, 31.999999999999986], [2.4273098571189893, 3.364168124240194, 4.195449802535298, 5.023747987529886, 5.916381827456377, 6.888630180214186, 7.973011538680309, 9.207715976080364, 10.63965727628524, 12.33292254511194, 14.378786616727009, 16.91270155702841, 20.140856744830952, 24.334385884901828, 29.286413349403315, 31.935382688666568, 31.999999999850914, 32.0, 31.999999999999986]];
  const prob_dec = [[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], [0.9025, 0.81, 0.7224999999999999, 0.6400000000000001, 0.5625, 0.48999999999999994, 0.42250000000000004, 0.36, 0.30250000000000005, 0.25, 0.20249999999999996, 0.16000000000000003, 0.12249999999999998, 0.09000000000000002, 0.0625, 0.03999999999999998, 0.022500000000000006, 0.009999999999999995, 0.0025000000000000044], [0.9900374375390624, 0.9605960100000001, 0.9129921937890626, 0.8493465600000003, 0.7724761962890625, 0.6857496099999998, 0.5929096250390624, 0.49787136, 0.40450395003906264, 0.31640625, 0.23668833128906247, 0.16777216, 0.11122641878906245, 0.06765201000000004, 0.0366363525390625, 0.016796159999999984, 0.005929962539062502, 0.0013032099999999989, 9.036878906250033e-05], [0.9990004373906417, 0.9920279440699441, 0.973316793729638, 0.9377636128923159, 0.8816264350298333, 0.8033461600955809, 0.704286365475572, 0.5891241008203073, 0.4656217526275575, 0.34360891580581665, 0.23322002813860482, 0.14273434994667497, 0.07664797201295727, 0.03471546257339889, 0.01247883380245085, 0.0032163149989349873, 0.000491556156639796, 2.909071040502414e-05, 1.712242448075139e-07], [0.9999000046873625, 0.9984011994401824, 0.9919306821489504, 0.9747049181218859, 0.9392980958938163, 0.8779832774762397, 0.785119198012139, 0.6603837903587233, 0.5117436099379112, 0.3560741304517928, 0.21535308754295868, 0.10851808410760551, 0.04301978326824327, 0.012362409125215284, 0.002273889383407967, 0.00021794232571150878, 7.426009297133897e-06, 3.82749659620575e-08, 1.9645744801607117e-12], [0.9999900000484364, 0.9996800495950412, 0.9975728580151781, 0.9898106282471153, 0.9692184356283225, 0.9250988967914954, 0.8449203477209792, 0.7193773278812381, 0.5510079377007696, 0.3620552892563166, 0.19157986817237108, 0.07499055253703457, 0.019320376235181298, 0.002771897314680955, 0.00017188361205231186, 3.0369174235274227e-06, 7.075501073634908e-09, 3.9125902320861526e-13, 2.2127601617218643e-21], [0.9999990000004888, 0.9999360020159597, 0.9992712615070529, 0.9959122466246896, 0.9844945589235832, 0.9543994214590585, 0.8889117939808944, 0.7689861335405376, 0.5864547467150791, 0.3649865242439075, 0.16587147370786245, 0.04698690159335716, 0.006614256252484605, 0.0003319314954942692, 3.568804673000933e-06, 3.549631279491067e-09, 6.927293963647933e-14, 8.490126976231882e-22, 1.197005651110712e-37], [0.9999999000000006, 0.9999872000812837, 0.9997813237263042, 0.9983629309759001, 0.9922177016874548, 0.9723916130799655, 0.9209212010168063, 0.810675695915375, 0.6192831019737897, 0.36643771592203755, 0.14033773387668633, 0.026402675132206965, 0.0016062156864887075, 1.668800177912824e-05, 1.0849514608715946e-08, 8.247161706662705e-14, 3.2654579043383333e-22, 6.763903760978058e-37, 2.3920336828590893e-67], [0.9999999900000014, 0.9999974400032705, 0.9999343921438792, 0.9993448538631703, 0.9961013397836809, 0.9833435672259209, 0.9439760331404331, 0.8454999585967968, 0.6499696989161974, 0.36715975489153607, 0.11618009117003028, 0.01308437286869258, 0.0002509893811128812, 2.503611364514657e-07, 1.8712544540762926e-12, 3.819560646025089e-21, 4.2726310423825134e-36, 2.5869953361223644e-63, 8.599315745679746e-122], [0.9999999990000303, 0.9999994880001456, 0.9999803171933209, 0.9997378902896864, 0.9980487773894428, 0.9899728156390364, 0.9604482299095564, 0.8743842774314049, 0.6787060645489055, 0.36751989125453444, 0.09410030174411863, 0.005594587270064571, 2.2190208089771118e-05, 6.93349901595476e-10, 4.407665990511204e-18, 8.97942820569536e-33, 2.6050881154479527e-59, 1.0645915533551997e-109, 5.879555627528288e-222], [0.9999999999001349, 0.9999998976000288, 0.999994095117398, 0.9998951478920881, 0.9990239137167762, 0.9939716086573427, 0.9721473274879182, 0.8981844666953158, 0.7055780964764727, 0.36769973941127077, 0.0744942803954426, 0.002008169321236563, 9.380259388670011e-07, 1.807137528373072e-13, 1.6734052711692776e-26, 3.05851438705004e-51, 3.1497082521542855e-98, 2.1210222986905454e-191, 0.0], [0.999999999990421, 0.9999999795200313, 0.9999982285315324, 0.9999580578393448, 0.9995118378817168, 0.9963785993718465, 0.9804208478814848, 0.9176849422697053, 0.7306398361863763, 0.3677896085775189, 0.05754972480765902, 0.0005851780155201035, 1.5222694625872885e-08, 1.7248793110301221e-18, 4.1517257480965484e-39, 1.3054262602723752e-80, 1.3013351780862635e-163, 0.0, 0.0], [0.9999999999999989, 0.9999999959040569, 0.999999468559057, 0.9999832229250637, 0.9997558891676285, 0.997825584559181, 0.9862540399195812, 0.9335879984685753, 0.7539424244445759, 0.3678345294443425, 0.04329875699495249, 0.00013291260394968917, 7.126631669856064e-11, 1.6075287885970581e-25, 5.496980421012695e-58, 2.2584523132927735e-127, 1.1551311712784704e-273, 0.0, 0.0]];
-        
+
  async function do_randao_extend_0() {

    const xVals = rs;
    const yVals = expected;

    const dashPattern = [[0], [13, 8], [12, 8], [11, 8], [10, 8], [9, 8], [8, 8], [7, 8], [6, 8], [5, 8], [3, 8], [2, 8], [1, 8]];
-    
+
    new roughViz.Line({
      element: '#randao_extend_0',
      width: opts.width,
@@ -747,7 +762,7 @@
  do_randao_extend_0().then(makeLink('randao_extend_0'));

  const dashPattern = [[13, 8], [12, 8], [11, 8], [10, 8], [9, 8], [8, 8], [7, 8], [6, 8], [5, 8], [3, 8], [2, 8], [1, 8]];
- 
+
  async function do_randao_extend_1() {

    const xVals = rs;
@@ -882,20 +897,6 @@
 <script>
  async function do_randao_proposals() {

-    const fac = [];
-    fac[0] = 1;
-    for (var i = 1; i <= 32; i++) {
-      fac[i] = i * fac[i - 1];
-    }
-
-    function choose(n, k) {
-      return fac[n] / fac[k] / fac[n-k];
-    }
-
-    function prob(n, k, p) {
-      return Math.pow(p, k) * Math.pow((1 - p), (n - k)) * choose(n, k);
-    }
-
    const xInterval = 0.05;
    const xVals = [], exp = [], exp_1 = [], exp_n = [], per_n = [];
    const exp_n_old = [];
@@ -932,7 +933,7 @@
        diff = Math.abs(exp_n[idx] - exp_n_old[idx]);
        exp_n_old[idx] = exp_n[idx];
      } while (diff > 0.001);
-      
+
      // Percentage difference
      per_n[idx] = 100 * (exp_n[idx] / exp[idx] - 1);

@@ -1029,6 +1030,62 @@
  do_randao_proposals().then(makeLink('randao_proposals')).then(makeLink('randao_proposals_percent'));
 </script>

+<!-- Committee Aggregators - - - - - - - - - - - - - - - - - - - - - -->
+
+<div class="svg" id="committee_aggregators"></div>
+<script>
+  async function do_committee_aggregators() {
+
+    xData = [];
+    yData = [];
+
+    nMembers = 256;
+    target = 16;
+    p = 1.0 / Math.floor(nMembers / target);
+    for (var i = 0; i <=32; i++) {
+      xData.push(i);
+      yData.push(prob(nMembers, i, p));
+    }
+
+    new roughViz.Bar({
+      element: '#committee_aggregators',
+      width: opts.width,
+      height: opts.height,
+      font: opts.font,
+
+      data: {
+        labels: xData,
+        values: yData
+      },
+      xLabel: "Number of aggregators selected from a 256 member committee",
+      yLabel: "Probability",
+      xLabelDelta: 0,
+      yLabelDelta: -10,
+
+      roughness: opts.roughness,
+      bowing: opts.bowing,
+      simplification: opts.simplification,
+
+      color: 'white',
+      fillStyle: 'solid',
+      strokeWidth: opts.strokeWidth,
+      padding: 0.01,
+
+      axisStrokeWidth: opts.axisStrokeWidth,
+      axisRoughness: opts.axisRoughness,
+      axisFontSize: opts.axisFontSize,
+      labelFontSize: opts.labelFontSize,
+
+      margin: {top: 30, right: 20, bottom: 90, left: 100},
+
+      legend: opts.legend,
+      interactive: opts.interactive,
+    });
+
+  }
+  do_committee_aggregators().then(makeLink('committee_aggregators'));
+</script>
+
 </div>
 </body>
 </html>
--- a/src/constants.json
+++ b/src/constants.json
@@ -91,5 +91,11 @@
  "DOMAIN_DEPOSIT": "DomainType(0x03000000)",
  "DOMAIN_VOLUNTARY_EXIT": "DomainType(0x04000000)",
  "DOMAIN_SELECTION_PROOF": "DomainType(0x05000000)",
-  "DOMAIN_AGGREGATE_AND_PROOF": "DomainType(0x06000000)"
+  "DOMAIN_AGGREGATE_AND_PROOF": "DomainType(0x06000000)",
+  "TARGET_AGGREGATORS_PER_COMMITTEE": "16",
+  "RANDOM_SUBNETS_PER_VALIDATOR": "1",
+  "EPOCHS_PER_RANDOM_SUBNET_SUBSCRIPTION": "256",
+  "ATTESTATION_SUBNET_COUNT": "64",
+  "TARGET_AGGREGATORS_PER_SYNC_SUBCOMMITTEE": "16",
+  "SYNC_COMMITTEE_SUBNET_COUNT": "4"
 }
--- a/src/md/images/charts/committee_aggregators.svg
+++ b/src/md/images/charts/committee_aggregators.svg