Configuration

The following page will guide you through the configuration of a node and a client. The node is used to run the blockchain network, produce blocks and validate transactions. The client is used as a gateway to interact with the blockchain network by sending transactions and querying the state. Additionally we walk through running the JSON-RPC server.

These configurations can impact the performance, security, and functionality of your node. Thus, understanding and correctly configuring your node and client is essential.

Config and data directory

By default, your config and data are stored in the folder located at the ~/.dep directory. You can easily change the default directory by using the --home flag. It is important to note that you can have multiple home directories that each represent a different blockchain.

.                                   # ~/.dep
  ├── 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.

To specify the dep config and data storage directory; you can update it using the global flag --home <directory>.

Node Configuration

The Cosmos SDK automatically generates two configuration files inside ~/.dep/config:

• config.toml: used to configure the Tendermint, learn more on Tendermint's documentation,
• app.toml: generated by the Cosmos SDK, and used to configure your app, such as state pruning strategies, telemetry, gRPC and REST servers configuration, state sync, JSON-RPC, etc.

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

One example config to tweak is the minimum-gas-prices field inside app.toml, which defines the minimum amount the validator node is willing to accept for processing a transaction. It is an anti spam mechanism and it will reject incoming transactions with less than the minimum gas prices.

If it's empty, make sure to edit the field with some value, for example 10token, or else the node will halt on startup.

 # 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 = "0aevmos"

Pruning of State

There are four strategies for pruning state. These strategies apply only to state and do not apply to block storage. To set pruning, adjust the pruning parameter in the ~/.dep/config/app.toml file. The following pruning state settings are available:

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

By default, every node is in default mode which is the recommended setting for most environments. If you would like to change your nodes pruning strategy then you must do so when the node is initialized. Passing a flag when starting evmos will always override settings in the app.toml file, if you would like to change your node to the everything mode then you can pass the --pruning everything flag when you call dep start.

danger

IMPORTANT: When you are pruning state you will not be able to query the heights that are not in your store.

Client Configuration

We can view the default client config setting by using dep config command:

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

We can make changes to the default settings upon our choices, so it allows users to set the configuration beforehand all at once, so it would be ready with the same config afterward.

For example, the chain identifier can be changed to evmos_9000-4 from a blank name by using:

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

Other values can be changed in the same way.

Alternatively, we can directly make the changes to the config values in one place at client.toml. It is under the path of .evmos/config/client.toml in the folder where we installed evmos:

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

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

# The network chain ID

chain-id = "evmos_9000-4"

# 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 evmos_9000-4 to evmostest_9000-4, and output to number, it would change instantly as shown below.

dep config
{
 "chain-id": "evmostest_9000-4",
 "keyring-backend": "os",
 "output": "number",
 "node": "tcp://localhost:26657",
 "broadcast-mode": "sync"
}

Running the JSON-RPC Server

This section walks through the steps to enable the JSON-RPC server. JSON-RPC is provided on multiple transports. DEP supports JSON-RPC over HTTP and WebSocket. In terms of requirements we recommend a server with minimum 8-core CPU and 64gb of RAM. You must have ports 8545 and 8546 open on your firewall.

tip

Important: You cannot use all JSON RPC methods unless your node stores the entire copy of the blockchain locally. Do you need archives/snapshots of our networks? Go to this section.

Enable Server

To enable RPC server use the following flag (set to true by default).

dep start --json-rpc.enable

Defining Namespaces

Eth,Net and Web3 namespaces are enabled by default, but for the JSON-RPC you need to add more namespaces. In order to enable other namespaces edit app.toml file.

# 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

eth_call and eth_estimateGas define a global gas cap over rpc for DoS protection. You can override the default gas cap value of 25,000,000 by passing a custom value in app.toml:

# 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 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 setting 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

For all methods to work correctly, your node must be archival (store the entire copy of the blockchain locally). Pruning must be disabled. The pruning settings can be updated from the app.toml

###############################################################################
###                           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.

Because Websocket is bidirectional, servers can push events to clients. That makes Websocket a good choice for use-cases involving event subscription. Another benefit of Websocket is that after the handshake procedure, the overhead of individual messages is low, making it good for sending high number of requests. The WebSocket Server can be enabled from the app.toml

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