Steps to Reproduce
- Set up a local devnet using Kurtosis
ethereum-package with Besu.
- Connect a custom peer capable of sending batched transactions.
- Send a large number of valid transactions within a single network message:
- Case 1: 100 transactions
- Case 2: 1000 transactions
- Case 3: 10000+ transactions
- Observe the number of transactions that:
- Enter the mempool
- Eventually get included on-chain
Expected behavior: [What you expect to happen]
The client should process all valid transactions in the batch, or enforce a reasonable upper bound that does not significantly degrade transaction propagation. The limit (if any) should be sufficiently high and/or clearly documented.
Actual behavior: [What actually happens]
Besu appears to enforce an upper bound of approximately 200 transactions per batch:
- 100 transactions sent → all processed successfully
- 1000 transactions sent → only the first ~200 transactions are included on-chain
- 10000+ transactions sent → still only ~200 transactions are processed
All remaining transactions in the batch are ignored and do not enter the mempool.
Frequency: [What percentage of the time does it occur?]
100% (consistently reproducible under the same conditions)
Logs
Versions (Add all that apply)
// The ethereum-package network-para.yaml
participants:
- el_type: geth V1.16.2
cl_type: lighthouse V7.0.1
- el_type: nethermind V1.33.0
cl_type: lighthouse V7.0.1
- el_type: reth V1.6.0
cl_type: lighthouse V7.0.1
- el_type: besu V25.8.0
cl_type: lighthouse V7.0.1
- el_type: erigon V3.0.15
cl_type: lighthouse V7.0.1
additional_services:
- dora
- Consensus Client & Version if using Proof of Stake: [e.g. Teku, Lighthouse, Prysm, Nimbus, Lodestar]
This suggests that Besu enforces a relatively strict upper bound on batch transaction processing, which may impact transaction propagation efficiency compared to other clients.
Ref: ethereum/go-ethereum#32723
Steps to Reproduce
ethereum-packagewith Besu.Expected behavior: [What you expect to happen]
The client should process all valid transactions in the batch, or enforce a reasonable upper bound that does not significantly degrade transaction propagation. The limit (if any) should be sufficiently high and/or clearly documented.
Actual behavior: [What actually happens]
Besu appears to enforce an upper bound of approximately 200 transactions per batch:
All remaining transactions in the batch are ignored and do not enter the mempool.
Frequency: [What percentage of the time does it occur?]
100% (consistently reproducible under the same conditions)
Logs
Versions (Add all that apply)
// The ethereum-package network-para.yaml
participants:
cl_type: lighthouse V7.0.1
cl_type: lighthouse V7.0.1
cl_type: lighthouse V7.0.1
cl_type: lighthouse V7.0.1
cl_type: lighthouse V7.0.1
additional_services:
This suggests that Besu enforces a relatively strict upper bound on batch transaction processing, which may impact transaction propagation efficiency compared to other clients.
Ref: ethereum/go-ethereum#32723