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
The library has several state machines that require providing a HostVmPrototype as part of their configuration, and that drive one or more runtime calls.
However, given that there are several ways to serve the state behind runtime calls, I think that this design was a mistake.
Instead, these state machines should only ask the API user to perform the call:
Transactions validation
Block execution
Authoring a block
Building chain information
I'm not completely sure what to do with the warp syncing state machine, as it does something kind of similar. At the moment I think it could be left as is.
The text was updated successfully, but these errors were encountered:
One issue related to block execution and block authoring is the fact that there's a "new runtime compilation" step.
If the block being verified or authored modifies the code or heappages, we compile the new runtime as one of the steps.
If we change the state machines as proposed by this issue, the API user would either need to do that manually or would need to provide the storage diff to the state machine, neither of which are great solutions.
The library has several state machines that require providing a
HostVmPrototype
as part of their configuration, and that drive one or more runtime calls.However, given that there are several ways to serve the state behind runtime calls, I think that this design was a mistake.
Instead, these state machines should only ask the API user to perform the call:
I'm not completely sure what to do with the warp syncing state machine, as it does something kind of similar. At the moment I think it could be left as is.
The text was updated successfully, but these errors were encountered: