Devcon 8 India: Open Networks, Observability & Trillion Security Hub

Devcon 8 India Community Hub Proposal

Hub Name and Topic

Devcon 8 India: Open Networks, Observability & Security Hub

Theme: Understanding, measuring, and securing hidden leakages across Ethereum’s P2P and network infrastructure.

Core topics: Ethereum P2P networking, libp2p, network observability, privacy, metadata leakage, cross-layer security, censorship resistance, network resilience, adversarial networking, and open-source security tooling.

Community initiative:

Devcon Community Hub: Devcon Community Hub Proposal: LeakDetect AI

Road to Devcon: Road to Devcon India · libp2p & Ethereum Observability

Devcon Research Retreat: https://trillion-security-rr.lovable.app/

Leak Detect AI Project Website: https://leak-detect-tooling.lovable.app/

Infrastructure Support: Credits for AI model testing and experimentation sponsored by Akamai through https://protocol-mesh-cloud.lovable.app/


Summary of Proposal

The Devcon 8 India: Open Networks, Observability & Security Hub will bring together Ethereum developers, P2P networking engineers, security researchers, privacy practitioners, open-source contributors, and the Indian developer community to explore an increasingly important security problem: hidden information leakage across the networks that connect Ethereum users, applications, agents, and infrastructure.

The Hub will focus on the intersection of Ethereum security and P2P networking, exploring how information can leak across communication layers even when applications and smart contracts are designed with strong security assumptions.

Through technical talks, hands-on workshops, security labs, network experiments, research clinics, open-source contributor sessions, and community discussions, participants will learn how to identify, measure, reproduce, and mitigate network-level and cross-layer leakage.

The objective is to move the conversation beyond smart-contract security and examine the broader attack surface created by communication metadata, peer-to-peer protocols, network topology, observability, timing, connectivity, and interactions between different infrastructure layers.


Motivation and Rationale

Ethereum security is often discussed primarily in terms of smart contracts, wallets, and application-layer vulnerabilities.

However, Ethereum is also a distributed communication system.

A user’s activity can traverse multiple layers:

User → Wallet → Application → RPC → Ethereum Node → P2P Network → Peers

At each layer, information may be observable or inferable.

Even when the underlying transaction or application data is protected, metadata surrounding communication can potentially reveal useful information about users, applications, nodes, relationships, timing, behaviour, or network topology.

This creates an important class of security and privacy questions:

  • What information can be inferred from P2P communication?

  • What metadata is exposed through network interactions?

  • Can timing information be correlated across layers?

  • What can an observer learn from peer relationships and network topology?

  • How can network-level observations undermine application-level privacy?

  • How do node discovery and peer selection affect privacy?

  • What happens when an adversary controls or observes a portion of the network?

  • How can network-level attacks influence application-level security?

  • How can developers detect leakage before deploying systems?

  • How can security researchers reproduce and measure these risks?

  • How can we improve observability without unnecessarily compromising privacy?

  • How can decentralized systems remain measurable while preserving the properties that make them resilient and censorship-resistant?

The Leak Detect AI initiative provides a practical framework for exploring these questions.

The proposed Community Hub will extend this work into an open, collaborative environment where researchers and developers can study leakage across Ethereum’s network stack and build practical tools and methodologies for identifying and mitigating it.


Why a Community Hub?

The subject of network-level and cross-layer leakage cannot be effectively addressed through a single conference talk.

It requires collaboration between people with different expertise:

  • Ethereum protocol developers;

  • P2P networking engineers;

  • security researchers;

  • privacy researchers;

  • distributed-systems researchers;

  • application developers;

  • infrastructure operators;

  • open-source maintainers; and

  • students and emerging contributors.

A Community Hub provides an environment where these groups can work together over multiple days.

Rather than simply presenting research, the Hub will allow participants to:

  • reproduce experiments;

  • inspect network behaviour;

  • build threat models;

  • conduct controlled security experiments;

  • analyse network metadata;

  • develop measurement methodologies;

  • contribute to open-source tooling;

  • discuss unfinished research;

  • identify new attack surfaces; and

  • collaborate on mitigations.

The Hub will therefore operate as a community security laboratory and learning space, rather than a conventional conference track.


How This Complements Devcon 8 India

Devcon brings together the Ethereum ecosystem across protocol development, applications, security, infrastructure, research, and community.

The proposed Hub adds a specific focus on a layer that is often less visible:

What can Ethereum’s network reveal, and how can we measure and reduce unintended leakage without compromising openness and decentralization?

The Hub complements Devcon programming around:

  • Ethereum security;

  • privacy;

  • censorship resistance;

  • open-source infrastructure;

  • decentralized systems;

  • P2P networking;

  • protocol development;

  • decentralized AI and agents;

  • infrastructure security; and

  • Ethereum’s core properties.

