Add EIP: eth/70 - partial block receipt lists #9906

fjl · 2025-06-16T21:37:26Z

No description provided.

eth-bot · 2025-06-16T21:37:48Z

✅ All reviewers have approved.

jochem-brouwer

Ok gave this some thought, mainly some style things. Also did some brainstorming about possible attack scenarios and possibly a way (if we want) to introduce verification of the partial data 😄 👍

EIPS/eip-XXXX.md

jochem-brouwer · 2025-06-16T22:08:03Z

EIPS/eip-XXXX.md

+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.


I think that only additional checks are necessary if lastBlockIncomplete is true (1), and that these checks should only be applied on the final receipts list in the response, right? For all other entries we can perform the original checks (as are done currently (?)): calculating the receiptsRoot and verify it is correct (and possibly short-circuit this check by first validating if the receipts count equals the transaction count, but this implies we have the block body (from header alone it cannot be derived how much transactions were in the block) which means that the receipts downloader is behind the block body downloader (which is fine))

I changed the text to make this more clear.

jochem-brouwer · 2025-06-16T22:10:40Z

EIPS/eip-XXXX.md

+
+- 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.


It is unclear at this point where the 8 comes from (the reason is introduced in Rationale, absolute minimum cost of this data size in the logs), so should maybe be clarified earlier? 🤔

If we "need" the transaction for this check, it would also mean we should first download the block body and we can then download the receipts (so cannot be done in parallel).

Yes, the restriction on concurrent download is something I need to investigate more during implementation.

jochem-brouwer · 2025-06-16T22:48:10Z

EIPS/eip-XXXX.md

+- 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.


