diff --git a/EIPS/eip-7975.md b/EIPS/eip-7975.md new file mode 100644 index 00000000000000..979cbba7665aca --- /dev/null +++ b/EIPS/eip-7975.md @@ -0,0 +1,91 @@ +--- +eip: 7975 +title: eth/70 - partial block receipt lists +description: Adds a facility for paginating block receipts in the p2p protocol +author: Felix Lange , Jochem Brouwer (@jochem-brouwer), Giulio Rebuffo (@Giulio2002) +discussions-to: https://ethereum-magicians.org/t/eip-7975-eth-70-partial-block-receipt-lists/24658 +status: Draft +type: Standards Track +category: Networking +created: 2025-06-16 +requires: 7642, 7825 +--- + +## 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 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](../LICENSE.md). + +[EIP-7825]: ./eip-7825.md