P2P Networking #009
Transcript
- Daniel Knopik
silver 👀
- jxs
yeah Vlad, do you want to introduce yourself and silver?
- Raúl Kripalani
nice, daniel has a branch integrating the probe into lighthouse btw
- Csaba
Who is building on Sepolia?
- Daniel Knopik
sigma prime has a builder which is picked fairly often
- Daniel Knopik
Reacted to "nice, daniel has a..." with 👍
- Csaba
Since there is no financial incentive, timings games are not something that gets played I guess
- Daniel Knopik
Replying to "nice, daniel has a..." in dire need of a rebase though :D
- cayman
Replying to "nice, daniel has a b..." are there docs on what is needed to be added? would love to add to lodestar if possible
- Raúl Kripalani
Replying to "nice, daniel has a b..." good news is that the xray protocol should be stable 😄
- Daniel Knopik
Reacted to "Since there is no ..." with 👍
- Raúl Kripalani
Replying to "nice, daniel has a b..." @cayman i'd prompt: "study the wire protocol and how the prysm probe hooks into the client to produce the necessary traces, and propose the cleanest integration path for lodestar"
- Daniel Knopik
Replying to "nice, daniel has a..." I'll try to clean it up and mainline it
- cayman
Reacted to "@cayman i'd prompt: ..." with 👍
- Raúl Kripalani
what's the rationale for the builder to wait til it sees a few attestations?
- Csaba
It can get a direct message with the consensus block, isolated, and release
- Raúl Kripalani
a selective release/withhold attack doesn't make sense
- Raúl Kripalani
if its a valid consensus block, it will also propagate the block, no?
- Csaba
If it is propagated. It has to do active work for that (which is possible)
- cayman
Replying to "nice, daniel has a b..." @Raúl Kripalani what is the name of that dashboard? querying "ethereum xray network propagation" is not finding anything
- Raúl Kripalani
@Csaba mind elaborating?
- Raúl Kripalani
what active work? you mean propagating the block?
- Csaba
Also, discv5 was deliberately made to be a protocol used by many networks. I’m not saying it how it should be, but worth noting
- Felix (Geth)
Service discovery: https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md#topic-based-service-discovery Implementation: https://github.com/datahop/go-ethereum/blob/topdisc/p2p/discover/topicindex/topictable.go
- Onur
Reacted to "Service discovery: https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md#topic-based-service-discovery Implementation: https://github.com/datahop/go-ethereum/blob/topdisc/p2p/discover/topicindex/topictable.go" with 👍
- Daniel Knopik
Reacted to "Service discovery:..." with 👍
- Kamil Salakhiev
Reacted to "Service discovery: https://github.com/ethereum/devp2p/blob/master/discv5/discv5-theory.md#topic-based-service-discovery Implementation: https://github.com/datahop/go-ethereum/blob/topdisc/p2p/discover/topicindex/topictable.go" with 👍
- cayman
Reacted to "Service discovery: h..." with 👍
- Csaba
As I understand (but not my area), some builders don’t want to release the payload until they are quite sure it will get on chain without large reorg risk.
- Raúl Kripalani
yeah! should be fairly easy to make xray work with shadow
- Sukun Tarachandani
Reacted to "yeah! should be fairly easy to make xray work with shadow" with 👍
- Sukun Tarachandani
- Yann Vonlanthen
Reacted to "https://hackmd.io/@sukunrt/rkMKx1Eoze" with ❤️
- Kamil Salakhiev
Reacted to "https://hackmd.io/@sukunrt/rkMKx1Eoze" with ❤️
- Raúl Kripalani
yeah and our propagation tends to be O log
- Raúl Kripalani
so until the next order of magnitude, things should be "fine"
- Sukun Tarachandani
Reacted to "so until the next order of magnitude, things should be "fine"" with 👍
- Sukun Tarachandani
Replying to "so until the next or..." Yeah that’s our intuition too.
- Csaba
It’s even O log if every node has just enough bandwidth to send a stream (I had a paper on it in the past). Here we are much better, there is more BW. Still O log, but the increment is small
- Daniel Knopik
xatu data will be very interesting once gloas is live
- Raúl Kripalani
yeah we should probably update EIP-7870 because Nielsen's Law has rolled over several times since 🙂
- Yann Vonlanthen
Reacted to "yeah we should probably update EIP-7870 because Nielsen's Law has rolled over several times since 🙂" with 👀
- Daniel Knopik
I think it is perfectly fine to delay it to I-star if we hit these roadblocks
- Daniel Knopik
but we should IMO attempt it in H because otherwise will be here again when we discuss the scope for I star
- Yann Vonlanthen
Also, since we might revamp attestation propagation in I*, it feels wise to tackle payload propagation before that, no?
- Daniel Knopik
Reacted to "Also, since we mig..." with 💯
- Daniel Knopik
yeah. I think each client has people interested in networking stuff (i.e. the people in this call). From a pm perspective it makes sense to let these people work on improvements already so that we dont have to improve everything all at once (in the worst case) once the network becomes the bottleneck
- Sukun Tarachandani
Reacted to "yeah. I think each client has people interested in networking stuff (i.e. the people in this call). From a pm perspective it makes sense to let these people work on improvements already so that we dont have to improve everything all at once (in the worst case) once the network becomes the bottleneck" with ❤️
- Yann Vonlanthen
Reacted to "yeah. I think each client has people interested in networking stuff (i.e. the people in this call). From a pm perspective it makes sense to let these people work on improvements already so that we dont have to improve everything all at once (in the worst case) once the network becomes the bottleneck" with ❤️
- jxs
we plan to do it in the most optimal way
- Daniel Knopik
Reacted to "we plan to do it i..." with 🔥
- Kamil Salakhiev
Reacted to "we plan to do it in the most optimal way" with 🔥
- Csaba
Reacted to "we plan to do it in the most optimal way" with 🔥
Call summary
Targets
- •Decoupled consensus 500-node Cloud Run simulation — October 08, 2026 (tomorrow) - 01:00:49
Decisions
- •Lighthouse will implement EIP-8411 regardless of Hegota fork inclusion, with network backward compatibility - 01:43:20
Highlights
- Client Updates:
- ·Lighthouse: simplifying networking stack; prototyping EIP-8411 and attestation bundling - 00:18:05
- ·Prysm: partial columns merged and enabled by default for Fulu and Gloas; peer scoring/connectivity revamp soaking on mainnet and Hoodi nodes; dashboard demo planned for next call - 00:19:10
- ·Lodestar: QUIC 1.3 in progress; partial columns not enabled until after Gloas mainnet - 00:21:01
- ·Geth (Csaba): published post on blob pool protections; hardening of sparse blob pools this cycle - 00:22:13
- Service Discovery:
- ·Felix (Geth): topic-based service discovery now in discv5 spec, replacing old unimplemented messages; allows targeted peer search without ENR encoding - 00:32:18
- ·Spec considered final; Geth implementation (with Datahop) in progress but not merged; incremental deployment supported — not all nodes need to upgrade simultaneously - 00:35:03
- ·Per-node index table is bounded (constant storage overhead); scales with network size; post-quantum ENR growth motivates moving away from full-network crawl assumption - 00:50:46
- Eip Proposals Hegota:
- ·EIP-8411 (segmented execution payload broadcast): CFI for Hegota; splits payload into 64 chunks; reduces propagation latency ~3×; includes consensus change adding chunk root to bid - 01:10:33
- ·Lodestar concern: insufficient mainnet data showing propagation problems; risk of scope creep delaying Hegota past June; prefer deferral to I-star if not clearly needed - 01:12:28
- ·Counter-arguments: testnets lack realistic builder/home-node/bandwidth conditions; machinery needed regardless for PQ signatures and LeanVM proofs; segmentation is a prerequisite unlock (consensus bid change) for future networking work - 01:13:51
- ·Lighthouse committed to implement EIP-8411 regardless of Hegota inclusion, with backward compatibility; Prysm expressed interest (thumbs up from Vlad/Gattaca) - 01:43:02
- Gloas Sepolia Bandwidth Profile:
- ·Post-Glamsterdam Sepolia bandwidth profile: execution payloads propagate immediately at slot start, not after attestation threshold - 00:24:00
- ·Lodestar (no partial columns): data column sidecar bandwidth ~10x higher than Prysm (e.g., ~1 MB vs ~120 KB per block) - 00:28:30
- ·Lodestar receiving up to 77 copies of execution payload per message (~150 KB × 61+); likely IDONTWANT bug fixed in recent release — version under investigation - 00:30:35
- Dc Simulations Decoupled Consensus:
- ·Sukun: Shadow sims (100 nodes, 20% supernodes) testing decoupled consensus with 8-slot rounds; 2,500 attesters/subnet vs. ~500 today; 500-node Cloud Run sim scheduled for tomorrow - 00:53:43
- ·Three strategies under simulation: (1) all FFG votes at slot start, (2) staggered per-second publishing, (3) three committees across slot; goldfish vote latency improves significantly in strategies 2 and 3 - 00:56:23
- ·Key problem: no cross-topic stream prioritization between goldfish and FFG meshes; QUIC stream priorities only work per-connection - 00:58:48
- ·Plan: integrate GossipSub IHAVE/IHAVEv1 tracer; also attempt to make X-ray work with Shadow simulations - 01:00:49
Action Items
- •Lodestar (Matthew Keil / cayman) - Lodestar: verify IDONTWANT fix is present in Sepolia-targeted release; investigate 60-77 duplicate execution payload copies observed - 00:31:41
- •Sukun Tarachandani - Add X-ray support to Shadow simulator; raise PR - 01:04:09
- •Kamil Salakhiev - Raise EIP-8411 on upcoming ACDC call for broader client alignment - 01:46:33
Key decisions
EIPs discussed
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.