How do we calculate the maximum given the block gas limit? This one is also tricky, since we can effectively spend 20% (due to refund cap of 1/5 https://eips.ethereum.org/EIPS/eip-3529) more than than the reported block gas limit due to refunds. So we have to take into account that the gas limit to calculate this for is 20% more than what is reported in the header.

We know that the max log data size in bytes is block.gasLimit // 8. But we also have to take into account the status value (1 byte) (or state root of 32 bytes for legacy receipts) and the cumulative block gas used which could at most take N times the maximum byte size to encode the block gas limit in. So this gives a max size of the receipts, but only for the flat data of the receipts, not the encoded RLP variant.

I will come up with a more exact formula later when implementing the prototype.

Or if you know what to put here, you can also make a PR to the EIP once this is merged. You are co-author and so you can just update.

jochem-brouwer · 2025-06-16T22:52:18Z

EIPS/eip-XXXX.md

+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


Suggested change

Downloading block receipts across multiple messages creates new attack surface. In order

Downloading block receipts across multiple messages creates new attack surfaces. In order

'attack surface' is a common term, and it just means the places where it can be attacked. So I'm not changing it to plural.

Yes upon re-reading it looks correct and should not change. I should also not suggest things regarding grammar/spelling since English is not my main language 😅

EIPS/eip-XXXX.md

jochem-brouwer · 2025-06-16T23:35:44Z

EIPS/eip-XXXX.md

+
+- (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


Suggested change

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 must omit receipts

Since receipts are unique (due to cumulativeGasUsed) this is technically not a problem, but it would make implementations more complex if we have to deal with the case that the server is sending us receipts which we already have (and thus did not request) 🤔 This also helps to find the position (key) where the receipts should enter the trie, otherwise we have to take all receipts which we have gotten, then sort them by cumulativeGasUsed and then insert them in the trie to calculate the root.

Since receipts are unique (due to cumulativeGasUsed) this is technically not a problem, but it would make implementations more complex if we have to deal with the case that the server is sending us receipts which we already have (and thus did not request) 🤔 This also helps to find the position (key) where the receipts should enter the trie, otherwise we have to take all receipts which we have gotten, then sort them by cumulativeGasUsed and then insert them in the trie to calculate the root.

One thing to note while changing the "should" to "must", it needs to be in capital letters

I have changed the language to make it more clear.

jochem-brouwer · 2025-06-16T23:39:23Z

EIPS/eip-XXXX.md

+
+- (eth/69): `[request-id: P, [[receipt₁, receipt₂], ...]]`
+
+- (eth/70): `[request-id: P, lastBlockIncomplete: {0,1}, [[receipt₁, receipt₂], ...]]`


Do we need to spec behavior if the flag is set incorrectly? If it sends all receipts but marks it as "partial" I think we are still fine (?) and do not have to disconnect. But this would then send a request which would thus yield 0 receipts for the first block... 🤔

I don't think we need to document this case in the EIP. Either way I think it's OK to define it more thoroughly in the spec later. For the EIP, it is more important to document the basic idea of the change.

jochem-brouwer · 2025-06-16T23:41:49Z

EIPS/eip-XXXX.md

+
+- (eth/69): `[request-id: P, [blockhash₁: B_32, blockhash₂: B_32, ...]]`
+
+- (eth/70): `[request-id: P, firstBlockReceiptIndex: P, [blockhash₁: B_32, blockhash₂: B_32, ...]]`


Should we spec behavior if a peer requests firstBlockReceiptIndex which would yield 0 receipts as response (given that the receiptRoot is not the empty list root)? I can't think of a way how this could be malicious (except wasting resources on the receiver).

bomanaps

Use RFC 2119 uppercase keywords where appropriate: MUST, SHOULD, etc.

bomanaps · 2025-06-17T06:22:02Z

EIPS/eip-XXXX.md

+
+- (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


Since receipts are unique (due to cumulativeGasUsed) this is technically not a problem, but it would make implementations more complex if we have to deal with the case that the server is sending us receipts which we already have (and thus did not request) 🤔 This also helps to find the position (key) where the receipts should enter the trie, otherwise we have to take all receipts which we have gotten, then sort them by cumulativeGasUsed and then insert them in the trie to calculate the root.

One thing to note while changing the "should" to "must", it needs to be in capital letters

Co-authored-by: Jochem Brouwer <jochembrouwer96@gmail.com>

lightclient · 2025-06-18T10:47:40Z

EIPS/eip-XXXX.md

@@ -0,0 +1,91 @@
+---
+eip: XXX


github-actions · 2025-06-18T12:13:13Z

The commit 3f9b7d4 (as a parent of 61c13e8) contains errors.
Please inspect the Run Summary for details.

g11tech · 2025-06-23T08:40:49Z

@fjl let know when the issues flagged by bots are resolved and EIP is draft ready

fjl · 2025-06-24T18:16:16Z

@g11tech it should be good now

eth-bot

All Reviewers Have Approved; Performing Automatic Merge...

WIP

ca37a64

fjl requested a review from eth-bot as a code owner June 16, 2025 21:37

github-actions bot added c-new Creates a brand new proposal s-final This EIP is Final t-networking labels Jun 16, 2025

eth-bot added e-consensus Waiting on editor consensus e-review Waiting on editor to review labels Jun 16, 2025

eth-bot changed the title ~~eth/70~~ Add EIP: eth/70 - partial receipt queries Jun 16, 2025

github-actions bot added the w-ci Waiting on CI to pass label Jun 16, 2025

fjl added 3 commits June 16, 2025 23:42

WIP

ab53d57

WIP

ddc7363

WIP

ebc27ee

eth-bot changed the title ~~Add EIP: eth/70 - partial receipt queries~~ Add EIP: eth/70 - partial block receipt lists Jun 16, 2025

WIP

fdcf2f1

github-actions bot added w-ci Waiting on CI to pass and removed w-ci Waiting on CI to pass labels Jun 16, 2025

fjl added 2 commits June 16, 2025 23:56

WIP

d3fbc3a

WIP

2b0b756

jochem-brouwer suggested changes Jun 16, 2025

View reviewed changes

bomanaps reviewed Jun 17, 2025

View reviewed changes

Giulio2002 mentioned this pull request Jun 17, 2025

All Core Devs - Execution (ACDE) #214 (June 19, 2025) ethereum/pm#1569

Closed

Update EIPS/eip-XXXX.md

10766f1

Co-authored-by: Jochem Brouwer <jochembrouwer96@gmail.com>

github-actions bot added the s-draft This EIP is a Draft label Jun 18, 2025

lightclient reviewed Jun 18, 2025

View reviewed changes

EIPS/eip-XXXX.md Outdated

@@ -0,0 +1,91 @@

---

eip: XXX

Copy link

Member

lightclient Jun 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

7975

github-actions bot removed the s-final This EIP is Final label Jun 18, 2025

fjl added 2 commits June 18, 2025 14:01

7975

e7a90cc

7975

3f9b7d4

fjl added 2 commits June 24, 2025 12:46

EIP-7975: updates

0ac395d

EIP-7975: add discussion link

4d48429

github-actions bot removed the w-ci Waiting on CI to pass label Jun 24, 2025

lightclient approved these changes Jun 27, 2025

View reviewed changes

eth-bot enabled auto-merge (squash) June 27, 2025 12:09

eth-bot approved these changes Jun 27, 2025

View reviewed changes

eth-bot merged commit 217c749 into ethereum:master Jun 27, 2025
17 of 18 checks passed

Moameri55 approved these changes Jul 1, 2025

View reviewed changes

	Downloading block receipts across multiple messages creates new attack surface. In order
	Downloading block receipts across multiple messages creates new attack surfaces. In order


		- (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


		- (eth/69): `[request-id: P, [[receipt₁, receipt₂], ...]]`

		- (eth/70): `[request-id: P, lastBlockIncomplete: {0,1}, [[receipt₁, receipt₂], ...]]`


		- (eth/69): `[request-id: P, [blockhash₁: B_32, blockhash₂: B_32, ...]]`

		- (eth/70): `[request-id: P, firstBlockReceiptIndex: P, [blockhash₁: B_32, blockhash₂: B_32, ...]]`

Add EIP: eth/70 - partial block receipt lists #9906

Add EIP: eth/70 - partial block receipt lists #9906

Uh oh!

Conversation

fjl commented Jun 16, 2025

Uh oh!

eth-bot commented Jun 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jochem-brouwer left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jochem-brouwer Jun 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fjl Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bomanaps left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Jun 18, 2025

Uh oh!

g11tech commented Jun 23, 2025

Uh oh!

fjl commented Jun 24, 2025

Uh oh!

eth-bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

eth-bot commented Jun 16, 2025 •

edited

Loading

jochem-brouwer left a comment •

edited

Loading

jochem-brouwer Jun 16, 2025 •

edited

Loading

fjl Jun 24, 2025 •

edited

Loading