It provides a bridge between application-level security and the underlying communication infrastructure.

The Hub’s central message is that Ethereum security cannot stop at the smart-contract boundary.

Security assumptions must also consider the users, wallets, applications, nodes, peers, transports, network topology, and communication patterns that surround the protocol.


Supporting Builders

The Hub will be designed around a practical progression.

Learn

Participants will learn how Ethereum’s P2P layer works and how information can be exposed or inferred through decentralized communication.

Observe

Participants will learn how to inspect network behaviour and identify potentially sensitive metadata and communication patterns.

Measure

Participants will learn how to turn security assumptions into measurable experiments.

Experiment

Participants will run controlled experiments involving network conditions, adversarial behaviour, metadata, connectivity, and communication patterns.

Secure

Participants will explore mitigation strategies and understand their trade-offs for privacy, decentralization, resilience, and observability.

Contribute

Participants will be encouraged to contribute code, tests, documentation, research, threat models, and measurement methodologies to open-source security and networking projects.

The goal is for attendees to leave with something concrete:

  • a better understanding of P2P security;

  • a reproducible security experiment;

  • a new threat model;

  • a network measurement;

  • an open-source contribution;

  • a research question; or

  • a collaboration with other researchers and developers.


Community / Coalition Behind the Proposal

The Hub is being developed by an interdisciplinary group of open-source engineers, security researchers, technology practitioners, and community contributors.

The initial organizing team brings together experience across:

  • libp2p and Ethereum P2P networking;

  • open-source protocol development;

  • security research;

  • enterprise technology;

  • public-interest technology;

  • Indian developer communities;

  • distributed systems;

  • networking infrastructure; and

  • open-source maintenance.

The Hub will remain open to additional contributors from the Ethereum, security, privacy, networking, academic, and open-source communities.

The Leak Detect AI initiative will provide the central thematic and practical foundation for the Hub.


Audience

The Hub is intended for:

  • Ethereum protocol developers;

  • Ethereum client developers;

  • libp2p contributors;

  • P2P networking engineers;

  • security researchers;

  • privacy researchers;

  • distributed-systems researchers;

  • infrastructure engineers;

  • application developers;

  • wallet developers;

  • decentralized AI and agent developers;

  • open-source maintainers;

  • students and early-career researchers; and

  • Ethereum community members interested in security and privacy.

We particularly want to reach developers who understand application-level security but want to learn more about the network-level assumptions underneath their systems.

The Hub will also provide an accessible entry point for students and developers in India who want to begin contributing to Ethereum security and open-source infrastructure.


India and Local Community Engagement

Devcon 8 India provides an opportunity to connect the global Ethereum security and networking community with India’s growing technology and open-source ecosystem.

The organizing team includes contributors with experience across India, Europe, global open-source communities, academia, industry, and public-interest technology.

We will actively engage:

  • Indian universities;

  • security research communities;

  • Ethereum developer groups;

  • open-source communities;

  • distributed-systems researchers;

  • networking engineers;

  • student developers; and

  • early-career security researchers.

The Hub will prioritize accessible workshops and contributor sessions so that participants do not need to already be experts in P2P networking or security research to participate.

The primary technical language will be English, with organizers and contributors able to support informal engagement in Hindi and other Indian languages where appropriate.


Programming Philosophy

The Hub will deliberately avoid becoming a traditional conference track.

The programme will combine structured educational content with hands-on community activities.

Approximately 50% of the programming will be structured talks and presentations, while 50% will focus on workshops, experiments, research discussions, contributor sessions, and open community activities.

The programme will include:

  • technical talks;

  • security workshops;

  • P2P networking workshops;

  • live demonstrations;

  • leakage detection experiments;

  • research clinics;

  • threat-modelling sessions;

  • open-source contributor hours;

  • unconference discussions;

  • security roundtables; and

  • community networking.


Programming Formats

Technical Talks

Focused presentations covering P2P security, privacy, metadata leakage, network observability, adversarial networking, and cross-layer security.

Security Workshops

Hands-on sessions where participants learn how to identify and reason about information leakage across communication layers.

Network Experiments

Controlled experiments demonstrating how network topology, peer behaviour, timing, connectivity, and communication patterns can influence security and privacy.

Leak Detection Labs

Practical sessions based around identifying hidden leakage and developing methodologies for reproducing and measuring it.

Research Clinics

Researchers can present work-in-progress, threat models, datasets, hypotheses, or experiments and receive feedback from the wider community.

Contributor Hours

Dedicated time for participants to contribute code, tests, documentation, research tooling, specifications, and measurement infrastructure.

