EF<> libp2p coordination for Eth Consensus Clients

[seetadev]

Discussion Draft

Context

Ethereum Consensus Clients rely on libp2p as a core networking layer for
peer discovery, connectivity, secure transport, and protocol
communication. As the Consensus Layer continues to evolve, the
networking stack is also evolving across multiple dimensions: transport
implementations, dependencies, GossipSub, PeerDAS-related networking,
interoperability, performance, privacy, and security.

This creates an opportunity for the Ethereum Foundation (EF), Consensus
Client teams, and libp2p maintainers to scale an existing pattern of
technical collaboration into a more consistent coordination model.

The goal is not to centralize client development or reduce client
diversity. Each Consensus Client should continue to retain independent
ownership of its implementation, release process, security practices,
and engineering decisions. Instead, the proposal is to create a
lightweight coordination layer around shared libp2p networking
dependencies and security-sensitive changes so that relevant information
can move efficiently between the upstream libp2p ecosystem and all
affected Consensus Clients.

This discussion proposes a practical coordination model that can start
small, using dependency and security coordination as the first use case.

---

The opportunity

A significant portion of Consensus Client networking behavior is built
on shared upstream components. A change in one upstream component can
therefore be relevant to several Consensus Clients at approximately the
same time, even though each client integrates the dependency
differently.

The opportunity is to make this coordination more visible and
predictable.

For example, when an upstream libp2p or networking dependency receives
an important fix, the relevant Consensus Client maintainers could have a
shared way to answer:

• Which clients use the affected dependency?
• Which dependency versions or commits are currently integrated?
• Which clients have already incorporated the relevant fix?
• Which clients are evaluating or preparing an update?
• Is additional interoperability or regression testing useful?
• Does the change have implications for a shared Ethereum networking
  protocol?
• Is there any security-sensitive information that should be
  coordinated privately before broader publication?

This does not require a large process or centralized system. A small
amount of shared metadata, clear points of contact, and a predictable
communication path could provide substantial value.

---

Why coordination matters for security

Security coordination is particularly well suited to this model because
the underlying networking stack is shared while the Consensus Clients
remain independently implemented.

A coordinated approach can help ensure that:

1. Relevant upstream information reaches the right client maintainers
   quickly.
2. Affected dependency versions can be identified efficiently.
3. Client teams can independently assess and integrate fixes.
4. Interoperability and regression testing can be coordinated where
   useful.
5. Security-sensitive information can be shared through an
   appropriate channel before public disclosure.
6. The status of an important dependency update can be understood
   across the Consensus Client ecosystem.
7. The same coordination pattern can be reused for future libp2p
   networking changes.

The objective is not to create a single security process for every
client. The objective is to provide a common coordination surface around
shared infrastructure.

---

Case Study: Quinn / QUIC dependency coordination

Overview

A useful example of this coordination model is the upstream Quinn/QUIC
dependency work.

Quinn is an important component in the QUIC networking stack used by
Consensus Client implementations. When an upstream Quinn change
addresses a security or networking concern, the relevant question for
Ethereum is not only whether the upstream project has released a fix,
but also how that fix propagates through the different Consensus Client
dependency graphs.

The case study illustrates why a lightweight cross-client coordination
mechanism can be valuable.

An upstream Quinn change was available through the Quinn project:

• Quinn PR: proto: enforce packet capacity for large Initial tokens quinn-rs/quinn#2860

The relevant versions and dependency states differed across Consensus
Client implementations. The case study identified, among others:

• Lodestar: @chainsafe/libp2p-quic@2.1.4, with the referenced
  Quinn dependency state associated with an earlier Quinn
  revision/version.
• Grandine: quinn-proto 0.11.16.
• Lighthouse: quinn 0.11.19, representing the newer/fixed
  dependency state identified in the case study.

The important lesson is not the specific version numbers themselves.
Dependency versions naturally change as clients progress through their
release cycles.

The useful coordination pattern is the ability to move from:

An upstream networking dependency has an important change

to:

Here are the Consensus Clients that may be relevant, here is the
dependency state currently known for each client, here is the upstream
fix, and here is the coordination status for evaluation, testing, and
integration.

That creates a repeatable process that can be applied to future libp2p,
QUIC, transport, GossipSub, or related networking changes.

---

What the Quinn case study demonstrates

The case study provides a concrete example of several coordination
questions that are worth making routine.

1. Upstream visibility

The upstream project may have the most complete technical context about
a change.

Consensus Client maintainers benefit when the relevant upstream
information can be connected directly to the Ethereum networking teams
that need to evaluate it.

2. Dependency mapping

Different clients may use:

