implement an Smt with a HistoricalView
to look back
#541
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Describe your changes
Continuation of 0xMiden/miden-node#1229 without the operational issues of being out-of-crate.
First piece of part 3 of 0xMiden/miden-node#1185
Approach
The current approach is to track inverted
MutationSet
s in addition to the latest version of theSmt
, underpinning anAccountTree
(not part of this implementation.Now we do not store inner nodes, but recalculate them (and cache them) on a per block (= set of overlays) basis. We do this by creating a
HistoricalView
and use dynamic programming (~ish) to use the cache as the walk down the children of a desired node index, part of the merkle path, is done.An additional optimization is performed only checking overlays that actually modify any of the leaves that are able to modify a node index, which is relatively cheap, it's called "poisoning" for now.
Left TODOs
Arc<ReadWriteLock<Cache>>
for sharing the same cache for multiple viewsOverlay::new
is missing an implintegration without of scopeAccountTree