Skip to content

Update EIP-7549: Fix typos 7549 #9785

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
SamWilsn merged 1 commit into from
May 27, 2025
Merged

Update EIP-7549: Fix typos 7549 #9785

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 10 additions & 10 deletions EIPS/eip-7549.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,21 +12,21 @@ created: 2023-11-01

## Abstract

Move the committee `index` field outside of the signed Attestation message to allow aggregation of equal consensus votes.
Move the committee's `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 the most impact.
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 will likely have the most impact.

On a beacon chain network with at least 262144 active indices, 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).
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).

On-chain attestations can now be packed more space-efficiently into beacon blocks. This proposal allows to include up to 8 slots worth of votes into a block, compared to 2 today. In order words, a chain with only 1/8 online proposers can still potentially include all votes on-chain.
On-chain attestations can now be packed more space-efficiently into beacon blocks. This proposal allows for up to 8 slots worth of votes in a block, compared to 2 today. In other words, a chain with only 1/8 online proposers can still potentially include all votes on-chain.

## Specification

Expand Down Expand Up @@ -61,32 +61,32 @@ 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.
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.
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` compared to the `Bitvector` type. Beacon chain state transition ensures correctness of the `committee_bits` when the effective number of committees in a slot is less than its max value.

## 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.
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

### First block after the fork

Because the on-chain `Attestation` container changes, attestations from the prior fork can't be included in post-electra blocks. Therefore the first block after the fork may have zero attestations. LMD votes can still be applied to fork-choice via `on_attestation` handler, so there will be only a 1/32 loss of FFG votes. Attesters assigned to the last slot of the fork will incur one epoch worth of offline penalties. One possible mitigation is to change the Electra block body type to allow including attestations from both forks. However, the mitigation increases complexity for little gain so this proposal chooses to not address the issue.
Because the on-chain `Attestation` container changes, attestations from the prior fork can't be included in post-Electra blocks. Therefore, the first block after the fork may have zero attestations. LMD votes can still be applied to fork-choice via `on_attestation` handler, so there will be only a 1/32 loss of FFG votes. Attesters assigned to the last slot of the fork will incur one epoch worth of offline penalties. One possible mitigation is to change the Electra block body type to allow including attestations from both forks. However, the mitigation increases complexity for little gain, so this proposal chooses not to address the issue.

### Mutation over gossip

Moving the `index` field outside of the signed 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:

> - [REJECT] The attester is a member of the committee -- i.e. `attestation.attester_index` in `get_beacon_committee(state, attestation.data.slot, index)`
> - [REJECT] The attester is a member of the committee -- i.e., `attestation.attester_index` in `get_beacon_committee(state, attestation.data.slot, index)`

If an attacker mutates the `index` field, the above rule verification will fail and the message will be dropped. If implementations runs the above check before registering the attestation in a 'first-seen' cache, there's no risk of cache pollution.
If an attacker mutates the `index` field, the above rule verification will fail, and the message will be dropped. If implementations run the above check before registering the attestation in a 'first-seen' cache, there's no risk of cache pollution.

## Copyright

Expand Down
Loading