• Different versions of the same dependency.
• Different transitive dependency paths.
• Different language bindings.
• Different release cadences.
• Different mechanisms for incorporating upstream fixes.

A shared dependency map makes this information easier to establish.

3. Independent client assessment

Once an upstream change is identified, each client should retain control
over its own assessment.

The coordination layer should provide information and facilitate
communication, rather than prescribe how a client integrates the change.

4. Shared testing opportunities

Where a change affects a common networking behavior, the relevant teams
can coordinate interoperability or regression testing.

This is particularly useful for changes involving:

• QUIC
• libp2p transports
• GossipSub
• peer connectivity
• connection establishment
• stream behavior
• protocol negotiation
• performance-sensitive networking paths

5. Security-sensitive coordination

For security-relevant changes, coordination can begin before public
details are broadly distributed, when appropriate.

The same dependency mapping used for ordinary engineering coordination
can therefore become part of a security-readiness workflow.

---

Proposed coordination model

The proposed model is intentionally lightweight.

1. Consensus Client networking contact map

Create and maintain a small list of relevant contacts for each Consensus
Client, focused specifically on:

• libp2p
• networking
• transport
• security
• release/dependency management
• interoperability testing

The purpose is to make routing information predictable.

The contact map could be maintained jointly by EF/client representatives
and libp2p maintainers.

---

2. Shared dependency visibility

Maintain a lightweight view of important shared networking dependencies.

The initial scope could include:

• Quinn / QUIC
• libp2p implementations
• libp2p transport libraries
• GossipSub
• Noise / secure transport components
• multiaddr and related addressing components
• other dependencies identified jointly by the Consensus Client and
  libp2p teams

For each dependency, the coordination view could contain:

Field Purpose

---

Dependency Shared upstream component
Upstream project Source project
Current client version Version currently integrated
Upstream relevant version Version containing the relevant change
Client status Assessing / Testing / Integrated / Not affected
Client contact Appropriate technical contact
Notes Relevant implementation or testing context

This does not need to become a heavy database. A GitHub-based tracker or
simple shared document could be sufficient for an initial pilot.

---

Security coordination workflow

A security-oriented coordination workflow could follow a simple
sequence.

Step 1 --- Upstream change identified

A libp2p maintainer, EF representative, or Consensus Client maintainer
identifies a security-relevant change in a shared networking dependency.

Step 2 --- Impact surface identified

The relevant dependency and affected versions are identified.

Where practical, the dependency is mapped to the Consensus Clients that
may use the affected component.

Step 3 --- Appropriate contacts notified

The relevant Consensus Client networking/security contacts receive the
information through the agreed coordination channel.

For security-sensitive matters, the communication can remain private
until disclosure is appropriate.

Step 4 --- Client-specific assessment

Each client independently determines:

• Whether it is affected.
• Which dependency path is relevant.
• Whether an update is required.
• Whether additional testing is appropriate.
• Which release or patch process should be used.

Step 5 --- Interoperability/testing coordination

If useful, libp2p maintainers and Consensus Client teams coordinate
targeted tests.

Step 6 --- Status tracking

The coordination tracker records high-level status without exposing
sensitive information prematurely.

Possible states:

• Reviewing
• Affected
• Testing
• Update prepared
• Integrated
• Released
• Not affected

Step 7 --- Disclosure and retrospective

After the appropriate disclosure point, the teams can document the
relevant technical learning and improve the coordination workflow.

---

Dependency visibility as a security primitive

One of the most useful outcomes of this model would be better visibility
into the dependency graph of Consensus Client networking.

Security coordination is significantly easier when there is a known
relationship between:

Upstream dependency → version → Consensus Client → release branch →
maintainer

For example:

Quinn
  |
  +-- version/revision A
  |      |
  |      +-- Consensus Client X
  |
  +-- version/revision B
         |
         +-- Consensus Client Y
         |
         +-- Consensus Client Z

The purpose is not to expose sensitive implementation details. It is to
establish enough information to answer the operational question:

If an important upstream networking change occurs, who needs to know
and what should be evaluated?

This can substantially reduce coordination time while preserving
independent client processes.

---

Cross-client interoperability

Consensus Client diversity is an important property of Ethereum.

The proposed coordination model should therefore strengthen, rather than
reduce, independent implementations.

libp2p can help provide common interoperability surfaces around:

• transport behavior
• protocol negotiation
• GossipSub behavior
• peer discovery
• connection management
• stream management
• secure transport
• multiaddr
• QUIC
• WebTransport where relevant
• future networking protocols

When a common networking component changes, the teams can coordinate
focused interoperability tests rather than requiring each client team to
independently discover every relevant interaction.

---

GossipSub coordination

