# Node Template The `node-template` program provides a working Substrate node with FRAME system pallets and a subset of additional pallets for working with common blockchain functional operations. With its baseline of functional pallets, the `node-template` serves as a starter kit for building your own blockchain and developing a custom runtime. You can use the `node-template` program to start a Substrate node and to perform the tasks listed in [Subcommands](#subcommands). ### Basic command usage The basic syntax for running `node-template` commands is: ```shell node-template [subcommand] [flags] [options] ``` Depending on the subcommand you specify, additional arguments, options, and flags might apply or be required. To view usage information for a specific `node-template` subcommand, specify the subcommand and the `--help` flag. For example, to see usage information for `node-template key`, you can run the following command: ```shell node-template key --help ``` #### Flags You can use the following optional flags with the `node-template` command. | Flag | Description | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `--alice` | Adds the session keys for the predefined `Alice` account to the local keystore. This flag is equivalent to running the node using `--name alice --validator` as command-line options. | | `--allow-private-ipv4` | Allows the node to connect to private IPv4 addresses. This flag is enabled by default if the chain specifications for the node is identified as `local` or you start the node in development mode with the `--dev` flag. | | `--bob` | Adds the session keys for the predefined `Bob` account to the local keystore. This flag is equivalent to running the node using `--name bob --validator` as command-line options. | | `--charlie` | Adds the session keys for the predefined `Charlie` account to the local keystore. This flag is equivalent to running the node using `--name charlie --validator` as command-line options. | | `--dave` | Adds the session keys for the predefined `Dave` account to the local keystore. This flag is equivalent to running the node using `--name dave --validator` as command-line options. | | `--dev` | Starts the node in development mode in a fresh state. No state is persisted if you run the node using this flag. | | `--disable-log-color` | Disables the use of color in log messages. | | `--disable-log-reloading` | Disables log filter updates and reloading. By default, dynamic log filtering is enabled. However, the feature can affect performance. If you start the node with this flag, the `system_addLogFilter` and `system_resetLogFilter` remote procedure calls have no effect. | | `--discover-local` | Enables peer discovery on local networks. By default, this flag is `true` if you start the node using the `--dev` flag or if the chain specification is `Local` or `Development` and `false` otherwise. | | `--eve` | Adds the session keys for the predefined `Eve` account to the local keystore. This flag is equivalent to running the node using `--name eve --validator` as command-line options. | | `--ferdie` | Adds the session keys for the predefined `Ferdie` account to the local keystore. This flag is equivalent to running the node using `--name ferdie --validator` as command-line options. | | `--force-authoring` | Enables block authoring even if the node is offline. | | `-h`, `--help` | Displays usage information. | | `--ipfs-server` | Joins the IPFS network and serve transactions over bitswap protocol. | | `--kademlia-disjoint-query-paths` | Requires iterative Kademlia distributed hash table (DHT) queries to use disjointed paths. This option increases resiliency in the presence of potentially adversarial nodes. See the S/Kademlia paper for more information on the high level design as well as its security improvements. | | `--no-grandpa` | Disables the GRANDPA voter if the node is running as a validator mode.If the node is not running as a validator, the option disables the GRANDPA observer. | | `--no-mdns` | Disables mDNS discovery. By default, the network uses mDNS to discover other nodes on the local network. This option disables discovery and is automatically applied if you start the node using the `--dev` option. | | `--no-private-ipv4` | Prevents connecting to private IPv4 addresses, unless the address was passed with the `--reserved-nodes` or `--bootnodes` option. This setting is enabled by default for chains that are marked as "live" in their chain specifications. | | `--no-prometheus` | Disables the exposure of a Prometheus endpoint for receiving metrics. By default, metrics are exported to a Prometheus endpoint. | | `--no-telemetry` | Disables connecting to the Substrate telemetry server. Telemetry is enabled for global chains by default. | | `--one` | Provides a shortcut for specifying `--name One --validator` to add session keys for `One` to the keystore. | | `--password-interactive` | Enables you to specify the password for connecting to the keystore interactively in the terminal shell. | | `--prometheus-external` | Exposes the Prometheus exporter on all interfaces. The default is local. | | `--reserved-only` | Specifies whether to only synchronize the chain with reserved nodes. This option also disables automatic peer discovery. TCP connections might still be established with non-reserved nodes. In particular, if you are a validator, your node might still connect to other validator nodes and collator nodes regardless of whether they are defined as reserved nodes. | | `--rpc-external` | Listens to all RPC interfaces. By default, the node only listens to local RPC calls. If you set this command-line option, keep in mind that that not all RPC methods are safe to be exposed publicly. Use an RPC proxy server to filter out dangerous methods. For more information about RPC methods that shouldn't be publicly exposed, see [Remote procedure calls](https://github.com/InfraBlockchainTeam/infrablockspace-docs/blob/master/build/remote-procedure-calls/README.md). Use `--unsafe-rpc-external` to suppress the warning if you understand the risks. | | `--storage-chain` | Enables storage chain mode. If you set this option, each transaction is stored separately in the transaction database column and is only referenced by hash in the block body column. | | `--tmp` | Runs a temporary node. This option creates a temporary directory to store the blockchain configuration, including the node database, node key, and the keystore. | | `--two` | Provides a shortcut for specifying `--name Two --validator` to add session keys for `Two` to the keystore. | | `--unsafe-pruning` | Forces the node to start with unsafe pruning settings. When running as a validator, it is highly recommended to disable state pruning (that is, archive) which is the default. The node will refuse to start as a validator if pruning is enabled unless this option is set. | | `--unsafe-rpc-external` | Listens to all RPC interfaces. This option is the same as `--rpc-external`. | | `--unsafe-ws-external` | Listens to all Websocket interfaces. This option is the same as `--ws-external` but doesn't warn you about it. | | `--validator` | Starts the node with the authority role and enables it to actively participate in any consensus task that it can (for example, depending on availability of local keys). | | `-V`, `--version` | Displays version information. | | `--ws-external` | Listens to all Websocket interfaces. By default, the node only listens locally. Keep in mind that not all RPC methods are safe to be exposed publicly. You can use an RPC proxy server to filter out dangerous methods. You can use `--unsafe-ws-external` to suppress the warning if you understand the risks. | #### Options You can use the following options with the `node-template` command. | Option | Description | | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `-d`, `--base-path ` | Specifies a custom base path. | | `--bootnodes ...` | Specifies a list of boot nodes identifiers for peer-to-peer communication. | | `--chain ` | Specifies the chain specification to use. You can set this option using a predefined chain specification name, such as `dev`, `local`, or `staging`or you can specify the path to a file that contains the chain specification, for example, the chain specification generated by using the `build-spec` subcommand. | | `--database ` | Selects the database backend to use. Valid values are `rocksdb`, `paritydb-experimental`, or `auto`. | | `--db-cache ` | Limits how much memory the database cache can use. | | `--offchain-worker ` | Determines when offchain worker processes are executed. By default, offchain workers are only enabled for nodes that are authoring new blocks and the offchain worker is executed during block validation. Valid values are `Always`, `Never`, or `WhenValidating`. | | `--execution ` | Determines the execution strategy used by all execution contexts. Valid values are `Native`, `Wasm`, `Both` or `NativeElseWasm`. | | `--execution-block-construction ` | Specifies the type of execution used when calling into the runtime to construct blocks. Valid values are `Native`, `Wasm`, `Both`, or `NativeElseWasm`. | | `--execution-import-block ` | Specifies the type of execution used when calling into the runtime to import blocks (including locally-authored blocks). Valid values are `Native`, `Wasm`, `Both`, or `NativeElseWasm`. | | `--execution-offchain-worker ` | Specifies the type of execution used when calling into the runtime to use an offchain worker. Valid values are `Native`, `Wasm`, `Both`, or `NativeElseWasm`. | | `--execution-other ` | Specifies the type of execution used when calling into the runtime while not syncing, importing, or constructing blocks. Valid values are `Native`, `Wasm`, `Both`, or `NativeElseWasm`. | | `--execution-syncing ` | Specifies the type of execution used when calling into the runtime to import blocks as part of an initial synchronization. Valid values are `Native`, `Wasm`, `Both`, or `NativeElseWasm`. | | `--in-peers ` | Specifies the maximum number of incoming connections to accept. The default is 25 peers. | | `--enable-offchain-indexing ` | Enables the offchain indexing API. The offchain indexing API enables the runtime to write directly to a offchain worker database during block import. | | `--ipc-path ` | Specifies the path to send inter-process communication (IPC)to a remote procedure call (RPC) server. | | `--keep-blocks ` | Specifies the number of finalized blocks to keep in the database. The default is to keep all blocks. | | `--keystore-path ` | Specifies the path to a custom keystore. | | `--keystore-uri ` | Specifies a custom URI to connect to for keystore services. | | `--listen-addr ...` | Specifies the address for the node to listen on. By default, if you start a node using the `--validator` option, the addresses `/ip4/0.0.0.0/tcp/` and `/ip6/[::]/tcp/` are used. Otherwise, the `/ip4/0.0.0.0/tcp//ws` and `/ip6/[::]/tcp//ws` addresses are used. | | `-l`, `--log ...` | Sets a custom logging filter. The syntax to use is `=`, for example `-lsync=debug`. The valid log levels from least to most verbose are `error`, `warn`, `info`, `debug`, and `trace`. By default, all targets log `info` level messages. You can set the global log level with `-l`. | | `--max-parallel-downloads ` | Specifies the maximum number of peers from which to ask for the same blocks in parallel. This option allows nodes to download announced blocks from multiple peers. You can decrease the count to reduce traffic, but risk increasing latency. The default is 5 parallel downloads. | | `--max-runtime-instances ` | Specific the maximum size of the instances cache for each runtime. The default value is 8 and values higher than 256 are ignored. | | `--name ` | Specifies the human-readable name for this node. The node name is reported to the telemetry server, if enabled. | | `--node-key ` | Specifies the secret key to use for `libp2p` networking. The value is a string that is parsed based on the `--node-key-type`. For example, if the node key type is `ed25519`, the node key is parsed as a hex-encoded Ed25519 32-byte secret key (64 hex characters). The value of this option takes precedence over `--node-key-file`. Note that secrets provided as command-line arguments are easily exposed. You should only use this option for development and testing. To use an externally managed secret key, use the `--node-key-file` option. | | `--node-key-file ` | Specifies the file that contains the secret key for a node to use for `libp2p` networking. The contents of the file are parsed based on the `--node-key-type`. For example, if the node key type is `ed25519`, the file must contain an unencoded 32-byte or hex-encoded Ed25519 secret key. If the file does not exist, it is created with a newly generated secret key of the type you specify using the `--node-key-type` option. | | `--node-key-type ` | Specifies the type of secret key to use for peer-to-peer (`libp2p`) networking. You can specify the secret key on the command-line using the `--node-key` option, read the key from a file using the `--node-key-file` option, or read the key from a file specifies in the chain-specific `config` directory inside the base directory specified by the `--base-dir` option. If this file does not exist, it is created with a newly generated secret key of the chosen type. The node's secret key determines the public key—the peer identifier—that is used to communicate with the node using the `libp2p` library. The default type is Ed25519. | | `--out-peers ` | Specifies the maximum number of outgoing connections to maintain. The default is 25. | | `--password ` | Specifies the password to use for the keystore. | | `--password-filename ` | Specifies the path to a file that contains the password used for the keystore. | | `--pool-kbytes ` | Specifies the maximum number of kilobytes for all transactions stored in the transaction pool. The default is 20480 KB. | | `--pool-limit ` | Specifies the maximum number of transactions that can be in the transaction pool. The default is 8192 transactions. | | `--port ` | Specifies the TCP port to use for peer-to-peer communication. | | `--prometheus-port ` | Specifies the TCP port to use for the Prometheus exporter service. | | `--pruning ` | Specifies the maximum number of block states to keep or `archive` to keep all block states. If the node is running as a validator, the default is to keep all block states. If the node does not run as a validator, only state for the last 256 blocks is kept. | | `--public-addr ...` | Specifies the public address that other nodes can use to connect to the node. You can use this option to connect to a node through a proxy. | | `--reserved-nodes
...` | Specifies a list of reserved node addresses. | | `--rpc-cors ` | Specifies the browser Origins allowed to access the HTTP and WS RPC servers. You can specify this option as a comma-separated list of origins using `protocol://domain` syntax,`null`, or `all`. A value of `all` disables origin validation. By default, `localhost` and `https://polkadot.js.org` origins are allowed. If you start the node with the `--dev` option, all origins are allowed by default. | | `--rpc-http-threads ` | Specifies the size of the RPC HTTP server thread pool. | | `--rpc-max-payload ` | Sets the the maximum RPC payload size for both requests and responses (both HTTP and web socket), in megabytes. The default is 15 MiB. | | `--rpc-methods ` | Specifies the RPC methods to expose. Valid values are `Unsafe` to expose every RPC method, `Safe` to only exposes a safe subset of RPC methods, denying unsafe RPC methods, or `Auto` to expose `Safe` RPC methods if RPC is served externally, for example if you run the node using `--rpc-external` or `--rpc-external`, or expose `Unsafe` RPC methods if RPC is not served externally. The default is `Auto`. | | `--rpc-port ` | Specifies the TCP port to use for the HTTP RPC server. | | `--state-cache-size ` | Specifies the state cache size. The default is 67108864 bytes. | | `--sync ` | Specifies the blockchain syncing mode Valid values are `Full` to download and validate the full blockchain history, `Fast` to download blocks and the latest state only, or `FastUnsafe`to download the latest state but skip downloading state proofs. The default is `Full`. | | `--telemetry-url ...` | Specifies the URL of the telemetry server to connect to. You can pass this flag multiple times to specify multiple telemetry endpoints. Verbosity levels range from 0-9, with 0 denoting the least verbose. Use the following format to specify the URL followed the verbosity option is `--telemetry-url 'wss://foo/bar 0'`. | | `--tracing-receiver ` | Specifies the receiver to process tracing messages. The default is Log. | | `--tracing-targets ` | Sets a custom profiling filter. Syntax is the same as for logging: `=`. | | `--wasm-execution ` | Specifies the method for executing Wasm runtime code. Valid values are `interpreted`, or `compiled`. The default is `Compiled`. | | `--wasm-runtime-overrides ` | Specifies the path where local WASM runtimes are stored. These runtimes override on-chain runtimes when the version matches. | | `--ws-max-connections ` | Specifies the maximum number of WS RPC server connections. | | `--rpc-port ` | Specifies the TCP port to use for the WebSockets RPC server. | #### Subcommands You can use the following subcommands with the `node-template` command. For reference information and examples that illustrate using these subcommands, select an appropriate command. | Command | Description | | --------------- | ----------------------------------------------------------------------------- | | `benchmark` | Benchmarks runtime pallets. | | `build-spec` | Builds a chain specification. | | `check-block` | Validates blocks. | | `export-blocks` | Exports blocks. | | `export-state` | Exports the state of a given block into a chain specification. | | `help` | Displays usage information for `node-template` or for a specified subcommand. | | `import-blocks` | Imports blocks. | | `key` | Provides local key management utilities. | | `purge-chain` | Removes all chain data. | | `revert` | Reverts the chain to a previous state. | ### benchmark Use the `node-template benchmark` command to analyze the resources required to execute the transactions in extrinsic calls you have configured in runtime pallets. You can analyze individual extrinsic calls in specific pallets or all extrinsic calls in all pallets. With the `benchmark` subcommand, you can use additional command-line options to test different execution scenarios and compare the results. Note that you must compile the node with benchmarking enabled to use all subcommands of `node-template benchmark`. To compile the node with benchmarking features enabled, run the following command: ```shell cargo build --package node-template --release --features runtime-benchmarks ``` **Basic command usage** ```shell node-template benchmark [subcommand] [flags] [options] ``` Depending on the subcommand you specify, additional arguments, options, and flags might apply or be required. To view usage information for a specific `benchmark` subcommand, specify the subcommand and the `--help` flag. For example, to see usage information for `benchmark pallet`, you can run the following command: ```shell node-template benchmark pallet --help ``` **Subcommands** You can use the following subcommands with the `node-template benchmark` command. | Command | Description | | ---------- | --------------------------------------------------------------------------------------- | | `block` | Benchmarks the execution time of historic blocks. | | `help` | Displays usage information for `node-template benchmark` or for a specified subcommand. | | `overhead` | Benchmarks the execution overhead per-block and per-extrinsic. | | `pallet` | Benchmarks the extrinsic weight of FRAME pallets. | | `storage` | Benchmarks the storage speed of a chain snapshot. | **Flags** You can use the following optional flags with the `node-template benchmark` command. | Flag | Description | | ----------------- | ----------------------------- | | `-h`, `--help` | Displays usage information. | | `-V`, `--version` | Displays version information. | **Options** You can use all of the common node-template command-line options in combination with `node-template benchmark` subcommands. For example, you can use `--base-path ` to specify a custom directory for blockchain data and `--chain ` to specify the chain specification to use with any `benchmark` subcommand. However, there are many command-line options that are specifically for performing benchmarking tasks. For example, the `node-template benchmark block` subcommand supports `--from` and `--to` command-line options for specifying the blocks to analyze. Because benchmarking FRAME pallets represents the most common benchmarking task, the `node-template benchmark pallet` subcommand supports the most task-specific command-line options. For example, you can use the following options with the `node-template benchmark pallet` subcommand. | Option | Description | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--external-repeat` | Specifies the number of times to repeat the execution of a benchmark for the client. Note that this option might give slower results, but maximizes Wasm memory. The default is one execution. | | `--extra` | Displays and runs extra benchmarks that would otherwise not be needed for weight construction. | | `-e`, `--extrinsic ` | Specifies an individual function in the pallet to benchmark, or `*` to benchmark all function calls in a pallet. | | `--header
` | Adds a header file to your benchmark output. | | `--heap-pages ` | Sets the heap pages while running benchmarks. If not set, the default value from the node is used. | | `--high ...` | Indicates highest values for each of the component ranges. | | `json-input ` | Specifies the path to a JSON file with previously-generated benchmark results. This option enables you to reuse the benchmarks raw results generated with the `--json-file` to rerun the benchmark analysis and to regenerate the weights for a pallet without actually rerunning the benchmarks tests. | | `--list` | Lists all currently defined benchmarks without running them. | | `--low ...` | Indicates lowest values for each of the component ranges. | | `--no-median-slopes` | Disables the median-slopes linear regression analysis. | | `--no-min-squares` | Disables the min-squares linear regression analysis. | | `--no-storage-info` | Disables the display of storage information in the analysis output. This is independent of the storage information appearing in the *output file*. Use a Handlebar template for that purpose. | | `--no-verify` | Disables verification logic when running benchmarks. | | `--output ` | Outputs the benchmarks to a Rust file at the given path. | | `--output-analysis ` | Specifies the analysis function to use in the benchmark output. Valid vales are `min-squares`, `median-slopes`, or `max`. The default is the `min-squares` analysis. For more information about benchmarking analysis, see [Benchmark](https://github.com/InfraBlockchainTeam/infrablockspace-docs/blob/master/test/benchmark/README.md). | | `-p`, `--pallet ` | Specifies the FRAME pallet to benchmark, or `*` to benchmark all pallets. If you benchmark all pallets, you must also specify `--extrinsic *` to benchmark all extrinsic calls. | | `--record-proof` | Estimates the proof-of-validation (PoV) size. | | `-r`, `--repeat ` | Specifies the number of times to repeat the execution of a benchmark from within the WebAssembly binary. The default is one execution. | | `-s`, `--steps ` | Specifies how many samples to take across the variable components. The default is one sample. | | `--template