Update EIP-7549: Move to Last Call

EIPS/eip-7549.md

@@ -2,9 +2,10 @@
 eip: 7549
 title: Move committee index outside Attestation
 description: Move committee index outside of the signed Attestation message
-author: dapplion (@dapplion)
+author: dapplion (@dapplion), Mikhail Kalinin (@mkalinin)
 discussions-to: https://ethereum-magicians.org/t/eip-7549-move-committee-index-outside-attestation/16390
-status: Review
+status: Last Call
+last-call-deadline: 2025-02-21
 type: Standards Track
 category: Core
 created: 2023-11-01
@@ -50,17 +51,23 @@
 
 1. Removing the field 
 2. Preserving the field and setting it to zero
 3. Changing the field type to Optional (from [EIP-7495](./eip-7495.md) StableContainer)
 
 This EIP chooses the second option to not complicate the inclusion of `AttesterSlashing` objects. While the `Attestation` container changes, `AttesterSlashing` includes indexed attestations without committee data.
 
 ### `MAX_ATTESTATIONS` value
 
 The maximum size of an attestation increases, with a bitfield 64 times larger on networks with maxed committees. `MAX_ATTESTATIONS` value is reduced to limit the beacon block size while still increasing the total capacity of votes. A value of 8 increases the voting capacity by 4 while having the same attestation space size with a network of 1.2M active indices.
+Read the details [here](../assets/eip-7549/complexity_analysis.md).
 
 ### `MAX_ATTESTER_SLASHINGS` value
 
 On-chain `AttesterSlashing` includes a list of participants' indices. With this EIP the worst-case size increases by 64 times, resulting in an uncompressed size of 488 KB per `AttesterSlashing` in a network of 1M validators. Snappy compression reduces it to 320 KB, which is still significant. To bound the maximum size of the block this proposal reduces `MAX_ATTESTER_SLASHINGS` from 2 to 1, the minimum value.
+Read the details [here](../assets/eip-7549/complexity_analysis.md).
+
+### Using `Bitvector` for `committee_bits`
+
+The `committee_bits` sequence has a variable length with the max size `MAX_COMMITTEES_PER_SLOT = 64`. Encoding of the `Bitlist` includes its actual length which doubles the size of the `committee_bits` comparing to the `Bitvector` type. Beacon chain state transition ensures correctness of the `committee_bits` when effective number of committees in a slot is less than its max value.
 
 ## Backwards Compatibility
 

assets/eip-7549/complexity_analysis.md

@@ -0,0 +1,37 @@
+# Complexity analysis
+
+## Network aggregates
+
+Data complexity of the network aggregtes does not increase as the new validity condition for the `beacon_aggregate_and_proof` gossipsub topic ensures that every network aggregate comprises a single committee.
+
+## On chain aggregates
+
+![image](./on_chain_aggregates.png)
+
+The above plot shows potential optimisation effect of the proposed change. Namely, it is roughly 18KB to 4KB reduction in the size of a 64-committee aggregate for a 1 million validator set. Note that these numbers assumes perfect aggregation.
+
+### `MAX_ATTESTATIONS`
+
+`MAX_ATTESTATIONS` parameter should be adjusted respectively to avoid increase of the block size.
+
+![image](./max_attestations.png)
+
+The above plot suggests `MAX_ATTESTATIONS = 8` as a reasonable limitation. Which means that assuming perfect aggregation the attestation capacity of the block increases from `128` committees to `8*64 = 512` committees, i.e. from `2` slots worth of attestations to `8`.
+
+## Attester slashing
+
+The plot below shows different variations of attester slashing data complexity. Numbers e.g. 64 vs 64 mean a number of committees which validator indices are respresented by the corresponding `IndexedAttestation` structure. For instance, today every on chain aggregate comprises a single committee thus the worst case attester slashing produced from on chain aggregates will have two indexed attestations with `1_000_000 / 32 / 64 = 488` validator indices each, which is roughly `8 KB` of uncompressed data. With the proposed change an attester slashing obtained in the same way could require `488 KB` of uncompressed data because it could contain indices from up to 64 committees instead of just 1.
+
+![image](./attester_slashing.png)
+
+Note that in the case of attack entailing mass slashing the overall complexity of attester slashing data with the proposed change remains the same as it is with the status quo. However, the proposed changed increases the size of the beacon block as each slashing will contain up to 64 times more indices than with the status quo. The positive outcome here is that all slashable attestations can be processed during roughly one epoch (EIP-7549 makes this already possible).
+
+The red line on the plot represents the case when one of the indexed attestations is obtained from an on chain aggregate and the other one from a network aggregate. Moreover, with the proposed change it is still possible to create a slashing from two network aggregates. Therefore, complexity of attester slashing data in case of a single slashing event depends on the _slasher database schema, i.e. whether or not a slasher has access to network aggregates_.
+
+`MAX_ATTESTER_SLASHINGS = 1` is suggested to alleviate the increase of the attester slashing complexity.
+
+### Compressed validator indices
+
+Intuitively validator indices should compress well as there is just `20` bits of useful information per each validator index in the case of `1_000_000` validator set size. So `488 KB` of attester slashing data (the worst case) can be reduced to `153 KB` by employing a trivial compression algorithm.
+
+_AttesterSlashing with 64x64 committees (1_000_000 validators) takes 320KB if compressed by Snappy (checked with PySpec SSZ test suite)._