GossipSub is another natural area for structured coordination.

Consensus Clients depend on predictable behavior across peers, and
changes to GossipSub can have implications across multiple
implementations.

A scalable coordination model could provide:

• Early visibility into relevant GossipSub changes.
• Clear identification of affected implementations.
• Shared test scenarios.
• Interoperability testing across client combinations.
• Performance measurements where appropriate.
• A common place to record implementation status.

The goal is to make the existing technical relationships easier to
operate at scale.

---

Specification coordination

libp2p specifications can also benefit from a direct coordination path
with Consensus Client teams.

For a networking specification or protocol change, the coordination
process could identify:

1. What is changing?
2. Why is it changing?
3. Which Consensus Client implementations are relevant?
4. Which libp2p implementations are affected?
5. Is interoperability testing required?
6. Is there a proposed rollout sequence?
7. Are there security considerations?
8. What documentation needs to be updated?

This creates a clear bridge between specification development and
implementation.

---

Development-branch readiness

For important networking changes, it can be useful to coordinate earlier
than the final release stage.

A lightweight readiness process could identify:

• Upstream change available.
• Consensus Client implementations evaluating it.
• Test vectors or interoperability tests available.
• Client integration underway.
• Client releases incorporating the change.

This provides visibility without requiring clients to synchronize their
development processes.

---

Proposed shared coordination artifacts

A small number of reusable artifacts could support the model.

1. Consensus Client networking contact map

A maintained list of:

• Client
• Networking maintainer
• Security contact
• Release contact
• libp2p implementation
• Preferred coordination channel

2. Shared dependency tracker

A concise view of important networking dependencies and client versions.

3. Security coordination template

A standard format for sharing:

• Dependency
• Affected versions
• Fixed version
• Upstream reference
• Potential Ethereum networking impact
• Relevant clients
• Testing recommendation
• Disclosure status
• Coordination contacts

4. Interoperability test matrix

A lightweight matrix covering important networking behaviors across
Consensus Clients.

5. Coordination history

A record of completed coordination activities so that future maintainers
can understand what worked well and reuse the established pattern.

---

Suggested GitHub-based workflow

The first implementation could be deliberately simple.

A dedicated repository or section within an existing coordination
repository could contain:

consensus-client-coordination/
├── contacts.md
├── dependencies.md
├── security/
│   ├── templates/
│   └── coordination-records/
├── interoperability/
│   ├── test-matrix.md
│   └── scenarios/
└── specifications/
    └── tracking.md

GitHub Issues, Discussions, or private coordination mechanisms could be
used depending on the sensitivity of the information.

For security-sensitive matters, the public tracker should only contain
information that is appropriate for public disclosure.

---

Roles and responsibilities

Ethereum Foundation / Consensus Client coordination

EF can help provide the coordination layer across Consensus Client
teams, particularly where a shared networking or security topic affects
multiple implementations.

This could include:

• Maintaining the Consensus Client contact map.
• Helping route security-sensitive information.
• Facilitating cross-client discussions.
• Coordinating common testing where useful.
• Helping identify shared priorities.

libp2p maintainers

libp2p maintainers can provide:

• Upstream technical context.
• Dependency and release information.
• Networking expertise.
• Interoperability support.
• Specification context.
• Relevant security information.
• Test and debugging support.

Consensus Client teams

Each client team retains responsibility for:

• Assessing its implementation.
• Determining whether it is affected.
• Integrating upstream changes.
• Running client-specific testing.
• Managing releases.
• Communicating client-specific status.

This separation preserves independence while improving coordination.

---

Initial pilot: Quinn / QUIC

The Quinn/QUIC case study provides a practical starting point because it
represents a shared dependency with relevance across multiple Consensus
Client implementations.

A small pilot could establish:

1. A current Consensus Client networking contact list.
2. A mapping of Quinn/QUIC versions across clients.
3. A standard dependency-security coordination template.
4. A process for notifying relevant maintainers of upstream changes.
5. A small interoperability/regression test set.
6. A simple status view showing assessment and integration progress.

Once the process works for Quinn/QUIC, the same pattern could be
extended to other shared networking components.

---

Future coordination areas

After the initial dependency pilot, the same model could support
coordination around:

libp2p releases

Early visibility into releases that contain changes relevant to
Consensus Clients.

GossipSub

Protocol changes, performance improvements, interoperability, and
security-related updates.

QUIC and transports

Transport upgrades, dependency changes, connection behavior, and
performance.

PeerDAS networking

Coordination around networking requirements, implementation behavior,
testing, and interoperability.

Secure transport

Noise, TLS, QUIC security properties, and future transport improvements.

Post-quantum networking

