try-runtime: RPC endpoint / Node Integration

[kianenigma]

When we do follow-chain, it would be useful to have the basic RPCs implemented and exposed on a specific port, so that you can connect PJS Apps to your fake chain.

An alternative for this is to actually integrate this in the node. #12537 envisioned that you would be able to run a node that is normally syncing, but instead of calling Core_execute_block, it would call into TryRuntime_execute_block. This would give us a fully working client.

[kianenigma]

not sure yet which is worthwhile, if any.

[kianenigma]

atm it has to be either:

• native
• wasm-override

[kianenigma]

the scenario that he is interested in is:

You run execute-block or fast-forward, and once the block have all executed, you want to inspect the state.

one way to approach this is to make try-runtime cli programmable, so you can define more tests to be written, but this is a holy PITA in Rust.

an easier way, which Alan from Moonbeam is also asking is, to make the try-runtime cli capable of implementing a few important RPCs like state_getStorage and so on, and then we query it with Polkadot JS api/apps.

in principle, I think this is not hard, but I have no idea how hard it is.

So, imagine the try-runtime CLI being able to return a value to a subset of the RPC requests, namely all of the ones that can be answered by having a state.

because end of the day, try-runtime-cli is just a wrapper for remote-externalities, which is a "test state".

the problem though is that the underlying remote-ext can have a partial state etc. So there are a lot of edge cases that we may not be able to handle, and developers might confuse themselves.

For example, you would run:

try-runtime fast-forward 1000 --rpc and this will run 1000 empty blocks for you, and the process is still running, hosting an RPC server.

[liamaharon]

Moved: paritytech/try-runtime-cli#9