Different EL clients have inconsistencies in applying for non-existent blockheaders

[1033309821]

Hi, I'm working on a project to verify that five Ethereum excution clients devp2p network protocol implementations (Geth, Erigon, Nethermind, Besu and Reth) behave consistently with each other.

Steps to reproduce the behaviour

When we were fuzz testing the devp2p/eth68 protocol, we found that if I mutated the packets and sent them to the nodes, they would behave differently. For example, if I mutated the Getblockheaders data when sending it, it is likely that some abnormal values will appear (non-existent block numbers, amount, skip, etc.). In this same situation, different EL clients react differently. Geth and Erigon will not respond to this data or return an empty message, but will not disconnect from the peer. Other clients, Reth, Neth and Besu, will disconnect the peer quickly. The tolerance for this message may be (0-10), and they have very strict protocol verification. This may violate the excution-spec because there should be no difference between their implementations.

System information

• Geth v1.13.8
• Reth v1.1.4
• Erigon v2.60.10
• Nethermind v1.30.3
• Besu-25.2.0

[kilnhast]

hey @fjl can you assign me this task? I would like to work on this.

[fjl]

We maintain a test suite here: https://github.com/ethereum/go-ethereum/blob/master/cmd/devp2p/internal/ethtest/suite.go
Would be nice to add the cases you found into this test suite.

[1033309821]

We maintain a test suite here: https://github.com/ethereum/go-ethereum/blob/master/cmd/devp2p/internal/ethtest/suite.go Would be nice to add the cases you found into this test suite.

Received 🫡 , I have submitted the relevant PR. We also found some interesting issues about DevP2P Testing Suite, which have been put in this issue .
Regarding the use of the simple testing tool we developed, we have also made the same response [Besu].(hyperledger/besu#8445) Thanks Mr. flj, I hope this is helpful to you.

[lightclient]

Closed in #31506, thank you @1033309821 🙏