Installation Reqirement

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. Your node's performance, security, and functionality may be impacted by these configurations. Therefore, it's crucial to comprehend and configure your node and client correctly. Config and data directory By default, your config and data are stored in the folder located at the ~/.cvmd 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.

.                                   # ~/.cvmd
  ├── 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.// Some code

Node Configuration

The Cosmos SDK automatically generates two configuration files inside ~/.cvmd/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.

Please refer to both files directly to modify your node because they are both heavily commented.

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 10 token, or else the node will halt on startup. The minimum gas prices a validator is willing to accept for processing a

//  # 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 = "0aCosVM"Some code

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 ~/.cvmd/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 CosVM 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 cvmd start.

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 cvmd config command:

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

Users can set the configuration in advance so that it is ready with the same configuration later because we can change the default settings based on our preferences.

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

Cvmd config
{
 "chain-id": "CosVM_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 .CosVM/config/client.toml in the folder where we installed CosVM

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

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

# The network chain ID

chain-id = "cosvm_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 CosVM_9000-2 to CosVMtest_9000-1, and output to number, it would change instantly as shown below.

ecvmd config
{
 "chain-id": "cosvmtest_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. CosVM supports JSON-RPC over HTTP and WebSocket. In terms of requirements, we recommend a server with a 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).

cvmd 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

A bidirectional transport protocol is called Websocket. Client and server keep a Websocket connection going until one of them explicitly ends it. The majority of contemporary browsers have good tooling because they support Websocket.

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"