Implement gadgets for append-only MT with rate-3 Rescue #144
Conversation
* Initial commit * structured + impl * Base merkle tree impl * merkle_tree_impl * generic indextype * Refactored code for further SMT impl. * Batch insertion implementation. * Major refactoring & forget implementation. * Remember implemented. * cargo fmt * Big refactor. Leaf now digest index to prevent forge attack. * unit test for Forgettable merkle tree. * cleanup * Clear Arity & replace F::zero() with default() * trait bound refactor * New example. * cargo fmt * More example. * ElementType->Element; rename trait, impl and module; remove missing license check * IndexType refactor * Refactor DigestAlgorithm * Pull out Element,Index,NodeValue as traits; add trait bound to unconstrainted generic struct/fn * Refactor capacity interface * Renaming & better crate import. * var renaming * MerkleProof API refactor Co-authored-by: Alex Xiong <[email protected]>
* A new macro for general merkle tree implementation * Better trait bound for data types * New Universal Merkle tree implementation, including non-membership proof * Better comments for examples.
prelude now includes 2 canonical instantiation of rescue merkle tree.
There was a problem hiding this comment.
Sorry for my late review, but I feel that this PR didn't address the ergonomic issue I raised up in the first place in #88.
other problems include: while our MT impl has become very generic, our gadget is only supports RescueMerkleTree::<F> <-- this is not reflective just from our gadget API.
Concretely, the gadget API can be more intuitive imo. See my comments here: #88 (comment)
| /// Circuit variable for an accumulated element. | ||
| pub struct CommittedElemVar { |
There was a problem hiding this comment.
Is this a good name? what about AccumulatedElemVar? (I'm not sure what does "committed" mean in this context")
Alternatively, I think removing this struct completely is probably also not a bad idea. Sometimes I feel this is an unnecessary abstraction.
|
@alxiong You're right in that it's a gadget very specific for one concrete instantiation of the MT. As discussed here, we are still planning to make it more generic. I think you have a good point in re-opening the issue. This PR was intended more as a refresh of our old MT gadget (which was also for a concrete instantiation of an MT) to match with the new API introduced in Some related tasks:
I guess the above order is only natural given how they depend on one another, with potentially some though on doing 2nd and 3rd in parallel to avoid too much redesign. |
|
I see, makes sense! thanks for the clarification. |
Description
Replacement for #138 after mt-refactor has been merged.
Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
Pendingsection inCHANGELOG.mdFiles changedin the GitHub PR explorer