Security Roundtables

Open discussions between protocol developers, security researchers, privacy practitioners, and infrastructure engineers.

Unconference Sessions

Participants can propose topics and questions during the event, allowing the programme to respond to emerging community interests.


Sample Four-Day Programme

The following is an indicative programme for four days of Hub operation. The final schedule will be developed collaboratively with contributors and the Devcon team.

Day 1 : Understanding Ethereum’s Network Attack Surface

09:00–10:00 : Welcome & Community Onboarding

  • Introduction to the Hub.

  • Introduction to Leak Detect AI.

  • What is Ethereum’s P2P network?

  • Why network-level security matters.

  • How participants can contribute during the four days.

10:00–11:00 : Ethereum Security Beyond Smart Contracts

An introduction to cross-layer security and the attack surface created by interactions between users, wallets, applications, nodes, and P2P networks.

11:00–12:00 : libp2p and Ethereum P2P Networking

Introduction to:

  • peer discovery;

  • transports;

  • DHTs;

  • GossipSub;

  • NAT traversal;

  • relays;

  • peer identity.

12:00–13:00 : Open Community Discussion

13:00–14:00 : Lunch

14:00–15:30 : Hands-on: Observing a P2P Network

Participants deploy and observe a controlled network environment.

Topics include:

  • peer discovery;

  • connection establishment;

  • latency;

  • peer relationships;

  • transport selection;

  • network failures.

15:30–16:30 : Threat Modelling Clinic

Participants identify potential information leakage across different layers of a decentralized application.

16:30–17:30 : Open-Source Contributor Hour

17:30–18:00 : Day 1 Closing


Day 2 : Network Observability & Leakage

09:00–09:30 : Welcome / Recap

09:30–10:30 : What Can a P2P Network Reveal?

Exploring network metadata, communication patterns, timing, topology, and other observable information.

10:30–11:30 : Network Measurement Workshop

Participants learn how to convert security assumptions into measurable network experiments.

11:30–13:00 : Leak Detection Lab

Controlled experiments around:

  • timing;

  • metadata;

  • peer behaviour;

  • network observations;

  • communication patterns.

13:00–14:00 : Lunch

14:00–15:00 : Measuring Resilience and Privacy Together

Exploring the tension between network observability and privacy.

15:00–16:00 : Live Network Observability Demonstration

Demonstrating how network behaviour can be measured and visualized.

16:00–17:00 : Research Clinic

Researchers present work-in-progress and receive feedback.

17:00–18:00 : Open Discussion: What Should We Measure Next?


Day 3 : Adversarial Networks & Security

09:00–09:30 : Welcome / Recap

09:30–10:30 : P2P Networks as an Attack Surface

Exploring adversarial behaviour at the network layer.

10:30–11:30 : Metadata Leakage and Privacy Attacks

Exploring how information that appears harmless individually can become sensitive when correlated across layers.

11:30–13:00 : Security Lab

Controlled experiments around:

  • adversarial peers;

  • Sybil conditions;

  • network partitions;

  • eclipse scenarios;

  • peer-discovery manipulation;

  • communication failures.

13:00–14:00 : Lunch

14:00–15:00 : Censorship Resistance and Network Resilience

How network-level censorship can emerge and how it can be measured.

15:00–16:00 : Cross-Layer Security

Connecting observations from:

  • applications;

  • wallets;

  • nodes;

  • P2P networks.

16:00–17:00 : Security Research Roundtable

17:00–18:00 : Open Security Clinic


Day 4 : Mitigation, Privacy & Building Together

09:00–09:30 : Welcome / Recap

09:30–10:30 : Designing for Privacy at the Network Layer

Exploring approaches for reducing unnecessary information leakage while maintaining useful network functionality.

10:30–11:30 : Observability Without Unnecessary Exposure

How developers can design measurement systems that provide useful information while respecting privacy.

11:30–13:00 : Mitigation Workshop

Participants develop mitigation strategies for previously identified leakage scenarios.

13:00–14:00 : Lunch

14:00–15:00 : Future Security of Ethereum P2P Networks

Discussion around emerging threats, new communication patterns, agentic systems, and future cryptographic requirements.

15:00–16:00 : Open-Source Build Session

Participants work on:

  • tooling;

  • tests;

  • documentation;

  • research code;

  • measurement methodologies.

16:00–17:00 : Research & Contributor Roundtable

What should be continued after Devcon?

17:00–18:00 : Closing: From Leak Detection to Better Network Security

The final session will identify concrete follow-up research, tooling, open-source contributions, and collaborations.

Possible Speakers and Contributors

Participation will be subject to availability and confirmation.

