-
Notifications
You must be signed in to change notification settings - Fork 772
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
Define stable API for StateManager #268
Comments
Note: this should probably include making access to the cache ( |
In an ideal world I think the |
Let's push forward towards an ideal world. 😁 Yes, that really makes sense. The |
Not sure if it's just/mainly the lack of code documentation though. |
A little while ago I did some investigation to work out what we might change to make this interface more compact, easier to implement and cleaner in intention. I'll apologise in advance for the size of this post but there's quite a lot to go through. I've got a functioning implementation of most of these changes at https://github.com/mattdean-digicatapult/ethereumjs-vm/tree/stateManagerCleanup-hacks but this is obviously too large to PR. I can rebase this into separate changes as desired, but I thought this could start the discussion. Here we go... Firstly, I believe
Next, are some things that I've noticed are in the current implementation that we might fix to clean things up. Most of these can be done in isolation of one-another.
If we did all of this the documented interface would become:
All this is only my thoughts from playing around with the code. Hopefully some discussion can now help us work to some consensus as to what this interface should look like. |
Hi Matthew, cool that you do such a serious take on this, looking forward to read this! |
Hi Matthew, sorry this got a bit delayed, the day I promised to do the reading I had two 2-line PRs and I didn't expect that to take 3 hours before I started on this. 😄 Will keep on with this though. |
@mattdean-digicatapult Hi Matthew, ok, I am slowly approaching this. Generally I think @cdetrio should join this discussion, since he has already done some StateManager refactoring work and you two might want to coordinate to bring things together. Some first statements on your
Yes.
Yes, that also makes very much sense.
Yes, I'm no complete StateManager expert, but that was also one of my first thoughts when I had a first look. Ideally caching solution probably also should be swappable but that's maybe something for a second round.
Not completely sure or having a strong opinion on this one. |
@mattdean-digicatapult Maybe already do a draft PR with a |
@mattdean-digicatapult I've allowed myself to add numberings to the points you have in your original post for easier reference, hope that was ok. |
Pre-note: will give answers to all of the listed points within this comment and save in between. Please don't read in e-mail but head over to GitHub to have the full list.
I would also feel 80%+ comfortable with the proposed documented interface. |
Hi @mattdean-digicatapult, ok, did a first review of your proposed changes and had some (very first) look into your commits. I think this is generally very much going into the right direction, and from my side I would strongly encourage you to keep on with this work. Will nevertheless be good to have a further opinions on this, hopefully @cdetrio can join the discussion. This is also generally a good time for actually implementing these changes, since atm no other restructuring changes are on the way, so there can be a solid focus on this without a lot of risk with interference with other major refactoring works. |
Hi @holgerd77, thanks for having a look. I'll do a Broadly speaking it seems like we're on the same page so that's good. Regarding point 3, I'm really keen to hide the caching functionality so getting rid of the warm/flush cache functions is important. The exact implementation is what's in question I think. When I was suggesting all methods should be asynchronous, the real benefit is that it allows other |
Hi @mattdean-digicatapult, thanks for the quick response. The topic of promises came up several times lately and I think the transition to a promise-based interface has become common sense in the team to be desirable (please contradict me everyone who is reading this and is of different opinion). |
(we are generally behind throughout whole EthereumJS org with a modern JS code base transition). |
Hi @mattdean-digicatapult, I've lost a bit track, is there a last PR to do for the I am thinking about how to release for some time now, generally I would like to do a somewhat bigger VM release within the next 1-2 weeks or so once we have the last I initially thought to also have the Does this generally make sense? I would have some tendency to remove Would it eventually make sense to integrate the Cheers, hope you recovered (if necessary 😋) well from Devcon! |
@holgerd77, so there is a bit more to do. I've been keeping #309 up to date as I've been doing all this so everything there needs to be merged still. There's also API documentation as well as you mention. I see no reason why all of that cannot be completed in the 1-2 weeks timeline that you've set out. Whether there is an intermediate release or not is up to you guys but it might be a little more conservative and a little safer to do so. I really don't mind either way. Now, whether it's 1 or more PRs somewhat depends on how you feel about what's left. As far as I'm concerned there is:
Regarding point 2, I recently also had to make a change to do with SSTORE calculations for copy: Creates a new instance of the current Incidently, my change here has also fixed one of the remaining |
Ah, didn't know #309 is kept up to date. Just had a look at the scope of changes, I think it should be fine to do this in a single PR, also your reasoning for the different changes sound valid, so please go for it! 😄 |
Awesome, I'm going to add unit tests for the new |
Will close in favor of #503. |
Follow up of #33. Please read that thread properly first.
@kumavis since you had some suggestions, would you have a plan for a nice API?
The text was updated successfully, but these errors were encountered: