Skip to main content

Configuration

You can follow the instructions for configuring a node and a client on the page that follows. The blockchain network is operated by the node, which also creates blocks and verifies transactions. In order to send transactions and inquire about the health of the blockchain network, the client serves as a gateway. In addition, we demonstrate how to run the JSON-RPC server.

The functionality, security, and performance of your node may be affected by these configurations. Therefore, it's crucial to comprehend and effectively configure your node and client.

Config and data directory​

Your configuration and data are by default kept in the /.humansd directory folder. Using the --home flag makes changing the default directory simple. You can have numerous home directories, each of which represents a separate blockchain, which is a crucial point to remember.

.                                   # ~/.humansd
  ├── data/                           # Contains the databases used by the node.
  └── config/
      ├── app.toml                   # Application-related configuration file.
      ├── config.toml                # Tendermint-related configuration file.
      ├── genesis.json               # The genesis file.
      ├── node_key.json              # Private key to use for node authentication in the p2p protocol.
      └── priv_validator_key.json    # Private key to use as a validator in the consensus protocol.
tip

👉 The global parameter --home <directory> can be updated to provide the humansd configuration and data storage directory.

Node Configuration​

Inside /.humansd/config, the Cosmos SDK creates two configuration files automatically:

  • config.toml: used to configure Tendermint; for more information, see the documentation at Tendermint's documentation;
  • app.toml: produced by the Cosmos SDK and used to set up your app's telemetry, gRPC and REST server configuration, state sync, JSON-RPC, and other settings.

Both files are heavily commented, please refer to them directly to tweak your node.

The minimum-gas-prices field in app.toml, which specifies the very minimum the validator node is willing to accept for executing a transaction, is one such setting to alter. It is an anti-spam feature that disallows inbound transactions with gas prices below the minimum.

If the field is empty, please edit it to contain a value, such as 10token. This is necessary to prevent the node from halting during the startup process.

 # The minimum gas prices a validator is willing to accept for processing a
 # transaction. A transaction's fees must meet the minimum of any denomination
 # specified in this config (e.g. 0.25token1;0.0001token2).
 minimum-gas-prices = "0aheart"

Pruning of State​

There are four methods for state pruning. Only state is covered by these techniques; block storage is excluded. Adjust the pruning parameter in the ~/.humansd/config/app.toml file to configure pruning. There are available settings for the following pruning states:

  • everything: Prune all previously saved states besides the current state;
  • nothing: Save all states and delete nothing.
  • default: Save the last 100 states and the state of every 10,000 blocks.
  • custom: Specify pruning settings with the pruning-keep-recent, pruning-keep-every, and pruning-interval parameters.

Every node has default mode selected by default, which is the suggested choice for the majority of environments. Changes to pruning strategies for nodes must be made at the time the node is initialized. If you want to switch your node to the everything mode, you can give the --pruning everything flag when you call humansd start, which will always override settings in the app.toml file.

danger

IMPORTANT: You won't be able to query heights outside of your store when you are pruning state.

Client Configuration​

By executing the humansd config command, we can see the default client configuration:

humansd config
{
 "chain-id": "",
 "keyring-backend": "os",
 "output": "text",
 "node": "tcp://localhost:26657",
 "broadcast-mode": "sync"
}

We can adjust the default settings based on our preferences, which enables users to configure the configuration all at once in advance so that it will be ready with the same configuration later.

For instance, the chain identification can be changed from a blank name to humans_1089-1 by utilizing:

humansd config "chain-id" humans_1089-1
humansd config
{
 "chain-id": "humans_1089-1",
 "keyring-backend": "os",
 "output": "text",
 "node": "tcp://localhost:26657",
 "broadcast-mode": "sync"
}

The same method can be used to modify other values.

Alternately, we can directly alter the configuration values at client.toml in one location. It is located in the folder where we installed humans under the path .humans/config/client.toml:

############################################################################
### Client Configuration ###

############################################################################

# The network chain ID

chain-id = "humans_1089-1"

# The keyring's backend, where the keys are stored (os|file|kwallet|pass|test|memory)

keyring-backend = "os"

