P2P Networking #010
Transcript
- FLCL (Nethermind)
gm!
- Mega | ethlambda
hello
- Anton Nashatyrev
Reacted to "hello" with 🤚
- Chase Wright
I can’t stay for the entire meeting, I have an appointment, but my thing should be quick, in theory
- Csaba
I don’t want to be first :-)
- Sukun Tarachandani
9 pm :/
- Csaba
Not the best, but not sure there are better ones :-)
- Daniel Knopik
both is fine rn, but i support moving to the AM as i will be in australia for a while :D
- Sukun Tarachandani
Reacted to "both is fine rn, but i support moving to the AM as i will be in australia for a while :D" with 🎉
- FLCL (Nethermind)
partial messages of which protocol?
- Daniel Knopik
partial data columns
- Chase Wright
- FLCL (Nethermind)
lgtm
- FLCL (Nethermind)
appears to be useful for light clients
- vlad | gattaca
payload must arrive by 6s, vote deadline at 9s
- Kamil Salakhiev
Reacted to "payload must arrive by 6s, vote deadline at 9s" with 👍
- Sukun Tarachandani
Reacted to "payload must arrive by 6s, vote deadline at 9s" with 👍
- Sukun Tarachandani
https://github.com/ethereum/dc-networking/tree/main/personal/sukun Slides here: ff-workshop.html is the one I presented. The slot structure are the ones where we discuss whether to do scenario 1 vs scenario 3.
- Kamil Salakhiev
Reacted to "https://github.com/ethereum/dc-networking/tree/main/personal/sukun Slides here: ff-workshop.html is the one I presented. The slot structure are the ones where we discuss whether to do scenario 1 vs scenario 3." with ❤️
- Anton Nashatyrev
Reacted to "https://github.com/ethereum/dc-networking/tree/main/personal/sukun Slides here: ff-workshop.html is the one I presented. The slot structure are the ones where we discuss whether to do scenario 1 vs scenario 3." with ❤️
- Mikel Cortes (ProbeLab)
Sorry guys, I need to dop
- Kamil Salakhiev
Reacted to "Sorry guys, I need to dop" with 👍
- Daniel Knopik
ecbroadcast as in ethp2p?
- Sukun Tarachandani
Reacted to "ecbroadcast as in ethp2p?" with 😃
- Anton Nashatyrev
This is great 🚀
Call summary
Decisions
- •No consensus reached on snap ENR entry; issue to remain open for async comment from EL client teams before any PR is merged - 00:19:35
Highlights
- Client Updates:
- ·Lighthouse enabled partial data columns on mainnet by default in Monday's release - 00:06:00
- ·Csaba: implemented message validation in Go-libp2p P2P at multiple levels; slides forthcoming next call - 00:07:41
- ·Geth BLSync CL lite client updated to be Glamsterdam-compatible with efficiency improvements - 00:12:00
- Snap Enr Discussions:
- ·Cross-client ENR analysis: Geth alone publishes a 'snap' key (empty array); no other clients set it; no EIP guidance on value or versioning - 00:14:00
- ·Three options proposed: omit snap from ENR entirely; include with supported version; or keep as empty array (Geth current behavior) - 00:14:40
- ·Edge cases: Reth skips SNAP 1, will support SNAP 2 in Glamsterdam; Nimbus EL can sync but not serve snap data - 00:18:00
- Informed Diffusion Zcast:
- ·Csaba introduced zcast: fast & lean broadcast protocol built on segmentation, erasure coding, controlled I-have/I-want, and sampling; targets payloads and sampled broadcast (PeerDAS-style) - 00:52:15
- ·Benchmark: gossipsub today is far from optimal; zcast achieves sub-700 ms payload propagation with <2x bandwidth overhead even with 50 Mbps home builder uplink - 00:58:30
- ·zcast is not designed for attestation aggregation (many-to-one / in-network compute); that remains a separate protocol domain - 01:04:26
- ·Implementation: Go on top of go-libp2p/GossipSub + Python executable spec + TLA+ formal verification (in progress); runs on Shadow and native QUIC; post on ethresear.ch with full technique breakdown - 01:05:43
- ·Byzantine resilience tested up to 50% withholders and active malicious nodes; formal verification work ongoing to close remaining gaps - 01:19:50
- Decoupled Consensus Simulation:
- ·Sukun presented decoupled consensus simulations (Cambridge workshop): decouple LMD-GHOST head vote (Goldfish) from FFG finality vote (Simplex); targets 4x faster finality - 00:20:46
- ·Simulation: 500 cloud Prysm-fork nodes, 64 subnets, 2,500 validators/subnet (~25% above mainnet); Scenario 1 (staggered FFG) works but home nodes hit ~440 Mbps peak vs 25 Mbps limit - 00:22:10
- ·EIP-8334 (bundle attestations): batching 4 votes reduces 960 bytes → 552 bytes; with partial messages, home node bandwidth drops well below 25 Mbps limit and Goldfish votes are >20% faster at P99 - 00:33:00
- ·Scenario 3 (3 committees/subnet, fully decoupled finality): works but Goldfish propagation degrades to ~1.2s without topic prioritization; topic priority work (Csaba) could resolve this - 00:37:53
- ·Open design question: staggered publishing (Scenario 1) vs. multiple committees per subnet (Scenario 3); need to define desired properties before choosing - 00:40:45
Action Items
- •Kamil Salakhiev / EL client teams - Raise snap ENR behavior with Geth team; gather consensus on whether to include snap key and how to value it - 00:19:10
- •Sukun Tarachandani - Share decoupled consensus simulation slides publicly for broader review - 00:50:30
Key decisions
No consensus reached on snap ENR entry; issue to remain open for async comment from EL client teams before any PR is merged
Snap ENR entry discussion unresolved; awaiting EL client team comments before merging any PR
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.