Coordination around hybrid or post-quantum transport and identity
mechanisms as they become relevant to Ethereum networking.

Observability

Common approaches for understanding peer connectivity, protocol
behavior, and network health while preserving client independence.

---

Measuring success

The coordination model should remain lightweight and measurable.

Useful indicators include:

• Time from an upstream relevant change to the correct Consensus
  Client contacts being notified.
• Percentage of relevant clients with known dependency status.
• Time required to identify potentially affected clients.
• Number of coordinated interoperability tests.
• Time from upstream fix availability to client assessment.
• Time from assessment to integration where an update is required.
• Number of reusable coordination workflows established.
• Feedback from Consensus Client and libp2p maintainers.

The most important measure is not the number of processes created. It is
whether maintainers can coordinate important networking and security
changes more efficiently while preserving client independence.

---

Principles

The proposed coordination model follows a few simple principles:

Lightweight

Coordination should reduce operational overhead rather than introduce
another large process.

Security-first

Security-sensitive networking changes should have a clear path to the
right maintainers.

Client-independent

Each Consensus Client retains ownership of its implementation and
release decisions.

Open and transparent where appropriate

Public technical coordination should remain visible and reusable
whenever the information is suitable for public discussion.

Private when necessary

Security-sensitive information should use appropriate private channels
until disclosure is ready.

Interoperability-oriented

Shared testing should focus on practical network behavior across
implementations.

Reusable

The same model should work for dependencies, specifications, releases,
and security coordination.

---

Discussion questions

This document is intended as a starting point for discussion with EF and
the Ethereum Consensus Client teams.

A few questions that could help shape the initial implementation:

1. Which Consensus Client networking contacts should participate in the
   initial coordination group?
2. Which shared networking dependencies should be included in the first
   dependency map?
3. Would a GitHub-based tracker be sufficient for the initial pilot?
4. What is the preferred security coordination channel for shared
   networking dependencies?
5. Which Quinn/QUIC interoperability tests would be most useful as the
   first pilot?
6. Which existing EF or client security workflows should this
   coordination layer integrate with?
7. Which libp2p specifications or upcoming networking changes would
   benefit most from early Consensus Client coordination?
8. What information should remain private during security coordination,
   and what should become public after disclosure?
9. How can we make the process useful without creating additional
   release-management overhead for individual client teams?

---

Proposed next steps

A practical first phase could be completed with a small working group
from EF, Consensus Client teams, and libp2p.

Phase 1 --- Establish contacts

Create the Consensus Client networking/security contact map.

Phase 2 --- Map dependencies

Start with Quinn/QUIC and document the relevant dependency versions and
integration paths.

Phase 3 --- Define the coordination template

Create a reusable template for upstream networking and security changes.

Phase 4 --- Run the Quinn pilot

Use a real or representative Quinn/QUIC coordination cycle to validate
the process.

Phase 5 --- Add interoperability testing

Identify a small set of cross-client networking tests that can be reused
for future changes.

Phase 6 --- Expand

Extend the model to libp2p releases, GossipSub, transports, PeerDAS
networking, and other shared networking components.

---

Long-term vision

The longer-term objective is to make coordination around Ethereum
Consensus Client networking predictable without making it bureaucratic.

When an important change occurs in the shared networking stack, the
ecosystem should have a straightforward path:

Upstream change
      ↓
Technical/security assessment
      ↓
Affected dependency identification
      ↓
Consensus Client contact routing
      ↓
Independent client assessment
      ↓
Shared interoperability testing where useful
      ↓
Client integration and release
      ↓
Coordinated disclosure / documentation

This model can provide a stronger operational connection between EF,
Consensus Client teams, and libp2p while preserving the diversity and
independence that make Ethereum resilient.

The Quinn/QUIC case study provides a concrete starting point. From
there, the same coordination pattern can be applied incrementally to the
broader Consensus Client networking stack.

---

Conclusion

Ethereum's Consensus Client ecosystem already has strong technical
relationships across clients, EF, and libp2p. As the networking stack
continues to evolve, there is an opportunity to make these relationships
easier to operate at scale.

A lightweight coordination layer focused initially on shared
dependencies and security can provide:

• Faster routing of important upstream information.
• Better visibility into dependency impact.
• More efficient security coordination.
• More predictable interoperability testing.
• Earlier alignment on important networking changes.
• Better continuity across maintainers and release cycles.

The intent is to build on existing collaboration rather than create a
new centralized process.

The proposed Quinn/QUIC pilot offers a concrete way to test the model,
learn from it, and progressively extend it to other areas of Consensus
Client networking.

Feedback and suggestions from EF, Consensus Client teams, and libp2p
maintainers are welcome.