Abstract
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 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:
- LMD GHOST vote
(beacon_block_root, slot). Note: includes slot in the event (block, slot) voting is adopted.
- FFG vote
(source, target)
- 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).
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
Execution layer
This requires no changes to the Execution Layer.
Consensus layer
- Set
index field from AttestationData to a fixed value of zero
- Move committee indexing data to the outer
Attestation container with committee_bits
- Increase the capacity of
aggregation_bits to all committees in a slot
The full specification of the proposed change can be found in /specs/electra/beacon-chain.md.
Rationale
Deprecation strategy
The index field in AttestationData can be deprecated by:
- Removing the field
- Preserving the field and setting it to zero
- Changing the field type to Optional (from EIP-7495 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.
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.
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 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.
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 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)
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
Copyright and related rights waived via CC0.
