You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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).
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:
FILL_COST
The text was updated successfully, but these errors were encountered: