-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cached Trie Updates For In-Memory Chains With >1 Block #7788
Comments
Fixed in #7753. |
It's not, this is for the long term solution/re-enabling of what we disabled in #7753 |
Oh, OK, right nvm. |
I had a pass at this and I made changes to as best as I could understand the problem. I have added in-memory cursor which successfully passes the test @rkrasiuk provided. here is the update trie cursor https://github.com/lakshya-sky/reth/blob/testing-trie-updates/crates/trie/src/trie_cursor/update.rs and the test where I use it: I don't know where should I use this new code to test on a live node! |
I've managed to sync full node Holesky with latest changes, which is running for a day now. But I would like to keep it running to test against reorgs. |
This issue is stale because it has been open for 21 days with no activity. |
closed via transition to new engine |
Context
Trie updates are in-memory state trie diffs that represent trie changes that would occur after committing the block.
reth/crates/trie/src/updates.rs
Lines 45 to 49 in 0231492
Cached trie updates were enabled for in-memory canonical chains for any length since
alpha.14
(#5871). Recently, we discovered that extended trie updates for in-memory chains with >1 block sometimes resulted in an invalid state of the trie (#7559) and disabled it for chains with more than 1 block (#7753). This was in part surfaced by the degraded performance of Engine API message processing with the release of the beta version (issue to be linked).Test Case
Consider the following test:
In the test above account starts off with an empty storage.
In block 1 four account storage slots get modified to a non-zero value which results in the following intermediate nodes:
format:
<trie node key>: <trie node value>
In block 2 storage slot with hash
0x0fab0..
gets zeroed out resulting in no trie updates.Upon extension, trie updates from block 1 will remain in the cache resulting in them being committed to the database.
Final test result - storage root mismatch:
Root Cause
The root cause for this is that root computation does not consider updated nodes from previous computations and only produces trie diffs against the current trie state in the database.
Solutions
Solution 1: Consider only the latest trie updates
Considering that at the moment we rely only on database state trie, the latest (and only the latest) produced trie updates should theoretically be sufficient for updating the trie. This solution needs validation.
Solution 2: Overlay database trie nodes with in-memory ones
Solution 1 still does not allow us to reuse the results of previous state root computations to speed it up for higher in-memory blocks. Another solution would be to create a data structure that would act as an in-memory overlay of the current database trie state akin to how
HashedPostState
is an overlay for database hashed statereth/crates/trie/src/state.rs
Lines 25 to 32 in 0231492
and implement
TrieCursorFactory
for this new structure.reth/crates/trie/src/trie_cursor/mod.rs
Lines 19 to 29 in 0231492
The text was updated successfully, but these errors were encountered: