Sparse Merkle Tree & MerkleInclusionQuantifier #403
Conversation
Yep! DB is the way to go. We can for sure use an in-memory DB if we need extra performance so you’re totally right that we might as well implement as a DB. The state will likely grow very large so some sort of in-memory cache could make sense even if in the long term when we have too much state to fit in RAM. |
…y locating it in the tree
willmeister
force-pushed
the
feat/386/MerkleInclusionQuantifier
branch
from
b94df81
to
b75eccf
Compare
willmeister
changed the title
|
Oh btw one thing that would be very interesting is if you could benchmark this! Basically insert random keys using a tree of height 160 or so & see how many inserts we can do per second |
| * if data exists at the key. | ||
| */ | ||
| export class MerkleInclusionQuantifier implements Quantifier { | ||
| public constructor(private readonly tree: MerkleTree) {} |
There was a problem hiding this comment.
So it's interesting that we pass a tree into the constructor, but then also we query the root--as intuitively "a merkle tree' has just one unique root. I guess this is because the MerkleTree values can be updated. I wonder if we should specify that the tree class is dynamic?
There was a problem hiding this comment.
The MerkleTree interface specifies that itself, no?
There was a problem hiding this comment.
Oh totally--I guess I was just saying we could consider naming the interface UpdateableMerkleTree or something of the like. Not sure it's worth the verbosity though, you're right that that is apparent when you check the interface (which is pretty concise)
packages/core/test/app/ovm/quantifiers/merkle-inclusion-quantifier.spec.ts
Outdated
Show resolved
Hide resolved
Description
Implements a Sparse Merkle Tree and MerkleInclusionQuantifier using it.
Metadata
Fixes
Contributing Agreement