P2P2026-08-12_006

P2P Networking #006

2026-08-12 1 decision 602 transcript lines

Transcript

Call summary

Decisions
  • Waggle rollout strategy: build one high-quality implementation first, test extensively in distributed settings, then hard-fork switch-over rather than prolonged dual gossip-sub/Waggle period - 00:39:57
Highlights
  • Client Updates:
    • ·Lighthouse: partial data columns for Gloas in final review; sparse blob pool FCU V4 / Get blobs V4 branches ready - 00:05:08
    • ·Prysm: Gloas partial columns nearly merged to glamsterdam-devnet-7 branch; interop tested on Kurtosis (green) - 00:06:02
    • ·Prysm bug: when Get blobs V3 and has-blobs both return empty, node must still push request bitmap of all-ones; Lighthouse asked to verify same edge case - 00:08:57
    • ·Nethermind (chat): snap/2 sparse blob pool on devnets - 00:12:59
    • ·Besu/Geth (Csaba): sparse blob pool fixes landing today; current impl focuses on first 64 cells — edge cases being resolved with Bosul; expect changes today if testing PeerDAS upper-custody columns - 00:12:59
  • Waggle Protocol:
    • ·Waggle: proposed ETH-native gossip PubSub replacing gossip-sub; drops fixed mesh, adds first-class partial messages, EC-broadcast, per-topic QUIC streams with priority (stream.SetPriority); spec at hackmd link shared in chat - 00:20:25
    • ·Prysm excited about Waggle; willing to co-implement Go library with Sukun; key open questions: client consensus, timeline, hard-fork vs. soft upgrade path - 00:07:05
    • ·Upgrade path: ENR flag to signal Waggle support; dual gossip-sub + Waggle period risks doubling bandwidth unless gossip-sub mesh size reduced — acknowledged as complex - 00:38:06
    • ·Csaba: prefer single high-quality implementation tested in distributed settings before interop; favours hard-fork switch-over rather than prolonged dual-stack - 00:39:57
    • ·QUIC stream priority: no QUIC RFC; most libraries expose HTTP/3 RFC 9218 API (stream.SetPriority); go-quic now supports it; rust QUIC ecosystem already does - 00:41:00
  • Eip Proposals Hegota:
    • ·New EIP-8C71 (Distributed Block Construction / RowDAS) proposed for Hegota: uses column subnets + bitmaps to reduce supernode CPU load, speed reconstruction, and enable supernode-free reconstruction - 00:15:06
  • Payload Distribution And Lindia:
    • ·Proposal: distribute execution payloads via column subnets using Merkle-root commitments instead of KZG, enabling partial messages per cell; no EL changes required — CL only - 00:43:46
    • ·Merkle commitment aligns with Leanda design (ethresear.ch post linked in chat); message format would be identical to future Leanda data-column sidecars, easing future transition - 00:46:00
    • ·Csaba (chat): Merkle tree does NOT prove RS extension correctness — acceptable for distribution, insufficient for sampling without ZK proof - 00:49:32
    • ·Leanda snark proofs estimated at 128–512 KB and seconds of compute on 16–32 core machines; builder latency concern if payload committed via snark on slot deadline - 00:56:26
Action Items
  • CL client teams (flagged to Lighthouse explicitly) - All CL teams: verify empty-mempool edge case — push request bitmap of all-ones when Get blobs and has-blobs both return empty - 00:08:57
  • All CL client teams - Engage Waggle spec (hackmd + libp2p specs PR #732); other CL teams (Teku, Nimbus, Lodestar, Grandine) to review and signal interest before next call - 00:37:11
  • Kamil Salakhiev - Kamil to update payload-distribution EIP with Merkle-commitment approach and share slides to group post-call - 00:50:42

Key decisions

  • Waggle rollout strategy: build one high-quality implementation first, test extensively in distributed settings, then hard-fork switch-over rather than prolonged dual gossip-sub/Waggle period

    To ensure a smooth transition and minimize potential issues, the group decided to implement Waggle through a hard fork rather than a prolonged dual-stack period.

AI Disclaimer: Some content or metadata on EIPsInsight may be AI-inferred or automatically compiled. If you find any discrepancy, please contact us at dev@avarch.org.