Bart c617b7cf4f refactor: Derive a node's position from its path, not a stored ID ...

Responds to review feedback on PR 7942, which asked whether the stored ID could
go away entirely. `NodePathStack` stored a `SHAMapNodeID` beside every node, so
the path carried two answers to "where does this node sit" that could disagree.
The path already answers it: a SHAMap has no path compression, so every nibble
down to a leaf has an inner node of its own and entry `i` sits at depth `i`. The
stack now holds `std::vector<SHAMapTreeNodePtr>` and offers `topDepth()`.

No consumer wanted the ID. Each one wanted a depth and read the nibbles it cared
about from a key it already held, so `selectBranch` gains a depth overload and
the ID-taking one becomes a thin wrapper for the sync paths that hold real IDs.
`unshareNode` takes a depth, since it only ever asked `isRoot()`.
`walkTowardsKey`'s no-stack mode counts a depth rather than advancing an ID.

What a path cannot derive is whether the caller descended the branches it says it
did, so that much is still recorded: one `uint256` of nibbles for the whole path
rather than an ID per entry, and a leaf is still judged against every branch
recorded above it. Judging only the last nibble would have accepted a whole
subtree hung under the wrong branch, since one wrong child pointer leaves every
leaf below it agreeing at its own final nibble.

2026-09-23 21:48:41 +02:00

..

xrpl

refactor: Derive a node's position from its path, not a stored ID

2026-09-23 21:48:41 +02:00