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

add Getter that bypasses internal nodes #442

Open
gballet opened this issue Jul 18, 2024 · 1 comment
Open

add Getter that bypasses internal nodes #442

gballet opened this issue Jul 18, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@gballet
Copy link
Member

gballet commented Jul 18, 2024

Since verkle uses the path-based storage, it is possible to read the value of a leaf directly. We only need to read the intermediate nodes for updating the commitments... which can be done by a prefetcher.

This might not be useful in most cases as the snapshot is used, but there are several cases where this can make a difference:

  • when checking for FILL_COST
  • when the snapshot is missing
@gballet gballet added the enhancement New feature or request label Jul 18, 2024
@jsign
Copy link
Collaborator

jsign commented Aug 28, 2024

I am leaving here a summary of some side-channel discussion about this.

The way PBSS works is that each node in the tree has a deterministic key depending on where it lives in the tree. If a LeafNode has stem 0xAABBCCDDEE... then the key in the db could be 0xAA, 0xAABB, 0xAABBCC, or similar depending on the depth of its depth in the tree.

This means that at the API level, we can't fetch a leaf node directly without the client providing more information about the node's depth, which doesn't sound viable.

A potential option is that the PBSS key for a LeafNode is the full stem, which:

  • Might reduce disk churn when new internal nodes are created since leaf nodes have a stable key.
  • Require some extra logic to load nodes from internal nodes. To load "the next node", now you'd have two potential options depending on whether the child is an internal or leaf node (since their keys are encoded differently).
    • Option 1: do a double-lookup (which might have a perf hit)
    • Option 2: do some extra data encoding in internal nodes to signal which children are a leaf node (e.g: a bitlist) (which might have a storage overhead)

If reading a leaf node directly is helpful, as mentioned for FILL_COST, or when snapshots aren't available, we probably need to benchmark the mentioned options (or explore others).

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

No branches or pull requests

2 participants