BinaryTrie.GetAccount returned the wrong account data for non-existent
addresses when the trie root was a StemNode (single-account trie). The
StemNode branch directly returned r.Values without verifying that the
queried address's stem matched the node's stem. Similarly, GetStorage
panicked via StemNode.Get("this should not be called directly") when
the root was a StemNode.
Additionally, Empty.GetValuesAtStem returned a non-nil slice of 256
nil entries instead of nil, creating a semantic trap for callers that
check values != nil to determine membership.
Fix all four bug sites:
1. StemNode.Get: replace panic with proper stem verification and value
lookup, matching InternalNode.Get's contract.
2. GetAccount StemNode branch: delegate to GetValuesAtStem (which
already has the stem equality check) instead of accessing r.Values
directly. This is consistent with the InternalNode branch.
3. Empty.GetValuesAtStem: return nil instead of 256 nil values.
Callers (InternalNode.Get, GetAccount) already handle nil correctly.
4. GetAccount: add explicit nil-values guard before the decode logic
as defense-in-depth, and simplify the now-redundant values != nil
condition in the emptyAccount loop.
This is an optimization that existed for verkle and the MPT, but that
got dropped during the rebase.
Mark the nodes that were modified as needing recomputation, and skip the
hash computation if this is not needed. Otherwise, the whole tree is
hashed, which kills performance.
Implement the binary tree as specified in [eip-7864](https://eips.ethereum.org/EIPS/eip-7864).
This will gradually replace verkle trees in the codebase. This is only
running the tests and will not be executed in production, but will help
me rebase some of my work, so that it doesn't bitrot as much.
---------
Signed-off-by: Guillaume Ballet
Co-authored-by: Parithosh Jayanthi <parithosh.jayanthi@ethereum.org>
Co-authored-by: rjl493456442 <garyrong0905@gmail.com>
