From ca37a6412a36d17ea9e3816be538186b06e8e4b8 Mon Sep 17 00:00:00 2001 From: Felix Lange Date: Mon, 16 Jun 2025 23:37:01 +0200 Subject: [PATCH 01/12] WIP --- EIPS/eip-XXXX.md | 93 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 EIPS/eip-XXXX.md diff --git a/EIPS/eip-XXXX.md b/EIPS/eip-XXXX.md new file mode 100644 index 00000000000000..4edb68f8e0ad0b --- /dev/null +++ b/EIPS/eip-XXXX.md @@ -0,0 +1,93 @@ +--- +eip: XXX +title: eth/70 - partial receipt queries +description: Adds a facility for paginating block receipts in the p2p protocol +author: Felix Lange , Jochem Brouwer (@jochem-brouwer), Giulio Rebuffo (@Giulio2002) +discussions-to: +status: Final +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 10MB 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 block 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, ...]]` + +`firstBlockReceiptIndex` specifies an index into the block receipt list of the first +block. For the first block in the list of requested block hashes, the server should omit +receipts up to the given index from the response. + +Downloading block receipts across multiple messages creates new attack surface. In order +to defend against malicious servers trying to overload syncing clients by supplying +oversized receipts across many messages, the client should perform appropriate validation +on block receipt lists in `Receipts` responses: + +- 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 at can +produce at most 30000000/8 = 3.75MB 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 ~80M, the `Receipts` message +could exceed 10MB. Clients typically reject such large messages because their validity can +only be determined after fetching the complete message. + +For a `Receipts` message, the validity of a block receipts list can only be determined +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 is unavoidable since the protocol allows receipt lists of +such size at a high block gas limit. However, we can at least bound the input by applying +sanity checks as recommended in the specifcation 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 From ab53d57f67d02775ab29a5729b3a6dcaee82d0ea Mon Sep 17 00:00:00 2001 From: Felix Lange Date: Mon, 16 Jun 2025 23:42:07 +0200 Subject: [PATCH 02/12] WIP --- EIPS/eip-XXXX.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-XXXX.md b/EIPS/eip-XXXX.md index 4edb68f8e0ad0b..50c1f0e099ad2e 100644 --- a/EIPS/eip-XXXX.md +++ b/EIPS/eip-XXXX.md @@ -66,12 +66,12 @@ receipts list can be much larger. At a block gas limit of ~80M, the `Receipts` m could exceed 10MB. Clients typically reject such large messages because their validity can only be determined after fetching the complete message. -For a `Receipts` message, the validity of a block receipts list can only be determined -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 is unavoidable since the protocol allows receipt lists of -such size at a high block gas limit. However, we can at least bound the input by applying -sanity checks as recommended in the specifcation section. +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 apply an upper bound on the size of the input by +applying sanity checks as recommended in the specifcation section. ## Backwards Compatibility From ddc73639590eab93b6d2a3dc39e3ef824404610d Mon Sep 17 00:00:00 2001 From: Felix Lange Date: Mon, 16 Jun 2025 23:45:29 +0200 Subject: [PATCH 03/12] WIP --- EIPS/eip-XXXX.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-XXXX.md b/EIPS/eip-XXXX.md index 50c1f0e099ad2e..28ce8aa1c4e735 100644 --- a/EIPS/eip-XXXX.md +++ b/EIPS/eip-XXXX.md @@ -45,8 +45,8 @@ receipts up to the given index from the response. Downloading block receipts across multiple messages creates new attack surface. In order to defend against malicious servers trying to overload syncing clients by supplying -oversized receipts across many messages, the client should perform appropriate validation -on block receipt lists in `Receipts` responses: +oversized receipts across many messages, implementations should perform additional +validation for `Receipts` responses: - 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, From ebc27ee106f03492d7351793384af0db8a1f783f Mon Sep 17 00:00:00 2001 From: Felix Lange Date: Mon, 16 Jun 2025 23:52:10 +0200 Subject: [PATCH 04/12] WIP --- EIPS/eip-XXXX.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-XXXX.md b/EIPS/eip-XXXX.md index 28ce8aa1c4e735..226c8985d54526 100644 --- a/EIPS/eip-XXXX.md +++ b/EIPS/eip-XXXX.md @@ -1,6 +1,6 @@ --- eip: XXX -title: eth/70 - partial receipt queries +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: @@ -70,8 +70,8 @@ For a `Receipts` message, each block receipts list is validated by checking the 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 apply an upper bound on the size of the input by -applying sanity checks as recommended in the specifcation section. +block gas limit. However, we can at bound the input size by applying sanity checks as +recommended in the specifcation section. ## Backwards Compatibility From fdcf2f1481d63055cb18c993cb6cec04489c9df9 Mon Sep 17 00:00:00 2001 From: Felix Lange Date: Mon, 16 Jun 2025 23:53:07 +0200 Subject: [PATCH 05/12] WIP --- EIPS/eip-XXXX.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-XXXX.md b/EIPS/eip-XXXX.md index 226c8985d54526..617c626102035f 100644 --- a/EIPS/eip-XXXX.md +++ b/EIPS/eip-XXXX.md @@ -70,8 +70,8 @@ For a `Receipts` message, each block receipts list is validated by checking the 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 bound the input size by applying sanity checks as -recommended in the specifcation section. +block gas limit. However, we can at least bound the input size by applying sanity checks +as recommended in the specification section. ## Backwards Compatibility From d3fbc3a426cc5a9dcf826e96e7823f0cfdbfe125 Mon Sep 17 00:00:00 2001 From: Felix Lange Date: Mon, 16 Jun 2025 23:56:25 +0200 Subject: [PATCH 06/12] WIP --- EIPS/eip-XXXX.md | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/EIPS/eip-XXXX.md b/EIPS/eip-XXXX.md index 617c626102035f..a3012bba3f1009 100644 --- a/EIPS/eip-XXXX.md +++ b/EIPS/eip-XXXX.md @@ -29,8 +29,8 @@ Modify the encoding for receipts in the `Receipts (0x10)` message as follows: - (eth/70): `[request-id: P, lastBlockIncomplete: {0,1}, [[receipt₁, receipt₂], ...]]` -If the `lastBlockIncomplete` flag is set to true (`1`), the last block receipt list does -not contain all receipts of the block, and the client will have to request the remaining +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: @@ -39,14 +39,12 @@ To support such partial queries, we also modify the `GetReceipts (0x0f)` message - (eth/70): `[request-id: P, firstBlockReceiptIndex: P, [blockhash₁: B_32, blockhash₂: B_32, ...]]` -`firstBlockReceiptIndex` specifies an index into the block receipt list of the first -block. For the first block in the list of requested block hashes, the server should omit -receipts up to the given index from the response. +For the first block in the list of requested block hashes, the server should omit receipts +up to the `firstBlockReceiptIndex` from the response. Downloading block receipts across multiple messages creates new attack surface. In order -to defend against malicious servers trying to overload syncing clients by supplying -oversized receipts across many messages, implementations should perform additional -validation for `Receipts` responses: +to defend against malicious servers trying to overload syncing clients, implementations +should perform additional validation for `Receipts` responses: - 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, @@ -55,16 +53,16 @@ validation for `Receipts` responses: ## 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 at can produce at most 30000000/8 = 3.75MB 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 ~80M, the `Receipts` message -could exceed 10MB. Clients typically reject such large messages because their validity can -only be determined after fetching the complete message. +could exceed 10MB. 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 From 2b0b75686d00fa5eda8bbb29a38192bc02eb2355 Mon Sep 17 00:00:00 2001 From: Felix Lange Date: Tue, 17 Jun 2025 00:49:03 +0200 Subject: [PATCH 07/12] WIP --- EIPS/eip-XXXX.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-XXXX.md b/EIPS/eip-XXXX.md index a3012bba3f1009..d6f3be00fe7c73 100644 --- a/EIPS/eip-XXXX.md +++ b/EIPS/eip-XXXX.md @@ -56,7 +56,7 @@ should perform additional validation for `Receipts` responses: 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 at can +transaction receipt will always be limited in size. Specifically, a transaction can produce at most 30000000/8 = 3.75MB of log data. However, a block can contain contain multiple transactions, and thus the entire block From 10766f14bc44c9f1bc2c9ee3da0a2b511e25ab63 Mon Sep 17 00:00:00 2001 From: Felix Lange Date: Wed, 18 Jun 2025 12:47:35 +0200 Subject: [PATCH 08/12] Update EIPS/eip-XXXX.md Co-authored-by: Jochem Brouwer --- EIPS/eip-XXXX.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-XXXX.md b/EIPS/eip-XXXX.md index d6f3be00fe7c73..53a4ed1462cc81 100644 --- a/EIPS/eip-XXXX.md +++ b/EIPS/eip-XXXX.md @@ -4,7 +4,7 @@ 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: -status: Final +status: Draft type: Standards Track category: Networking created: 2025-06-16 From e7a90cc5f497334ef25b43f1e979aa50ae3b950c Mon Sep 17 00:00:00 2001 From: Felix Lange Date: Wed, 18 Jun 2025 14:00:01 +0200 Subject: [PATCH 09/12] 7975 --- EIPS/{eip-XXXX.md => eip-7975.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename EIPS/{eip-XXXX.md => eip-7975.md} (100%) diff --git a/EIPS/eip-XXXX.md b/EIPS/eip-7975.md similarity index 100% rename from EIPS/eip-XXXX.md rename to EIPS/eip-7975.md From 3f9b7d45eaa6b7dd42abb0de1217a844707877a7 Mon Sep 17 00:00:00 2001 From: Felix Lange Date: Wed, 18 Jun 2025 14:00:36 +0200 Subject: [PATCH 10/12] 7975 --- EIPS/eip-7975.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7975.md b/EIPS/eip-7975.md index 53a4ed1462cc81..156fabdf121862 100644 --- a/EIPS/eip-7975.md +++ b/EIPS/eip-7975.md @@ -1,5 +1,5 @@ --- -eip: XXX +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) From 0ac395d9b2a7ba0fe7a5f723aba5006844379ec4 Mon Sep 17 00:00:00 2001 From: Felix Lange Date: Tue, 24 Jun 2025 12:46:10 +0200 Subject: [PATCH 11/12] EIP-7975: updates --- EIPS/eip-7975.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/EIPS/eip-7975.md b/EIPS/eip-7975.md index 156fabdf121862..b12ca775445678 100644 --- a/EIPS/eip-7975.md +++ b/EIPS/eip-7975.md @@ -18,7 +18,7 @@ This EIP modifies the 'eth' p2p protocol to allow requesting partial block recei ## 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 10MB message size +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 @@ -39,29 +39,29 @@ To support such partial queries, we also modify the `GetReceipts (0x0f)` message - (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 should omit receipts +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. In order -to defend against malicious servers trying to overload syncing clients, implementations -should perform additional validation for `Receipts` responses: +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 + - +## 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.75MB of log data. +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 ~80M, the `Receipts` message -could exceed 10MB. Clients typically reject messages above this size because their +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 From 4d4842954bab4eee8956eb954319afbfe533377f Mon Sep 17 00:00:00 2001 From: Felix Lange Date: Tue, 24 Jun 2025 20:02:45 +0200 Subject: [PATCH 12/12] EIP-7975: add discussion link --- EIPS/eip-7975.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-7975.md b/EIPS/eip-7975.md index b12ca775445678..979cbba7665aca 100644 --- a/EIPS/eip-7975.md +++ b/EIPS/eip-7975.md @@ -3,7 +3,7 @@ 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: +discussions-to: https://ethereum-magicians.org/t/eip-7975-eth-70-partial-block-receipt-lists/24658 status: Draft type: Standards Track category: Networking