feat(el): ENR bootnodes and discv5-only, staged for devnet-8

[barnabasbusa]

Draft — do not merge onto running devnet-7. This is the discv5-only config for devnet-8; merging it against devnet-7's current images would break besu and reth (see Image requirements).

Why

Devnet-8 runs discv5-only, and discv5 bootstraps from ENRs, not enodes:

• besu discards its enode bootnode list entirely once discv5 is enabled and rejects enodes with Invalid ENR bootnode: ... must start with 'enr:'.
• nimbus-eth1 now hard-disables discv4 (status-im/nimbus-eth1#4582, merged), so its enode bootnodes feed a protocol that no longer runs.

The list has to be all-ENR rather than mixed, since besu drops the enode half.

What

Both EL bootnode sources swapped to their ENR equivalents:

before	after
ethereum_node_fact_discovery_el_enode	ethereum_node_fact_discovery_el_enr
bootnodoor_fact_enode	bootnodoor_fact_el_enr

and discv4 turned off per client:

client	flag
geth / erigon	--discovery.v4=false --discovery.v5=true
ethrex	--p2p.discv4=false --p2p.discv5=true
reth	--disable-discv4-discovery
nethermind	--Discovery.DiscoveryVersion=V5
besu	--discovery-mode=V5
nimbusel	none needed — discv4 disabled upstream

Applied to the devnet-7 inventory because devnet-8 is cut from it. I deliberately did not add an inventories/devnet-8/ tree: it would carry 47 live devnet-7 host IPs and copied sops secrets under a devnet-8 name, which terraform regenerates anyway and which risks deploying devnet-8 config onto running devnet-7 boxes.

Image requirements

Both flags are recent and not in any release, nor on the current devnet branches — verified by running the images:

image	result
ethpandaops/besu:glamsterdam-devnet-7-caa5abf	Unknown option: '--discovery-mode=V5'
ethpandaops/reth:glamsterdam-devnet-7	invalid value 'enr:...': Failed to parse url: no host specified
ethpandaops/besu:main	accepts --discovery-mode=V5
ethpandaops/reth:main	starts on enr: bootnodes — 2.4.1-dev (c505ed2)

So devnet-8's besu and reth images must be rebased on their mains: besu #10800 (2026-07-22), reth #26448 (2026-07-29).

geth, erigon, nethermind, nimbusel and ethrex on their devnet-7 tags already accept the flags and ENR bootnodes.

Depends on

ethpandaops/ansible-collection-general#568 — provides both facts. The collection is pinned to master, so they arrive once that merges.

Testing

Ran a 7-EL kurtosis enclave (geth, besu, erigon, reth, nethermind, nimbusel, ethrex) discv5-only with ENR bootnodes, using devnet-7 images plus :main for besu and reth. All seven peered and began syncing:

el-1-geth        peers=6  block=8
el-2-besu        peers=1  block=6
el-3-erigon      peers=1  block=6
el-4-reth        peers=1  block=0
el-5-nethermind  peers=1  block=0
el-6-nimbus      peers=1  block=0
el-7-ethrex      peers=1  block=6

The same run on unmodified devnet-7 images had el-2-besu and el-4-reth both Exited (2).

Nethermind takes ~2 min to find its first peer (slow discv5 lookup cadence) and cannot publish its own ENR at all — admin_nodeInfo has no enr field — so it can dial others but cannot serve as a bootnode. Worth not making it primary_bootnode.