-
Notifications
You must be signed in to change notification settings - Fork 33
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
feat: add simple sparse merkle tree #27
Conversation
8e68b7d
to
463e90b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Thank you! I left a few small comments inline and have a few general comments as well:
- I am not sure we need a generic version of
SimpleSmt
. Under themerkle
module we place structures which rely onRpo256
as the hash function. Maybe in the future we'll also need other hash functions, but I would rather keep things simple for now and not add features which we might not need to use for a while. - I'd prefer to keep public interfaces as consistent with interfaces for MerkleTree and MerklePathSet as possible. These are all just different variants of advice sets and the more consistent they are, the better. So, ideally, the following methods should look the same across all 3:
a.root()
b.depth()
c.get_node()
d.get_path()
e.get_path()
f.update_leaf()
I like the idea of usingMerklePath
struct - but then we should use it across all 3 consistently. - It is difficult for me to understand performance implications of this structure vs. the one in the original implementation. So, I am thinking we should put together some benchmarks, both for new structure and for the old one and see how they perform. We probably want to measure tree construction times for various fill factors as well as
get_merkle_path()
andupdate_leaf()
functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
In addition to the other comments, I have added just one, a nit in fact, to those.
463e90b
to
406eba5
Compare
Understood! It is indeed not desirable to have a whole new implementation when we will lose compatibility with the AdviceTape interface. I restored the original API and implementation from miden-core and reused the new added tests/bench to not waste the effort. It was actually beneficial because I picked a couple of small nits with the proptest. I'm resolving the old conversations because the PR changed entirely. |
5c2928c
to
253bb23
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Looks good! I left a few small comments inline.
Also, one comment about benchmarks: it might be good to benchmark the get_leaf_path()
and update_leaf()
operations for a couple of different scenarios. Specifically:
- For a tree which is 50% full.
- For a tree which is 1% full.
Also, for tree depth - could we use 20 - or is that too slow?
@bobbinth as for the benches, 20 depth is indeed considerably slow. As for the tree contents, we shouldn't have difference of performance between empty, partially filled and full trees, except for the memory overhead of fetching the nodes/leaves from the internal I'll add these as sanity check. |
Let's keep it at depth 16 then. Agreed that it shouldn't make a difference - but I think a sanity check in this case wouldn't hurt. |
253bb23
to
340b554
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All looks good! Thank you! Just a couple more small nit comments inline.
src/merkle/simple_smt/mod.rs
Outdated
if !self.store.check_leaf_node_exists(key) { | ||
return Err(MerkleError::InvalidIndex(self.depth, key)); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we already do this check in get_path()
, we can probably get rid of it here, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, should have been removed in the last commit. Fixed!
340b554
to
af9fca7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All looks good! Thank you!
af9fca7
to
98155c2
Compare
@bobbinth I pushed another commit to make the bench check for a range of depths and leaves, so I'm requesting your review again |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All looks good! Thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! I left one nit inline for clarity
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thank you! I left one small nit which can be discarded.
Hey @Al-Kindi-0 , I don't see your comment. Is it for the previous storage file? |
This commit moves the previous implementation of `SparseMerkleTree` from miden-core to this crate. It also include a couple of new tests, a bench suite, and a couple of minor fixes. The original API was preserved to maintain compatibility with `AdviceTape`. closes #21
98155c2
to
5fd0d69
Compare
I think it was for some days ago. I see know that it was taken into account so thank you! |
This commit moves the previous implementation of
SparseMerkleTree
frommiden-core to this crate.
It also include a couple of new tests, a bench suite, and a couple of
minor fixes. The original API was preserved to maintain compatibility
with
AdviceTape
.closes #21