Run a Cumulus Runtime Without a Relay Chain

[shawntabrizi]

For some testing and development purposes, it would be nice to be able to run a cumulus node with a cumulus runtime without needing to set up a whole Polkadot test network.

Imagine doing development against the runtime and wanting to simply test some single-chain logic, or building UIs and such where you just need to connect to a running node.

[JoshOrndorff]

Moonbeam has a dev-service that does this.

First we mock the parachain inherent https://github.com/PureStake/moonbeam/blob/master/node/service/src/inherents.rs#L28-L85

Then we construct our service which is compatible with instant seal, manual seal, or fixed-interval block authoring. https://github.com/PureStake/moonbeam/blob/master/node/service/src/lib.rs#L668-L907

If you like this approach, I'd be happy to move the MockValidationDataInherentDataProvider into cumulus.

I'd recommend having a separate binary for this rather than baking into the same existing binary as Moonbeam has done. Better separation of concerns.

[bkchr]

Yeah that goes into a direction of what I also had in my mind

[nuke-web3]

As #484 is now merged, is --dev mode expected to work out of the box for collators to produce blocks?
If so, we can close this issue, and I can create a PR to include this in the https://github.com/substrate-developer-hub/cumulus-workshop/ as an option to do rapid debugging with the https://github.com/substrate-developer-hub/substrate-parachain-template/pulls 😁

[bkchr]

No, this is not expected to work now.

[JoshOrndorff]

@bkchr I could take this issue further. What direction would you prefer.

1. A separate dedicated binary that runs the dev service
2. Extend the existing polkadot-collator binary so that --dev works also
3. Something else?

Moonbeam took option #2, but in hindsight I wish we had taken #1 (better separation of concerns). If they are combined you have to include a select chain rule, possibly a different import queue etc.

Another question to address is what to do in the consensus layer. For some runtimes (Statemine etc) we could use the same Aura client-side worker, but for others (tick, trick, track, etc) we couldn't. In moonbeam we just allowed manual and instant seal. I'm open to your suggestion.

@nukemandan if you want to do this urgently and just don't know how, you can copy how moonbeam did it. https://github.com/PureStake/moonbeam/blob/master/node/service/src/lib.rs#L652-L883

[bkchr]

Hey @JoshOrndorff, sorry for the late answer. I did not yet decided what would be the best way. Sorry.

In the end it needs to be something reusable. polkadot-collator is not what other projects are using, so it is not that important how it is done there.

[nuke-web3]

Checking in on this issue, as there are related requests being surfaced that this will solve 🤞

[stechu]

Also there are some related discussions here: paritytech/polkadot#5201

[bkchr]

Checking in on this issue, as there are related requests being surfaced that this will solve crossed_fingers

Not related in any way to the discussion on stack exchange.

[JoshOrndorff]

We will need paritytech/substrate#11240 to make this meaningful since nearly all parachains use aura.