Skip to content

single node

After this page, you can run a single-node local network manually or with an already prepared automated script. Running a single-node setup is useful for developers who want to test the functionality of their applications and protocols because of its simplicity and speed. For more complex setups, please refer to the [Multi-node setup] page.

prerequisites

Automation script

The easiest way to start a local Daodst node is to use the provided helper script, which will create a sensible default configuration for testing purposes:

$ local_node.sh
...

📣 Tip: $install_path is used to indicate the path where you installed the stcd binary

📣 Tips: To avoid overwriting any data from real nodes used in production, it was decided to store the auto-generated test configuration in ~/.tmp-stcd instead of the default $install_path/.stcd.

When using the local_node.sh script, it is necessary to extend all stcd commands targeting the local test node with the --home ~/.tmp-stcd flag. This is mandatory because the home directory cannot be stored in the stcd configuration, which can be seen in the output below. For ease of use, it may be wise to export this directory path as an environment variable:

$ export TMP=$HOME/.tmp-stcd`
$ stcd config --home $TMP
{
"chain-id": "daodst_7000-1",
"keyring-backend": "test",
"output": "text",
"node": "tcp://localhost:26657",
"broadcast-mode": "sync"
}

You can customize local node scripts by changing configuration variables. See the following script excerpt for ideas on what can be adjusted:

# Customize the name of your keys, the chain-id, moniker of the node, keyring backend, and more
KEYS[0]="dev0"
KEYS[1]="dev1"
KEYS[2]="dev2"
CHAINID="daodst_7000-1"
MONIKER="localtestnet"
# Remember to change to other types of keyring like 'file' in-case exposing to outside world,
# otherwise your balance will be wiped quickly
# The keyring test does not require private key to steal tokens from you
KEYRING="test"
KEYALGO="eth_secp256k1"
LOGLEVEL="info"
# Set dedicated home directory for the stcd instance
HOMEDIR="$HOME/.tmp-stcd"
# to trace evm
#TRACE="--trace"
TRACE=""

[...]

  # Adjust this set a different maximum gas limit
  jq '.consensus_params["block"]["max_gas"]="10000000"' "$GENESIS" >"$TMP_GENESIS" && mv "$TMP_GENESIS" "$GENESIS"

[...]

Manual deployment

This guide helps you create a single validator node that runs the network locally for testing and other development-related purposes.

Initialize the chain

Before actually running the node, we need to initialize the chain, most importantly its genesis file. This is done with the init subcommand:

$MONIKER=testing
$KEY=dev0
$CHAINID="daodst_7000-1"

# The argument $MONIKER is the custom username of your node, it should be human-readable.
stcd init $MONIKER --chain-id=$CHAINID

📣 Tips: You can modify this moniker later by updating the config.toml file.

The command above creates all the configuration files your node and validators need to run, as well as a default genesis file which defines the initial state of the network. By default all these configuration files are in ~/.stcd, but you can override the location of this folder by passing the --home flag.

Genesis program

Add genesis account

Before starting the chain, you need to populate the state with at least one account using keyring:

stcd keys add my_validator

After creating the local account, go ahead and grant it some dst tokens in the chain's genesis file. Doing this will also ensure your chain is aware of the existence of this account:

stcd add-genesis-account my_validator 10000000000dst

Now that your account has some tokens, you need to add a validator to your chain.

For this guide, you will add your local node (created via the init command above) as a validator for the chain. Validators can be claimed via a special transaction called gentx included in the genesis file before the chain is first launched:

# Create a gentx
# NOTE: this command lets you set the number of coins.
# Make sure this account has some coins with the genesis.app_state.staking.params.bond_denom denom
stcd add-genesis-account my_validator 1000000000dst,10000000000fm

gentx does three things:

  1. Register the validator account you created as the validator operator account (that is, the account that controls the validator).
  2. Delegate the pledged tokens of the provided amount by yourself.
  3. Associate the operator account with the Tendermint node public key that will be used to sign blocks. If the --pubkey flag is not provided, it defaults to the local node pubkey created via the stcd init command above.

For more information on gentx, use the following command:

stcd gentx --help

Collect gentx

By default, the genesis file does not contain any gentxs. gentx is a transaction that binds staked tokens present in the genesis file under accounts to a validator, essentially creating a validator at genesis. The chain starts once more than 2/3 validators (weighted by voting power) that are valid gentx recipients come online after genesis_time.

gentx can be added manually to the genesis file, or via the following command:

# Add the gentx to the genesis file
stcd collect-gentxs

This command will add all gentxs stored in ~/.stcd/config/gentx to the genesis file.

daemon running single node

Finally, check the genesis.json file for correctness:

stcd validate-genesis

Now that everything is set up, you can finally start your node:

stcd daemon

📣 Tips: To inspect all available customizable options when running node, use the --help flag.

You should see blocks coming in.

The preceding commands allow you to run a single node. This is enough for the next section about interacting with this node, But you might want to run multiple nodes at the same time and see how consensus is reached between them.

You can then stop the node with Ctrl+C.

Further configuration

Key Management

Run node with the same key each time: replace stcd keys add $KEY in ./local_node.sh with:

echo "your mnemonic here" | stcd keys add $KEY --recover

📣 Tips: Daodst currently supports 12-word mnemonics. :::

You can generate a new key/mnemonic using:

stcd keys add $KEY

Export your Daodst key as an Ethereum private key (for Metamask for example):

stcd keys unsafe-export-eth-key $KEY

For more information on available key commands, use the --help flag

stcd keys -h

Keyring backend options

The instructions above include the command to use test as keyring-backend. This is an insecure keyring that does not require a password and should not be used in production. Otherwise, Daodst supports using file or OS keyring backends for key storage. To create and use a file to store keys instead of the default operating system keyring, add the flag --keyring-backend file to any relevant command and a password prompt will appear via the command line. This can also be saved as a CLI configuration option:

stcd config keyring-backend file

📣 Tips: For more information on Keyring and its backend options, click here.

Enable tracing

To enable tracing while running node, modify the last line of the local_node.sh script to the following command, Where:

  • $TRACER is the EVM tracer type used to collect execution traces from EVM transaction executions (e.g. json|struct|access_list|markdown)
  • $TRACESTORE is the output file containing the KVStore trace (e.g. store.txt)
stcd start --evm.tracer $TRACER --tracestore $TRACESTORE --pruning=nothing $TRACE --log_level $LOGLEVEL --minimum-gas-prices=0.0001dst --json-rpc.api eth,txpool,personal,net ,debug,web3

Clear data from the chain

Reset Data

Alternatively, you can reset the blockchain database, delete the node's address book file, and reset priv_validator.json to the genesis state.

📣 Tips: Always be careful when doing stcd unsafe-reset-all if you are running a validator node. If you don't switch chain-id, you should never use this command.

🚨 DANGER: Make sure each node has a unique priv_validator.json. DO NOT copy priv_validator.json from old nodes to multiple new nodes. Running two nodes with the same priv_validator.json will result in you dual signing and will be permanently jailed!

📣 Tip: $install_path is used to indicate the path where you installed the stcd binary

First, delete obsolete files and reset data.

rm $install_path/.stcd/config/addrbook.json $install_path/.stcd/config/genesis.json
stcd tendermint unsafe-reset-all --home .stcd

Your node is now in pristine state, while keeping the original priv_validator.json and config.toml. If you previously set up any sentinel nodes or full nodes, your nodes will still attempt to connect to them, but may fail if they have not been upgraded.

delete data

Binaries are stored in $install_path/.stcd by default, to remove existing binaries and configurations, run:

rm -rf $install_path/.stcd

To clear all data except the keystore (if the keyring backend is selected), you can then re-run the full node install command from above to start the node again.

Transactions per second (TPS)

To get a cumulative value of transactions per second, we use the Prometheus return value. The Prometheus exporter runs at address http://localhost:8877, so add this section to your Prometheus installation config.yaml file ,As follows

global:
scrape_interval: 10s

external_labels:
   monitor: 'daodst'

scrape_configs:
- job_name: 'daodst'

   scrape_interval: 10s

   static_configs:
     - targets: ['localhost:8877']

Then run Prometheus like this

prometheus --config.file=prom_config.yaml

Then visit the Prometheus dashboard at http://localhost:9090/ and navigate to the expression area and enter the following expression

rate(daodst_transactions_processed[1m])

This will show the speed at which transactions are processed.

📣 Tips: Daodst currently supports 12-word mnemonics.