fix(eth/70): reject null receipt payloads

[BZO95]

Changes

• Reject null receipt entries in eth/70 receipt responses with a SubprotocolException.
• Keep the existing segmented receipt validation path responsible for peer payload shape checks.
• Add coverage for a peer response containing a null receipt payload.

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other: Description

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Notes on testing

• Added Should_reject_null_receipt_payload_when_requesting_from_peer.
• dotnet format whitespace src/Nethermind/ --folder --verify-no-changes --include ... passes for changed files.
• dotnet test --project src/Nethermind/Nethermind.Network.Test/Nethermind.Network.Test.csproj -c release --no-restore passes.

Documentation

Requires documentation update

• Yes
• No

Requires explanation in Release Notes

• Yes
• No

[LukaszRozmej]

@flcl42 can we get partly null-receipts in eth/70?

[LukaszRozmej]

Wire format: the eth/70 receipts payload reuses ReceiptsMessageInnerSerializer69 → ReceiptsMessageSerializer (V63). That legacy serializer can encode both a whole-block null (Rlp.OfEmptyList at the outer level) and an individual receipt null (Rlp.OfEmptyList at the inner level). So the wire format does not structurally forbid a partly-null block array — it can be deserialized.

Protocol semantics (EIP-7975): partial deliveries are contiguous — the peer tells you "I'm giving you receipts starting at firstBlockReceiptIndex, and the last block may be cut off (lastBlockIncomplete)." Sparse / hole-punched receipts inside a single block array are not part of the design — there's no slot in the message format for the receiver to know which transaction indices a null corresponds to, and ValidateBlockReceipts walks the array sequentially under the assumption that index i of blockReceipts corresponds to transaction firstReceiptIndex + i.

Conclusion: no, eth/70 does not allow partly-null receipts. A null at any position is malformed:

• A whole-block null was already caught ("Unexpected null receipt block payload").
• An individual null inside an otherwise-populated block is what the new GetReceipt helper now catches.

So the new check is necessary and correct. The test happens to cover the [null] shape (one block, one receipt), but the same GetReceipt guard fires for [r0, null, r2] — partly-null is covered by the same code path. If you want to make that explicit, you could add a second [TestCase] with TxReceipt[] receipts = [validReceipt, null!], but it's exercising the same branch.

[BZO95]

@flcl42 Done.