EIP-7975 - eth/70 - partial block receipt lists

Created 2025-06-16
Status Draft
Category Networking
Type Standards Track
Authors
Requires

Abstract

This EIP modifies the 'eth' p2p protocol to allow requesting partial block receipt lists.

Motivation

As Ethereum moves toward a higher block gas limit on mainnet, the worst-case total size of a block receipts list also becomes larger, and may eventually exceed the 10MiB message size limit commonly applied in clients. This can lead to sync failures.

Specification

Modify the encoding for receipts in the Receipts (0x10) message as follows:

If the lastBlockIncomplete flag is set to true (1), the last receipt list does not contain all receipts of the block, and the client will have to request the remaining receipts of that block in a new request.

To support such partial queries, we also modify the GetReceipts (0x0f) message:

For the first block in the list of requested block hashes, the server shall omit receipts up to the firstBlockReceiptIndex from the response.

Downloading block receipts across multiple messages creates new attack surface. Partial receipt lists cannot be verified against the block header, so in responses with lastBlockIncomplete = 1, the last receipts list must be validated in a different way:

Rationale

Since EIP-7825 caps the gas limit of a single transaction to 30M gas, a single transaction receipt will always be limited in size. Specifically, a transaction can produce at most 30000000/8 = 3.75MiB of log data.

However, a block can contain contain multiple transactions, and thus the entire block receipts list can be much larger. At a block gas limit of ~83M, the Receipts message could exceed 10MiB. Clients typically reject messages above this size because their validity can only be determined after fetching the complete message.

For a Receipts message, each block receipts list is validated by checking the full list against the tree root stored in the block header. When downloading a paginated list across multiple requests, the client must potentially buffer more than 10MB of unvalidated input. This cannot be avoided, since the protocol allows receipt lists of such size at a high block gas limit. However, we can at least bound the input size by applying sanity checks as recommended in the specification section.

Backwards Compatibility

This EIP changes the eth protocol and requires rolling out a new version, eth/70. Supporting multiple versions of a wire protocol is possible. Rolling out a new version does not break older clients immediately, since they can keep using protocol version eth/69.

This EIP does not change consensus rules of the EVM and does not require a hard fork.

Security Considerations

None

Copyright

Copyright and related rights waived via CC0.