The initial organizing team includes:

  • Manu Gupta : libp2p maintainer and technical contributor; P2P networking, open-source infrastructure, interoperability, and network observability.

  • Johanna Moran : Operations & Strategy Lead, libp2p; open-source ecosystem development, community coordination, and network infrastructure.

  • Vishesh Mathur : Director, AIC, NITI Aayog; public-interest technology, technology ecosystems, and India-focused innovation.

  • Dr. Pritha Gupta : Security Researcher, Germany; security research and emerging attack surfaces.

  • Deepti Gupta : Tech Lead, SAP; enterprise technology, distributed systems, and engineering.

  • Anurag : C4GT contributor; open-source and public-interest technology.

  • Soham Boir : QMeshPy maintainer; open-source networking and Python-based networking infrastructure.

The Hub will additionally invite:

  • Ethereum client developers;

  • Ethereum protocol researchers;

  • libp2p maintainers;

  • P2P networking researchers;

  • security researchers;

  • privacy researchers;

  • distributed-systems academics;

  • open-source maintainers;

  • Indian Ethereum developers;

  • wallet and infrastructure developers; and

  • students and emerging security researchers.

The speaker programme will remain open to community contributions throughout the preparation period.


Core Organizing Team and Experience

Manu Gupta : Technical Lead / Organizer

Manu is a libp2p maintainer and contributor to the broader IPFS, IPLD, and multiformats ecosystem. His work spans P2P networking, interoperability, protocol implementations, testing, network observability, and open-source infrastructure.

His experience includes Python libp2p, GossipSub, QUIC, NAT traversal, DHTs, peer records, multiformats, IPFS, and decentralized networking.

For this Hub, Manu will lead the technical programme, networking workshops, security experiments, research discussions, and open-source contributor activities.

Johanna Moran : Operations & Strategy / Organizer

Johanna is the Operations and Strategy Lead at libp2p, working across the global libp2p ecosystem and its contributor community.

She brings experience in open-source community coordination, ecosystem development, programme design, and connecting technical communities around shared infrastructure challenges.

Johanna will lead community coordination, programme development, contributor engagement, and Hub operations.

Vishesh Mathur : Organizer

Director, AIC, NITI Aayog

Vishesh brings experience in technology ecosystems, public-interest technology, innovation, and India’s technology landscape.

He will help connect the technical security and infrastructure conversation with India’s broader technology and public-interest ecosystem.

Dr. Pritha Gupta : Security Researcher / Organizer

Based in Germany, Dr. Pritha Gupta contributes security research expertise to the organizing group.

She will help shape the Hub’s security programme, including network-layer threats, privacy, adversarial behaviour, responsible research, and emerging security challenges.

Deepti Gupta : Technology / Organizer

Tech Lead, SAP

Deepti brings industry engineering experience and a practical perspective on building and operating complex technology systems.

She will contribute to discussions connecting open decentralized infrastructure with real-world engineering challenges.

Anurag : Open-Source / Organizer

C4GT contributor

Anurag brings experience from India’s public-interest technology and open-source ecosystem and will help connect the Hub to developers and contributors working at the intersection of technology and public good.

Soham Boir : Networking / Organizer

QMeshPy maintainer

Soham brings hands-on open-source networking experience and will contribute to the Hub’s practical networking, experimentation, Python, and contributor-oriented sessions.


Community-Driven

The Hub will be developed as an open community programme rather than as a programme controlled by a single organization.

The organizers will provide the initial structure, but contributors will be encouraged to propose:

  • talks;

  • workshops;

  • security experiments;

  • research presentations;

  • threat-modeling sessions;

  • open-source activities;

  • demonstrations; and

  • unconference discussions.

The Leak Detect AI initiative provides the central theme and initial programme foundation, while the Hub will remain open to the broader Ethereum security and networking communities.

The intention is to create a space where established researchers and maintainers can work alongside students, developers, and first-time contributors.


Marketing-Free and Neutral

The Hub will have no token promotion, sales activity, product pitches, or commercial marketing.

The organizing team includes people with different professional and community affiliations. These affiliations will not determine which technologies, projects, or research are represented.

Sessions will be selected based on:

  • technical relevance;

  • educational value;

  • security relevance;

  • openness;

  • practical usefulness;

  • contribution to the Ethereum ecosystem; and

  • community benefit.

Specific projects may be discussed where technically relevant, but the purpose will be education, research, and open-source collaboration rather than promotion.


Educational

The Hub will focus on practical education.

Every major session should answer at least one of the following:

  • What can participants learn?

  • What can they measure?

  • What can they reproduce?

  • What can they build?

  • What can they contribute?

  • What security problem can they investigate?

