Add EIP: Move committee index outside Attestation

Merged by EIP-Bot.

EIPS/eip-7549.md

@@ -0,0 +1,71 @@
+---
+eip: 7549
+title: Move committee index outside Attestation
+description: Move committee index outside of the signed Attestation message
+author: dapplion (@dapplion)
+discussions-to: https://ethereum-magicians.org/t/eip-7549-move-committee-index-outside-attestation/16390
+status: Review
+type: Standards Track
+category: Core
+created: 2023-11-01
+---
+
+## Abstract
+
+Move the committee `index` field outside of the signed Attestation message to allow aggregation of equal consensus votes.
+
+## Motivation
+
+This proposal aims to make Casper FFG clients more efficient by reducing the average number of pairings needed to verify consensus rules. While all types of clients can benefit from this EIP, ZK circuits proving Casper FFG consensus are likely to have to most impact.
+
+On a beacon chain network with at least 262144 active indexes it's necessary to verify a minimum of `ceil(32*64 * 2/3) = 1366` attestations to reach a 2/3 threshold. Participants cast two votes at once: LMD GHOST vote and Casper-FFG vote. However, the Attestation message contains three elements:
+
+1. LMD GHOST vote `(beacon_block_root, slot)`. Note: includes slot in the event (block, slot) voting is adopted.
+2. FFG vote `(source, target)`
+3. Committee index `(index)`
+
+Signing over the 3rd item causes tuples of equal votes to produce different signing roots. If the committee index is moved outside of the Attestation message the minimum number of attestations to verify to reach a 2/3 threshold is reduced to `ceil(32 * 2/3) = 22` (a factor of 62).
+
+## Specification
+
+### Execution layer
+
+This requires no changes to the Execution Layer.
+
+### Consensus layer
+
+- Move `index` field from `AttestationData` to `Attestation`
+
+The full specification of the proposed change can be found in [`/specs/_features/eip7549/beacon-chain.md`](https://github.com/ethereum/consensus-specs/blob/bcead2ff59048dba859c7eb4b62389f0e9168ef8/specs/_features/eip7549/beacon-chain.md).
+
+## Rationale
+
+### Deprecation strategy
+
+The `index` field in `AttestationData` can be deprecated by:
+
+1. Removing the field 
+2. Preserving the field and setting it to be zero
+3. Changing the field type to Optional (from [EIP-7495](./eip-7495.md) StableContainer)
+
+This EIP chooses the first option for simplicity, but all three accomplish the EIP's goal.
+
+## Backwards Compatibility
+
+This EIP introduces backward incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork.
+
+## Security Considerations
+
+Moving the `index` field outside of the sign message allows malicious mutation only on the p2p gossip topic `beacon_attestation_${subnet_id}`. Everywhere else, the `Attestation` message is wrapped with an outer signature that prevents mutation.
+
+Gossip verification rules for the `beacon_attestation_${subnet_id}` topic include:
+
+> - [IGNORE] There has been no other valid attestation seen on an attestation subnet that has an identical attestation.data.target.epoch and participating validator index.
+> - [REJECT] The signature of attestation is valid.
+
+For an unaggregated attestation, the tupple (slot, index, aggregation_bits) uniquely identify a single public key. Thus there is a single correct value for the field `index`. If an attacker mutates the `index` field the signature will fail to verify and the message will be dropped. This is the same outcome of mutating the aggregation bits, which is possible today. If implementations verify the attestation signature before registering it in a 'first-seen' cache, there's no risk of cache pollution.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).
+