Node Template
Command-line reference information for the 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.
Basic command usage
The basic syntax for running node-template
commands is:
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:
Flags
You can use the following optional flags with the node-template
command.
Flag | Description |
---|---|
| Adds the session keys for the predefined |
| 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 |
| Adds the session keys for the predefined |
| Adds the session keys for the predefined |
| Adds the session keys for the predefined |
| Starts the node in development mode in a fresh state. No state is persisted if you run the node using this flag. |
| Disables the use of color in log messages. |
| 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 |
| Enables peer discovery on local networks. By default, this flag is |
| Adds the session keys for the predefined |
| Adds the session keys for the predefined |
| Enables block authoring even if the node is offline. |
| Displays usage information. |
| Joins the IPFS network and serve transactions over bitswap protocol. |
| 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. |
| 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. |
| 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 |
| Prevents connecting to private IPv4 addresses, unless the address was passed with the |
| Disables the exposure of a Prometheus endpoint for receiving metrics. By default, metrics are exported to a Prometheus endpoint. |
| Disables connecting to the Substrate telemetry server. Telemetry is enabled for global chains by default. |
| Provides a shortcut for specifying |
| Enables you to specify the password for connecting to the keystore interactively in the terminal shell. |
| Exposes the Prometheus exporter on all interfaces. The default is local. |
| 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. |
| 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. Use |
| 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. |
| Runs a temporary node. This option creates a temporary directory to store the blockchain configuration, including the node database, node key, and the keystore. |
| Provides a shortcut for specifying |
| 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. |
| Listens to all RPC interfaces. This option is the same as |
| Listens to all Websocket interfaces. This option is the same as |
| 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). |
| Displays version information. |
| 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 |
Options
You can use the following options with the node-template
command.
Option | Description |
---|---|
| Specifies a custom base path. |
| Specifies a list of boot nodes identifiers for peer-to-peer communication. |
| Specifies the chain specification to use. You can set this option using a predefined chain specification name, such as |
| Selects the database backend to use. Valid values are |
| Limits how much memory the database cache can use. |
| 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 |
| Determines the execution strategy used by all execution contexts. Valid values are |
| Specifies the type of execution used when calling into the runtime to construct blocks. Valid values are |
| Specifies the type of execution used when calling into the runtime to import blocks (including locally-authored blocks). Valid values are |
| Specifies the type of execution used when calling into the runtime to use an offchain worker. Valid values are |
| Specifies the type of execution used when calling into the runtime while not syncing, importing, or constructing blocks. Valid values are |
| Specifies the type of execution used when calling into the runtime to import blocks as part of an initial synchronization. Valid values are |
| Specifies the maximum number of incoming connections to accept. The default is 25 peers. |
| Enables the offchain indexing API. The offchain indexing API enables the runtime to write directly to a offchain worker database during block import. |
| Specifies the path to send inter-process communication (IPC)to a remote procedure call (RPC) server. |
| Specifies the number of finalized blocks to keep in the database. The default is to keep all blocks. |
| Specifies the path to a custom keystore. |
| Specifies a custom URI to connect to for keystore services. |
| Specifies the address for the node to listen on. By default, if you start a node using the |
| Sets a custom logging filter. The syntax to use is |
| 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. |
| Specific the maximum size of the instances cache for each runtime. The default value is 8 and values higher than 256 are ignored. |
| Specifies the human-readable name for this node. The node name is reported to the telemetry server, if enabled. |
| Specifies the secret key to use for |
| Specifies the file that contains the secret key for a node to use for |
| Specifies the type of secret key to use for peer-to-peer ( |
| Specifies the maximum number of outgoing connections to maintain. The default is 25. |
| Specifies the password to use for the keystore. |
| Specifies the path to a file that contains the password used for the keystore. |
| Specifies the maximum number of kilobytes for all transactions stored in the transaction pool. The default is 20480 KB. |
| Specifies the maximum number of transactions that can be in the transaction pool. The default is 8192 transactions. |
| Specifies the TCP port to use for peer-to-peer communication. |
| Specifies the TCP port to use for the Prometheus exporter service. |
| Specifies the maximum number of block states to keep or |
| 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. |
| Specifies a list of reserved node addresses. |
| 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 |
| Specifies the size of the RPC HTTP server thread pool. |
| Sets the the maximum RPC payload size for both requests and responses (both HTTP and web socket), in megabytes. The default is 15 MiB. |
| Specifies the RPC methods to expose. Valid values are |
| Specifies the TCP port to use for the HTTP RPC server. |
| Specifies the state cache size. The default is 67108864 bytes. |
| Specifies the blockchain syncing mode Valid values are |
| 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 |
| Specifies the receiver to process tracing messages. The default is Log. |
| Sets a custom profiling filter. Syntax is the same as for logging: |
| Specifies the method for executing Wasm runtime code. Valid values are |
| Specifies the path where local WASM runtimes are stored. These runtimes override on-chain runtimes when the version matches. |
| Specifies the maximum number of WS RPC server connections. |
| 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 |
---|---|
| Benchmarks runtime pallets. |
| Builds a chain specification. |
| Validates blocks. |
| Exports blocks. |
| Exports the state of a given block into a chain specification. |
| Displays usage information for |
| Imports blocks. |
| Provides local key management utilities. |
| Removes all chain data. |
| 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:
Basic command usage
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:
Subcommands
You can use the following subcommands with the node-template benchmark
command.
Command | Description |
---|---|
| Benchmarks the execution time of historic blocks. |
| Displays usage information for |
| Benchmarks the execution overhead per-block and per-extrinsic. |
| Benchmarks the extrinsic weight of FRAME pallets. |
| Benchmarks the storage speed of a chain snapshot. |
Flags
You can use the following optional flags with the node-template benchmark
command.
Flag | Description |
---|---|
| Displays usage information. |
| 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 <path>
to specify a custom directory for blockchain data and --chain <chain-specification>
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 |
---|---|
| 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. |
| Displays and runs extra benchmarks that would otherwise not be needed for weight construction. |
| Specifies an individual function in the pallet to benchmark, or |
| Adds a header file to your benchmark output. |
| Sets the heap pages while running benchmarks. If not set, the default value from the node is used. |
| Indicates highest values for each of the component ranges. |
| 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 |
| Lists all currently defined benchmarks without running them. |
| Indicates lowest values for each of the component ranges. |
| Disables the median-slopes linear regression analysis. |
| Disables the min-squares linear regression analysis. |
| 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. |
| Disables verification logic when running benchmarks. |
| Outputs the benchmarks to a Rust file at the given path. |
| Specifies the analysis function to use in the benchmark output. Valid vales are |
| Specifies the FRAME pallet to benchmark, or |
| Estimates the proof-of-validation (PoV) size. |
| Specifies the number of times to repeat the execution of a benchmark from within the WebAssembly binary. The default is one execution. |
| Specifies how many samples to take across the variable components. The default is one sample. |
| Specifies the path to a Handlebars template file used for outputting benchmark results. |
For examples of different benchmarking subcommands and the related command-line options, see Benchmarking examples.
Benchmarking examples
After you have compiled the runtime with benchmarking enabled, you can run a command similar to the following to benchmark all of the function calls in all of the pallets that have runtime-benchmarking configured:
With this command, each function call is executed once with a single value and the resulting weight is recorded in the weights.rs
file.
Depending on the function you want to benchmark, you can add the --steps
and --repeat
command-line options to execute the call multiple times with different values. For example, the following command executes the do_something
function in the pallet_template
and calls the function 20 times to take 10 data points:
With the --list
option, the command displays the following output:
With the --steps
and --repeat
command-line options, the command displays the following benchmarking results:
To measure the average, median, minimum, and maximum execution time per-block and per-extrinsic, you can run the node-template benchmark overhead
subcommand:
The command displays output similar to the following:
By default, the command executes the benchmark 100 times, generates results, and writes the output to the block_weights.rs
and extrinsics_weights.rs
files. You can use command-line options to adjust the calculated weight by adding units or by multiplying the average execution time by some factor.
To measure the storage execution time for the Substrate development chain specification, you can run the following command:
The command displays output similar to the following:
To get benchmarking information for the paritydb
database instead of the default rocksdb
database, use the --db paritydb
command-line option. TO get storage benchmarking information for Polkadot or any other real chain snapshot, use the command-line option --state-version 0
. For more information about using the benchmark storage subcommand, see benchmark storage command.
For more information about how to add benchmarking to the runtime, see Benchmark and Add benchmarks.
build-spec
Use the node-template build-spec
command to create a chain specification file for your runtime.
Basic command usage
Flags
You can use the following optional flags with the node-template build-spec
command.
Flag | Description |
---|---|
| Enables detailed log output, including the log target name, the log level, and the thread name. This option is used automatically if you enable a logging level any higher level than |
| Starts the node in development mode. Using this flag also enables the |
| Disables adding the default boot node to the specification. By default, the |
| Disables log color output. |
| Enables the log filter to be dynamically updated and reloaded. Note that this option can significantly decrease performance. Setting this option does not affect the |
| Displays usage information. |
| Formats the chain specification as raw genesis storage output. |
| Displays version information. |
Options
You can use the following command-line options with the node-template build-spec
command.
Option | Description |
---|---|
| Specifies a custom base path. |
| Specifies the chain specification to use. You can set this option using a predefined chain specification name, such as |
| Sets a custom logging filter. The syntax to use is |
| Specifies the secret key to use for |
| Specifies the file that contains the secret key for a node to use for |
| Specifies the type of secret key to use for peer-to-peer ( |
| Specifies the receiver to process tracing messages. The default is Log. |
| Sets a custom profiling filter. Syntax is the same as for logging: |
Examples
To export the predefined local
chain specification to a file named customSpec.json
, you can run the following command:
If you have previously created a JSON file that contains a custom chain specification, you can specify the path to that file and use the --raw
command-line option to export the chain specification with encoded storage keys that the node uses to reference the data in its local storage.
check-block
Use the node-template check-block
command to validate a specific block. You must specify the block to validate by the block hash or block number.
Basic command usage
Flags
You can use the following optional flags with the node-template check-block
command.
Flag | Description |
---|---|
| Enables detailed log output, including the log target name, the log level, and the thread name. This option is used automatically if you enable a logging level any higher level than |
| Starts the node in development mode. Using this flag also enables the |
| Disables log color output. |
| Enables the log filter to be dynamically updated and reloaded. Note that this option can significantly decrease performance. Setting this option does not affect the |
| Displays usage information. |
| Changes the storage format for blocks. If you specify this option, each transaction is stored separately in the transaction database column and is only referenced by its hash in the block body column. |
| Forces the node to start with pruning enabled. By default, validator nodes have state pruning disabled. To start a validator node with pruning enabled—also referred to as archive mode—you must set this option. |
| Displays version information. |
Options
You can use the following command-line options with the node-template check-block
command.
Option | Description |
---|---|
| Specifies a custom base path. |
| Specifies the chain specification to use. You can set this option using a predefined chain specification name, such as |
| Selects the database backend to use. Valid values are |
| Limits how much memory the database cache can use. The default is 128 MiB. |
| Specifies the default number of 64KB pages to allocate for Wasm execution. You should not use this option unless you know what you're doing. |
| Determines the execution strategy used by all execution contexts. Valid values are |
| Determines the execution strategy used when calling into the runtime to construct blocks. Valid values are |
| Determines the execution strategy used when calling into the runtime to import blocks, including locally authored blocks. Valid values are |
| Determines the execution strategy used when calling into the runtime to use an offchain worker. Valid values are |
| Determines the execution strategy used when calling into the runtime for operations other than synchronizing, importing, or constructing blocks. Valid values are |
| Determines the execution strategy used when calling into the runtime to synchronize blocks. Valid values are |
| Specifies the number of finalized blocks to keep in the database. The default is to keep all blocks. |
| Sets a custom logging filter. The syntax to use is |
| Specifies the maximum number of block states to keep or |
| Specifies the state cache size. The default is 67108864 bytes. |
| Specifies the receiver to process tracing messages. The default is Log. |
| Sets a custom profiling filter. Syntax is the same as for logging: |
| Specifies the method for executing Wasm runtime code. Valid values are |
| Specifies the path where local WASM runtimes are stored. If you set this option, the node uses the local runtime instead of the on-chain runtime if the runtime versions are the same. |
Arguments
You must specify the following command-line argument when you run the node-template check-block
command.
Argument | Description |
---|---|
| Specifies the block hash or block number to check. |
export-blocks
Use the node-template export-blocks
command to export blocks.
Basic command usage
Flags
You can use the following optional flags with the node-template export-blocks
command.
Flag | Description |
---|---|
| Exports blocks as binary output rather than to a JSON file. |
| Enables detailed log output, including the log target name, the log level, and the thread name. This option is used automatically if you enable a logging level any higher level than |
| Starts the node in development mode. Using this flag also enables the |
| Disables log color output. |
| Enables the log filter to be dynamically updated and reloaded. Note that this option can significantly decrease performance. Setting this option does not affect the |
| Displays usage information. |
| Changes the storage format for blocks. If you specify this option, each transaction is stored separately in the transaction database column and is only referenced by its hash in the block body column. |
| Displays version information. |
Options
You can use the following command-line options with the node-template export-blocks
command.
Option | Description |
---|---|
| Specifies a custom base path. |
| Specifies the chain specification to use. You can set this option using a predefined chain specification name, such as |
| Selects the database backend to use. Valid values are |
| Limits how much memory the database cache can use. The default is 128 MiB. |
| Specifies the block number to start exporting from. The default is the first block (1). |
| Specifies the number of finalized blocks to keep in the database. The default is to keep all blocks. |
| Sets a custom logging filter. The syntax to use is |
| Specifies the maximum number of block states to keep or |
| Specifies the last block number to export. The default is the best block. |
| Specifies the receiver to process tracing messages. The default is Log. |
| Sets a custom profiling filter. Syntax is the same as for logging: |
Arguments
You can specify the following command-line argument when you run the node-template export-blocks
command.
Argument | Description |
---|---|
| Specifies the output file name for the exported blocks. If you don't specify an output file name, blocks are exported to standard output ( |
export-state
Use the node-template export-state
command to export the state of a given block into a chain specification.
Basic command usage
Flags
You can use the following optional flags with the node-template export-state
command.
Flag | Description |
---|---|
| Enables detailed log output, including the log target name, the log level, and the thread name. This option is used automatically if you enable a logging level any higher level than |
| Starts the node in development mode. Using this flag also enables the |
| Disables log color output. |
| Enables the log filter to be dynamically updated and reloaded. Note that this option can significantly decrease performance. Setting this option does not affect the |
| Displays usage information. |
| Displays version information. |
Options
You can use the following command-line options with the node-template export-state
command.
Option | Description |
---|---|
| Specifies a custom base path. |
| Specifies the chain specification to use. You can set this option using a predefined chain specification name, such as |
| Specifies the number of finalized blocks to keep in the database. The default is to keep all blocks. |
| Sets a custom logging filter. The syntax to use is |
| Specifies the maximum number of block states to keep or |
| Specifies the receiver to process tracing messages. The default is Log. |
| Sets a custom profiling filter. Syntax is the same as for logging: |
Arguments
You can specify the following command-line argument when you run the node-template export-state
command.
Argument | Description |
---|---|
| Specifies the block hash or block number to export. |
help
Use the node-template help
command to display usage information for node-template
or a summary of command-line usage information for any node-template
subcommand.
Basic command usage
Examples
To display a summary of usage information for the export-blocks
subcommand, run the following command:
import-blocks
Use the node-template import-blocks
command to import blocks.
Basic command usage
Flags
You can use the following optional flags with the node-template import-blocks
command.
Flag | Description |
---|---|
| Attempts to import blocks in binary format rather than from a JSON file. |
| Enables detailed log output, including the log target name, the log level, and the thread name. This option is used automatically if you enable a logging level any higher level than |
| Starts the node in development mode. Using this flag also enables the |
| Disables log color output. |
| Enables the log filter to be dynamically updated and reloaded. Note that this option can significantly decrease performance. Setting this option does not affect the |
| Displays usage information. |
| Changes the storage format for blocks. If you specify this option, each transaction is stored separately in the transaction database column and is only referenced by its hash in the block body column. |
| Forces the node to start with pruning enabled. By default, validator nodes have state pruning disabled. To start a validator node with pruning enabled—also referred to as archive mode—you must set this option. |
| Displays version information. |
Options
You can use the following command-line options with the node-template import-blocks
command.
Option | Description |
---|---|
| Specifies a custom base path. |
| Specifies the chain specification to use. You can set this option using a predefined chain specification name, such as |
| Selects the database backend to use. Valid values are |
| Limits how much memory the database cache can use. The default is 128 MiB. |
| Specifies the default number of 64KB pages to allocate for Wasm execution. In most cases, you should not use this option. |
| Determines the execution strategy used by all execution contexts. Valid values are |
| Determines the execution strategy used when calling into the runtime to construct blocks. Valid values are |
| Determines the execution strategy used when calling into the runtime to import blocks, including locally authored blocks. Valid values are |
| Determines the execution strategy used when calling into the runtime to use an offchain worker. Valid values are |
| Determines the execution strategy used when calling into the runtime for operations other than synchronizing, importing, or constructing blocks. Valid values are |
| Determines the execution strategy used when calling into the runtime to synchronize blocks. Valid values are |
| Specifies the number of finalized blocks to keep in the database. The default is to keep all blocks. |
| Sets a custom logging filter. The syntax to use is |
| Specifies the maximum number of block states to keep or |
| Specifies the state cache size. The default is 67108864 bytes. |
| Specifies the receiver to process tracing messages. The default is Log. |
| Sets a custom profiling filter. Syntax is the same as for logging: |
| Specifies the method for executing Wasm runtime code. Valid values are |
| Specifies the path where local WASM runtimes are stored. If you set this option, the node uses the local runtime instead of the on-chain runtime if the runtime versions are the same. |
Arguments
You can specify the following command-line argument when you run the node-template import-blocks
command.
Argument | Description |
---|---|
| Specifies the input file to use for importing blocks. If you don't specify an input file, blocks are imported from standard input ( |
key
Use the node-template key
command to generate, inspect, and manage private and public key pairs and addresses. The node-template key
command provides convenient access to a subset of key management services that are available in the standalone subkey
program. For complete details about the subcommands and command-line options for most node-template key
subcommands, see subkey
. Although most of the node-template key
subcommands are identical to [subkey
] subcommands, the node-template key insert
subcommand is not a supported [subkey
] subcommand. The node-template key insert
subcommand enables you to add generated keys directly to a node keystore. For information about the command-line options and arguments to use with the node-template key insert
subcommand, see Insert a key on a node or run the following command:
Basic command usage
Flags
You can use the following optional flags with the node-template key
command.
Flag | Description |
---|---|
| Displays usage information. |
| Displays version information. |
Subcommands
You can use the following subcommands with the node-template key
command.
Command | Description |
---|---|
Generates a random account key. | |
Generates a random node | |
Displays usage information for a specified subcommand. | |
Adds an account or node key to the keystore on the local node. | |
Displays the public key and SS58 address for the secret URI you specify. | |
Displays the peer ID that corresponds with the secret node key in the file name you specify. |
Insert a key on a node
Use the node-template key insert
command to add the keys used for performing node operations to the node keystore. For example, keys are required to secure peer-to-peer communication between nodes and to enable nodes to act as validating authorities for consensus.
Basic command usage
Flags
You can use the following optional flags with the node-template key insert
command.
Flag | Description |
---|---|
| Enables detailed log output, including the log target name, the log level, and the thread name. This option is used automatically if you enable a logging level any higher level than |
| Starts the node in development mode. Using this flag also enables the |
| Disables log color output. |
| Enables the log filter to be dynamically updated and reloaded. Note that this option can significantly decrease performance. Setting this option does not affect the |
| Displays usage information. |
| Displays an interactive prompt for you to enter the password in the terminal shell to access the keystore. |
| Displays version information. |
Options
You can use the following command-line options with the node-template key insert
command.
Option | Description |
---|---|
| Specifies a custom base path. |
| Specifies the chain specification to use. You can set this option using a predefined chain specification name, such as |
| Specifies the type of node activity the key authorizes. For example, valid key types include |
| Specifies the path to a custom keystore. |
| Specifies custom URIs to connect to for keystore services. |
| Sets a custom logging filter. The syntax to use is |
| Enables you to add an extra user-defined secret to the secret key required by the keystore. |
| Specifies the file that contains the password used to access the keystore. |
| Specifies the cryptography scheme to use to generate the key out of the given URI. Valid values are |
| Specifies the secret key URI. If you specify a file for this option, the file content is used as the URI. If you don't specify this option, you are prompted to specify the URI. |
| Specifies the receiver to process tracing messages. The default is Log. |
| Sets a custom profiling filter. Syntax is the same as for logging: |
purge-chain
Use the node-template purge-chain
command to remove a blockchain and all blockchain-related information.
Basic command usage
Flags
You can use the following optional flags with the node-template purge-chain
command.
Flag | Description |
---|---|
| Enables detailed log output, including the log target name, the log level, and the thread name. This option is used automatically if you enable a logging level any higher level than |
| Starts the node in development mode. Using this flag also enables the |
| Disables log color output. |
| Enables the log filter to be dynamically updated and reloaded. Note that this option can significantly decrease performance. Setting this option does not affect the |
| Displays usage information. |
| Changes the storage format for blocks. If you specify this option, each transaction is stored separately in the transaction database column and is only referenced by its hash in the block body column. |
| -V
, --version
| Displays version information. -y
| Provides a preemptive yes
response to skip the interactive prompt to confirm that you want to remove the chain.
Options
You can use the following command-line options with the node-template purge-chain
command.
Option | Description |
---|---|
| Specifies a custom base path. |
| Specifies the chain specification to use. You can set this option using a predefined chain specification name, such as |
| Selects the database backend to use. Valid values are |
| Limits how much memory the database cache can use. The default is 128 MiB. |
| Sets a custom logging filter. The syntax to use is |
| Specifies the receiver to process tracing messages. The default is Log. |
| Sets a custom profiling filter. Syntax is the same as for logging: |
revert
Use the node-template revert
command to revert the chain to a previous state.
Basic command usage
Flags
You can use the following optional flags with the node-template revert
command.
Flag | Description |
---|---|
| Enables detailed log output, including the log target name, the log level, and the thread name. This option is used automatically if you enable a logging level any higher level than |
| Starts the node in development mode. Using this flag also enables the |
| Disables log color output. |
| Enables the log filter to be dynamically updated and reloaded. Note that this option can significantly decrease performance. Setting this option does not affect the |
| Displays usage information. |
| Displays version information. |
Options
You can use the following command-line options with the node-template rever
command.
Option | Description |
---|---|
| Specifies a custom base path. |
| Specifies the chain specification to use. You can set this option using a predefined chain specification name, such as |
| Specifies the number of finalized blocks to keep in the database. The default is to keep all blocks. |
| Sets a custom logging filter. The syntax to use is |
| Specifies the maximum number of block states to keep or |
| Specifies the receiver to process tracing messages. The default is Log. |
| Sets a custom profiling filter. Syntax is the same as for logging: |
Arguments
You can use the following command-line argument with the node-template revert
command.
Argument | Description |
---|---|
| Specifies the number of blocks to revert. The default is 256 blocks. |
Last updated