You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think we do not loose anything if we also switch on the VM to use the SimpleStateManager as the default one, since in this case the VM is not meant to operate on some state-containing state manager anyhow. This will have a substantial effect on the bundle size for the default VM initalization.
This likely needs some small adjustments like going from throwing for the get/has/setStateRoot methods for the simple state manager to fake ones like (I think?) being done for the RPC state manager, also a bit related is #3546 in this context.
The text was updated successfully, but these errors were encountered:
I think we do not loose anything if we also switch on the VM to use the SimpleStateManager as the default one, since in this case the VM is not meant to operate on some state-containing state manager anyhow. This will have a substantial effect on the bundle size for the default VM initalization.
This likely needs some small adjustments like going from throwing for the get/has/setStateRoot methods for the simple state manager to fake ones like (I think?) being done for the RPC state manager, also a bit related is #3546 in this context.
I have done a simple, naive attempt at this task (switch the VM DefaultStateManager's instantiation to SimpleStateManager). This works for some cases, but not for others.
The main blocker I have run into is that a lot of tests rely on the presence of a trie or (or at least a state root), e.g. runBlock, index.spec.ts, some EIPs, etc.
Of course it is expected that the SimpleStateManager would be limited. A couple of options/improvements that come to mind:
Adjust the concerned tests so that they use a manually instantiated DefaultStateManager instead of the default SimpleStateManager
Adjust the SimpleStateManager so it has some capability to handle stateRoot. I've done that alrady to some extent by copying the behavior we have in the RpcStateManager, but I don't see how much more could be done
We could also add some checks in the VM, for example validating that a proper stateManager (e.g. not the SimpleStateManager) has been provided to perform some actions like runBlock with validation?
I think we do not loose anything if we also switch on the VM to use the
SimpleStateManager
as the default one, since in this case the VM is not meant to operate on some state-containing state manager anyhow. This will have a substantial effect on the bundle size for the default VM initalization.This likely needs some small adjustments like going from throwing for the
get/has/setStateRoot
methods for the simple state manager to fake ones like (I think?) being done for the RPC state manager, also a bit related is #3546 in this context.The text was updated successfully, but these errors were encountered: