Skip to content
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

Sparse Merkle Tree & MerkleInclusionQuantifier #403

Merged

Conversation

@willmeister
Copy link
Collaborator

commented Aug 23, 2019

Description

Implements a Sparse Merkle Tree and MerkleInclusionQuantifier using it.

Metadata

Fixes

Contributing Agreement

@karlfloersch

This comment has been minimized.

Copy link
Contributor

commented Aug 24, 2019

Do we need / want a DB in SMT? If nothing else, we'll need to store nodes in memory, so we can just create an in memory DB, so might as well use a DB, right?

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.

willmeister added 5 commits Aug 28, 2019
…y locating it in the tree
@willmeister willmeister force-pushed the willmeister:feat/386/MerkleInclusionQuantifier branch from b94df81 to b75eccf Aug 29, 2019
willmeister added 3 commits Aug 29, 2019
@willmeister willmeister changed the title [WIP] Sparse Merkle Tree & MerkleInclusionQuantifier Sparse Merkle Tree & MerkleInclusionQuantifier Aug 29, 2019
@karlfloersch

This comment has been minimized.

Copy link
Contributor

commented Aug 30, 2019

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) {}

This comment has been minimized.

Copy link
@ben-chain

ben-chain Aug 30, 2019

Contributor

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?

This comment has been minimized.

Copy link
@willmeister

willmeister Aug 30, 2019

Author Collaborator

The MerkleTree interface specifies that itself, no?

This comment has been minimized.

Copy link
@ben-chain

ben-chain Aug 30, 2019

Contributor

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)

Copy link
Contributor

left a comment

Left a couple of comments/questions, but this is looking DOPE 😃

Copy link
Contributor

left a comment

LGTM--I think the naming thing is fine, let's get it!!! 😃🌈

@willmeister willmeister merged commit df4e7d2 into plasma-group:master Aug 30, 2019
2 checks passed
2 checks passed
Codacy/PR Quality Review Up to standards. A positive pull request.
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@willmeister willmeister deleted the willmeister:feat/386/MerkleInclusionQuantifier branch Aug 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.