**Date:** 2026 / 05 / 01
**Hosts:** Raul
**Time:** 10:00 + 11:00

Shorter Slots, Attestations, and ETH-P2P Broadcast
(note: meeting notes combined because sessions flowed into each other)

## Session 1: Shorter Slots, Attestation Propagation, and Batching EIP

### Context & Recap
Building on prior discussions at the Paris L1 R&D event, this session focused on aligning client teams on the path toward shorter slot times (potentially 6-8 seconds for Hangota), with the understanding that:
- Adaptation work, engineering work, and updated test methodologies are all required
- External stakeholders making timing assumptions need to be informed and prepared
- Test stacks should be parameterized to handle multiple slot durations

### Client Implementation Status
- **Slot parameterization**: Most clients have basis points / parameterized slot times in trunk branches
- **Six-second slot branch**: Implemented and working on Kurtosis (Kevin's team)
- **Testing gap identified**: Real-world performance under shorter slots is hard to validate; Gnosis chain (5s slots) was suggested as the best real-world reference

### Key Concerns Raised

**Epoch Transition Compute (Potuz, Speaker 6)**
- The "dead part" of the slot (post-broadcast) doesn't shrink proportionally with slot time, becoming a larger relative percentage
- Validator set size is a growing concern — beacon state is becoming prohibitively large
- Some clients (e.g., Speaker 6's) already do epoch-transition pre-computation to amortize work, but this can't be fully incremental

**Trade-off Space (Potuz)**
- Shorter slots vs. shorter epochs (faster finality) are competing priorities
- More committees with more bandwidth for signatures vs. fewer/larger committees with faster slots
- The team is not yet aligned on where to land in this trade-off space

### Attestation Pipeline Issues

**Late Attestations at 4 seconds**
- Network data shows a consistent burst of attestations at the 4-second mark
- Suspected sources: Vouch, Obol, SSV, Vero — middleware that waits for threshold signing
- Spec was changed to "must" attest as soon as block is valid (not "should"), though merge status was uncertain
- Most clients (Lighthouse, Teku, Lodestar, Nimbus) reportedly comply

**Prysm Cross-Slot Bleed**
- Kasey/Prysm node observed sending ~1.3 MB of rebroadcast attestations from prior slots
- Initially attributed to attestation cache aging issue; persists even after Manu's cache fix
- Requires further debugging

### Object/Timing Inventory for GLOAS-Era Slot

Raul mapped propagation responsibilities across CL and EL:
- **Beacon block + execution payload**: To be separated; ~2-3 KB compressed
- **Inclusion lists, data columns, PTC, bids, attestations, aggregates, proposal preferences**
- **EL side**: Mempool, blob pool (changing significantly), snap sync, discovery, RPC
- **Discv5**: Migrating to v5.1

### Data Column Improvements
1. **Sparse blob pool + partial messages**: Together provide ~5x efficiency improvement
2. **Blob streaming**: Proposed for Hangota inclusion (uncertain) — offloads data transmission off the critical path; aligns CL custody requirements with EL data
3. **EL/CL co-scheduling**: Proposed enhancement so EL throttles non-critical traffic when CL is on critical path

### Aggregate Streaming Discussion
Raul proposed parallelizing aggregation: aggregators emit multiple aggregates per slot meeting different criteria (consensus threshold, 90% strength, time-based). Potuz pushed back, arguing fork choice computation is the bottleneck, not aggregate processing, and that streaming aggregates would necessitate streaming fork choice. **No consensus reached.**

### Radical Proposal (Barnabas Busa)
Add a dedicated "epoch transition slot" with extra time (e.g., 6-8s) for fork choice and shuffling, allowing reduction to 8 slots/epoch with 6s base slot times. Concerns raised:
- UX impact on apps making static slot-time assumptions
- Risk of optimizing for happy path; cross-epoch reorgs would miss

### EIP: Batching Attestations at Source

**Motivation**: Large operators run many validators on the same committee behind the same canonical state. Allowing them to emit pre-aggregated attestations could massively reduce subnet traffic.

**Mechanism**: New batch attestation type with two components:
- **Batcher signature**: A validator (in the aggregation bits) endorses the batch by signing over (slot, committee index, included validators)
- **Batch seal**: Each validator pre-signs consent to be aggregated by a specific batcher for a specific slot/committee — generated ahead of time from known duty schedules

**Validation Rule**: Each batcher can only produce one batch per (slot, committee, data root) — disincentivizes permutation spam and forces rational consolidation.

**Adversarial Bound**: 2x committee size — even an attacker controlling an entire committee can only generate one batch per validator they control.

**Open Debate (extensive)**: Potuz, Paul Harris, and Kasey questioned whether the batch seal is necessary, arguing the batcher signature alone might suffice. Raul defended it as protection against replay attacks where an attacker re-broadcasts another node's batch under their own batcher identity. Discussion did not converge — **breakout planned for next week or week after**.

**Concerns**:
- DVT compatibility: Potuz worried that requiring per-validator seals would break clusters with many keys
- Validator counts trending down (now ~800k from peak ~1M), reducing the EIP's relative value over time
- Target fork: not Hangota — later

### Subnet Redesign (Sukun)

**Inefficiencies in Current Subnet Attestation Propagation**:

1. **Repeated attestation data**: Currently sent separately for every attestation. Proposal: Nagle-like batching — accumulate attestations for the same block and push them together (~20ms in simulation; production would be size/time adaptive)

2. **IHAVE/IWANT overhead**: ~25-33% of bandwidth for IHAVEs that are essentially never used (mesh too thick at D=8 for IWANTs to fire). 20-byte hashes can be replaced with bit lists or validator indices. **Strong consensus to remove IHAVE for attestation subnets.**

3. **Topic name overhead**: Per-topic streams in a custom protocol could eliminate ~40 bytes/message of topic name compression overhead

4. **Mesh size reduction**: Current D=8 is over-provisioned; analysis shows D=4 better as committee size grows (queueing at high D causes latency degradation)

**Simulation Results**:
- Baseline: matches mainnet observations reasonably
- 500-node subnet, 500-validator committee at D=8: 30-40% reduction in P95 reception time
- 1000-validator committee (effective half-epochs): performance comparable to current mainnet (~800ms)
- 2000-validator committee (1/4 epoch slots): GossipSub fails (~2s); batched partial-message system stays under 1s with D=4
- For decoupled-consensus finality chain: 8000-node subnet with 1000-member committee can broadcast all attestation traffic to entire aggregator set in ~1.5s, enabling ~10-15s finality slot

**Open Items**:
- Switch back to bit lists (was changed to validator IDs after Potuz raised concerns; Sukun confirmed bit lists work if attestation data is sent for committee inference)
- Consider QUIC datagrams for shadow-mesh delivery (with caveats about kernel queueing behavior)
- Latency-sensitive routing (politically sensitive due to geographically isolated nodes)

## Session 2: ETH-P2P Broadcast Deep Dive

### Design Philosophy
ETH-P2P moves away from GossipSub's one-size-fits-all model toward **object-specific broadcast protocols**. Each object (beacon block, execution payload, data column, etc.) has different timing, size, source-cardinality, and concurrency characteristics. Erasure-coded broadcast is suitable for large payloads (execution payloads, data columns) but not small ones (beacon block).

### Terminology
- **Message**: Uncoded raw payload
- **Channel** (replaces "topic"): Interest group bound to one object type
- **Session**: New broadcast instance for a message; carries coder configuration in preamble
- **Strategy**: Pluggable state machine (RS, RNC, etc.) that handles encoding/routing decisions
- **Framework**: Drives the strategy via polling; not autonomous

### Protocol Structure (over QUIC)

Three stream types:
1. **Broadcast control stream** (per-connection): handshaking, subscribing, unsubscribing
2. **Session stream** (per-session, unidirectional): preamble + routing updates; close-with-error-code signals completion
3. **Chunk streams** (ephemeral, one per chunk): allow header inspection + early stream interrupt to avoid wasting bandwidth on already-received chunks

**Why unidirectional**: Avoids simultaneous-open issues common in P2P settings.

**Why ephemeral chunk streams**: QUIC streams are extremely cheap (HTTP/3 pattern). Closing a stream evicts buffered data from the kernel immediately. Native access to RTT and congestion stats enables smarter routing.

### Reed-Solomon Strategy

- Preamble: systematic chunk count, parity chunk count, data length, authentication scheme (placeholder; needs revisit)
- Bitmap-based routing updates with configurable threshold (e.g., suppress until 30% completion) — matches expected propagation curve (chaotic spray phase, then convergence)
- Per-peer budget accounting (e.g., 4-chunk forward multiplier) combined with QUIC back-pressure data for adaptive load balancing

### Authentication Discussion
Potuz argued strongly for a single commitment (e.g., KZG over all chunks) signed once, rather than per-chunk hashes. Sukun noted both approaches were tested in simulations; commitments are more compact. **Open issue**: streaming-friendly signing vs. pre-committed batch.

### Verdict System
Strategy returns one of: `Accepted`, `Redundant`, `LateAfterCompleteness`, `Surplus`, `Valid`, `Pending` — useful for both metrics and concurrency-safe verification.

### Session Scoping
Unlike GossipSub (which is largely protocol-unaware beyond loose cache windows), ETH-P2P sessions are explicitly bounded by slot — enabling clean state cleanup and zero cross-slot bleed-over.

### Benchmark Results (Shadow Simulation)

**Setup**: 2000 nodes; 95% at 50/50 Mbps; 5% at 1 Gbps symmetric; 3 MB payload

| Metric | RS | RLNC |
|---|---|---|
| P95 reception latency | ~2.4s | ~2.4s |
| Origin upload multiplier | ~3x | ~3x |
| Relay traffic | Comparable | Comparable |

**vs. GossipSub**: Same payload took ~13s on GossipSub (P100 ~30s observed in earlier runs). Multipliers roughly half of GossipSub's full-replication.

**RLNC duplication issue**: Still seeing non-innovative chunks; rank-based routing may be over-engineered (deferred for off-band discussion).

### Adoption Path

**Plan**: ETH-P2P runs alongside libp2p. All clients must use QUIC. Per peer, ETH-P2P holds a handle to the direct QUIC connection alongside libp2p. A small shim routes incoming streams to the right protocol via magic byte.

**Alternative**: Mount ETH-P2P on top of libp2p. Loses some flexibility but simpler transition. Speaker 6 advocated for this incremental approach using only a simple subset of QUIC initially.

### Open Questions
- Attack prevention and peer scoring
- Deterministic encoding choice for RS (e.g., Leopard variant)
- Reference implementation language(s) — current plan is detailed self-describing specs, with LLMs assisting cross-language ports
- **Sync fallback (Potuz)**: If RPC sync is slower than the optimized broadcast path, we risk creating slots so short that validators behind on chain cannot catch up. BALLS doesn't fully solve this — validating nodes need execution, not just availability.

### Tooling Demonstrated
- `netvis.ethp2p.dev` — visualizes traces from Shadow + framework
- Continuous fuzzer running parameter sweeps and topology variants
- Both Shadow and Shadownet backends supported (Shadownet needs more polish)

## Action Items / Next Steps

1. **Batching attestations EIP**: Breakout session in 1-2 weeks after teams review the EIP draft
2. **Prysm cross-slot bleed**: Continue debugging
3. **Sukun**: Re-run subnet simulations with bit-list (vs. validator-ID) representation
4. **All clients**: Inventory engineering work required for 10s / 8s / 6s slot targets to inform Hangota scoping
5. **Trade-off space alignment**: Need explicit discussion on slot time vs. epoch length vs. committee size before locking targets
6. **ETH-P2P**: Continue work on attack prevention, scoring, transport intelligence; finalize broadcast spec; reference implementation
7. **Blob streaming EIP**: Decision pending on Hangota inclusion

## Unresolved Tensions
- **Aggregate streaming**: Raul/Potuz disagreement on whether streaming aggregates provides any value if fork choice can't also stream
- **Batching EIP seal necessity**: Multiple participants questioned whether the batch seal is needed; replay-attack scenario not universally accepted
- **Slot vs. epoch optimization**: Fundamental disagreement on whether to prioritize shorter slots or shorter epochs
- **ETH-P2P transport approach**: Standalone-with-shim vs. mount-on-libp2p