Inconsistent handling of large transaction batches sent in a single P2P message

[bingcicle]

Summary
When we send a single devp2p network message that contains a large batch of regular transactions, execution clients accept and process different maximum counts. Beyond those counts, transactions do not enter the mempool and never make it on-chain.

Observed limits (eventual on-chain inclusion):

Geth: up to 5,120 txs

Nethermind: up to 2,048 txs

Reth: up to 16 txs

Erigon: no practical limit observed (all included, albeit over time)

Besu: up to 200 txs

Steps to reproduce

Spin up a local network via kurtosis using the ethereum-package and the environment below.

From a peer, broadcast a single network message containing N signed, valid, non-conflicting “normal” transactions (tested with 100 / 1,000 / 10,000+).

Observe per-client mempool admission and eventual on-chain inclusion.

Expected result
All valid transactions in the batch are accepted into the mempool and eventually included on-chain.

Actual result:

Reth - Failed — only 16 entered mempool & later on-chain