EIP-8243 Source-stage attestation batching (Batching Attestations at Source)
Hegota Declined for Inclusion · Consensus & staking · EIP status Draft · created 2026-05-01
Lets an operator running multiple validators assigned to the same committee gossip one pre-aggregated batch attestation instead of N individual attestations. The on-chain format does not change.
Why it is needed
Ethereum currently has about 1 million active validators. If all of them participate, about 31,000 attestations (validator votes) per slot spread across 64 subnets. Large operators run many validators, and these usually see the same chain state and vote identically. Yet the protocol today allows only one individual message per validator. This is because relaxing the duplicate aggregation rule would let an attacker collect other validators' attestations and form exponentially many subset combinations, flooding the network with spam. Making slots shorter and finality faster requires a large reduction in attestation volume. EIP-7251 reduces the validator count through balance consolidation, but it is optional, so adoption is slow. This proposal gets a similar effect at the network level without any action from operators: beacon nodes that manage multiple validator clients combine the votes of validators assigned to the same committee into one message at the source.
What changes
Today
- Each validator sends its own attestation, so with full participation about 31,000 messages propagate per slot
- Validators of the same operator each sign and send the same vote separately
- To prevent duplicate aggregation spam, gossip allows only individual messages
After EIP-8243
- Votes of validators assigned to the same committee can be bundled into one batch and propagated
- Each validator's pre-consent signature (batch_seal) and the batcher's composition signature protect the batch, so spam is bounded at the committee size
- The on-chain attestation format and state transition stay the same, and only the gossip layer changes
- Validators that have not pre-signed a seal automatically fall back to individual attestations as they do today
Who is affected
- Large operators and staking pools: Bundles the votes of many validators in the same committee into one message to reduce bandwidth. The beacon node can handle this transparently without any extra action.
- Solo validators: The existing SingleAttestation path is kept as is, and there is no penalty for not taking part in a batch.
- Client teams: Requires implementing the gossip topic message type change, new signature verification, and a per-vote deduplication cache, and all nodes must upgrade at the same time at the fork boundary.
- Protocol design: More vote information is delivered per byte, which widens the design space for consensus throughput, such as subnet consolidation or a shorter epoch.
In depth
Wire format: the WireAttestation union
The message type of the gossip topic beacon_attestation_{subnet_id} changes from SingleAttestation to the SSZ union WireAttestation. A 1-byte selector is prepended: 0x00 means SingleAttestation and 0x01 means BatchAttestation. Pre-fork nodes expect raw SingleAttestation bytes with no prefix, and post-fork nodes expect the selector prefix, so all nodes must upgrade at the same time at the fork boundary. Validation branches on the selector, and malformed SSZ or an unknown selector is handled as REJECT.
BatchAttestation structure and the three signatures
BatchAttestation contains committee_index, aggregation_bits, data, and three signatures. signature is the standard BLS aggregate signature of the included validators, signed over data under DOMAIN_BEACON_ATTESTER, so it is identical to an existing aggregate signature. batch_seal is the aggregate of signatures from all validators indicated by aggregation_bits over BatchSealPreimage(slot, committee_index, batcher) under the new domain DOMAIN_BATCH_ATTESTER('0x0B000000'). batcher_signature is the batcher's signature over BatcherPreimage(slot, committee_index, aggregation_bits) under DOMAIN_BATCHER('0x0B0000FF'). The last two signatures are gossip-only, are discarded after verification, and are not included on chain.
Why the seal binds only to (slot, committee_index, batcher)
If the seal were also bound to aggregation_bits, the batcher and the members would have to exchange extra signatures synchronously every slot. That creates stateful interaction and eats into the attestation latency budget. Because the binding is looser, a validator can pre-sign the seals for its duty slots at the start of the epoch while the chain is finalized, and it tolerates arbitrary validator client failures. If seals are pre-signed for both a primary batcher and a backup batcher, the backup takes over without extra signing delay when the primary stalls, and the backup batcher only needs to create its own composition signature. If there is no seal for any active batcher, the validator automatically falls back to SingleAttestation with no penalty.
Gossip validation rules
is_valid_batch_attestation first checks that at least 2 bits are set in aggregation_bits (if only 1 is set, SingleAttestation must be used). The batcher must be in the attester set. It then verifies the three signatures. The aggregate attestation signature over data and the aggregate seal over BatchSealPreimage are checked with bls.FastAggregateVerify, and the batcher signature over BatcherPreimage is checked with bls.Verify. If any one fails, the result is REJECT. Other REJECT reasons are including a validator that is not in the committee, a slot outside the allowed window, and receipt on a subnet different from the one for that committee.
Deduplication: accept if there is at least one new vote
Nodes keep seen_attesters and seen_batchers caches per (slot, committee_index, data_root). The principle is a single one: accept only a message that carries at least one vote not seen before. A single attestation already seen, a second batch from the same batcher, and a batch whose members are all already known are silently dropped as IGNORE. As a result, an attacker holding k committee keys can get at most k messages per duty through, and since each message needs a valid attestation, seal, and batcher signature, the bandwidth the attacker consumes is proportional to the attacker's own signing cost. The O(2^k) subset explosion is not propagated. Even if the single attestation of a validator bundled in a batch leaks out first, the batch is not suppressed, thanks to the unseen votes of the remaining members, and no vote is lost regardless of arrival order.
No state transition change and no new slashing
BatchAttestation.signature has the same domain and message as the standard aggregate attestation signature, so the aggregator can feed it directly into compute_on_chain_aggregate. The on-chain Attestation container and process_attestation do not change, so block validity rules and processing of past blocks are unaffected. No new slashing condition is added either. Inclusion without consent and signature theft are structurally impossible because the seal is a signature over a separate domain and a separate message. A batcher reversing its composition is filtered out in gossip by seen_batchers, and duplicates across batchers converge at the aggregation stage. The batcher signature leaves slashable evidence, but introducing actual slashing is left as an open question.
The design space opened by throughput and privacy
Because more attestation information fits in each network byte, if traffic is left unchanged, subnets and committees can be consolidated by the efficiency multiple (for example, from 64 to 16 at 4x efficiency) and the epoch can be shortened by the same ratio (for example, from 32 to 8 slots), so faster L1 finality follows as a side effect, the source explains. How aggressive this can be remains an open question. Also, if a validator picks any committee peer as batcher and routes its vote there, this becomes a k-anonymity-style attester privacy primitive, and if it is left out of the batch, it can fall back to publishing individually. Conversely, batches carry a privacy and efficiency trade-off, since they reveal which validators are under the same operator. The source states that this mechanism is not a substitute for physically shrinking the validator set, such as the 128K cap (strawmap), but makes use of existing slack.
Status: Draft, excluded from Hegotá candidates
This EIP is in Draft status, and the source notes that test cases and a reference implementation do not exist yet, so the specification may change. Because it changes the gossip topic message type, nodes must upgrade at the same time at the fork boundary, so actual adoption depends on whether it is included in a hard fork. According to the call records, at 09.17 ACDC #187 seven EIPs (EIP-8237, 8341, 8367, 8321, 8243, 8146, 8375) were excluded (DFI) from the Hegotá candidates, and this EIP-8243 was among them.