Private PoS network: should a Reth bootnode be reth p2p bootnode or a full reth node seed?

[SyedMuhamadYasir]

Question

I am trying to set up reliable bootnode-based discovery for a private Ethereum PoS network using Reth.

I need to understand the intended Reth architecture for private-network bootnodes:

• should the seed be reth p2p bootnode, or
• should it be a normal full reth node whose enode is used as the bootnode?

Environment

Dedicated bootnode host:

• Reth bootnode binary: reth-ethereum-cli v1.6.0
• Command: reth p2p bootnode
• Bootnode port: UDP <BOOTNODE_PORT>
• NAT: extip:<BOOTNODE_EXTERNAL_IP>
• Public enode: <BOOTNODE_ENODE>

Execution nodes:

• Reth node binary: v1.11.1
• Private PoS custom genesis.json
• Started with the same custom chain file
• Started with only the dedicated bootnode in --bootnodes
• DNS discovery disabled
• NAT/external IP configured for each host

Goal

I want this behavior:

1. Start one dedicated bootnode.
2. Start many Reth execution nodes with only --bootnodes <BOOTNODE_ENODE>.
3. Nodes discover each other through the bootnode.
4. The peer graph fills without manually listing every full node as a trusted/static peer.

This is for a classroom/lab network where many student nodes may join and leave.

Current dedicated bootnode command

On my v1.6.0 bootnode binary, the flag is --node-key:

reth p2p bootnode \
  --addr 0.0.0.0:<BOOTNODE_PORT> \
  --node-key ./nodekey \
  --nat extip:<BOOTNODE_EXTERNAL_IP>

Current execution-node command shape

reth node \
  --chain ./genesis.json \
  --datadir ./node1 \
  --bootnodes "<BOOTNODE_ENODE>" \
  --disable-dns-discovery \
  --nat extip:<CLIENT_EXTERNAL_IP> \
  --port <CLIENT_P2P_PORT> \
  --discovery.port <CLIENT_DISCOVERY_PORT> \
  --http \
  --http.addr 127.0.0.1 \
  --http.port <LOCAL_HTTP_PORT> \
  --http.api "admin,eth,net,web3,rpc,reth" \
  --authrpc.jwtsecret ./jwtsecret

What I observed

With packet tracing:

• Client sends UDP discovery traffic to the bootnode
• Bootnode replies over UDP
• After a few minutes, the client can get net_peerCount = 0x1
• The actual established TCP/RLPx peer is a full Reth node, not the reth p2p bootnode itself
• This suggests bootnode-assisted discovery may be working, but it is slow/noisy and not very transparent

I also see occasional RLPx handshake decode errors from unsuitable peers, which makes me wonder whether the standalone reth p2p bootnode is chain-blind and can return unsuitable discovery records.

Main questions

1. Is reth p2p bootnode intended to be sufficient as the only seed for a private Reth network?

2. Or is the recommended production/lab setup to run a normal full reth node on the seed port and use that node’s enode as the bootnode?

3. Does reth p2p bootnode perform only discovery, or should clients ever establish TCP/RLPx sessions with it?

4. Should the bootnode enode point to the dedicated bootnode port, or should private networks prefer a full Reth node’s normal P2P port?

5. Should a private PoS network use discv4 only, or should discv5 also be enabled?

6. Is --bootnodes alone supposed to let nodes discover each other, or should private networks also configure --trusted-peers, --trusted-only, --peers-file, or static full-node seeds?

7. Does version skew matter here? My dedicated bootnode is v1.6.0, while the Reth execution nodes are v1.11.1.

8. Is matching --chain ./genesis.json enough on the Reth side for private PoS EL peering, or is there another network identifier/fork config setting I should explicitly verify?

9. What is the recommended minimal command set for:

   • dedicated bootnode
   • full Reth seed node
   • regular Reth execution node
   • consensus-client pairing on a private PoS network?

Possible fix I am considering

I am considering replacing the standalone discovery bootnode with a full Reth seed node on the same seed port and same node key:

reth node \
  --chain ./genesis.json \
  --datadir ./seed-node \
  --p2p-secret-key ./nodekey \
  --port <SEED_P2P_PORT> \
  --discovery.port <SEED_DISCOVERY_PORT> \
  --nat extip:<SEED_EXTERNAL_IP> \
  --bootnodes "<KNOWN_FULL_NODE_ENODES>" \
  --trusted-peers "<KNOWN_FULL_NODE_ENODES>" \
  --disable-dns-discovery \
  --http \
  --http.addr 127.0.0.1 \
  --http.port <LOCAL_HTTP_PORT> \
  --http.api "admin,eth,net,web3,rpc,reth" \
  --authrpc.jwtsecret ./jwtsecret

The idea is that this seed would provide both UDP discovery and real TCP/RLPx peering, instead of being a discovery-only service.

Is this the recommended approach for a robust private Reth network?

[cookesan]

Use reth p2p bootnode as a discovery seed, not as the full execution peer.

The command is explicitly a "discovery only bootnode": it starts discv4 and optionally discv5 and logs discovered peers. A normal reth node still builds the full network stack from --bootnodes, trusted peers, listener address, chain/network id, etc. The eth handshake then validates fork compatibility.

So the pattern you saw is expected: UDP discovery can go to the bootnode while the TCP/RLPx peer is another full Reth node. For a classroom private PoS network, a dedicated bootnode is fine for discovery, but keep at least one always-on full node as a seed/trusted peer if you want deterministic peer counts and easier debugging. Also avoid mixing very old and new Reth builds unless you are deliberately testing version skew.