shim: simulate

[pepyakin]

As described here https://github.com/thrumdev/sugondat/issues/24

Mainly it should try to model closely a running sugondat parachain:

• it probably should emulate distinction between finalized and not finalized blocks.
• blobs may take some time to land, but also can land immediatelly.

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 to query, 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

[rphmeier]

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?

[pepyakin]

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.