# Electra EIP-7549 - P2P impact

This is an analysis of the [EIP-7549](https://eips.ethereum.org/EIPS/eip-7549) impacts on the attestation aggregation logic.

<p style="text-align: center;"><a href="https://eth2book.info/capella/part2/building_blocks/committees/#the-number-of-committees">From eth2book</a></p>

#### Status quo, the process of aggregation is as follows

> 1. Committee members sign their votes (`Attestations`) and broadcast them to a peer-to-peer subnet that the whole committee is 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, then aggregate all the votes they receive that agree with their own view of the network into a single aggregate vote (aggregate Attestation or 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`)
> 5. Finally, the aggregator broadcasts its aggregated vote and proof to a global channel to be received by the next block proposer.

<p style="text-align: center;"><a href="https://eth2book.info/capella/part2/building_blocks/aggregator/#introduction">From eth2book</a></p>

#### With EIP-7549 the process of aggregation becomes

1. Committee members sign their votes (Attestations) and broadcast them to a peer-to-peer subnet that the whole committee is subscribed to (`beacon_attestation_{subnet_id}` where `subnet_id` is the committee index, eventhough the index in `AttestationData` will always be set to 0)
2. A subset of the committee is selected to be aggregators for that committee
3. 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 Attestation or 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`)
5. The aggregator broadcasts its aggregated vote and proof to a global channel (`beacon_aggregate_and_proof` p2p gossip topic) to be received by the next block proposer.
6. The block proposer, listening to the global channel (`beacon_aggregate_and_proof` p2p gossip topic), performs the last aggregation. It aggregates all the votes that have a similar `AttestationData` received from all the aggregators (described in the previous step) and includes the resulting aggregated attestions in the block. Assuming a perfect aggregation, the proposer ends up with 1 aggregated attestation per slot

The first 4 steps are the same, the committee members perform exactly the same tasks (ignoring the fact that the index in `AttestationData` is set to 0), the difference is in the last aggregation steps 5 and 6 after which the block proposer performs a last global aggregation of all the aggregates it sees in the global `beacon_aggregate_and_proof` topic.

The block proposer runs the following function to construct an on chain aggregate form a list of network aggregates with equal `AttestationData`

def compute_on_chain_aggregate(network_aggregates: List[Attestation]) -> Attestation:
    
    aggregates = sorted(network_aggregates, key=lambda a: get_committee_indices(a.committee_bits)[0])
    
    data = aggregates[0].data
    aggregation_bits = [a.aggregation_bits[0] for a in aggregates]
    signature = bls.Aggregate([a.signature for a in aggregates])
    
    committee_indices = [get_committee_indices(a.committee_bits)[0] for a in aggregates]
    committee_flags = [(index in committee_indices) for index in range(0, MAX_COMMITTEES_PER_SLOT)]        
    committee_bits = Bitvector[MAX_COMMITTEES_PER_SLOT](committee_flags)

    return Attestation(aggregation_bits=aggregation_bits,
                       data=data,
                       committee_bits=committee_bits,
                       signature=signature)

<p style="text-align: center;"><a href="https://hackmd.io/@n0ble/eip7549_onchain_aggregates#Block-proposal">From @n0ble note</a></p>

#### Other considerations
Considering the proposer will now have less aggregated attestaion to include in the block, the `MAX_ATTESTATIONS` parameter should be adjusted respectively to avoid increase of the block size. [EIP-7549 updates it from 128 to 8](https://github.com/ethereum/consensus-specs/pull/3559/files#diff-6f5c13bea9ec2901b5e4bfed43c58ba4170fdd94e887a0baf814a208c045706dR37).

The block will now contain 8 slots worth of attestations(`8 = 1 aggregated attestation per slot * 8`) instead of only 2 slots worth of attestations (`128 = 64 (aggregated attestations per slot) * 2`)

<p style="text-align: center;"><a href="https://hackmd.io/@n0ble/eip7549_onchain_aggregates#Block-proposal">From @n0ble note</a></p>