# eth2 phase 0 networking requirements ## Attestation ### Message size ~368 bytes (@300k validators) _[This does not scale much larger or smaller as v-set grows]_ _Breakdown:_ * `Crosslink`: 88 bytes * `AttestationData`: 200 bytes (`112 + size(Crosslink)`) * `Attestation`: 368 bytes (`168 + size(AttestationData)`) ### Description of propagation In the normal case, there are `SHARD_COUNT` (1024) committees per epoch divided across `SLOTS_PER_EPOCH` (64) slots. In this case, the number of validators per committee is `num_validators / SHARD_COUNT` (expected between 128-300). At each slot, `SHARD_COUNT / SLOTS_PER_EPOCH` committees are expected to create and broadcast an attestation to the associated shard pub-sub channel. For example, assume a committee of 290 validators is assigned to shard 10 at the 3rd slot in an epoch. Halfway through the assigned slot (3), each of the validators from the committee creates an `Attestation` and broadcasts it to pub-sub channel `shard-10`. The expectation is that most of these attestations can propogate on this sub-topic on the order of ~1 slot (6 seconds). An aggregate (of same byte-size) is then created by a subset of the committee and broadcast to the `beacon` pub-sub channel. This, too is expected to propogate in ~1 slot. The earliest the attestation can be included on the beacon chain is `MIN_ATTESTATION_INCLUSION_DELAY` slots (currently defined as 4) so the initial propagation, aggregation, and re-propagation of the aggregate should happen in roughly `MIN_ATTESTATION_INCLUSION_DELAY - 1` slots or less in the normal case so that it can be included in the earliest possible block. Attestations are allowed up to an epoch worth of slots to be included on chain, but we want normal behavior to have them included at the earliest possible slot. _Note_: It is important to note when assessing bandwidth here that we expect somewhere on the order of at least 10 validators to be able to run on a single node. Frequently they will be assigned to shards at different slots in the epoch so the burst of bandwidth consumed by the quick flood of attestations will be generally distributed, but will certainly have some overlap at times. ## BeaconBlock ### Message size * Normal message size ~23948 bytes (23KB) (@300k validators) * Max message size ~78668 bytes (78KB) (@300k validators) _Breakdown:_ * `BeaconBlockHeader`: 200 bytes * `ProposerSlashing`: 408 bytes (`8 + 2 * size(BeaconBlockHeader)`) * `AttesterSlashing`: 1200 bytes (`~1000 + size(AttestationData)`) * `Attestation`: 368 bytes * `DepositData`: 184 bytes * `Deposit`: 1172 bytes (`1088 + size(DepositData)`) * `VoluntaryExit`: 112 bytes * `Transfer`: 184 bytes * `Eth1Data`: 128 bytes * `BeaconBlockBody`: 23780 bytes [normal case](`128 + size(Eth1Data) + 0 * size(ProposerSlashing) + 0 * size(AttesterSlashing) + (MAX_ATTESTATIONS / 4) * size(Attestation) + (MAX_DEPOSITS / 2) * size(Deposit) + (MAX_VOLUNTARY_EXIT / 2) * size(VoluntaryExit) (MAX_TRANSFERS / 2) * size(Transfer)`) * `BeaconBlock`: 23948 bytes (`168 + size(BeaconBlockBody)`) ### Description of propagation One proposer is assigned to each slot. The single proposer is expected to create a `BeaconBlock` and broadcast it on the `beacon` pub-sub channel at the start of the slot (almost every node in the network will be on this channel). The expecation is that this block is near completely propagated at or before the halfway point in the slot so that it can be processed and attested to.