[MegaRedHand]

Draft: pins ethrex to the head of an open PR (lambdaclass/ethrex#7217, 4462253ea). Not mergeable until that lands and we can move back to a release tag.

Motivation

ethrex paces its discv5 iterative lookups by how far along its consumer is: one lookup every 500ms at startup, easing to one every 10s at the target peer count. That completion figure came from the peer table's connected map, which only an RLPx PeerConnection could fill. ethlambda connects over libp2p and registered nothing, so the count was permanently 0, completion was permanently 0, and the pacing never left the startup rate. A lean node kept looking up every 500ms rather than settling at 10s, roughly 20x the intended steady-state FindNode traffic, for the life of the process.

It was worse than an oversight: the target had to be lied about. peer_completion divided by it, so target_peers: 0 yielded 0/0 = NaN, which saturates to a zero-delay re-fire. docs/discovery.md carried the whole thing as a known limitation, and PEER_TABLE_TARGET_PEERS existed only to keep that division off NaN.

ethrex #7217 closes it upstream. Discovery now owns its contacts as plain state and keeps its own connected set, fed by DiscoveryHandle::record_peer_event(node_id, PeerEvent). Any consumer can report its own connections, whatever transport they run over.

What this does

Pins ethrex-p2p/-rlp/-common to that PR's head, and reports every libp2p connection opened and closed:

// crates/net/p2p/src/lib.rs, on ConnectionEstablished / ConnectionClosed
report_peer_connected(server, &peer_id);
report_peer_disconnected(server, &peer_id);

--discovery.target-peers now feeds the pacing it was deliberately kept out of, so the flag means one thing in both places: the dial loop's cutoff, and how hard discovery looks. PEER_TABLE_TARGET_PEERS is gone, and so is the known-limitation section that documented it.

Naming the same peer twice

Reporting needs the discv5 node id, and the swarm only ever hands us a libp2p PeerId. Both derive from one secp256k1 key: the node id is keccak256 of the uncompressed point, the peer id a multihash of the protobuf encoding. libp2p inlines any key encoding short enough, and secp256k1 always is, so the key is recoverable from the peer id. discovery/node_id.rs does that round trip in both directions.

That derivation covers inbound peers too, which matters: a peer we never discovered still counts towards how hard we should be looking, and undercounting is exactly the bug being fixed. A peer id carrying something other than secp256k1 answers None and is simply not reported.

The derivation is pinned against ethrex's own (Node::from_enr(&record).node_id()) in a test, because a silent disagreement would make every dial-target lookup miss and the dial loop would draw candidates forever and dial none.

What the peer table's removal forced

The peer table is gone from this crate, which took two things with it.

The ENR is no longer in reach at dial time. get_contact_to_initiate returned a Contact carrying the record; next_dial_candidate returns a Node, which knows an address and a public key and nothing about quic or attnets. Judging a record is now the one moment ethlambda holds it, so LeanFilter files each admitted peer's multiaddr and subnets in DialTargets as it goes, and the dial loop looks the node id back up there.

The division of labour is unchanged in substance: discovery decides whether to dial (knows us, already tried, already connected, passed the filter), we supply how. A lookup miss is ordinary rather than a surprise, and means the same thing the old contact.record.is_none() did: a bootnode known only as a bare endpoint.

DialTargets is capped. Only records passing admission land in it, so on any real network it is the size of the lean population, but minting ENRs costs only a signature and an unbounded map would grow with however many an adversary gossips. The cap matches ethrex's own connection-pool bound. A record re-judged and rejected at a higher seq is dropped from the map, so a peer that leaves our network does not leave a dialable address behind.

nat_extip_set is new on DiscoveryConfig, and --discovery.advertise-ip is exactly what it describes: an operator naming the address peers should reach this node on. Wired to advertise_ip.is_some(), so discv5's PONG-based IP voting no longer overwrites an address that was explicitly asked for. Voting still resolves the address when the flag is unset. This is a deliberate behaviour change, called out in docs/discovery.md.

Also required by the newer spawn signature, both inert here: shared_local_node, ethrex's live identity mirror, which nothing on this side reads yet; and a fork_id watch channel whose sender is dropped immediately, since lean has no fork schedule and its digest lives in eth2 rather than eth.

Testing

make fmt, make lint and make test clean: 30 test binaries, no failures, clippy at -D warnings. cargo check --workspace --all-targets --locked passes, so the lock is what CI will see; the ethrex bump did not reopen the two-libssz split.

New tests: the PeerId to node id round trip and both of its None arms; the node id agreeing with Node::from_enr; and a peer that republishes onto another network losing its filed dial target. That last one was checked against a mutant of its own fix rather than assumed to fail (the forget call disabled: it fails, and only it).

Not covered by a test: the two record_peer_event casts themselves, which would want a running discovery server and a P2PServer together. The part that could break silently is the node id derivation, and that is pinned.

Follow-ups

• Move back to an ethrex release tag once #7217 lands.
• shared_local_node is a live view of the ENR after IP voting re-signs it. SpawnedDiscovery::local_enr is still a startup snapshot, with a doc comment admitting it lags. Wiring the two together is now a small change, deliberately not made here.