-
Notifications
You must be signed in to change notification settings - Fork 35
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
add AggregationTree
#177
add AggregationTree
#177
Conversation
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.
It may be a good time to refactor the MST-related functions inside the utils and turn them into the MST trait. Now, after you have introduced an aggregate tree, some of the functions serve both data structures (the old "mini" tree and the aggregate tree). It would be nice to have them both implementing an "MST" trait that has the default implementation for shared methods like getting the Merkle proof. This way I could simply write some_mst.get_proof(&leaf)
- that's what I expect when working with a language that allows for OOP. Having data structures and functions completely separate is not as intuitive - if I'm a new developer coming to the project, I would have to search for the Merkle proof function to find out that it actually lives in a separate file in a separate module.
See here, for example: https://doc.rust-lang.org/book/ch10-02-traits.html#using-trait-bounds-to-conditionally-implement-methods
@alxkzmn great point! gonna apply the changes |
#172
AggregationMerkleSumTree
data structure tomerkle_sum_tree
moduleMstInclusionProof
starting fromAggregationMerkleSumTree