Module polkadot_sdk_docs::guides::your_first_node

Running the given runtime with a node. No specific consensus mechanism is used at this stage.

Your first Node

In this guide, you will learn how to run a runtime, such as the one created in your_first_runtime, in a node. Within the context of this guide, we will focus on running the runtime with an omni-node. Please first read this page to learn about the OmniNode, and other options when it comes to running a node.

your_first_runtime is a runtime with no consensus related code, and therefore can only be executed with a node that also expects no consensus (sc_consensus_manual_seal). polkadot-omni-node’s --dev-block-time precisely does this.

All of the following steps are coded as unit tests of this module. Please see Source of the page for more information.

Running The Omni Node

Installs

The polkadot-omni-node can either be downloaded from the latest Release of polkadot-sdk, or installed using cargo:

cargo install polkadot-omni-node

Next, we need to install the [chain-spec-builder]. This is the tool that allows us to build chain-specifications, through interacting with the genesis related APIs of the runtime, as described in crate::guides::your_first_runtime.

cargo install staging-chain-spec-builder

The name of the crate is prefixed with staging as the crate name chain-spec-builder on crates.io is already taken and is not controlled by polkadot-sdk developers.

Building Runtime

Next, we need to build the corresponding runtime that we wish to interact with.

cargo build --release -p path-to-runtime

Equivalent code in tests:

Command::new("cargo")
	.arg("build")
	.arg("--release")
	.arg("-p")
	.arg(FIRST_RUNTIME)
	.assert()
	.success();

This creates the wasm file under ./target/{release}/wbuild/release directory.

Building Chain Spec

Next, we can generate the corresponding chain-spec file. For this example, we will use the development (sp_genesis_config::DEVELOPMENT) preset.

Note that we intend to run this chain-spec with polkadot-omni-node, which is tailored for running parachains. This requires the chain-spec to always contain the para_id and a relay_chain fields, which are provided below as CLI arguments.

chain-spec-builder \
	-c <path-to-output> \
	create \
	--para-id 42 \
	--relay-chain dontcare \
	--runtime polkadot_sdk_docs_first_runtime.wasm \
	named-preset development

Equivalent code in tests:

let chain_spec_builder = find_release_binary(&CHAIN_SPEC_BUILDER).unwrap();
let runtime_path = find_wasm(PARA_RUNTIME).unwrap();
let output = "/tmp/demo-chain-spec.json";
Command::new(chain_spec_builder)
	.args(["-c", output])
	.arg("create")
	.args(["--para-id", "1000", "--relay-chain", "dontcare"])
	.args(["-r", runtime_path.to_str().unwrap()])
	.args(["named-preset", "development"])
	.assert()
	.success();
std::fs::remove_file(output).unwrap();

Running polkadot-omni-node

Finally, we can run the node with the generated chain-spec file. We can also specify the block time using the --dev-block-time flag.

polkadot-omni-node \
	--tmp \
	--dev-block-time 1000 \
	--chain <chain_spec_file>.json

Note that we always prefer to use --tmp for testing, as it will save the chain state to a temporary folder, allowing the chain-to be easily restarted without purge-chain. See sc_cli::commands::PurgeChainCmd and sc_cli::commands::RunCmd::tmp for more info.

This will start the node and import the blocks. Note while using --dev-block-time, the node will use the testing-specific manual-seal consensus. This is an efficient way to test the application logic of your runtime, without needing to yet care about consensus, block production, relay-chain and so on.

Next Steps

• See the rest of the steps in crate::reference_docs::omni_node.