Where possible, workshop materials, research methodologies, code, experiments, and documentation will be shared openly after the event.


Open-Source and Community Bridge-Building

The Hub strongly aligns with Devcon’s open-source ethos.

Network security is inherently interdisciplinary. It requires protocol developers, application developers, security researchers, infrastructure operators, privacy researchers, and users to understand each other’s assumptions.

The Hub will specifically bridge:

Ethereum ↔ P2P Networking ↔ Security ↔ Privacy ↔ Open Source ↔ Research

The focus will be on practical collaboration and knowledge sharing rather than isolated presentations.


Responsible Security Research

Security experimentation will be conducted in controlled environments.

The Hub will emphasize:

  • defensive security;

  • responsible disclosure;

  • controlled experiments;

  • reproducibility;

  • privacy-preserving analysis;

  • ethical handling of datasets;

  • clear separation between research environments and production networks.

Participants will not be encouraged to conduct disruptive experiments against Devcon infrastructure, Ethereum mainnet, or other production systems.

The objective is to understand potential attacks so that developers and researchers can design stronger defenses.


Expected Outcomes

The Hub is intended to produce tangible outcomes beyond Devcon.

Open Security Research

New research questions and experiments around network-level and cross-layer leakage.

Network Measurement

Reproducible methodologies for measuring network behaviour, observability, and privacy risks.

Security Tooling

Open-source tools and experiments for identifying and investigating information leakage.

Open-Source Contributions

New code, tests, documentation, research tooling, and security improvements.

New Contributors

A pathway for developers, students, and researchers to begin contributing to Ethereum networking and security.

Research Collaborations

New connections between security researchers, protocol developers, P2P engineers, and academic communities.

Continued Community Activity

Follow-up research discussions, contributor sessions, open-source work, and experiments after Devcon.


Special Requirements / Production Considerations

The Hub should be relatively lightweight and should not require a complex production setup.

Essential

  • Reliable Wi-Fi / Internet connectivity.

  • Power outlets for participants using laptops.

  • Projector or large display.

  • Microphones and basic audio.

  • Flexible seating.

  • Whiteboards or writable surfaces.

  • Sufficient space for hands-on workshops.

Particularly Important

Because the programme includes P2P networking and security experiments, we would ideally have:

  • stable Internet connectivity;

  • reliable connectivity for multiple laptops simultaneously;

  • wired Internet for organizers where feasible;

  • sufficient power for laptops and networking equipment;

  • permission to conduct controlled networking experiments; and

  • flexibility to rearrange seating for workshops.

We do not require elaborate staging, branding installations, or marketing infrastructure.

The desired environment is closer to an open technical laboratory and community workspace than a conventional sponsored booth.


Documentation and Knowledge Sharing

Where appropriate, the Hub will document:

  • session materials;

  • workshop instructions;

  • research notes;

  • security experiments;

  • network measurements;

  • code;

  • threat models;

  • datasets where appropriate;

  • open-source issues; and

  • follow-up research questions.

The objective is for the value of the Hub to remain accessible after Devcon.


Measuring Success

We will evaluate the Hub through both quantitative and qualitative outcomes, including:

  • number of participants;

  • number of workshop participants;

  • number of first-time contributors;

  • number of research discussions;

  • number of security experiments conducted;

  • open-source contributions generated;

  • research collaborations initiated;

  • new threat models developed;

  • new measurement methodologies created;

  • participation from Indian developers and researchers; and

  • continued activity after Devcon.

Attendance will not be the primary measure of success.

The most important outcome is whether participants are able to:

understand → observe → measure → reproduce → mitigate → contribute.


Alignment with Devcon Community Hub Principles

Devcon Principle How the Hub Addresses It
Community-driven Built around an open coalition of Ethereum, P2P, security, privacy, research, and open-source contributors.
Marketing-free No token promotion, sales activity, product pitches, or commercial programming.
Educational Talks, workshops, security labs, research clinics, and hands-on experiments.
Open-source Focus on open tooling, reproducible research, open methodologies, testing, and contributor onboarding.
Security Direct focus on network-layer and cross-layer security threats.
Privacy Exploration of metadata leakage, network observations, correlation risks, and privacy-preserving measurement.
Builder-focused Participants can run experiments, build tools, conduct research, and contribute to open-source projects.
Bridge-building Connects Ethereum protocol developers, P2P engineers, security researchers, privacy researchers, and the Indian developer community.
Globally relevant Network security, privacy, resilience, and information leakage are fundamental challenges for decentralized systems globally.
India-connected Designed to actively involve Indian developers, researchers, students, and open-source contributors.

Why This Matters for Devcon 8 India

Ethereum’s security does not stop at the smart-contract boundary.

