-
Notifications
You must be signed in to change notification settings - Fork 771
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
Conversation
Codecov Report
Flags with carried forward coverage won't be shown. Click here to find out more. |
@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. |
16b299e
to
31f89cb
Compare
@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 |
@holgerd77 I pushed a change to rename |
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. |
6a821ef
to
925469b
Compare
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 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 |
(did several edits to the previous comment, please read on site) |
I already have a branch ready for the checkpointing. Just waiting for this to go green so I can merge it into my branch. |
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 😅 |
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! |
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. |
The implicit change is that the underlying storage gets swapped out at runtime after you initialise the trie because |
4ec3364
to
a50c89c
Compare
@holgerd77 should be ready, all green. |
@@ -17,26 +16,9 @@ for (const { constructor, title } of [ | |||
constructor: CheckpointTrie, | |||
title: 'CheckpointTrie', | |||
}, | |||
{ | |||
constructor: SecureTrie, |
There was a problem hiding this comment.
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.
There was a problem hiding this 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 }) |
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
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 baseTrie
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.