**Date:** 2026 / 04 / 30
**Hosts:** Raul
**Time:** 10:00

## Part 1: ETH P2P Vision & Design Principles

### Motivation
ETH P2P is a fresh, Ethereum-specific networking stack to replace the libp2p-based status quo. libp2p was a pragmatic choice during the ETH2 bootstrap when networking wasn't a bottleneck — but it increasingly is. The new design treats networking and protocol as **two sides of the same coin** rather than independent concerns.

### Four Design Principles

1. **Vertical Integration**
- Stack is aware of slot phases, deadlines, priorities, and object specificities
- Example: attestations in a slot/committee context can be represented as bitmaps and reconciled, rather than gossiped as individual hash-addressed objects

2. **Mechanical Sympathy**
- Goal: minimize idle resources; nodes self-measure bandwidth and impose appropriate caps
- **Pushback:** "Zero idle" is antithetical to elasticity, resilience under adverse conditions, and home staker viability (residential lines need spare capacity for other uses). Zero-idle should be reframed as a path to *resilience*, not maximal throughput
- Discussion of organic "supernodes" (DVTs, cloud-hosted nodes) — emerging bottom-up rather than designated, but incentivization remains an open hard problem

3. **Privacy by Default**
- Cannot be bolted on later; attestations are currently the worst correlation offender
- Proposal: set propagation upper-bound caps (e.g., P90 attestation propagation at 500ms) and use the slack within that budget for anonymization primitives (mixnets, RLNs, OHTTP-style two-hop relays, Privacy Pass tokens)
- Spam prevention in encrypted mixnets via **rate-limiting nullifiers**

4. **Consistent Performance**
- Performance consistency is part of correctness
- Couples to graceful-degradation finality research and consensus pacing

### Stack Layers

**Transport:** QUIC over TLS 1.3 (native multiplexing, 0-RTT, session resumption, Encrypted Client Hello). Ethereum traffic should be **indistinguishable from generic web traffic**. TCP fallback is open question — pending real-world mainnet measurement of QUIC-vs-TCP preference between dual-capable peers to detect UDP-hostile middleboxes. QMUX (QUIC-over-TCP) noted as future option.

**Peering:** Built on discv5; ~9 MB RAM to hold full CL discovery view. Background connection pre-warming with session resumption tokens enables single-message sends without handshake latency — critical foundation for deterministic mini-mixnets.

### Censorship Resistance Discussion
- Effectiveness depends on adversary sophistication
- Looking like normal HTTPS/QUIC traffic + proxying (MASQUE-style) helps against middleboxes/ISPs
- Against state actors (GFW), the goal is making DPI expensive
- Tor-style fingerprinting research shows real hiding requires either heavy cover traffic or significant slowdown
- Distinction noted: user-level censorship resistance ("post a tx") vs. validator-level privacy (much harder)

### Critical Concern: Overlay Bloat (Lighthouse dev)
> "We're running five overlays today: discv4, discv5 twice, libp2p, devp2p. Unless we get rid of them, all these promises are vacuous."

Some agreement: the other overlays should be retired to avoid compounding complexity.

### History / Sync Architecture Tangent
- Opinion: should be **one master number** for retained history, applied uniformly across blobs, EL, weak subjectivity, etc. (Currently ~5 months, derived from longest plausible WS period)
- Raul: even with that number set, the **validator P2P network shouldn't serve historical data** — that belongs to a separate cohort of disk/bandwidth-optimized nodes (conceptually similar to Portal Network)
- Some agreement that history retrieval is "personal interest" while recent-final-state sync is essential participation behavior
- Open design question: content negotiation layer to segregate workloads on shared library/transport

---

## Part 2: Erasure Coded Broadcast

### Problem
GossipSub is store-and-forward: each peer must fully receive and validate before forwarding. Inefficient and slow as payload sizes grow.

### Simulation Results (Shadow, 2000 nodes, degree 10, 2.4 MB payload, second/warm message)

| Metric | GossipSub | RS Broadcast |
|---|---|---|
| P95 latency | ~13 s | ~2 s |
| Bandwidth multiplier | ~6–8× | ~3–4× |

### Key Design Elements

**Reed-Solomon (systematic):** original data + parity (currently 2× multiplier, 16 KB chunks). Chosen over RLNC primarily due to **patent encumbrance on RLNC** (MIT/Optimum portfolio specifically targeting blockchains).

**Two innovations:**

1. **Convergence phase with bitmaps** — once peers reach a local availability threshold, they switch from random gossip to bitmap reconciliation, mitigating the coupon-collector tail problem
2. **Sessions** — a slot-scoped state container. Origin opens with a **preamble** announcing coder config (shard count, parity, chunk size, authentication commitment). All state torn down when slot elapses; thereafter served via request-response. Provides rapid network-wide announcement primitive

**Authentication:** chunks authenticated at source by builder signatures (preferred) or per-chunk Merkle proofs against an upfront commitment (rejected by Raul because it blocks streaming).

### Significant Technical Debate: RS vs. RLNC

**Pushback:**
- Earlier RLNC simulations showed **<1s P99** for 2 MB payloads over 10,000 nodes; ~1000-node real network tested up to 2 MB
- RLNC authentication uses homomorphic commitments — a **single signature** on the block plus per-chunk commitment verification (orders of magnitude faster than per-chunk signature verification at ~5–10 ms each)
- Coefficient-size bloat is a blob concern, not a payload concern
- Claims EF lawyers indicated RLNC **broadcasting** use (vs. storage) appeared clear; suggests pursuing MIT for a grant similar to Arbitrum/Princeton precedent

**Raul's position:**
- Patent uncertainty in a globally-deployed decentralized network is unacceptable risk
- Optimum (MIT-licensed) is actively commercializing against blockchain clients — unlikely to grant
- Fast RS encoding/decoding also has associated patents — neither path is patent-clean
- Authentication cost can be optimized; RS allows reuse of the erasure scheme already used elsewhere in the protocol
- Open to benchmarking signature-verification cost and exploring vector commitments over RS chunks

### Action Items / Follow-ups
- Benchmark per-chunk signature verification cost in the RS scheme
- Investigate vector commitments over RS chunks as RLNC-equivalent authentication
- Mainnet measurement campaign: QUIC vs. TCP preference between dual-capable peers
- Schedule Part 2 session — simulator walkthrough, deployment/testing/multi-language interop not yet covered
- Showcase of: EL mempool observatory + 30-second discv5 crawler with identify support

---

## Open Questions Left Hanging
- Concrete plan and timeline for retiring discv4 / second discv5 / devp2p
- How "trailing security" tiers (head-1, head-2) for low-bandwidth nodes would integrate with consensus rewards
- Scope of TCP fallback work given discv5's hard UDP dependency
- Whether historical data serving lives on a separate overlay or is content-negotiated on the same stack
- Final RLNC patent posture — is a Princeton/Arbitrum-style grant from MIT worth pursuing?