Users, wallets, applications, nodes, peers, transports, and networks all form part of the environment in which Ethereum operates.

As Ethereum becomes more widely used and increasingly interconnected with decentralized applications, wallets, infrastructure, and autonomous systems, understanding these layers becomes increasingly important.

The Devcon 8 India: Open Networks, Observability & Security Hub will create a dedicated space to explore this overlooked part of the security landscape.

The Hub will make network security practical by allowing participants to:

observe networks, identify leakage, reproduce security risks, measure their impact, explore mitigations, and contribute to open-source solutions.

By bringing together Ethereum developers, P2P engineers, security researchers, privacy practitioners, academics, and emerging contributors, the Hub aims to strengthen one of Ethereum’s most important but least visible properties:

A decentralized network should not only be open and resilient; we should also understand what it reveals, how it can be attacked, and how to make it safer without compromising the properties that make it decentralized.

The Community Hub will provide the collaborative environment needed to turn that principle into practical research, tooling, education, and open-source contributions.

Note for Participants interested in joining the community hub

If you are interested in joining the community hub, we recommend exploring the resources listed at the libp2p discussion page before participating: please visit Ethereum Networking & Security Commons: Building the Future of Permissionless Networks · libp2p/libp2p · Discussion #286 · GitHub .
These references are intended to help you build a foundational understanding of Ethereum, libp2p, peer-to-peer networking, decentralized infrastructure, and network observability. You do not need to be an expert or have prior experience with all of these technologies. The goal is to give participants enough context to follow the discussions, ask meaningful questions, experiment with the tools, and identify opportunities to contribute. Please connect with us at partner@libp2p.io for any questions, thoughts or feedback.

2 Likes

P2P Distributed Quantum Compute: Threat Models, Adversarial Peers and Resilience

Hi everyone — I’m Soham Boir, a QMeshPy maintainer and one of the contributors to this hub.

One topic I would like to explore with Devcon attendees is what happens when a peer-to-peer network is responsible not only for propagating information, but also for discovering, selecting, and invoking computational capabilities.

I have been working on QMeshPy’s Distributed Quantum Services research, where quantum operations are represented as discoverable network services. In the current architecture, service peers advertise capabilities over libp2p pubsub, a coordinator maintains a freshness-aware view of available services, circuits are broken into dependency-aware fragments, and selected peers are invoked over libp2p streams. The runtime also models reservations, retries, fallback peers, connection failures, and fidelity thresholds.

This is a research/orchestration environment rather than a claim that we already have a production quantum internet or a hardware-level entanglement-routing network. That limitation is actually what makes it useful as a controlled systems experiment: we can examine P2P behaviour and failure modes without experimenting against production infrastructure.

What I would like to discuss at Devcon

Once compute capabilities become P2P services, several familiar networking problems acquire a different consequence.

A malicious or faulty peer could advertise capabilities that are stale, unavailable, exaggerated, or inconsistent with its observed behaviour. A Sybil population could try to dominate discovery or candidate selection. An eclipse-like condition could cause a coordinator or agent to see a distorted view of the available compute network. Repeated reservations could become a resource-exhaustion vector. At the same time, the observability needed to detect these problems may itself reveal topology, workload, timing, capability, or peer-quality information.

I would therefore like to explore questions such as:

  • How should a decentralized compute network distinguish peer identity from trustworthy compute capability?
  • Which capability advertisements should be signed, freshness-limited, independently measured, or reputation-weighted?
  • How should peer selection behave when Sybil peers, churn, stale advertisements, partitions, or eclipse conditions are introduced?
  • Can ideas from GossipSub hardening — peer scoring, outbound diversity, opportunistic recovery, trusted bootstrap paths, and application-specific scoring — inform compute-provider selection without creating centralized trust?
  • What observability signals are genuinely useful for resilience, and which ones risk leaking too much about network topology or workloads?
  • How do we reason about a peer that is well-behaved at the networking layer but provides poor, dishonest, or unreliable computation?

A hands-on activity I would like to run

Rather than treating this as a presentation, I would be interested in building a small controlled peer swarm with attendees.

We could vary peer availability, latency, capability advertisements and failure behaviour, then observe:

  1. how the service registry changes,
  2. which peers are selected,
  3. how quickly fallback occurs,
  4. whether selection becomes concentrated,
  5. what metadata is exposed by our monitoring,
  6. and which mitigations improve resilience without introducing a central authority.

The result could be an open threat model and reproducible test matrix for capability-based P2P compute networks.

The quantum-compute case is useful to me, but I think the broader outcome could apply well beyond QMeshPy: decentralized AI inference, agent networks, storage providers, scientific compute marketplaces, and other systems where peers advertise scarce capabilities rather than simply forward messages.

