* feat(smt): impl constructing leaves that don't yet exist
This commit implements 'prospective leaf construction' -- computing
sparse Merkle tree leaves for a key-value insertion without actually
performing that insertion.
For SimpleSmt, this is trivial, since the leaf type is simply the value
being inserted.
For the full Smt, the new leaf payload depends on the existing payload
in that leaf. Since almost all leaves are very small, we can just clone
the leaf and modify a copy.
This will allow us to perform more general prospective changes on Merkle
trees.
* feat(smt): export get_value() in the trait
* feat(smt): implement generic prospective insertions
This commit adds two methods to SparseMerkleTree: compute_mutations()
and apply_mutations(), which respectively create and consume a new
MutationSet type. This type represents as set of changes to a
SparseMerkleTree that haven't happened yet, and can be queried on to
ensure a set of insertions result in the correct tree root before
finalizing and committing the mutation.
This is a direct step towards issue 222, and will directly enable
removing Merkle tree clones in miden-node InnerState::apply_block().
As part of this change, SparseMerkleTree now requires its Key to be Ord
and its Leaf to be Clone (both bounds which were already met by existing
implementations). The Ord bound could instead be changed to Eq + Hash,
if MutationSet were changed to use a HashMap instead of a BTreeMap.
* chore(smt): refactor empty node construction to helper function
Returning tuples is often confusing as they don't convey meaning and it
should be used only when there is no possible ambiguity.
For `MerkleStore`, we had a couple of tuples being returned, and reading
the implementation was required in order to distinguish if they were
leaf values or computed roots.
This commit introduces two containers that will self-document these
returns: `RootPath` and `ValuePath`. It will also update `set_node` to
return both the new root & the new path, so we can prevent duplicated
traversals downstream when updating a node (one to update, the second to
fetch the new path/root).
The store builds the path from root to leaf, this updates the code to
return a path from leaf to root, as it is done by the other structures.
This also added custom error for missing root.
Prior to this commit, the MerkleStore panicked under certain bounds. It
will prevent such panics by using checked operations.
ilog2, for instance, will panic when the operand is zero. However, there
is a documentation rule enforcing the merkle tree to be size at least 2.
If this rule is checked, then the panic is impossible.
Prior to this commit, there was an internal procedure with the merkle
trees to compute empty sub-tree for arbitrary depths.
However, this isn't ideal as this code can be reused in any merkle
implementation that uses RPO as backend.
This commit introduces a structure that will generate these empty
subtrees values.
A Merkle path is a vector of nodes, regardless of the Merkle tree
implementation.
This commit introduces an encapsulation for such vector, also to provide
functionality that is common between different algorithms such as
opening verification.
related issue: #36
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