Skip to content

chore(p2p): switch libp2p from the lambdaclass fork to upstream 0.57.1 - #724

Draft
MegaRedHand wants to merge 2 commits into
mainfrom
chore/upstream-libp2p
Draft

MegaRedHand wants to merge 2 commits into
mainfrom
chore/upstream-libp2p

Conversation

@MegaRedHand

Copy link
Copy Markdown
Collaborator

🗒️ Description / Motivation

  • Replaces the lambdaclass/rust-libp2p fork (rev 2f14d0e) with the crates.io release libp2p 0.57.1, and takes libp2p-mplex 0.44.0 from crates.io too.
  • The fork's only change of its own was send_request_with_protocol. Nothing calls it since req/resp became one request_response::Behaviour per protocol, so the fork now only costs rebasing.
  • Draft until the dependency tree clears the 14-day publish-age cooldown, on 2026-11-09 04:00 UTC (see below).

What Changed

  • crates/net/p2p/Cargo.toml: libp2p = "0.57.1" and libp2p-mplex = "0.44.0" instead of the git dependency.
  • Cargo.lock: re-resolved. Every new crate is pinned to its newest release past the cooldown, except the four listed below. main is merged in, and chore(deps): bump quinn-proto, h2, rkyv and crossbeam-epoch past RustSec advisories #718's quinn-proto, h2, rkyv and crossbeam-epoch bumps are kept.
  • crates/net/p2p/src/lib.rs: a Gossipsub alias that keeps AllowAllSubscriptionFilter, and max_publish_messages(500) in place of the removed max_messages_per_rpc(Some(500)).
  • crates/net/p2p/src/beacon/scoring.rs (tests): use the alias.
  • Comments in lib.rs, swarm_adapter.rs and req_resp/behaviour.rs that pointed at the fork; the libp2p line in CLAUDE.md.

Correctness / Behavior Guarantees

Upstream change Effect here
gossipsub 0.50 defaults to MaxCountSubscriptionFilter: 100 topics per peer and per RPC, and a peer over either limit has its whole subscription RPC ignored Kept the old behavior with the Gossipsub alias. A mainnet peer custodying every column subnet is over the limit from those subnets alone, and every peer doubles its topic set around a fork-digest rollover
max_messages_per_rpc became max_publish_messages Behavior change: an RPC over 500 messages now fails to decode and its inbound stream is closed. The fork processed the first 500 and dropped the rest
gossipsub 0.50 caps subscriptions plus control data per inbound RPC (max_control_message_size, default 16384 bytes) Not changed; see the open questions
gossipsub 0.50 sends all subscriptions in one hello RPC Not changed; see the open questions
libp2p-quic 0.14 prefers the X25519MLKEM768 key exchange Brings aws-lc-rs (a C build) into rustls. The Docker builder already has a C toolchain
libp2p-swarm 0.48 smart dialing is opt-in (with_smart_dial) QUIC-first dialing under DIAL_ADDRESS_CONCURRENCY is unchanged
libp2p-swarm pins wasm-bindgen-futures = "=0.4.58" Moves wasm-bindgen, js-sys and web-sys back in the lockfile

Publish-age cooldown

Four crates have no release old enough yet:

Crate Published Clears the cooldown
libp2p-peer-store 0.1.0 2026-10-15 2026-10-29 21:27 UTC
libp2p 0.57.1 2026-10-15 2026-10-29 21:40 UTC
ctutils 0.4.6 2026-10-25 2026-11-08 23:01 UTC
crypto-bigint 0.7.10 2026-10-26 2026-11-09 04:00 UTC

No older libp2p avoids the last two. Every libp2p 0.57.x needs libp2p-identity ^0.3, which reaches crypto-bigint ^0.7.5 through k256 0.14 (our secp256k1 node keys) and elliptic-curve 0.14.1. crypto-bigint 0.7.0 to 0.7.8 are all yanked over a breaking fix (RustCrypto/crypto-bigint#1373), so 0.7.9 and 0.7.10 are the only candidates, and both are under two weeks old.

The Dependency cooldown job will pass with a warning until then: its probe cannot resolve libp2p ^0.57.1 under the cooldown, and a failed probe only warns. While it fails, it checks nothing else in the lockfile. I ran the same probe locally with only these four crates held locked: nothing else in the lockfile is too young.

Tests Added / Run

  • make fmt and make lint: clean.
  • cargo test --profile release-fast -p ethlambda-p2p --lib: 360 passed.
  • cargo test --profile release-fast -p ethlambda --bins: 261 passed.
  • Not run yet: the full make test, and a run against mainnet or devnet peers.

Open questions

  • Should max_control_message_size be raised? Upstream rejects an inbound RPC whose subscriptions plus control data exceed it, and does not split its own outgoing IHAVEs to fit.
  • A node with --custody-group-count 128 now announces more than 100 topics in one hello RPC. How do peers that cap subscriptions per RPC treat it?
  • Should features = ["full"] be narrowed to what we use? That drops libp2p-peer-store and the unused transports and protocols.

Related Issues / PRs

✅ Verification Checklist

  • Ran make fmt — clean
  • Ran make lint (clippy with -D warnings) — clean
  • Ran make test (test-consensus plus test-node, at release-fast) — only ethlambda-p2p --lib and ethlambda --bins so far

The fork's only change of its own was `send_request_with_protocol`, which
nothing calls since req/resp became one `request_response::Behaviour` per
protocol. Tracking crates.io releases gets upstream fixes without keeping
a fork rebased.

Upstream changed two gossipsub behaviours this node depends on:

- libp2p-gossipsub 0.50 made `MaxCountSubscriptionFilter` the default (100
  topics per peer and per RPC, whole subscription RPC ignored when over).
  A mainnet peer custodying every column subnet is over that alone, so
  the `Gossipsub` alias keeps `AllowAllSubscriptionFilter`.
- `max_messages_per_rpc` became `max_publish_messages`, and an RPC over
  the limit now fails to decode and closes the inbound stream instead of
  being truncated.

libp2p-mplex is taken from crates.io at the release libp2p's own
dev-dependency names. libp2p-quic 0.14 prefers X25519MLKEM768, which
brings aws-lc-rs (a C build) into rustls. libp2p-swarm pins
wasm-bindgen-futures, which moves the wasm-bindgen crates back.

Every new crate was pinned to its newest release past the 14-day
publish-age cooldown, except four with no such release: libp2p 0.57.1,
libp2p-peer-store 0.1.0, crypto-bigint 0.7.10 and ctutils 0.4.6.
crypto-bigint 0.7.0 to 0.7.8 are yanked, and every libp2p 0.57.x reaches
it through libp2p-identity 0.3 and k256 0.14, so no older libp2p avoids
it.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant