P2P Networking #2, June 3, 2026

Protocol Calls & happenings
1

Agenda

– Client updates
– cell-level deltas updates
– Sparse blobpools state + blob devnets readyness
– PQ devnets simulations update

Meeting Time: Wednesday, June 03, 2026 at 15:30 UTC (60 minutes)

GitHub Issue

2

Meeting Summary:

The meeting focused on updates and discussions regarding the implementation and progress of sparse blob pools, partial messages, and related features in Ethereum clients. Kamil led the discussion, with participants sharing updates on client support for Discovery V5, sparse blob pool integration, and the deprecation of MPlex by default in the next Lighthouse release. Bosul and Daniel discussed implementation details for sparse blob pools, including caching strategies and the interaction between HasBlobs and GetBlobs calls, while Raúl and others highlighted potential consistency issues and proposed solutions such as streaming responses or renaming methods. The group also reviewed ongoing network testing with large SNARK signatures, discussing propagation delays and scalability challenges, and agreed on the need for further coordination and client support to roll out sparse blob pool features in upcoming devnets.

Click to expand detailed summary

Daniel provided an update on the Lighthouse release, mentioning that it will support partial messages for Fulu and other features. He noted limited progress on sparse blob pools due to time constraints and announced that MPlex will be disabled by default in the next release. Joao was invited to add additional information but did not respond.

The team discussed the deprecation of a feature, with JXS confirming that users can still enable it if needed. Csaba provided an update on Discovery V5, reporting that all clients can now enable it, though some tests are still failing and need attention. Anton reported no updates on Teiko and indicated that the QUIC introduction project in Svalbard appears to be stale. The conversation ended with Kamil inviting Etherex representatives to discuss Discovery V5 implementation on their side.

Kamil and Csaba discussed ESES passing both tests, with Csaba noting that most nodes are passing except for some exit testing issues that PPL cannot fix. The team reviewed progress on the sparse blog post implementation, with Geoff and the Nethermind team actively working on EIP-870, and Pablo confirming that Etherex will begin implementation. Kamil requested the creation of a Sparkable Pool channel in Etherex Discord to coordinate efforts and mentioned the need for client support, particularly from Lighthouse and Prism, to implement recent execution API changes.

Kasey and Kamil discussed changes needed for testing sparse blob pool functionality, including updates to custody groups and the transition from git blobs v3 to v4. Kamil mentioned that a branch exists but needs fixing. Csaba shared information about new direct support for limiting bandwidths in Kubernetes testnets and discussed the differences between using external scripts, shadow simulations, and Kurtosis for testing under various constraints. The group considered the pros and cons of different testing approaches, including the impact of CPU resource competition in Kurtosis networks.

Kamil and Csaba discussed implementing and testing kurtosis with shadow scaling to verify results. Kamil mentioned the need to deploy sparse blue pool on devnets, with Casey clarifying that partial messages remain the higher priority item. Bosul explained the caching challenges with supporting both GetBlobs v3 and Git blobs, noting that they are working on a local cache system to pre-compute and preload likely-to-be-used blobs.

Bosul proposed specifying a problem in the EIP and working on it after the meeting. Csaba suggested using a different operation mode when connected to CL to avoid the problem, but Bosul noted this would limit bandwidth consumption based on CL implementation. The team discussed using dynamic signals from CLs to determine cache pre-computation needs, with Bosul suggesting increasing patch probability as a solution when running in sparse local mode. Daniel asked about the timing between HasBlobs and GetBlobs calls, with Bosul assuming sufficient time for preloading, and Daniel agreeing to measure the actual duration.

The team discussed the potential for calling HasBlobs and GetBlobs concurrently to improve performance, particularly for partial message processing. Kasey explained that concurrent calls could help determine bitmaps faster and reduce message propagation time. However, Raúl raised concerns about breaking the atomicity guarantee of GetBlobs when splitting the requests, potentially leading to correctness issues. The team considered alternatives, including returning multiple responses or using streaming, and Kamil noted the need to specify assumptions about blob availability in the Engine API.

The team discussed the implementation and potential issues with the hasBlobs and getBlobs methods in the protocol. Raúl suggested renaming the method due to its side effects, and Bosul highlighted the possibility of inconsistencies between the two calls due to different time snapshots. Daniel explained the current handling of these methods and suggested adding an implementer’s note to the spec regarding their non-atomic nature. Kamil presented a network fuzzer testing the propagation of large SNARK signatures, noting performance issues with higher node counts and block sizes, and mentioned ongoing work to reduce signature sizes and improve aggregation.

Next Steps:

  • Kamil: Create a Sparse Blob Pool channel in the Ethereum Discord server for coordination among teams.
  • Kamil: Share links to EIP-4870 and finalized Engine API changes with other teams for the sparse blob pool implementation.
  • Kamil: Merge the beacon metrics PR for GetBlobs v4 (adding same metrics as GetBlobs v3).
  • Bosul: Work on specifying the caching/preloading problem (related to HasBlobs and GetBlobs v4 interaction) in the EIP after the meeting.
  • Bosul: Investigate and think about the approach for handling CLs that only support GetBlobs v3 when EL is running in sparse blob mode (e.g., increasing patch probability or dynamic mode switching).
  • Daniel: Measure the time duration between HasBlobs returning and Lighthouse issuing the subsequent GetBlobs call, and share the result with Bosul.
  • Daniel: Add an implementer’s note to the partial messages spec clarifying that HasBlobs and GetBlobs are not atomic with respect to each other, and document the failure/inconsistency recovery path.
  • kasey: Investigate and potentially implement sparse blob pool CL-side changes for Prism (ForkchoiceUpdated with custody set modification and GetBlobs v4 support), likely as two separate PRs, after partial messages work is in a good spot.
  • Csaba: Continue investigating and distributing failing Discovery V5 tests to relevant client teams, and increase test coverage.
  • Csaba: Continue Mempool-related changes and blob management work on Geth’s side.
  • Csaba: Proceed with bandwidth-limiting and latency testing using the Kurtosis testnet tooling for sparse blob pool bandwidth sensitivity testing.
  • Pablo: Follow up internally (with Edgar) on the status of Etherex’s sparse blob pool implementation and update the team via the new Discord channel.
  • CL teams (Lighthouse, Prism, Teku): Notify the team on the Sparse Blob Pool Discord channel once a branch supporting the recent Engine API changes (ForkchoiceUpdated custody set + GetBlobs v4) is available for testing.

Recording Access:

3

YouTube recording available: https://youtu.be/kWLsvi2egJ8