P2P networking #6 August 12, 2026

Protocol Calls & happenings
1

Agenda

– Client updates
– Waggle protocol (Joao, Sukun)

Meeting Time: Wednesday, August 12, 2026 at 15:30 UTC (60 minutes)

GitHub Issue

2

Meeting Summary:

The meeting focused on client updates and discussions about the Waggle protocol. Team members provided updates on their respective projects, including Lighthouse’s final review phase for partial messages in GLOAS and sparse blob pool changes, Prism’s progress on interop testing and GetBlobs v4 implementation, and various updates from Bosul and Csaba on SparseBlobPool modifications and EIP proposals. Sukun presented the Waggle protocol, describing it as a new gossip-based pubsub library designed specifically for Ethereum with first-class support for partial messages and EC Broadcast, discussing implementation details including stream prioritization and the potential transition from fixed mesh to random forwarding. The team also discussed technical aspects of message segmentation, particularly around execution payloads and the potential shift from KZG commitments to MerkleRoot commitments as part of the upcoming Lindsay proposal, with concerns raised about performance implications and the need for careful implementation and testing before deployment.

Click to expand detailed summary

The team discussed upcoming client updates and planned to wait for Sukun to join before fully discussing a “waggle” idea. Kamil indicated he had reached out to Sukun about an hour ago and expected him to join the meeting. The group agreed to start with client updates, with Daniel prepared to provide updates on both Prism and Lighthouse projects.

Daniel reported that Lighthouse is in the final review phase for partial messages in GLOAS and has prepared changes for sparse blob pool in FCU v4. Aarsh shared that Prismatis is close to merging GLOAS partial columns to the Glamsterdam DevNet 7 branch and completed interop testing on Kurtosis, with plans to implement GetBlobs v4 and Foxtrot’s updated V4 work. Aarsh also discussed a potential collaboration with Sukoon on the Waggle project, a gossip sublibrary for Ethereum with first-class support for partial messages, and identified a bug in Lighthouse related to handling empty get blobs v3 and hash blobs calls.

Aarsh explained the issue with the hasblobs functionality in the codebase, clarifying that even when there are no blobs in the mempool, a request should still be pushed out to retrieve all data columns. Csaba and Aarsh discussed the implementation details and edge cases in the Prism system. Bosul provided updates on working on partial prediction size cap PRs, fixing bugs related to sparse buffer, and integrating the CAIC listener on the GAP. Csaba mentioned modifications to the SparseBlobPool and addressed discrepancies between the draft spec and current implementation, noting that some spec modifications might be needed.

Csaba presented updates on a proposed EIP called ZODAS, which aims to reduce CPU load on super nodes, improve construction robustness, and enable reconstruction without super nodes through partial messaging and subnets. Kamil raised questions about using Merkle trees for row commitments and discussed potential post-quantum implications, with Csaba noting that while there will be some overhead, they can iterate on the approach. The team briefly discussed BPO efforts and devnet updates, with FLCL mentioning sparse nodes on devnets, before transitioning to Sukun’s presentation on the Waggle protocol.

Sukun presented a new protocol called Waggle designed as a baseline for PubSub that addresses limitations in GossipSub, particularly around partial messages and topic streams. He explained that message semantics and peer scoring should be handled at the application level rather than in the protocol framework, and proposed removing the fixed mesh approach in favor of random peer selection. Aarsh questioned the need for topic streams, but Sukun clarified that separate streams allow for parallel transmission of messages with different priorities, which can be managed through stream IDs and priority settings in the QUIC protocol.

The team discussed two main topics: QUIC stream prioritization and execution payload segmentation. Csaba explained the trade-offs between fixed mesh and random forwarding schemes in QUIC, noting that random forwarding could impact SPS coding and scrolling performance. Sukun confirmed that stream priority functionality exists in QUIC libraries following HTTP/3 RFC standards, though no specific QUIC RFC exists for priorities.Regarding execution payload segmentation, Kamil and Csaba proposed moving from KZG commitments to Merkle tree commitments for payload data, which would be more aligned with future post-quantum secure Lindsay scheme implementation. They discussed the performance implications, noting that while Merkle proofs are less expensive than KZG, the future Lindsay SNARK proofs would be significantly more computationally intensive at 128-512 kilobytes. The team agreed to further explore mixed schemes that could use cheaper encryption for short-term needs while planning for post-quantum security requirements.

Next Steps:

  • Daniel: Check Lighthouse implementation for the bug where request bitmap is not sent when both get blobs v3 and has blobs return empty, as reported by Aarsh.
  • Aarsh: Rebase and land GetBlobs v4 and Foxtrot’s updated V4 work on the GlamstreamDevNet7 branch, and notify Bosul when completed and tested.
  • Aarsh: Discuss consensus mechanism, team interest, and timelines for Waggle protocol with Sukun and other client teams in the next call.
  • Csaba: Land modifications to SparseBlobPool related to full 1 bitmaps and get blobs, and update the specification if needed.
  • Sukun: Share the QUIC Go priority API details with the team and follow up offline with kasey about peer scoring based on prioritization signals.
  • Kamil: Consolidate efforts and ensure alignment with the upcoming EIP about Linde (Lindsey/Linvium) and payload segmentation schemes.

Recording Access:

3

YouTube recording available: https://youtu.be/-428cUZ3Mfo