Easiest way to run with just a runtime

[kianenigma]

It seems like the 'fastest' way to run, given just a .wasm file is still to:

1. populate a config.yaml file
2. pass a --genesis chain_spec.json (which only works in --raw format) which is then used to fetch the code.

Two comments on this:

1. can we simplify this further, such that you can directly put the runtime-path in config.yarml, or your CLI, and that wasm blob will be used?
2. --genesis is somewhat unclear to me. Is it a chain-spec file? and if it defines storage, which one takes precedence over the storage overrides defined in config.yaml?

[xlc]

The thing is a wasm is only the runtime code, it doesn't include other necessary states to operate the chain. There is a new set of runtime API to populate genesis state so we maybe able to use it but it is not yet used as the runtime API wasn't super stable last time I checked.

--genesis is expecting the chain-spec file, that includes genesis storage and other things like chain properties. And the storage override in config.yml can further overrides the fields defined in the chain spec file.

I think one improvement we can do is that to have a special mode that generate the chain spec file using the runtime API if available to avoid require the user to do it with chain spec builder. But that is basically embedding the chain spec builder in Chopsticks, which is fine, but kinda one more duplicated work.

[kianenigma]

--genesis is expecting the chain-spec file, that includes genesis storage and other things like chain properties. And the storage override in config.yml can further overrides the fields defined in the chain spec file.

Got it. Then excuse my nitpicking, but I would have called this --chain or --chain-spec 😁

I think one improvement we can do is that to have a special mode that generate the chain spec file using the runtime API if available to avoid require the user to do it with chain spec builder. But that is basically embedding the chain spec builder in Chopsticks, which is fine, but kinda one more duplicated work.

I agree. I think for Chopsticks using --chain-spec is more or less fine. I am working on paritytech/polkadot-sdk#5117, and in there we can and will provide the option to generate the chain-spec on the fly from --runtime and --preset.

---

FYI, this is my vision for omni-node-driven development. I am completing the steps needed for this + will do some workshops and tutorials on it. Lmk if you have further ideas.

Omni Tutorial

• Grab parachain template, remove node.
• add a custom pallet to it for the sake of fun
  • Run chain-spec-builder, generate spec file
  • Run frame-omni-bencher, generate weights
• Local Testing 'Fake':
  • Run it with the dev-omni-node
  • Run it with chopsticks
• Local Testing 'real':
  • Zombienet + polkadot-parachain + polkadot binaries.
• Remote Testing
  • acquire on-demand coretime on a testnet, run it with polkadot-parachain

[xlc]

#797 will support --chain-spec. anything else needed?

[kianenigma]

Thanks for the quick fix