Devcon 8 India: P2P Networking Hub

Summary of Proposal

The P2P Networking Hub is a vendor-neutral home for the people who build and maintain Ethereum’s networking layer. Over four days, communities and teams across libp2p, devp2p, client implementations, research, and privacy networking will run workshops, protocol teardowns, and open debugging sessions on the discovery, broadcast, transport protocols and more that power Ethereum’s execution and consensus layers.

Motivation and Rationale

The networking layer stays invisible until it breaks, yet it is where much of Ethereum’s CROPS values are enforced in practice. The hub makes that layer visible, giving attendees somewhere to watch how peers find each other and how data actually moves across the network. The hub allows to meet the people working on the parts that are still unsolved. No other hub covers this ground. Networking is the foundation that sits beneath any Ethereum project, so it bridges communities that rarely share a room, and it ties into live roadmap work (ethp2p), most visibly shorter slot times and higher blob targets, which both run into limits set by the network layer.

Networking problems get debugged across implementations, and a workshop might be enough to describe a problem but not to reproduce and understand it. So, four full days matter here. A persistent space lets maintainers drop in at any point and work through their issues in the open.

We have not run a Community Hub before, though the convening communities have maintained and researched this layer for years. We are borrowing formats that have worked at deep technical gatherings we have been part of before, keeping sessions hands-on and leaving enough unstructured time for the conversations that tend to matter most.

Implementation

The standard hub package and setup (TV screen, boards, whiteboards, worktable, power, Ethernet) covers most of our needs. What we would like to ensure for a P2P networking hub is strong internet connectivity (wired or wireless).

Programming

Programming is a collaborative effort spread across the convening communities, organized into loose daily themes with a consistent daily rhythm. Devcon runs four full days and the hub will be active across all of them.

Daily rhythm (9:00–18:00):

Time Block
09:00–10:00 Open hours → coffee + informal networking
10:00–11:00 Onboarding / intro to the day’s theme
11:00–12:30 Workshop (hands-on)
12:30–13:30 Lunch / open space
13:30–14:30 Talk or cross-project panel
14:30–16:00 Debugging clinic / live measurement / hacking
16:00–17:00 Cross-community roundtable
17:00–18:00 Open hours → informal hacking + wind-down

Thematic days:

Most days are split into morning (AM) and afternoon (PM) sessions and included (in parenthesis) the lead team for the session. The following is tentative

  • Day 1: Foundations & Discovery (AM Ethereum Foundation, PM ProbeLab)
    Ethereum’s p2p stacks: libp2p, devp2p, and the emerging ethp2p; transports (QUIC, Noise). Peer discovery across the ecosystem: discv4, discv5, disc-ng, and Kademlia in general. The idea is to provide a beginner-friendly onboarding track for newcomers to the networking layer.

  • Day 2: Scaling, Broadcast (AM Ethereum Foundation, PM Optimum).
    A full-day discussion track on moving beyond gossipsub toward erasure-coded broadcast or alternative gossiping protocols. Data propagation and PeerDAS as a live networking challenge and network measurement and health.

  • Day 3: Privacy, Censorship-Resistance (Gnosis VPN).
    Metadata and traffic-analysis resistance, mixnets, peer-to-peer VPNs, and private messaging.

  • Day 4: Resilience (AM, Gnosis) & Open Problems (PM, ProbeLab).
    NAT traversal and hole-punching, eclipse and Sybil resistance, transport security. Finally an “open problems in p2p networking” roundtable across all the convening communities, plus a closing session.

Concrete schedule will be finalized after acceptance.

Example sessions and topics pool:

  • libp2p, devp2p, and ethp2p internals, and multi-implementation interoperability

  • Peer discovery: discv4 / discv5 / discovery-ng, Kademlia, and hyperdht

  • Beyond gossipsub (potentially a full-day discussion):

    • The good, the bad and the ugly of Gossipsub. What works well and what needs fixing.

    • Erasure-coded broadcast and data-availability networking

  • Network measurement, crawling, and health dashboards

  • NAT traversal and hole-punching at scale

  • Censorship-resistant transports and private messaging

  • Mixnets and peer-to-peer VPNs for metadata resistance

How this supports Ethereum’s core properties. The networking layer is where much of CROPS is enforced in practice: censorship-resistance (no single chokepoint to block), privacy (metadata and traffic-analysis defense), and security (Sybil/eclipse resistance, encrypted transports). It is open-source and multi-implementation by nature, and it is the connective tissue that bridges node operators, client teams, researchers, and privacy projects. This makes it a natural home for the cross-community collaboration Community Hubs are built for.

Audience

The hub is for protocol and networking engineers, client and libp2p/devp2p maintainers, distributed-systems researchers, node operators, privacy builders and curious newcomers who want to understand the layer beneath everything else they use.

We want to particularly engage with India’s growing Ethereum and open-source community, as well as node operators, university distributed-systems, networking groups, and privacy advocates.

Our organizing team is based outside India, so we are still in the process of (1) partner with local Ethereum and open-source communities to co-design and promote sessions, (2) recruit India-based volunteers and contributors ahead of and during the event, and (3) run a beginner-friendly onboarding track so the hub is genuinely accessible to local builders and students, not only to existing networking specialists.

Organising Team

Lead organiser: ProbeLab

ProbeLab ensures the coordination and staffing of the space across all four days. ProbeLab is a network-measurement research group working across libp2p, devp2p, DHTs more generally, and client networking. Its measurement work is vendor-neutral and trusted across projects, which is exactly what makes it well-suited to host a neutral space. All core members hold relevant PhDs in networking.

Confirmed Organising Partners

  • ProbeLab (organiser) - Yiannis Psarras, Mikel Cortes, Dennis Trautwein

  • Ethereum Foundation Research - Csaba Kiraly, Kamil Salakhiev

  • Gnosis VPN / Hopr - Tino Breddin, Melissa Günthardt

  • Optimum - Swarnabha Sinha

Outreach to more potential partners is in progress

Re: Keeping the space neutral and marketing-free. We will run an explicit “no shilling” house rule for every session and vet content to be vendor-neutral. Some technologies are naturally tied to a certain project where we will rotate sessions across projects to ensure no single entity dominates. We will also ensure multiple implementations are represented by design. ProbeLab’s own contribution is open measurement data that benefits the whole ecosystem rather than any product.

Languages. The core team (ProbeLab) can offer content in English, with additional support available in German, Greek, and Spanish.

1 Like

This is a great proposal, and I want to flag a neighbouring one (Devcon 8 India: Sovereign Infrastructure Hub) rather than a competing one, so it’s on the record early.

I’m posting an intention this week for a “Sovereign Infrastructure” hub: a reframe of the “Node Operators” hub from previous editions, aimed at end users running their own connection to Ethereum instead of depending on a third-party RPC provider. Light clients, node tooling on hardware people already own, and wallets that verify rather than trust.

The relationship to yours is clean, I think: you serve the people who build the networking layer, we serve people downstream of it who mostly don’t know it exists. Every light client in our hub is a devp2p and libp2p consumer, and when they break for our attendees, they break in your territory: discovery behind NAT, UDP filtering, holding peers on a phone that keeps backgrounding, battery-driven connection churn.

So, concretely: we’d send anyone who wants to go a layer deeper straight to you, and you’d have somewhere to send people who want to actually run something. If a joint session appeals — light clients as p2p consumers, and what the network looks like from a phone or a conference wifi network rather than a datacentre, I’d be glad to put it together with you. We’ll have maintainers in the room with real data on what fails.

Either way, good luck with the proposal. Happy to coordinate scheduling so we’re not competing for the same audience at the same hour.

1 Like