Expose leaf node data#3
Conversation
|
@roysc can you rebase vulcanize:master, so that this PR is a bit cleaner. |
|
Nvm I rebased vulcanize:master, can you rebase roysc:cosmos-get-leaf? Thanks! |
i-norden
left a comment
i-norden
left a comment
There was a problem hiding this comment.
Now that I think about it, I think we should open this PR against something other than our master branch as we should keep that even with the upstream repo's master branch. When you get the chance rebase roysc:cosmos-get-leaf onto master, and then reopen this PR against https://github.com/vulcanize/smt/tree/main
|
|
||
| path := smt.th.path(key) | ||
| currentHash := smt.root | ||
| for i := 0; i < smt.depth(); i++ { |
There was a problem hiding this comment.
This is outside the scope of this PR butI wonder if it would be worthwhile to create a secondary index, internal to the SMT, that maps a key/path directly to the associated leaf node so that we don't have to iterate down a branch from the root- performing multiple db lookups- to get to the leaf (or discover it is nonexistent). Or rather than internal to the SMT this could be done similar to the state snapshot in Ethereum: ethereum/go-ethereum#20152, where it is handled at levels above the tree.
|
As discussed here, this PR is probably useless due to the performance cost of accessing the tree and the fact this access pattern likely won't be needed. We should close this and add a way to iterate the SMT. |
2 participants
Expose leaf node data with a
GetLeaf()method.This will allow us to avoid an external hashing step, and use the hashed key (path) and value directly from within a Cosmos KV store.