I would especially like to compare this with how Ethereum and libp2p contributors think about peer discovery, GossipSub hardening, Sybil/eclipsing resistance, reputation, observability, and responsible adversarial testing.

Would anyone working on Ethereum P2P, libp2p, decentralized compute, agent infrastructure, or network security be interested in developing this threat model or experiment together?

Project implementation:

Technical documentation:

Most applications that call themselves decentralised are not fully decentralised. Somewhere underneath there is a managed RPC endpoint, a cloud-hosted relay, a centralised discovery server, or a third-party API that the application quietly depends on. Users rarely see this layer. Developers often accept it as a practical compromise. But it is exactly the kind of hidden dependency that undermines the privacy, sovereignty, and resilience properties that decentralised systems are supposed to provide.

This talk is about changing that.
The core idea is that developers should be able to build a P2P application where every layer of the infrastructure it depends on is something they or their users actually run and control. Not as a theoretical exercise but as a practical workflow using open-source SDKs that exist today.
The talk will start by mapping where centralisation typically creeps into P2P applications at the transport layer, the discovery layer, the relay layer, and the observability layer. Understanding where these dependencies live is the first step toward removing them.

From there the session walks through what self-running infrastructure concretely looks like, owning your peer discovery, running your own relay and bootstrap nodes, controlling your own routing, and understanding at each step who can observe what your application is doing and where your data actually lives.

MeshKit will be the practical thread running through the session. It is an open-source toolkit built to make this architecture accessible to developers who do not want to spend months on networking primitives before they can ship something useful. The privacy properties are not an add-on, they follow naturally from the architecture because the design does not route data through infrastructure you do not control.

The session also covers the MeshKit MCP server, which allows open-weight AI agents to interact with IPFS and your own node infrastructure directly, without any managed cloud layer in the middle. This is what it looks like when autonomous agents operate on self-sovereign infrastructure rather than phoning home to a third-party API.
Talk Outline

  • Where hidden centralisation lives in most P2P applications today
  • What self-running infrastructure actually looks like in practice
  • Wiring open-source SDKs together to build apps on infrastructure you control
  • How MeshKit handles peer discovery, connectivity, and routing out of the box
  • Privacy by architecture and what it means for what third parties can observe
  • MeshKit MCP server and how open-weight agents can run on self-owned infrastructure
  • Live walkthrough and how to get started contributing

Resources
NPM Package:

https://www.npmjs.com/package/@ipfs-meshkit/meshkit

MCP Server:

https://www.npmjs.com/package/@ipfs-meshkit/mcp

GitHub:

Get in touch at partner@libp2p.io

1 Like

Beyond Exploits: What Does Ethereum Unintentionally Reveal?

When we talk about blockchain security, we usually ask whether a system can be exploited.

Can a smart contract be attacked? Can a wallet be compromised? Can an authentication mechanism be bypassed?

But there is another question that deserves much more attention:

What does a system unintentionally reveal simply by operating?

This is the question behind LeakDetect AI and the broader vision we want to explore through the Devcon 8 India Community Hub on Open Networks, Observability & Security.

Ethereum is not only a smart-contract platform. It is also a large distributed communication system involving wallets, applications, RPC providers, nodes, P2P networks, bridges and other infrastructure. At each layer, observable signals can potentially reveal information that was never intended to be public.

Timing patterns can reveal behaviour. Gas patterns can expose computational differences. Signing behaviour can create fingerprints. RPC and network interactions can help distinguish users, wallets or agents. Cross-chain activity can expose relationships between systems.

As autonomous AI agents begin interacting with blockchains, their operational behaviour creates another important source of observable signals.

The key point is simple:

A system does not necessarily have to fail for information to leak.

From security testing to observability-aware security

Our vision is to make information leakage something that can be detected, measured, reproduced and eventually mitigated.

LeakDetect AI explores a pipeline of:

Signal capture → adversarial simulation → ML-based inference → leakage quantification → security reporting

Instead of asking only whether a vulnerability exists, we want to ask:

  • What signals are observable?

  • Which signals can be correlated?

  • What can an adversary infer?

  • How much information is being exposed?

  • Can the leakage be reproduced?

  • Does a mitigation actually reduce it?

We are exploring metrics such as Vulnerability Score, Key Recovery Probability, Information Leakage Rate and Stealth Leakage Index to make observability risk more measurable.

Why this matters for Ethereum

Ethereum’s openness, transparency, decentralization and composability create a very rich observable environment.

This raises an important boundary between:

transparency and unnecessary exposure
observability and privacy
measurability and fingerprinting
resilience and information leakage

