This commit implements SparseMerkleTree::insert_ensure_root(), a version
of SparseMerkleTree::insert() that prevents modification of the tree if
the insert turns out to not result in the correct tree root (i.e., the
transaction is not valid).
This is an initial step towards issue 222.
As a logical next step, generalizing this to validation of inserting
multiple values at once will directly enable removing Merkle tree clones
in miden-node InnerState::apply_block().
For further work, as we generalize pre-validation for mutations we will
want a separate type to represent an arbitrary set of prospective
mutations on the Merkle tree and their validity, like the `ChangeSet`
type suggested in the issue.
This commit implements 'prospective leaf hashing' -- computing what the
hash of a sparse Merkle tree leaf *would* be for a key-value insertion
without actually performing that insertion.
For SimpleSmt, this is trivial, since the leaf hash and its payload are
the same.
For the full Smt, the new leaf payload (and thus, its hash) depend on
the existing payload in that leaf, making the prospective hash logic a
combination of the normal insertion logic and the normal hash logic. But
because we're only interested in the hash and not the intermediate
value, we can skip allocations and sorts for the payload itself.
This commit implements SparseMerkleTree::insert_ensure_root(), a version
of SparseMerkleTree::insert() that prevents modification of the tree if
the insert turns out to not result in the correct tree root (i.e., the
transaction is not valid).
This is an initial step towards issue 222.
As a logical next step, generalizing this to validation of inserting
multiple values at once will directly enable removing Merkle tree clones
in miden-node InnerState::apply_block().
For further work, as we generalize pre-validation for mutations we will
want a separate type to represent an arbitrary set of prospective
mutations on the Merkle tree and their validity, like the `ChangeSet`
type suggested in the issue.
This commit implements SparseMerkleTree::insert_ensure_root(), a version
of SparseMerkleTree::insert() that prevents modification of the tree if
the insert turns out to not result in the correct tree root (i.e., the
transaction is not valid).
This is an initial step towards issue 222.
As a logical next step, generalizing this to validation of inserting
multiple values at once will directly enable removing Merkle tree clones
in miden-node InnerState::apply_block().
For further work, as we generalize pre-validation for mutations we will
want a separate type to represent an arbitrary set of prospective
mutations on the Merkle tree and their validity, like the `ChangeSet`
type suggested in the issue.
This commit implements SparseMerkleTree::insert_ensure_root(), a version
of SparseMerkleTree::insert() that prevents modification of the tree if
the insert turns out to not result in the correct tree root (i.e., the
transaction is not valid).
This is an initial step towards issue 222.
As a logical next step, generalizing this to validation of inserting
multiple values at once will directly enable removing Merkle tree clones
in miden-node InnerState::apply_block().
For further work, as we generalize pre-validation for mutations we will
want a separate type to represent an arbitrary set of prospective
mutations on the Merkle tree and their validity, like the `ChangeSet`
type suggested in the issue.
This commit implements SparseMerkleTree::insert_ensure_root(), a version
of SparseMerkleTree::insert() that prevents modification of the tree if
the insert turns out to not result in the correct tree root (i.e., the
transaction is not valid).
This is a step towards issue 222, and an immediate step towards
0xPolygonMiden/miden-node issue 149.
Future work: as we generalize pre-validation for other mutations we will
likely want a separate type to represent prospective mutations on the
Merkle tree and their validity, (like the `ChangeSet` type suggested in
the issue).
This commit implements 'prospective leaf hashing' -- computing what the
hash of a sparse Merkle tree leaf *would* be for a key-value insertion
without actually performing that insertion.
For SimpleSmt, this is trivial, since the leaf hash and its payload are
the same.
For the full Smt, the new leaf payload (and thus, its hash) depend on
the existing payload in that leaf, making the prospective hash logic a
combination of the normal insertion logic and the normal hash logic. But
because we're only interested in the hash and not the intermediate
value, we can skip allocations and sorts for the payload itself.
This commit implements 'prospective leaf hashing' -- computing what the
hash of a sparse Merkle tree leaf *would* be for a key-value insertion
without actually performing that insertion.
For SimpleSmt, this is trivial, since the leaf hash and its payload are
the same.
For the full Smt, the new leaf payload (and thus, its hash) depend on
the existing payload in that leaf, making the prospective hash logic a
combination of the normal insertion logic and the normal hash logic. But
because we're only interested in the hash and not the intermediate
value, we can skip allocations and sorts for the payload itself.
This commit implements 'prospective leaf hashing' -- computing what the
hash of a sparse Merkle tree leaf *would* be for a key-value insertion
without actually performing that insertion.
For SimpleSmt, this is trivial, since the leaf hash and its payload are
the same.
For the full Smt, the new leaf payload (and thus, its hash) depend on
the existing payload in that leaf, making the prospective hash logic a
combination of the normal insertion logic and the normal hash logic. But
because we're only interested in the hash and not the intermediate
value, we can skip allocations and sorts for the payload itself.
This commit implements 'prospective leaf hashing' -- computing what the
hash of a sparse Merkle tree leaf *would* be for a key-value insertion
without actually performing that insertion.
For SimpleSmt, this is trivial, since the leaf hash and its payload are
the same.
For the full Smt, the new leaf payload (and thus, its hash) depend on
the existing payload in that leaf, making the prospective hash logic a
combination of the normal insertion logic and the normal hash logic. But
because we're only interested in the hash and not the intermediate
value, we can skip allocations and sorts for the payload itself.
