Open pepyakin opened 8 months ago
Can you elaborate a bit more about how the user is meant to submit commands while the simulation is running? Do you imagine there being multiple processes which communicate with each other somehow?
I envision that the user (e.g. rollup dev) would spin up the shim simulator, e.g. by running
shim simulate serve
then would run their rollup
./dn-chain
then the user would interact with the simulation by issuing the commands below.
# submit a blob
shim simulate submit blob.txt
# pause the chain
shim simulate pause
# revert the chain
shim simulate revert 1
Note those commands are fire-and-forget.
Under the hood, the command that is the part of simulate that controls simulation (maybe better described as simctl), must be able to connect to the simulation server, perform a command, and then disconnect (well, unless it's a listener of some kind). That implies that there is some kind of endpoint published by the simulation component that allows controlling the sim. I think normal HTTP/RPC should suffice for that.
I guess one take aways from the issue, is that it's probably not worth it to reuse the existing shim query
subcommand for the same purpose. I mean they do share some similarities, e.g. shim simulate submit
is very similar to shim query submit
, but I believe they are in the end super different.
E.g. shim query revert
doesn't make sense, because a normal RPC node simply doesn't provide such functionality. Also even shim simulate submit
could differ from shim query submit
by simulation specific flags.
As described here https://github.com/thrumdev/sugondat/issues/24
Mainly it should try to model closely a running sugondat parachain:
The user must be able to interact with the simulation somehow. First of all, there must be functionality comparable to
sugondat-shim query
. That is, the user must be able to submit blobs, inspect blobs, inspect the block contents, at the minimum. Optionally, the user must be able to do some advanced manipulations such as revert blocks.Given that, I think we should duplicate the those controls under simulate. E.g.
simulate serve
– starts the simulation. Optionally, provides a way to store the "blockchain" on disk.simulate submit
– similar toquery
, but operates on the simulation and provides additional settings such as inclusion delay.simulate revert
– reverts the simulated blockchain. I guess for simplicity operates on the running simulation as opposed to locally, although that's up for discussion.simulate get-blob