Creating sub-tries now never hashes leaves

[BGluth]

Very straightforward change.

plonky2 seems to always expect that leaf nodes are never hashed out directly. By "directly" I mean if you have a leaf that is never read/written to but is the direct child of a parent that is also not hashed, then if we hash the leaf it may be traversed over and panic. It's not clear to me if this always happens, but I have observed a leaf that had no reads/writes (and was hashed out) be hit by plonky2.

Let me know if this shouldn't be the case in plonky2.

[dvdplm]

The change LGTM, but for the deeper question re plonky2 we'll have to await @Nashtare I think!

[wborgeaud]

Do you have an example of where this happens? In theory, plonky2 should not traverse leafs that aren't used in the txn.
The only case I can think of where this could happen is when deleting a child from a branch node, and the branch node then has only one child, we have to check if the remaining child is a leaf/extension node. But in this case, I think the child should not be hashed anyway.
The PR looks good otherwise.

[BGluth]

@wborgeaud I have one block where this occurs. I'll send you the information to reproduce this.

[BGluth]

Hey @wborgeaud. I may have been wrong regarding plonky2 always requiring the leaf to never be hashed out and potentially misinterpreting what was happening here.

So this change in the PR is actually needed and correct for a different reason. When creating a sub-trie, we pass in a list of keys to not hash. Any nodes in the trie that these keys encounter do not get hashed out. Previously, before this PR, if traversing the trie for a given key encountered a leaf node and the remaining key portion did not match, we did not hash the leaf out. This is actually incorrect behavior, even if the leaf key portions do not match.

The assumption that the sub-trie logic makes is that if some portion of the key does not exist, then it will exist at some point in the future (eg. at the end of the txn) and the entire path of nodes we did encounter must not be hashed out. With the case here for leaf nodes, this also applies, where we need to assume that an incoming write is going to change the trie structure and this leaf must not be hashed out, which is the change that this PR is making.

The same is actually also true for extension nodes, where we always want to not hash an extension node that we encounter, even if the key does not match (I'll get this in in a separate PR with a bunch of other changes).