Skip to content

configure

The following pages will guide you through the configuration of nodes and clients. This node is used to run the blockchain network, produce blocks and verify transactions. Clients act as gateways, interacting with the blockchain network by sending transactions and querying state. Additionally, we introduced running the JSON-RPC server.

These configurations affect the performance, security, and functionality of the node. Therefore, it is crucial to understand and properly configure your nodes and clients.

Configuration and data directories

By default, your configuration and data are stored in folders located in the ~/.stcd directory. You can easily change the default directory with the --home flag. It's important to note that you can have multiple home directories, each representing a different blockchain.

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

Specifies the stcd configuration and data storage directory; you can update it with the global flag --home <directory>.

node configuration

The Cosmos SDK automatically generates two configuration files in ~/.stcd/config:

  • config.toml: used to configure Tendermint, read more in Tendermint's documentation, - app .toml : Generated by the Cosmos SDK to configure your application, such as state pruning strategies, telemetry, gRPC and REST server configuration, state sync, JSON-RPC, etc.

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

An example configuration to tune is the minimum-gas-prices field in app.toml, which defines the minimum amount a validator is willing to accept in order to process a transaction. This is an anti-spam mechanism that will reject incoming transactions below a minimum gas price.

If it's empty, make sure to edit the field with some value, such as 0dst, otherwise the node will stop 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 = "0dst"

State pruning

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

  • everything: Prune all saved states except the current state.
  • nothing: save all state, do not delete anything.
  • default: Save the last 100 states and the state every 10,000 blocks.
  • custom: Use pruning-keep-recent, pruning-keep-every, and pruning-interval parameters to specify pruning settings.

By default, each node is in default mode, which is the recommended setting for most environments. If you want to change your node pruning strategy, then you must do so at node initialization time. Passing a flag when starting daodst will always override the setting in the app.toml file, if you want to change the node to everything mode, then you can pass the --pruning everything flag when calling stcd stc-start.

🚨 Dangerous: When you trim the state, you won't be able to query the height that has been trimmed off.

Client Configuration

We can view the default client configuration settings with the stcd config command:

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

We can make changes to the default settings according to our choice, so it allows the user to pre-set all configurations at once, so that the same configuration can be used afterwards.

For example, the chain identifier can be changed from a blank name to daodst_7000-1 with the following command:

stcd config "chain-id" daodst_7000-1
stcd config
{
 "chain-id": "daodst_7000-1",
 "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 change configuration values in one place in client.toml .

Under the .stcd/config/client.toml path in the folder where we installed daodst:

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

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

# The network chain ID

chain-id = "daodst_7000-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 making the necessary changes in client.toml, then save. For example, if we directly change the chain-id from daodst_7000-1 to daodst_7000-2 and output it as a number, it will instantly change as shown below.

stcd config
{
 "chain-id": "daodst_7000-2",
 "keyring-backend": "os",
 "output": "number",
 "node": "tcp://localhost:26657",
 "broadcast-mode": "sync"
}

Run the JSON-RPC server

This section describes the steps to enable a JSON-RPC server. JSON-RPC is provided over several transports. Daodst supports JSON-RPC over HTTP and WebSocket. In terms of requirements, we recommend a server with at least an 8-core CPU and 64GB of RAM. You must open ports 8545 and 8546 on your firewall.

📣 Tip: Unless your nodes store an entire copy of the blockchain locally, you cannot use all JSON RPC methods. Do you need an archive/snapshot of our network? Go to [this section].

Enable server

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

stcd start --json-rpc.enable

Define the namespace

Eth, Net and Web3 namespaces are enabled by default, but for JSON-RPC you need to add more namespaces. In order to enable additional namespaces, edit the 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 amount

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 RPC from a browser, you need to enable CORS with the appropriate domain set. Otherwise, JavaScript calls are restricted by the same-origin policy and the request will fail.

CORS settings can be updated from 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

prune

In order for all methods to work, your node must be archival (storing an entire copy of the blockchain locally). Trimming must be disabled. Prune settings can be updated from 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 two-way transport protocol. A Websocket connection is maintained by both client and server until it is explicitly terminated by one. Most modern browsers support Websockets, which means it has good tools.

Because Websockets are bidirectional, the server can push events to the client. This makes Websockets a good choice for use cases involving event subscriptions. Another benefit of Websockets is the low overhead of a single message after the handshake process, making it ideal for sending large numbers of requests. WebSocket server can be enabled from app.toml

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