EIP-8334: Bundled Attestation Propagation

Abstract

This proposal redesigns attestation propagation within a subnet. Instead of sending each attestation as an individual message, nodes use the gossipsub partial-messages extension to transmit attestations in bundles that deduplicate the shared attestation data, and they reconcile which attestations each peer holds using sets of validator indices rather than gossipsub's per-message hashes. In simulations, this results in up to 30% lower latency and around 50% bandwidth savings.

Motivation

Attestation and aggregate propagation are the major factors that impact the time to finality. Reducing the bandwidth required for attestation propagation enables aggregating more attestations in a committee, thus reducing the time to finality. This proposal itself does not make any recommendations to reduce the epoch length, but the expectation is that this system will reduce time to finality in decoupled consensus.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

This EIP replaces the propagation mechanism on the beacon_attestation_{subnet_id} gossipsub topics. Currently, unaggregated attestations are gossiped as individual SingleAttestation messages. Every message duplicates the shared AttestationData, and gossipsub advertises each message by hash in IHAVE/IWANT control messages. This EIP transmits attestations in bundles over the gossipsub partial-messages extension, specified in libp2p/specs at pubsub/gossipsub/partial-messages.md (commit 6b6203ee6f62938ce67efdb33498173f475851c0), and reconciles attestation sets between peers with per-committee lists of validator indices. This is not signature aggregation. Signatures remain separate and bandwidth is saved by deduplicating attestation data.

Constants

Containers

AttestationData, CommitteeIndex, ValidatorIndex, BLSSignature, and MAX_VALIDATORS_PER_COMMITTEE are as defined in the consensus specifications.

class AttestationBundle(Container):
    committee_index: CommitteeIndex
    attestation_data: AttestationData
    attester_indices: List[ValidatorIndex, MAX_VALIDATORS_PER_COMMITTEE]
    signatures: List[BLSSignature, MAX_VALIDATORS_PER_COMMITTEE]

class CommitteeAttestationPartsMetadata(Container):
    committee_index: CommitteeIndex
    available: List[ValidatorIndex, MAX_VALIDATORS_PER_COMMITTEE]
    requests: List[ValidatorIndex, MAX_VALIDATORS_PER_COMMITTEE]

An AttestationBundle contains attestations from one committee sharing the same attestation_data. attester_indices lists the global validator indices of the included attestations; signatures[i] is the signature of validator attester_indices[i]. A bundle MUST NOT list the same validator twice.

CommitteeAttestationPartsMetadata carries no attestation data: the slot is the group identifier and a validator attests at most once per slot, so (slot, validator_index) fully identifies an attestation. available is the set of validators whose attestations for the slot the sender holds and requests the validators whose attestations it wants from the peer.

Validator indices are the same identifier SingleAttestation carries, so bridging between the two propagation paths is field copying, and no committee shuffle is needed to identify an attestation — the shuffle is needed only where it always was, in signature validation.

Protocol

The partial-messages group identifier on beacon_attestation_{subnet_id} is the slot number, encoded as a little-endian uint64. All AttestationBundle and CommitteeAttestationPartsMetadata entries exchanged within a group MUST be for attestations of that slot. Nodes SHOULD ignore groups whose slot is outside the attestation propagation window.

Attestations are small, so a node always eagerly pushes all attestations it has to its mesh peers. An ATTESTATION_BUNDLE_TICK_DURATION of 20 ms is RECOMMENDED.

1. Every ATTESTATION_BUNDLE_TICK_DURATION, the node selects the attestations to send to each peer. It SHOULD bundle attestations sharing the same (committee_index, attestation_data) into a single AttestationBundle and SHOULD NOT send the same attestation to a peer twice. An AttestationBundle MUST NOT carry more than MAX_ATTESTATIONS_PER_BUNDLE attestations; larger sets are split across multiple bundles. As attestations are eagerly forwarded in the mesh, the node SHOULD NOT send CommitteeAttestationPartsMetadata to mesh peers.
2. When gossipsub emits gossip for a group, the node advertises its available attestations to the gossip peers, one CommitteeAttestationPartsMetadata per committee, listing the validators in available.
3. On receiving CommitteeAttestationPartsMetadata, the node requests the attestations it lacks via the requests field (empty means nothing requested). A request needs no available list of the requester's own: attestations the requester already holds are deduplicated on receipt.

Nodes MUST NOT deduplicate unvalidated attestations by (slot, validator_index) alone — an invalid signature would suppress a later valid one. Before validation, the deduplication identity MUST include the attestation data and signature. Once a validator's attestation for a slot has passed validation, any further attestation from that validator in the same slot is a replay or a slashable equivocation and MAY be dropped.

Requests via CommitteeAttestationPartsMetadata are not persistent. A node that cannot satisfy a request on reception SHOULD discard it.

Validation

Each attestation in an AttestationBundle is validated individually under the existing beacon_attestation_{subnet_id} gossip conditions. A node forwards only attestations that pass validation.

A node SHOULD reject an AttestationBundle carrying more than MAX_ATTESTATIONS_PER_BUNDLE attestations. This bounds per-message work.

Rationale

This system deduplicates as much data as possible between peers in a subnet. As most attesters vote for the same block, deduplicating AttestationData reduces message size by around 50%.

Attestations are identified by global validator index rather than committee position. A committee position is only meaningful relative to a shuffle, which depends on the beacon state and may differ across forks, while a validator index is unambiguous and matches SingleAttestation. It also lets metadata omit the attestation data entirely: a validator attests at most once per slot, so (slot, validator_index) is a complete identifier, and one advertisement covers the slot regardless of how many distinct attestation datas the committee split over. This method also maps well to current gossipsub implementation leading to much lower implementation complexity.

The goal for this system is to disseminate attestations in a subnet efficiently. This system can then be used, with some modifications, with other orthogonal attestation improvements like EIP-8243 to further reduce attestation propagation latency.

Using the partial-messages extension allows rolling this out between forks in a backwards compatible way while keeping the scoring mechanism of gossipsub as it is today. Moreover, the extension will be used for cell-level deltas (EIP-8136), providing valuable production usage data. The extension was designed for cell-level deltas to improve data column dissemination, hence the name. However, the mechanism is a more general set reconciliation mechanism and is not limited to reconstructing a single full message.

Alternative Designs

Using a custom protocol for attestations can reduce the tail latency further by 10-20%. The benefits mostly come from a custom algorithm having complete control over the scheduling of outbound messages, which allows better prioritization and cancellation of messages. The proposed change in contrast is much smaller, reuses most of the available machinery and can be rolled out in a backwards compatible way while providing most of the latency improvements.

Using bitmaps for exchanging the set of available attestations is more efficient than exchanging validator indices. However, this comes with its own set of challenges. Late attestations, and validators attesting to different blocks can lead to greater bandwidth requirement than message hashes. The present change maps exactly to the current system leading to much lower implementation complexity. This is desirable as these objects will probably change with Decoupled Consensus and we can take up the attestation bitmap with that change.

Backwards Compatibility

Support is negotiated via the gossipsub partial-messages extension. Nodes that do not support it continue exchanging SingleAttestation messages on beacon_attestation_{subnet_id} unchanged. Upgraded nodes participate in both mechanisms during the transition.

Security Considerations

Peer scoring for gossipsub should be done in such a way that partial-message peers are not favored over non-partial-message peers. Signatures in a bundle are unaggregated and individually attributable to the sending peer. Peers sending bundles with invalid attestations should be downscored.

Attestations can be revealed long after their slot is complete. Retention and expiry of received attestations are left to the consensus specifications.

Copyright

Copyright and related rights waived via CC0.