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

Optimize Initialization Process in Concurrent Merkle Tree #6577

Open
silentEAG opened this issue Apr 14, 2024 · 0 comments
Open

Optimize Initialization Process in Concurrent Merkle Tree #6577

silentEAG opened this issue Apr 14, 2024 · 0 comments

Comments

@silentEAG
Copy link

Description:

In the file libraries/concurrent-merkle-tree/src/concurrent_merkle_tree.rs at line 109, an empty_node_cache is defined but it is immutable. Even though empty_node_cached generates rightmost_proof and path, it cannot utilize the cache when cache[target] == EMPTY. My understanding is that empty_node_cache should be able to store the results from previous levels and use them for generating the current level, thereby avoiding recursive calls.

Verification:
To verify the issue, insert println!("level: {}", level) in the empty_node_cached func to output the current level. Then, run the following test code:

#[tokio::test(flavor = "multi_thread")]
async fn verify_it() {
    let mut tree1 = ConcurrentMerkleTree::<DEPTH, BUFFER_SIZE>::new();
    let _ = tree1.initialize().unwrap();
}

For better observation of the output, insert a line after each node generation:

for (i, node) in path.iter_mut().enumerate() {
	*node = empty_node_cached::<MAX_DEPTH>(i as u32, &empty_node_cache);
	println!("");
}

When running the cargo test with stdout, you will observe:

level: 0

level: 1
level: 0

level: 2
level: 1
level: 0

level: 3
level: 2
level: 1
level: 0

level: 4
level: 3
level: 2
level: 1
level: 0

...

This pattern introduces an O(n(n+1)/2) computational overhead which is unnecessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
@silentEAG and others