# CLI output format (text|json)

output = "number"

# <host>:<port> to Tendermint RPC interface for this chain

node = "tcp://localhost:26657"

# Transaction broadcasting mode (sync|async|block)

broadcast-mode = "sync"

After the necessary changes are made in the client.toml, then save. For example, if we directly change the chain-id from humans_1089-1 to humans_4139-1, and output to number, it would change instantly as shown below.

humansd config
{
 "chain-id": "humans_1089-1",
 "keyring-backend": "os",
 "output": "number",
 "node": "tcp://localhost:26657",
 "broadcast-mode": "sync"
}

Running the JSON-RPC Server​

The guides to activate the JSON-RPC server are outlined in this section. It is possible to use JSON-RPC on several transports. WebSocket and JSON-RPC via HTTP are supported by Humans.ai. We advise a server with a minimum of an 8-core CPU and 64GB of RAM in terms of specifications. Ports 8545 and 8546 must be open on your firewall.

tip

Important: Unless your node keeps the whole copy of the blockchain locally, you will not be able to use all JSON RPC techniques. Do you require network snapshots or archives? Visit this section.

Enable Server​

Use the following flag (which is set to true by default) to enable RPC server:

humansd start --json-rpc.enable

Defining Namespaces​

Eth, Net, and Web3 namespaces are enabled by default; however, additional namespaces must be added for JSON-RPC. Edit the app.toml file to enable other namespaces:

# API defines a list of JSON-RPC namespaces that should be enabled
# Example: "eth,txpool,personal,net,debug,web3"
api = "eth,net,web3,txpool,debug,personal"

Set a Gas Cap​

The eth_call and eth_estimateGas functions define a global gas cap over rpc to prevent DoS attacks. By passing a unique value in app.toml, you can override the 25,000,000 default gas cap value:

# GasCap sets a cap on gas that can be used in eth_call/estimateGas (0=infinite). Default: 25,000,000.
gas-cap = 25000000

CORS​

If using a browser to access the RPC, CORS must be enabled with the proper domain specified. Otherwise, requests will fail because JavaScript calls are limitedby the same-origin policy.

From the app, you can adjust the CORS setting in app.toml:

If accessing the RPC from a browser, CORS will need to be enabled with the appropriate domain set. Otherwise, JavaScript calls are limit by the same-origin policy and requests will fail.

The CORS settings can be updated from the app.toml:

###############################################################################
###                           API Configuration                             ###
###############################################################################

[api]

# ...

# EnableUnsafeCORS defines if CORS should be enabled (unsafe - use it at your own risk).
enabled-unsafe-cors = true # default false

Pruning​

Your node must be archival (keep a local copy of the whole blockchain) for all methods to function properly. Pruning needs to be stopped. The app.toml file contains updated pruning settings:

###############################################################################
###                           Base Configuration                            ###
###############################################################################

# The minimum gas prices a validator is willing to accept for processing a
# transaction. A transaction's fees must meet the minimum of any denomination
# specified in this config (e.g. 0.25token1;0.0001token2).

# ...

# default: the last 100 states are kept in addition to every 500th state; pruning at 10 block intervals
# nothing: all historic states will be saved, nothing will be deleted (i.e. archiving node)
# everything: all saved states will be deleted, storing only the current state; pruning at 10 block intervals
# custom: allow pruning options to be manually specified through 'pruning-keep-recent', 'pruning-keep-every', >
pruning = "nothing"
pruning-keep-recent = "0"
pruning-keep-every = "0"
pruning-interval = "0"

WebSocket Server​

Websocket is a bidirectional transport protocol. A Websocket connection is maintained by client and server until it is explicitly terminated by one. Most modern browsers support Websocket which means it has good tooling.

Websocket allows for bidirectional communication, so servers can push events to clients. For use-cases involving event subscription, Websocket is a good option because of this. Websocket also has the advantage of having a minimal overhead for individual messages following the handshake process, which makes it suitable for sending many of requests. From the app.toml file, the WebSocket Server can be enabled.

# Address defines the EVM WebSocket server address to bind to.
ws-address = "0.0.0.0:8546"