EIPsInsight

Loading Experience

Preparing your insights...

Loading0%
P2P2026-06-03_002

P2P Networking #002

2026-06-03 2 decisions 445 transcript lines

Transcript

Ask about this call

Answered from this call's summary and transcript only.

AI-generated — verify against the recording.

Call summary

Decisions
  • EL should guarantee blob availability for current slot after hasBlobs returns true; next slot not guaranteed — 00:49:30
  • Lighthouse will disable MPLEX by default in next release; opt-in flag remains available — 00:18:19
Highlights
  • Client Updates:
    • ·Lighthouse: next release adds partial message support for Fulu and disables MPLEX by default — 00:17:47
    • ·Discovery V5: all clients now passing basic tests; ethrex passing most, coverage being expanded — 00:20:47
  • Sparse Blob Pool:
    • ·EIP-8070 sparse blob pool spec stable; Geth, Nethermind, and ethrex have active implementations — 00:23:51
    • ·No CL yet supports engine API changes (getBlobsV4 + custody group FCU notification) needed for devnet testing — 00:25:58
    • ·Atomicity concern raised: hasBlobs and getBlobsV4 are not atomic; Lighthouse confirmed it does not populate 'I have' bitmap from hasBlobs, only the request bitmap — 00:47:22
    • ·Raúl proposed renaming hasBlobs (e.g., 'lock blobs' or 'prepare blobs') since it carries implicit availability guarantee for current slot — 00:49:55
    • ·Partial messages spec lacks explicit implementer note about hasBlobs/getBlobsV4 non-atomicity; agreed to add one — 00:56:58
  • Pq Interop Devnets:
    • ·PQ shadow simulation: 32-node devnet stable (~500ms propagation); 64-node shows finalization gaps with 256KB SNARK blocks at 4s slots — 01:01:06
    • ·Zeam and other clients will add artificial aggregation delay flags to make simulations more realistic — 01:05:19
Action Items
  • Kamil / all CL teams — Create Sparse Blob Pool coordination channel in Ethereum Discord; CL teams (Prysm, Lighthouse, Teku) ping when getBlobsV4 + FCU custody group notification is ready — 01:00:07
  • Daniel Knopik / Michael — Add implementer's note to partial messages spec clarifying hasBlobs and getBlobsV4 are non-atomic — 00:56:53

Meeting chat29

  • Kamil Salakhiev

    https://github.com/ethereum/execution-apis/pull/774

  • Edgar | ethrex

    we have a pr open implementing 8070 on ethrex

  • Bosul Mun

    Reacted to "we have a pr open im..." with 👍

  • Edgar | ethrex

    https://github.com/lambdaclass/ethrex/pull/6776

  • kasey

    [CL changes for testing] This would be to notify EL of custody group changes?

  • Kamil Salakhiev

    https://github.com/ethereum/beacon-metrics/pull/23

  • Daniel Knopik

    i have a branch, but i need to fix it x)

  • Bosul Mun

    Replying to "[CL changes for test..." If you don’t use getBlobsV4, there could be more missing blobs, since if el doesn’t have enough cells to recover blobs on the blobpool then it will return nil for those

  • Bosul Mun

    Replying to "[CL changes for test..." So ideally we want to have both engine apis on devnet

  • kasey

    Would the EL then fallback to “dense” blob pool if CL stops sending custody group metadata in FCU? That could be a nice operational feature, because then we could have a single flag in the CL, and that CL flag would drive both layers.

  • Csaba

    Why is is hasBlobs query, and not a hasBlob stream from from EL to CL?

  • Kamil Salakhiev

    do we have streaming support in engine api?

  • Csaba

    Replying to "do we have streaming..." Don’t know, but I did propose to add it a few month ago :-)

  • Csaba

    Replying to "do we have streaming..." AFAIK the protocol itself supports it

  • kasey

    A blob appearing where we didn’t have it seems fine, a blob disappearing would be a bigger issue.

  • Daniel Knopik

    I built hasBlobs support with the assumption that the received blobs might be different, both appearing and disappearing

  • Csaba

    Replying to "do we have streaming..." I remember looking it up in JSON RPC, and there is something

  • Csaba

    Replying to "do we have streaming..." That was my getBlobs “v3” improvement proposal before other v3 and v4 things came up

  • Daniel Knopik

    Replying to "I built hasBlobs s..." this means e.g. that I do not implement optimization like intentionally not verifying incoming cells while waiting for getblobsv3

  • kasey

    FWIW, a lot of things can go sideways (buffering etc, across multiple implementations) with such a small streaming response. Meaning in practice we could very well not see the “fast” part of the message until we also get the “slow” part on the wire.

  • kasey

    Replying to "I built hasBlobs sup..." My concern was more that if we tell peers that we have a particular blob, but we actually need it, seems more likely to run into bugs where they don’t send us the missing cells on bitmap update.

  • Daniel Knopik

    Replying to "I built hasBlobs s..." i dont set it in my metadata until i truly have it hasblobs only affects the request bitmap: i do not request promised blobs

  • kasey

    hasBlobs: I want getBlobs: I have

  • Csaba

    Where is the hasBlobs description?

  • Kamil Salakhiev

    Replying to "Where is the hasBlob..." We don’t have it yet. Marco should start working on that soon. But it is implemented in geth already

  • Csaba

    Replying to "Where is the hasBlob..." OK

  • Kamil Salakhiev

    http://202.61.202.59:4321/

  • Kamil Salakhiev

    https://github.com/kamilsa/lean-shadow-fuzzer

  • Leandro

    Bye bye

Key decisions

  • EL should guarantee blob availability for current slot after hasBlobs returns true; next slot not guaranteed

    guarantee blob availability for current slot
  • Lighthouse will disable MPLEX by default in next release; opt-in flag remains available

    disable MPLEX by default in next release