Skip to content

Conversation

@gurukamath
Copy link
Contributor

(closes #1196 )

What was wrong?

The deposit requests from each transaction were being parsed immediately after that transaction. The specification is to parse the requests after all the transactions. Although this should not be an issue when it comes to the final block processing, it is best to align the EELS code with the spec.

Related to Issue #1196

How was it fixed?

Parse deposit requests at the end of block processing, after all the transactions and withdrawals have been processed.

@gurukamath gurukamath requested a review from SamWilsn April 17, 2025 11:13
Comment on lines 84 to 87
receipts_trie: Trie[Bytes, Optional[Union[Bytes, Receipt]]] = field(
default_factory=lambda: Trie(secured=False, default=None)
)
receipts: Tuple[Union[Bytes, Receipt], ...] = field(default_factory=tuple)
Copy link
Contributor

Choose a reason for hiding this comment

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

These seem to store similar data? Can receipts_trie be computed from receipts? Would it be better if Trie exposed a values() -> Iterator function?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

  1. receipts_trie can be computed from the receipts but then that would have to be done outside process_transaction function. However, this moves us away from the idea of packaging up all the transaction related logic in process_transaction

  2. With the data in a Trie stored as _data: Dict[K, V], iterating over the trie does not guarantee the proper order of receipts processing. The order in which receipts are processed matters here. Hence, value() -> Iterator function might not work. Perhaps, moving to OrderedDict might work but we need to look into other consequences that might have.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated to store receipt_keys in a tuple instead of the receipts themselves.

@gurukamath gurukamath force-pushed the deposit-requests-fix branch from 8909997 to 2c893be Compare April 22, 2025 18:08
if index not in receipts_trie._data:
# Meaning the transaction has somehow failed
return receipts
for key in block_output.receipt_keys:
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm getting an AttributeError on this line when I run the tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah. Missed pushing the commit which has the back-ports to older forks. Should be good now

@SamWilsn SamWilsn force-pushed the deposit-requests-fix branch from 9ec8101 to 1f476c9 Compare April 24, 2025 04:11
@SamWilsn SamWilsn merged commit e8b8988 into ethereum:forks/prague Apr 24, 2025
1 of 4 checks passed
Carsons-Eels pushed a commit to Carsons-Eels/execution-specs that referenced this pull request Oct 16, 2025
…ereum#1197)

* fix: broken documentation links have been repaired (issue ethereum#1196)

* Update src/ethereum_test_vm/opcode.py

---------

Co-authored-by: Mario Vega <[email protected]>
danceratopz pushed a commit to danceratopz/execution-specs that referenced this pull request Oct 22, 2025
…ereum#1197)

* fix: broken documentation links have been repaired (issue ethereum#1196)

* Update src/ethereum_test_vm/opcode.py

---------

Co-authored-by: Mario Vega <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants