Experiment with new StateManager interface of EthereumJS VM

[holgerd77]

Hi guys, Holger from EthereumJS here. We just released a new version v2.5.0 of the VM with a new (beta labelled) StateManager API which now completely encapsulate all accesses to the trie, goal for a next breaking release is to completely separate StateManager and VM.

Maybe it's worth to experiment with this a bit, I think your trie implementation might be a very interesting use case, would be excited to see to exchange the trie with yours and e.g. see how fast our tests will run or stuff like that. As a mid-term goal it might be also worth to think about supporting your trie implementation in a then separate StateManager repo.

Also circling @mattdean-digicatapult into the conversation, who did all the StateManager refactoring work. Matthew, if you find some time, you might also want to have a closer look how realistic the above scenario is and how well the current API (or this is somewhat more the internal code structure as far as I see) is suited to do such a trie replacement?

Cheers
Holger

[no2chem]

Hi @holgerd77 --- thanks for letting us know. We're definitely open to trying out integrating with the new statemanger API. I'll take a look over the next few days and let you know how it might all fit in.

By the way, the last time I looked at the EthereumJS VM, it seem like it didn't support really old rules, so something like processing blocks 0-1Million in mainnet wasn't possible. Has that changed? I'd be happy to look into re-adding legacy support, as I do need that in my use case.

[mattdean-digicatapult]

@holgerd77, after having a brief look this looks promising. The API is very similar to the current trie, apart from being synchronous, so should drop in quite nicely. The implementation probably won't need the cache used in the ethereumjs-vm stateManager implementation so should end up being quite simple.

[holgerd77]

@no2chem Cool!

Re-adding legacy support on the VM would be great, I already thought on this several times, so if you want to help out there this would be fantastic. The old code is still there (if needed for some inspiration or copy-over, but I am not even sure if this is necessary) and we have got much better structure in place for hardfork separation now. I think in many cases this should probably just be some additional if statements (the most obvious cases for opcodes added), some other stuff might be a bit more complicated and there will also be additional changes on other libraries needed, e.g. difficulty stuff on the block library. But overall, should be very much doable, this would be also valuable for our client project.

@mattdean-digicatapult: Sounds great! 😄

Will also circle in @vpulim here in case he is interested.

[vpulim]

@no2chem That would be awesome if you could add legacy fork branch logic to the VM and block libraries! Also, currently the VM is designed around the assumption that the entire blockchain is part of a single hardfork. We should modify the VM to allow the fork to change on a per-block basis as the blockchain is processed. This shouldn't be too hard I think... just need to change the current hardfork branch logic to use the current block's _common property instead of the VM's _common property.