eth: implement EIP-7975 (eth/70 - partial block receipt lists) #33153

healthykim · 2025-11-11T15:41:09Z

This is a draft PR to add support for EIP-7975.
Overall changes

Each response is buffered in the peer’s receipt buffer when the lastBlockIncomplete field is true.
Continued request uses the same request id of its original request(RequestPartialReceipts).
Partial responses are verified in validateLastBlockReceipt.
Even if all receipts for partial blocks of the request are collected, those partial results are not sinked to the downloader, to avoid complexity. This assumes that partial response and buffering occur only in exceptional cases. (The complexity added to the queue can be checked in 1f32d8959)

fjl · 2025-11-25T16:16:19Z

eth/protocols/eth/peer.go

+			buffer.list = append(buffer.list, packet.List...)
+			buffer.lastLogSize = logSize
+		} else {
+			p.receiptBuffer[requestId] = &partialReceipt{


The peer should not be able to create buffered items for unrequested blocks. So we need to create request ID entries explicitly when the request is made, instead of just making a buffer on demand here.

I added the request tracking here and the validation here.

The buffer is cleared when the request is canceled or completed.

It is also cleared when an empty response is received.

I think we could do this with just one map. Maybe keep an entry in p.receiptBuffer for all requests, even non-partial ones? It seems simpler this way

Yes I changed this, now receiptBuffer stores requested hashes and buffered receipts

fjl · 2025-11-26T11:45:46Z

eth/protocols/eth/peer.go

+			buffer.list = append(buffer.list, packet.List...)
+			buffer.lastLogSize = logSize
+		} else {
+			p.receiptBuffer[requestId] = &partialReceipt{


I think we could do this with just one map. Maybe keep an entry in p.receiptBuffer for all requests, even non-partial ones? It seems simpler this way

eth/protocols/eth/peer.go

fjl · 2025-11-26T11:51:15Z

eth/protocols/eth/peer.go

+
+	// 2. Verify the size of each receipt against the maximum transaction size.
+	for _, rc := range lastReceipts.items {
+		if uint64(len(rc.Logs)) > params.MaxTxGas/params.LogDataGas {


This check is weird. We only added MaxTxGas in the next fork, which has not even activated on mainnet yet, and I'm not sure this limit is always defined in other chains. The check against header gaslimit should be enough.

I am confused here, the check against the header’s gasLimit will always pass if the third condition passes. Or should we remove the second condition?

We agreed to remove condition 2.

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:

It's technically verifiable. The receipts can be proved with a range proof (although I agree there is some complexity around the 0th element whose index is 0x80), any particular reason to not attaching the proof for the paginated receipts?

fjl · 2025-11-27T12:44:29Z

eth/protocols/eth/peer.go

 	reqCancel   chan *cancel   // Dispatch channel to cancel pending requests and untrack them
 	resDispatch chan *response // Dispatch channel to fulfil pending requests and untrack them

+	receiptBuffer map[uint64]*partialReceipt // requestId to receiptlist map


Comment could be improved

I updated the comment to // Previously requested receipts to buffer partial receipts

rjl493456442 · 2025-11-28T07:58:24Z

eth/protocols/eth/handlers.go


+// serviceGetReceiptsQuery70 assembles the response to a receipt query.
+// If the receipts exceed 10 MiB, it trims them and sets the lastBlockIncomplete flag.
+// Indices smaller than firstBlockReceiptIndex are omitted from the first block receipt list.


nitpick, usually we limit the length of comment to 80 chars for better readability.

I updated this. Thank you!

rjl493456442 · 2025-11-28T08:00:49Z

eth/protocols/eth/handlers.go

+
+	for lookups, hash := range query {
+		if bytes >= softResponseLimit || len(receipts) >= maxReceiptsServe ||
+			lookups >= 2*maxReceiptsServe {


this lookup restriction is unnecessary? (similar in eth68, eth69)

the number of requested receipts is already limited by len(receipts) >= maxReceiptsServe?

rjl493456442 · 2025-11-28T14:42:43Z

eth/protocols/eth/dispatcher.go

 	Peer string    // Demultiplexer if cross-peer requests are batched together
 	Sent time.Time // Timestamp when the request was sent
+
+	continued bool


It's not used

I removed this. Thank you!

rjl493456442 · 2025-11-28T14:46:05Z

eth/protocols/eth/peer.go

+	lastReceipt := len(p.receiptBuffer[id].list[lastBlock].items)
+
 	req := &Request{
 		id:   id,


I think the hacky thing in the implementation is we try to reuse the same request ID for the subsequent requests.

How about this: if we detect that the response is incomplete and subsequent requests are required, we internally maintain the mapping between the original request ID and the following IDs, so that the following responses can be correctly detect and be assembled properly?

rjl493456442 · 2025-11-28T14:47:29Z

eth/protocols/eth/peer.go

+	buffer := p.receiptBuffer[requestId]
+
+	// Do not assign buffer to the response not requested
+	if buffer == nil {


I think it's a bit weird to always allocate an item in the receiptBuffer even the first response is complete.

The incomplete response for mega-receipt is not common. I think we should only maintain the additional records for this special case.

I found that the same data (requested hashes) is already stored in dispatcher.go (pending). Can we utilize that?

rjl493456442 · 2025-11-28T14:58:12Z

eth/protocols/eth/peer.go

+
+	// 2. Verify the size of each receipt against the maximum transaction size.
+	for _, rc := range lastReceipts.items {
+		if uint64(len(rc.Logs)) > params.MaxTxGas/params.LogDataGas {


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:

It's technically verifiable. The receipts can be proved with a range proof (although I agree there is some complexity around the 0th element whose index is 0x80), any particular reason to not attaching the proof for the paginated receipts?

healthykim added 7 commits November 8, 2025 17:28

feat: add handleReceipts70

429066f

feat: add handleGetReceipts70

bf16cd5

fix: no lint no life

4c2548e

chore: polish comments

cf48bd5

fix: add tests and fix errors

65debe9

chore: split validation and reconstruct logic

bfc878e

feat: clear buffers if the request is canceled

1f32d89

healthykim changed the title ~~WIP: add eip-7975~~ EIP-7975: eth/70 - partial block receipt lists Nov 15, 2025

healthykim changed the title ~~EIP-7975: eth/70 - partial block receipt lists~~ eth: implement EIP-7975 (eth/70 - partial block receipt lists) Nov 15, 2025

healthykim marked this pull request as ready for review November 18, 2025 13:37

healthykim requested review from fjl and rjl493456442 as code owners November 18, 2025 13:37

fix: remove partial sink

a62ec06

fjl requested changes Nov 25, 2025

View reviewed changes

healthykim added 5 commits November 26, 2025 10:54

test: add suit test

d33276f

fix: add reqeust id validation before the buffer allocation

7d7ff42

chore: change the test name

6a0b36d

fix: fix validation logic and add tests

22ab669

fix: add logic for the buffer clean up

786f876

fjl requested changes Nov 26, 2025

View reviewed changes

fix: remove request buffer

52ede97

fjl reviewed Nov 27, 2025

View reviewed changes

rjl493456442 reviewed Nov 28, 2025

View reviewed changes

healthykim added 3 commits November 29, 2025 00:05

fix: remove second validation

96891be

chore: improve comments

c961983

fix: fix test error

32de571

eth: implement EIP-7975 (eth/70 - partial block receipt lists) #33153

Are you sure you want to change the base?

eth: implement EIP-7975 (eth/70 - partial block receipt lists) #33153

Uh oh!

Conversation

healthykim commented Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

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!

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!

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!

healthykim Nov 28, 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

healthykim commented Nov 11, 2025 •

edited

Loading

healthykim Nov 28, 2025 •

edited

Loading