trie: rename trie helpers to mpt

[gabrocheleau]

This PR improves naming accross the trie and verkle packages so that Trie-related helpers, classes and types are namespaced as MPT/Verkle for clarity.

[jochem-brouwer]

LGTM, great renames!

[holgerd77]

Thanks a lot for all the renamings, that's definitely an improvement! 🤩

I've got two things:

1. Is it just me or do names like ExtensionMPTNode somewhat feel as having the wrong word order? For me MPTExtensionNode would read - somewhat substantially - more natural? Won't die on that hill, but maybe at least if there is a second confirm from someone within the team we might want to adjust?
2. Realized that we now still have a naming mix, lately we named all the SM proof methods with Merkle (getMerkleStateProof, MerkleStateManager,...). I generally think we should align here, also wonder if we would rather want to fully go to Merkle here? You already wrote in your initial comments:

namespaced as MPT/Verkle for clarity

Hmm. Not so consistent when having some second thought. Merkle/Verkle might indeed be the better choice? (I personally think I might also like the reading/sounding of it more, at least in e.g. proof contexts (verifyMPTRangeProof -> verifyMerkleRangeProof), where MerkleProof is the established version already.

Sorry for these annoying comments. 😂 😬

(in case we decide to adjust might (hopefully) be - relatively - simple/quick additional search/replace work)

[jochem-brouwer]

@holgerd77 forwarding this comment (on a open PR :) ), might be relevant: #3719 (comment)

[gabrocheleau]

Thanks a lot for all the renamings, that's definitely an improvement! 🤩

I've got two things:

1. Is it just me or do names like ExtensionMPTNode somewhat feel as having the wrong word order? For me MPTExtensionNode would read - somewhat substantially - more natural? Won't die on that hill, but maybe at least if there is a second confirm from someone within the team we might want to adjust?
2. Realized that we now still have a naming mix, lately we named all the SM proof methods with Merkle (getMerkleStateProof, MerkleStateManager,...). I generally think we should align here, also wonder if we would rather want to fully go to Merkle here? You already wrote in your initial comments:

namespaced as MPT/Verkle for clarity

Hmm. Not so consistent when having some second thought. Merkle/Verkle might indeed be the better choice? (I personally think I might also like the reading/sounding of it more, at least in e.g. proof contexts (verifyMPTRangeProof -> verifyMerkleRangeProof), where MerkleProof is the established version already.

Sorry for these annoying comments. 😂 😬

(in case we decide to adjust might (hopefully) be - relatively - simple/quick additional search/replace work)

All very valid questions!

1. I agree that the naming is somewhat unnatural in some cases. What I wanted to prioritize was consistency, for example by keeping "MPTNode" and "VerkleNode" together. In the case of e.g. ExtensionNode, I also initially wanted to go with MPTExtensionNode rather than ExtensionMPTNode but that led to inconsistencies with other related terminology, for example MPTRawNode felt weird compared to the more natural RawMPTNode. I also am not totally sold either way, but definitely would want to have some consistent naming scheme, and the MPTNode chunk seemed like a good thing to keep consistent when I did the PR.
2. Yeah that's a good point. Concerning the MPT vs. Merkle naming. While Merkle sounds more natural, and is not an acronym, it seems inaccurate to me in some contexts. Would we be comfortable naming things MerkleExtensionNode? The actual data structure is a Merkle Patricia Trie, which substantially differs from a Merkle Tree. However, the MPT data structure can consume "Merkle Proofs" (I've never seen the name "Merkle Patricia Trie Proof"), so there is some benefit to keeping that distinction (MPT vs. Merkle) separate. Also, given the latest verkle discussions, we might see a future with Binary tries. Binary tries are Merkle Trees, so if we've named everything "Merkle", we'll need another round of changes where we distinguish the MPT "merkle tree" from the Binary "merkle tree".

I'll give this some more thought. would be great if others can chime in, so that we take this opportunity and hopefully don't have to change in the future.

[gabrocheleau]

The discussed updates will be done along with the package renaming: #3719