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: Refactor SecureTrie as an option #2214

Merged
merged 12 commits into from
Aug 23, 2022

Conversation

holgerd77
Copy link
Member

Since both @faustbrian and @jochem-brouwer expressed support for this in some latest discussions this is executing on the SecureTrie refactoring to integrate the secure trie functionality as an option in the base Trie library and with this reduce inheritance complexity and be more flexible regarding the integration of future features.

This is also (obviously) a breaking change, so it needs to be integrated before we do the breaking releases RC versions at the end of the week.

Relatively straight forward up till now, nevertheless 5 secure trie tests still failing, will continue to investigate, if someone spots something let me know.

@codecov
Copy link

codecov bot commented Aug 23, 2022

Codecov Report

Merging #2214 (4bbc4cf) into master (310b9fa) will increase coverage by 1.99%.
The diff coverage is 87.23%.

Impacted file tree graph

Flag Coverage Δ
block 92.98% <ø> (?)
blockchain 88.88% <100.00%> (?)
client 87.00% <50.00%> (?)
common 98.08% <ø> (ø)
devp2p 92.33% <ø> (+0.21%) ⬆️
ethash ∅ <ø> (?)
evm 79.07% <ø> (ø)
rlp ∅ <ø> (∅)
statemanager 88.15% <100.00%> (?)
trie 89.88% <87.34%> (?)
tx 97.98% <ø> (?)
util 92.33% <ø> (ø)
vm 85.24% <ø> (?)

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

@faustbrian
Copy link
Contributor

@holgerd77 16b299e this fixes all but 1 failing test

@holgerd77
Copy link
Member Author

@holgerd77 16b299e this fixes all but 1 failing test

Ah, please wait with pushing, I have a lot of local commits and fixes as well.

@holgerd77 holgerd77 force-pushed the refactore-secure-trie-as-an-option branch from 16b299e to 31f89cb Compare August 23, 2022 12:11
@holgerd77
Copy link
Member Author

@faustbrian haha, have completely forgotten all the other libraries, lol. 😜

Will continue and do the upstream fixes as well (this worked for so long since I deleted SecureTrie relatively late in the process).

@faustbrian
Copy link
Contributor

faustbrian commented Aug 23, 2022

@holgerd77 I pushed a change to rename secure to useHashedKeys because it's more explicit and the use prefix allows us to indicate that it performs some function. We could then also introduce useCheckpoints for example.

@holgerd77
Copy link
Member Author

@holgerd77 I pushed a change to rename secure to useHashedKeys because it's more explicit and the use prefix allows us to indicate that it performs some function. We could then also introduce useCheckpoints for example.

Argh, this parallel library fixing makes me a bit crazy, since I was locally also doing work. 🙂

I leave it over to you then. Can you please do the upstream library fixes as well then, I had this partly done locally but likely easier to just go over it once again with the renamed option.

I am generally ok, with the renaming, makes sense.

@faustbrian faustbrian force-pushed the refactore-secure-trie-as-an-option branch 2 times, most recently from 6a821ef to 925469b Compare August 23, 2022 13:17
@holgerd77
Copy link
Member Author

holgerd77 commented Aug 23, 2022

Hmm, with Checkpointing, I am a bit drawn back and forth if it might be worth to think about an integration as well or if this is getting a bit insanely last-minute? 🤔

On the other hand this is not too much code to integrate (if we generally agree that this is a good idea).

I wondered if we could (would want) eventually just plainly integrate and completely leaving the option and an associated eventual panelty could be avoided by just creating the CP DB on an eventual first checkpoint() call (that's always the entrypoint, right?) and not already in the constructor.

So all functionality would simply be added and be there, but if people are not calling into anything checkpoint-related they would just have the plain Trie functionality without side effects. I guess this would work, might this be a path to follow? 🤔

@holgerd77
Copy link
Member Author

(did several edits to the previous comment, please read on site)

@faustbrian
Copy link
Contributor

I already have a branch ready for the checkpointing. Just waiting for this to go green so I can merge it into my branch.

@faustbrian
Copy link
Contributor

The implicit behaviour of changing the trie when calling any checkpointing methods is going down the same route as the convoluted implicit behaviour of the root persistence that was reverted 😅

@holgerd77
Copy link
Member Author

I already have a branch ready for the checkpointing. Just waiting for this to go green so I can merge it into my branch.

So what do you think, might it be worth (respectively eventually: better) to plainly do it without any option?

But also curious for your solution, happy to have a look first!

@holgerd77
Copy link
Member Author

The implicit behaviour of changing the trie when calling any checkpointing methods is going down the same route as the convoluted implicit behaviour of the root persistence that was reverted 😅

I think I would disagree, there is nothing implicit here in this case. If checkpointing is used, checkpointing works, that's all. I don't see where the implicit changing/modification of the trie would be.

But also not totally pushing for this solution. Just an additional idea.

@faustbrian
Copy link
Contributor

faustbrian commented Aug 23, 2022

The implicit change is that the underlying storage gets swapped out at runtime after you initialise the trie because DB has to be replaced with CheckpointDB which means your trie starts with this.db instanceof DB but then becomes this.db instanceof CheckpointDB at runtime.

@faustbrian faustbrian force-pushed the refactore-secure-trie-as-an-option branch from 4ec3364 to a50c89c Compare August 23, 2022 13:46
@faustbrian
Copy link
Contributor

@holgerd77 should be ready, all green.

@@ -17,26 +16,9 @@ for (const { constructor, title } of [
constructor: CheckpointTrie,
title: 'CheckpointTrie',
},
{
constructor: SecureTrie,
Copy link
Contributor

Choose a reason for hiding this comment

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

I enabled and fixed these in #2215 together with checkpoint tests.

Copy link
Member Author

@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.

LGTM, will merge when CI passes, eventually someone else can also approve (including @faustbrian) sinc I can't do as PR creator, then I would not have to admin-merge.

@@ -40,7 +40,7 @@ export class VMExecution extends Execution {
super(options)

if (isFalsy(this.config.vm)) {
const trie = new SecureTrie({ db: new LevelDB(this.stateDB) })
const trie = new CheckpointTrie({ db: new LevelDB(this.stateDB), useHashedKeys: true })
Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, really love this new option naming when reading with some distance! 👍

This is so much easier to grasp than having to deal with what a "Secure Trie" is.

@faustbrian faustbrian self-requested a review August 23, 2022 16:08
Copy link
Contributor

@faustbrian faustbrian left a comment

Choose a reason for hiding this comment

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

Looks good other than commented out tests which I've fixed in a separate PR.

@holgerd77 holgerd77 merged commit 241f566 into master Aug 23, 2022
@holgerd77 holgerd77 deleted the refactore-secure-trie-as-an-option branch August 23, 2022 16:10
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.

2 participants