---
eip: 8334
title: Bundled Attestation Propagation
description: A system for broadcasting attestations in bundles using gossipsub partial messages
author: Sukun Tarachandani (@sukunrt), Raul Kripalani (@raulk)
discussions-to: https://ethereum-magicians.org/t/eip-8334-bundled-attestation-propagation/29008
status: Draft
type: Standards Track
category: Networking
created: 2026-07-06
---

## 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](https://ethresear.ch/t/unblocking-faster-finality-with-decoupled-consensus/24527).

## 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](https://www.rfc-editor.org/rfc/rfc2119) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174).

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

| Name | Value | Description |
|------|-------|-------------|
| `MAX_ATTESTATIONS_PER_BUNDLE` | 50 | Maximum number of attestations in a single `AttestationBundle` |

### Containers

`AttestationData`, `CommitteeIndex`, `ValidatorIndex`, `BLSSignature`, and `MAX_VALIDATORS_PER_COMMITTEE` are as defined in the [consensus specifications](https://github.com/ethereum/consensus-specs/blob/5fa6edcca8ab4cf548653e6680b17b9d3e04d225/specs/phase0/beacon-chain.md).

```python
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](./eip-8243.md) 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](./eip-8136.md)), 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](../LICENSE.md).