Skip to main content

Single Node

This page will show you how to manually operate a single node local network or use an automated script that has already been created. Due to its simplicity and speed, running a single node setup is advantageous for developers who wish to test their apps and protocol features. Please see the Multi Node Setup page for more sophisticated installations.

Prerequisite Readings​

Automated Script​

The Humans.ai repository's helper script, which creates a reasonable default setup for testing purposes, is the simplest approach to launch a local Humans.ai node:

$ start.sh
...
tip

It was selected to save the automatically created testing configuration at ~/.tmp-humansd instead of the default ~/.humansd in order to prevent overwriting any data for a real node used in production.

All humansd commands that are directed to the local test node must be extended when using the start,sh script with the --home /.tmp-humansd parameter. The home directory cannot be stored in the 'humansd' configuration, as can be seen in the output below, thus this is necessary. It might make sense to export this directory path as an environment variable to make it easier to use:

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

By customizing the configuration variables, you can modify the local node script. For suggestions on how to make changes, see the script snippet that follows:

# 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="humans_1089-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 humansd instance
HOMEDIR="$HOME/.tmp-humansd"
# 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​

With the help of this manual, you may build a single validator node that manages a local network for testing and other development-related tasks.

Initialize the chain​

We must initialize the chain and, most critically, its genesis file before we can start the node. Using the init subcommand, this is accomplished:

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

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

By making changes to the config.toml file, you can edit the moniker at a later time.

The previously mentioned command produces a default genesis file that describes the network's starting state as well as all the configuration files required for your node and validator to function. The default location of all these configuration files is in ~/.humansd, but you can change it by giving the --home parameter.

Genesis Procedure​

Adding Genesis Accounts​

You must add at least one account to the state using the keyring before beginning the chain:

humansd keys add my_validator

Once a local account has been created, proceed to allocate it some aheart tokens in the chain's genesis file. Additionally, doing so will ensure that your chain is aware of the existence of this account:

humansd add-genesis-account my_validator 10000000000aheart

You need to add a validator to your chain now that your account has some tokens.

The local node you built with the init command above will serve as your chain's validator for the sake of this tutorial. A specific transaction called a gentx that is present in the genesis file allows validators to be specified before a chain is initially started:

# 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
humansd add-genesis-account my_validator 1000000000stake,10000000000aheart

A gentx performs out the following three tasks:

  1. Registers the account you generated for the validator as the account that controls the validator (also known as the validator operator account).
  2. Self-delegates the amount of staking tokens that has been allocated.
  3. Connect a Tendermint node pubkey that will be used for signing blocks to the operator account. Without a --pubkey argument, the local node pubkey generated by the aforementioned humansd init command is used by default.

Use the following command to learn more about gentx:

humansd gentx --help

Collecting gentx​

The genesis file does not, by default, include any gentx. A gentx is a transaction that bonds staking token that is already existing in the genesis file under accounts to a validator, thereby creating a validator at genesis. When more than 2/3 of the validators (weighted by voting power) who are the recipient of a valid gentx come online after genesis_time, the chain will begin.

You can manually add a gentx to the genesis file or use the command:

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

All of the gentxs contained in ~/.humansd/config/gentx will be added by this command to the genesis file.

Run Single Node​

Check the genesis.json file's correctness last:

humansd validate-genesis

After everything has been set up, you can now launch your node:

humansd start
tip

Use the --help parameter to see a list of all the adjustable options when running the node.

Blocks should come.

The command before lets you manage a single node, but you might want to run several nodes concurrently to observe how consensus develops between them.

Using Ctrl+C, you can then terminate the node.

Further Configuration​

Key Management​

To consistently run a node with the same key: replace humansd keys add $KEY in ./start.sh with:

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

Only 24 word mnemonics are supported by Humans.ai at the moment.

You can create a fresh key or mnemonic using:

humansd keys add $KEY

For use with Metamask, for example, export your Humans.ai key as an Ethereum private key as follows:

humansd keys unsafe-export-eth-key $KEY

Use the --help parameter to learn more about the key commands that are available:

humansd keys -h

Keyring backend options​

Using test as the keyring-backend is required by the previous instructions. This keyring is not secure, doesn't ask for a password, and isn't appropriate for usage in a working environment. A file or OS keyring backend is also supported by Humans.ai for key storage. Add the flag --keyring-backend file to any pertinent command, and the password prompt will appear through the command line, allowing you to generate and use a key stored in a file rather than using the OS keyring by default. As a CLI configuration option, this can also be saved using:

humansd config keyring-backend file
tip

Click here for additional information about the Keyring and its backend options.

Enable Tracing​

Change the final line of the start.sh script to the following command to allow tracing when the node is operating:

  • $TRACER is the EVM tracer type for gathering execution traces from EVM transaction execution (for example, json|struct|access_list|markdown);
  • $TRACESTORE refers to the output file that contains KVStore tracing (for example,store.txt).
humansd start --evm.tracer $TRACER --tracestore $TRACESTORE --pruning=nothing $TRACE --log_level $LOGLEVEL --minimum-gas-prices=0.0001aheart --json-rpc.api eth,txpool,personal,net,debug,web3

Clearing data from chain​

Reset Data​

You can also reset the blockchain database, delete the node's address book files, and restore the priv_validator.json to its genesis state.

danger

IMPORTANT: Always use caution while performing humansd unsafe-reset-all if you are running a validator node**. If chain-id is not being switched, you should never use this command.

danger

IMPORTANT: priv_validator.json must be unique for each node. Copying priv_validator.json from one old node to several new nodes is not advised. You will double sign if you run two nodes with the same priv_validator.json file!

Reset the data after removing the old files.

rm $HOME/.humansd/config/addrbook.json $HOME/.humansd/config/genesis.json
humansd tendermint unsafe-reset-all --home $HOME/.humansd

Your node is now in a perfect condition while retaining the original versions of config.toml and priv_validator.json. If you previously put up any sentry nodes or complete nodes, your node will continue attempt to connect to them, but if they haven't been upgraded, it might not succeed.

Delete Data​

By default, information for the humansd binary should be kept in /.humansd. Run: to delete the current configuration and binaries.

rm -rf ~/.humansd

In order to restart the node, you must first run the full node installation procedures from above to erase all data except key storage (if the keyring backend was selected).

Recording Transactions Per Second (TPS)​

We utilize Prometheus to return the values and obtain a progressive value of the transactions per second.The Prometheus exporter is accessible at http://localhost:8877. As a result, add this section to your Prometheus installation config.yaml file as follows:

global:
scrape_interval: 10s

external_labels:
  monitor: 'humans'

scrape_configs:
- job_name: 'humans'

  scrape_interval: 10s

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

then launch Prometheus as follows:

prometheus --config.file=prom_config.yaml

and then go to http://localhost:9090/ to access the Prometheus dashboard. then enter the following expression after moving to the expression field.

rate(humansd_transactions_processed[1m])

which will show the rate of transactions processed.

tip

Only 24 word mnemonics are supported by Humans.ai at the moment.