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:
(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:
- Verify the total number of delivered receipts matches the count of transactions.
- Verify the size of each receipt against the gas limit of the corresponding transaction,
i.e. reject if it is larger than gaslimit/8.
- Verify the total downloaded receipts size is no larger than allowed by the block gas limit.
Rationale
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 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.
