This EIP modifies the 'eth' p2p protocol to allow requesting partial block receipt lists.
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.
Modify the encoding for receipts in the Receipts (0x10) message as follows:
(eth/69): [request-id: P, [[receipt₁, receipt₂], ...]]
(eth/70): [request-id: P, lastBlockIncomplete: {0,1}, [[receipt₁, receipt₂], ...]]
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:
(eth/69): [request-id: P, [blockhash₁: B_32, blockhash₂: B_32, ...]]
(eth/70): [request-id: P, firstBlockReceiptIndex: P, [blockhash₁: B_32, blockhash₂: B_32, ...]]
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:
Since EIP-7825 caps the gas limit of a single transaction to ~16.7M gas, a single transaction receipt will always be limited in size. Specifically, a transaction can produce at most 16777216/8 = 2MiB 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.
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.
None
Copyright and related rights waived via CC0.