Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Easiest way to run with just a runtime #796

Closed
kianenigma opened this issue Jul 30, 2024 · 7 comments
Closed

Easiest way to run with just a runtime #796

kianenigma opened this issue Jul 30, 2024 · 7 comments

Comments

@kianenigma
Copy link

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
Copy link
Member

xlc commented Jul 31, 2024

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
Copy link
Author

--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
Copy link
Member

xlc commented Jul 31, 2024

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

@kianenigma
Copy link
Author

Thanks for the quick fix

@iulianbarbu
Copy link

iulianbarbu commented Nov 27, 2024

I am looking for an easy way to start the parachain-template-runtime from polkadot-sdk/templates. Trying to update the docs with suggestions for runtime development. Couldn't find docs for chopsticks usage with a chain spec. @xlc do you know of any link or some example I can direct people to?

For what is worth, I tried running something like below (where chain_spec.json is raw), but I got an error:

 npx @acala-network/chopsticks --chain-spec chain_spec.json

Error:

Error: Unresolved function `env`:`ext_benchmarking_add_to_whitelist_version_1`
    at Block.call (/home/iulian/.npm/_npx/81ad9c881cb83600/node_modules/@acala-network/chopsticks/node_modules/@acala-network/chopsticks-core/dist/cjs/blockchain/block.js:255:35)
    at async Promise.all (index 0)
    at async buildBlock (/home/iulian/.npm/_npx/81ad9c881cb83600/node_modules/@acala-network/chopsticks/node_modules/@acala-network/chopsticks-core/dist/cjs/blockchain/block-builder.js:225:22)
    at async TxPool.buildBlock (/home/iulian/.npm/_npx/81ad9c881cb83600/node_modules/@acala-network/chopsticks/node_modules/@acala-network/chopsticks-core/dist/cjs/blockchain/txpool.js:344:43)
    at async TxPool.buildBlockIfNeeded (/home/iulian/.npm/_npx/81ad9c881cb83600/node_modules/@acala-network/chopsticks/node_modules/@acala-network/chopsticks-core/dist/cjs/blockchain/txpool.js:328:9)

Do I need a config.yaml also? I haven't created/used one, and I am not sure what it must contain.

@xlc
Copy link
Member

xlc commented Nov 27, 2024

the error is the runtime is built with benchmarking feature, which expects some unimplemented host functions (ext_benchmarking_add_to_whitelist_version_1). you can either built the chain spec without benchmarking feature, or add --allow-unresolved-imports=true to make chopsticks ignore such error

@iulianbarbu
Copy link

Thanks @xlc ! This unblocked me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants