paritytech/cumulus

Run a Cumulus Runtime Without a Relay Chain

Opened this issue · 10 comments

shawntabrizi commented

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 commented

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.

  • 👍3
bkchr commented

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

nuke-web3 commented

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 commented

No, this is not expected to work now.

JoshOrndorff commented

@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 commented

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 commented

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

stechu commented

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

bkchr commented

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.

  • 👍1
JoshOrndorff commented

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