A timing signal, network fingerprint or transaction pattern may reveal little individually. But when signals from multiple layers are correlated, the resulting information can be much more significant.

This cross-layer perspective is one of the areas I would particularly like to explore with the community.

Building an open security laboratory

The goal of the Devcon Hub should be more than demonstrating that something can leak. It should provide a place where researchers, protocol developers, P2P engineers, wallet developers, infrastructure builders and students can experiment with these risks in reproducible ways.

Possible areas include:

  • P2P network and topology experiments

  • timing and metadata leakage

  • wallet and signing fingerprints

  • cross-layer correlation

  • AI-agent behavioural observability

  • hardware-wallet security

  • reproducible leakage benchmarks

  • privacy-preserving measurement

  • open-source detection and mitigation tooling

The broader research direction sits at the intersection of:

AI × Security × Privacy × P2P Networks × Observability

AI is particularly interesting because machine-learning systems can identify subtle correlations across large amounts of behavioural data. At the same time, AI agents themselves will increasingly create observable behavioural traces.

So we should be asking:

What does an autonomous agent unintentionally reveal through the way it interacts with Ethereum?

And:

Can we build systems that are aware of their own observable security surface?

Open resources and collaboration

The long-term vision is to build open infrastructure for observability-aware security, including open datasets, reproducible experiments, developer tooling, security benchmarks and practical mitigation methods.

We are already making parts of this work available for experimentation and discussion:

Python Package / Hardware Wallet Testing
https://github.com/LeakDetectAI/autosca-hw-wallet-tester

Discussion & Results Server
https://leak-detect-tooling.lovable.app/

GitHub Discussions
https://github.com/orgs/LeakDetectAI/discussions

The GitHub Discussions space is intended for sharing research ideas, experiments, results, questions and feedback with the wider community.

Project / Lead Author
https://leakdetectai.github.io/

Ultimately, I think the next generation of Ethereum security needs to look beyond:

“Can this system be hacked?”

and also ask:

“What can an observer learn from this system while everything appears to be working normally?”

If we can measure that systematically, we can begin designing decentralized systems that are not only resistant to direct attacks, but also more resilient against the information they unintentionally reveal.

I look forward to exploring these questions with the Ethereum community through the Devcon 8 India Hub.

1 Like

Title: SocialCalc × MeshKit: Decentralized Storage Integration for the Tornado Backend

As part of the SocialCalc Cloud Working Group under C4GT, I’ve been working on integrating MeshKit (the decentralized storage SDK referenced above) directly into SocialCalc’s production Tornado + Nginx backend moving spreadsheet/document storage off a single centralized store and onto IPFS-backed infrastructure, with two parallel backend strategies so the team could compare trade-offs.

What’s been built so far:

1. S3-compatible backend (Filebase)
Integrated MeshKit against Filebase’s S3-compatible layer to match SocialCalc’s existing storage patterns a low-friction entry point for teams already using S3-style storage who want IPFS-backed content addressing without changing their existing architecture.

2. Kubo (full IPFS daemon) backend
A separate sidecar service (meshkit-sidecar-kubo) that wraps the MeshKit SDK’s Kubo client and talks to a real Kubo/IPFS daemon over Docker. Tested end-to-end: nginx → Tornado → sidecar → Kubo daemon → IPFS, with byte-for-byte round-trip verification on real file uploads and a health check that does a live RPC call to Kubo.
PR: https://github.com/Brijesh-Thakkar/tornado_version/pull/7 (merged to staging, CI passing)

3. Helia (in-process, TypeScript-native) backend
Since MeshKit’s SDK is currently Kubo-only under the hood, I built a second sidecar directly against raw Helia + @helia/unixfs an in-process IPFS node with no separate daemon required, filesystem-backed persistence, and all routes tested.
PR: https://github.com/Brijesh-Thakkar/tornado_version/pull/9

The goal is to give SocialCalc (and by extension, other apps in the C4GT/public-goods ecosystem) a choice between daemon-backed (Kubo) and in-process (Helia) decentralized storage depending on deployment constraints relevant to both the networking/observability conversation (comparing Kubo vs. Helia transport/discovery behavior in production) and the public goods infrastructure conversation (giving contribution/evaluation data a path off centralized cloud storage, as Anurag noted above).

Next up: wiring in the MeshKit MCP server so AI evaluation agents can read/write to this storage layer directly, and expanding to Helia nodes per the Kubo-vs-Helia discussion linked in the P2P networking hub.

Resources:

This is a really important conversation. “Decentralised” shouldn’t just mean using a decentralised protocol while quietly depending on centralised infrastructure underneath. Making the entire stack self-running and accessible to developers is a compelling direction. Looking forward to trying MeshKit!