Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

trie: trie package renaming to mpt #3719

Merged
merged 13 commits into from
Oct 7, 2024
Merged

Conversation

gabrocheleau
Copy link
Contributor

This PR renames the trie package to mpt

Copy link
Member

@jochem-brouwer jochem-brouwer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments. We should also update https://github.com/ethereumjs/ethereumjs-monorepo/blob/master/README.md (and update the picture with dependencies to use mpt instead of trie)

@@ -49,7 +49,7 @@
"dependencies": {
"@ethereumjs/common": "^4.4.0",
"@ethereumjs/rlp": "^5.0.2",
"@ethereumjs/trie": "^6.2.1",
"@ethereumjs/mpt": "^6.2.1",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this is clean in the PR, do we want this rename + keep the same version here? 🤔 (I realize that this will likely mean we need a release of the new package though to pass CI - or will this be handled correctly?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought the same, seemed weird not to update the version at all

@@ -65,7 +65,7 @@
"@ethereumjs/evm": "2.1.0",
"@ethereumjs/rlp": "5.0.1",
"@ethereumjs/statemanager": "2.1.0",
"@ethereumjs/trie": "6.0.1",
"@ethereumjs/mpt": "6.0.1",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This points to mpt 6.0.1 which will (likely?) not hit a package at all?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have updated everything to 6.2.2

@@ -1,5 +1,5 @@
import { decodeNode } from '@ethereumjs/mpt'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm upon seeing this I realized that when renaming the MPT methods we might not have renamed them all.

I checked the MPT exports: (might be good to look over those all to see if we can make any improvements here)

{
  createMPT: [Getter],
  createMPTFromProof: [Getter],
  CheckpointDB: [Getter],
  MerklePatriciaTrie: [Getter],
  BranchMPTNode: [Getter],
  ExtensionMPTNode: [Getter],
  LeafMPTNode: [Getter],
  decodeRawNode: [Getter],
  isRawNode: [Getter],
  decodeNode: [Getter],
  verifyMPTProof: [Getter],
  verifyMPTRangeProof: [Getter],
  createMerkleProof: [Getter],
  updateMPTFromMerkleProof: [Getter],
  verifyMerkleProof: [Getter],
  verifyRangeProof: [Getter],
  ROOT_DB_KEY: [Getter],
  hasTerminator: [Getter],
  nibblesToBytes: [Getter],
  hexToKeybytes: [Getter],
  nibblesToCompactBytes: [Getter],
  bytesToNibbles: [Getter],
  compactBytesToNibbles: [Getter],
  nibbleTypeToByteType: [Getter],
  byteTypeToNibbleType: [Getter],
  pathToHexKey: [Getter],
  mergeAndFormatKeyPaths: [Getter],
  genesisStateRoot: [Getter],
  WalkController: [Getter]
}

Suggestions for rename:

decodeRawNode -> decodeRawMPTNode
isRawNode -> isRawMPTNode
decodeNode -> decodeMPTNode

Names which might not be specific enough:

hasTerminator

We also have verifyMerkleProof, createMerkleProof, verifyRangeProof, this starts to get somewhat confusing? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm upon seeing this I realized that when renaming the MPT methods we might not have renamed them all.

I checked the MPT exports: (might be good to look over those all to see if we can make any improvements here)

{
  createMPT: [Getter],
  createMPTFromProof: [Getter],
  CheckpointDB: [Getter],
  MerklePatriciaTrie: [Getter],
  BranchMPTNode: [Getter],
  ExtensionMPTNode: [Getter],
  LeafMPTNode: [Getter],
  decodeRawNode: [Getter],
  isRawNode: [Getter],
  decodeNode: [Getter],
  verifyMPTProof: [Getter],
  verifyMPTRangeProof: [Getter],
  createMerkleProof: [Getter],
  updateMPTFromMerkleProof: [Getter],
  verifyMerkleProof: [Getter],
  verifyRangeProof: [Getter],
  ROOT_DB_KEY: [Getter],
  hasTerminator: [Getter],
  nibblesToBytes: [Getter],
  hexToKeybytes: [Getter],
  nibblesToCompactBytes: [Getter],
  bytesToNibbles: [Getter],
  compactBytesToNibbles: [Getter],
  nibbleTypeToByteType: [Getter],
  byteTypeToNibbleType: [Getter],
  pathToHexKey: [Getter],
  mergeAndFormatKeyPaths: [Getter],
  genesisStateRoot: [Getter],
  WalkController: [Getter]
}

Suggestions for rename:

decodeRawNode -> decodeRawMPTNode isRawNode -> isRawMPTNode decodeNode -> decodeMPTNode

Names which might not be specific enough:

hasTerminator

We also have verifyMerkleProof, createMerkleProof, verifyRangeProof, this starts to get somewhat confusing? 🤔

I have now:

  • Updated all the ones you have suggested
  • Removed the hasTerminator export. It is only used as a helper within the file it's being declared, and it's unlikely that external usage would require such a niche and implementation-specific helper imo.
  • I am currently going through the different methods that have non-mpt names and trying to take this opportunity to make them clearer. Easy example is genesisStateRoot -> genesisMPTStateRoot. The merkle proofs are a bit more tricky since there is some overlap in naming, need to first familiarize myself with what each of them does.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, will take a look. Did you also see Holger's comment on the previously merged PR? :) #3718 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is now in a state where this can be reviewed again. I believe I've gone through all the renamings and made them clearer when possible.

"bugs": {
"url": "https://github.com/ethereumjs/ethereumjs-monorepo/issues?q=is%3Aissue+label%3A%22package%3A+trie%22"
"url": "https://github.com/ethereumjs/ethereumjs-monorepo/issues?q=is%3Aissue+label%3A%22package%3A+mpt%22"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ok, we should remove the package: trie label (or at least add package: mpt label) and update our general issue template to also point to the mpt label and not the trie label.

@ScottyPoi ScottyPoi force-pushed the trie/rename-trie-package-to-mpt branch from 1533156 to f564f41 Compare October 4, 2024 00:42
@jochem-brouwer
Copy link
Member

Side note: for this PR the trie /test trie (required job) is diabled and renamed, so this will need some coordination in order to get this merged (move required job to mpt/ test-mpt (not sure if this name is correct, but retrieved it from the passed CI jobs))

Copy link

codecov bot commented Oct 6, 2024

Codecov Report

Attention: Patch coverage is 0% with 12 lines in your changes missing coverage. Please review.

Project coverage is 6.29%. Comparing base (4470cc3) to head (63f2d1c).
Report is 86 commits behind head on master.

Additional details and impacted files

Impacted file tree graph

Flag Coverage Δ
block ?
client 0.00% <0.00%> (ø)
tx 76.70% <ø> (-1.08%) ⬇️
wallet ?

Flags with carried forward coverage won't be shown. Click here to find out more.

@gabrocheleau
Copy link
Contributor Author

Side note: for this PR the trie /test trie (required job) is diabled and renamed, so this will need some coordination in order to get this merged (move required job to mpt/ test-mpt (not sure if this name is correct, but retrieved it from the passed CI jobs))

Good point!

I do not think I have permission to do this. Neither can I edit the issue template, which should be renamed from trie to mpt. If someone else could handle that, that'd be great. Not sure who has permission aside from @holgerd77

@jochem-brouwer
Copy link
Member

I think Holger is the only person who has admin rights to do so :)

Copy link
Member

@holgerd77 holgerd77 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I am sold on everything, thanks for the extensive answers and continued discussions on how to properly name things! 🤩

I've adjusted the CI mpt/trie thing (also for future runs), browser tests were hanging, seemed unrelated but I have for now deactivated so that we can merge this huge beast in. We should have an eye upon that though and eventually fix on follow-up.

@holgerd77 holgerd77 merged commit 2f70c44 into master Oct 7, 2024
38 of 39 checks passed
@holgerd77 holgerd77 deleted the trie/rename-trie-package-to-mpt branch October 7, 2024 09:11
@holgerd77
Copy link
Member

What's with verifyRangeProof() in proof/range.ts ? 🤔

@gabrocheleau
Copy link
Contributor Author

What's with verifyRangeProof() in proof/range.ts ? 🤔

This one, to my knowledge, is only used internally by the verifyRangeMerkleProof in proof/index.ts, so I opted to leave it as is, but to not expose it externally

@holgerd77
Copy link
Member

At least the proof functionality naming is not consistent yet:

grafik

(or is it in some way I do not grasp?)

@holgerd77
Copy link
Member

Respectively: it's only verifyMPTProof(), which is not yet correct, isn't it?

@holgerd77
Copy link
Member

(in case you do a PR here, can you also update and put the code from proof/index.ts into its own file (I would suggest merkle.ts) and use index.ts only for the exports, as we do by convention? That would be nice! 🙂 )

@gabrocheleau
Copy link
Contributor Author

(in case you do a PR here, can you also update and put the code from proof/index.ts into its own file (I would suggest merkle.ts) and use index.ts only for the exports, as we do by convention? That would be nice! 🙂 )

Done here: #3730

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants