feat: add TrieNode trait and related functionality #1363
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
demosdemon
force-pushed
the
brandon.leblanc/trie-node-trait
branch
2 times, most recently
from
e032c28 to
7947e5b
Compare
demosdemon
force-pushed
the
brandon.leblanc/trie-node-trait
branch
from
7947e5b to
945becd
Compare
demosdemon
added a commit
that referenced
this pull request
Oct 15, 2025
Key proofs are a sequence of trie nodes that follow a linear path through the trie. This means we can reconstruct a narrow view of the trie over that linear path. In this narrow view, each node can refer to another full node or just its hash. This resulting trie can (and will in an upcoming change) be hashed to generate the same root hash. While merging with the key-value tries from #1363 and #1365, we can iteratively verify the hash of each layer and detect early if any node is incomplete. The `Remote` edges can also point outside of the key range. We can use these remote edges to identify holes in our overall trie and continue synchronizing down those paths.
demosdemon
added a commit
that referenced
this pull request
Oct 15, 2025
Key proofs are a sequence of trie nodes that follow a linear path through the trie. This means we can reconstruct a narrow view of the trie over that linear path. In this narrow view, each node can refer to another full node or just its hash. This resulting trie can (and will in an upcoming change) be hashed to generate the same root hash. While merging with the key-value tries from #1363 and #1365, we can iteratively verify the hash of each layer and detect early if any node is incomplete. The `Remote` edges can also point outside of the key range. We can use these remote edges to identify holes in our overall trie and continue synchronizing down those paths.
demosdemon
added a commit
that referenced
this pull request
Oct 17, 2025
Key proofs are a sequence of trie nodes that follow a linear path through the trie. This means we can reconstruct a narrow view of the trie over that linear path. In this narrow view, each node can refer to another full node or just its hash. This resulting trie can (and will in an upcoming change) be hashed to generate the same root hash. While merging with the key-value tries from #1363 and #1365, we can iteratively verify the hash of each layer and detect early if any node is incomplete. The `Remote` edges can also point outside of the key range. We can use these remote edges to identify holes in our overall trie and continue synchronizing down those paths.
demosdemon
force-pushed
the
brandon.leblanc/trie-node-trait
branch
from
945becd to
c726158
Compare
rkuris
approved these changes
Oct 22, 2025
Comment on lines
+165
to
+171
| pub fn fork(&mut self) -> PathGuard<'_> { | ||
| PathGuard::new(self.buf) | ||
| } |
There was a problem hiding this comment.
Why isn't this the clone implementation?
There was a problem hiding this comment.
Clone returns the same lifetime and the original type. This returns a new lifetime bound to self.
You also cannot Clone mutable references.
demosdemon
force-pushed
the
brandon.leblanc/trie-node-trait
branch
from
c726158 to
cec42cb
Compare
demosdemon
added a commit
that referenced
this pull request
Oct 29, 2025
Key proofs are a sequence of trie nodes that follow a linear path through the trie. This means we can reconstruct a narrow view of the trie over that linear path. In this narrow view, each node can refer to another full node or just its hash. This resulting trie can (and will in an upcoming change) be hashed to generate the same root hash. While merging with the key-value tries from #1363 and #1365, we can iteratively verify the hash of each layer and detect early if any node is incomplete. The `Remote` edges can also point outside of the key range. We can use these remote edges to identify holes in our overall trie and continue synchronizing down those paths.
`TrieNode` is a generic trait that abstracts over the behavior of nodes in a fixed-arity radix trie. This trait allows for different structures to represent tries while enabling similar operations on them. `TrieNode` is merkle-aware, meaning it can represent nodes that are a mix of locally described children or children referenced by only their hash. This is accomplished through `TrieEdgeState` and is used later in proof verification. The `HashedTrieNode` trait is for post-hashed nodes and is distinctly different from the hash described on `TrieNode`. This trait is intended to represent the computed hash of the node itself; whereas, the hash accessed via `TrieNode` is the hash of a child node as seen from its parent. While they are usually the same, they can differ during intermediate states of a trie or during proof verification when some information is incomplete. `KeyValueTrieRoot` is an implementation of `TrieNode` that only represents a key-value store and is not merkleized. This is really a separate change and is a component of proof verification but is also needed here as it is used to test and verify the iterator.
demosdemon
added a commit
that referenced
this pull request
Oct 29, 2025
Key proofs are a sequence of trie nodes that follow a linear path through the trie. This means we can reconstruct a narrow view of the trie over that linear path. In this narrow view, each node can refer to another full node or just its hash. This resulting trie can (and will in an upcoming change) be hashed to generate the same root hash. While merging with the key-value tries from #1363 and #1365, we can iteratively verify the hash of each layer and detect early if any node is incomplete. The `Remote` edges can also point outside of the key range. We can use these remote edges to identify holes in our overall trie and continue synchronizing down those paths.
demosdemon
force-pushed
the
brandon.leblanc/trie-node-trait
branch
from
cec42cb to
07d7fa5
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TrieNodeis a generic trait that abstracts over the behavior of nodes in a fixed-arity radix trie. This trait allows for different structures to represent tries while enabling similar operations on them.TrieNodeis merkle-aware, meaning it can represent nodes that are a mix of locally described children or children referenced by only their hash. This is accomplished throughTrieEdgeStateand is used later in proof verification.The
HashedTrieNodetrait is for post-hashed nodes and is distinctly different from the hash described onTrieNode. This trait is intended to represent the computed hash of the node itself; whereas, the hash accessed viaTrieNodeis the hash of a child node as seen from its parent. While they are usually the same, they can differ during intermediate states of a trie or during proof verification when some information is incomplete.KeyValueTrieRootis an implementation ofTrieNodethat only represents a key-value store and is not merkleized. This is really a separate change and is a component of proof verification but is also needed here as it is used to test and verify the iterator.