Pre-Requisites & Requirements
Last updated
Was this helpful?
Last updated
Was this helpful?
This document describes the hardware and software pre-requisites for setting up a new cheqd-node instance and joining the existing testnet/mainnet. The recommended installation method is to use the .
Alternative installation methods and a developer guide to building from scratch are covered at the end of this page.
For most nodes, the RAM/vCPU requirements are relatively static and do not change over time. However, the disk storage space needs to grow as the chain grows and will evolve over time.
It is recommended to mount disk storage for blockchain data as an expandable volume/partition separate from your root partition. This allows you mount the node data/configuration path on /home (for example) and increase the storage if necessary independent of the root / partition since hosting providers typically force an increase in CPU/RAM specifications to grow the root partition.
Extended information on . The figures below have been updated from the default Tendermint recommendations to account for current cheqd network chain size, real-world usage accounting for requests nodes need to handle, etc.
4-8 GB RAM (2 GB RAM minimum)
x64 2.0 GHz 2-4 vCPU or equivalent (x64 1.4 GHz 1 vCPU or equivalent minimum)
650 GB SSD (500 GB minimum)
β οΈ Storage requirements for the blockchain grows with time. Therefore, these minimum storage figures are expected to increase over time. Read our validator guide for "pruning" settings to optimise storage consumed.
We recommend using a storage path that can be kept persistent and restored/remounted (if necessary) for the configuration, data, and log directories associated with a node. This allows a node to be restored along with configuration files such as node keys and for the node's copy of the ledger to be restored without triggering a full chain sync.
We plan on supporting other operating systems in the future, based on demand for specific platforms by the community.
To function properly, cheqd-node requires two types of ports to be configured. Depending on the setup, you may also need to configure firewall rules to allow the correct ingress/egress traffic.
Node operators should ensure there are no existing services running on these ports before proceeding with installation.
The P2P port is used for peer-to-peer communication between nodes. This port is used for your node to discover and connect to other nodes on the network. It should allow traffic to/from any IP address range.
By default, the P2P port is set to 26656.
Inbound TCP connections on port 26656 (or your custom port) should be allowed from any IP address range.
Outbound TCP connections must be allowed on all ports to any IP address range.
The default P2P port can be changed in $HOME/.cheqdnode/config/config.toml.
The RPC port is intended to be used by client applications as well as the cheqd-node CLI. Your RPC port must be active and available on localhost to be able to use the CLI. It is up to a node operator whether they want to expose the RPC port to public internet.
By default, the RPC port is set to 26657
Inbound and outbound TCP connections should be allowed from destinations desired by the node operator. The default is to allow this from any IPv4 address range.
TLS for the RPC port can also be setup separately. Currently, TLS setup is not automatically carried out in the install process described below.
The default RPC port can be changed in $HOME/.cheqdnode/config/config.toml.
In addition to the P2P/RPC ports above, you need to allow the following ports in terms of firewall access for the node to function correctly:
Domain Name System (DNS): Allow outbound traffic on TCP & UDP port 53 which allows your node to make DNS queries. Without this, your node will fail to make DNS lookups necessary to reach the peer-to-peer traffic ports for other nodes.
While this setup is not compulsory, node operators with higher stakes or a need to have more robust network security may consider setting up a sentry-validator node architecture.
The default directory location for cheqd-node installations is $HOME/.cheqdnode, which computes to /home/cheqd/.cheqdnode when . Custom paths can be defined if desired.
Our are currently compiled and tested for Ubuntu 20.04 LTS, which is the recommended operating system for installation using interactive installer or binaries.
For other operating systems, we recommend using .
Further details on .
The provide REST, JSONRPC over HTTP, and JSONRPC over WebSockets. These API endpoints can provide useful information for node operators, such as healthchecks, network information, validator information etc.
Network Time Protocol (NTP): Allow outbound traffic on UDP port 123, which allows the NTP service to keep your system clock synchronised. Without this, , it can reject peer-to-peer connectivity.
Tendermint allows more complex setups in production, where the ingress/egress to a validator node is .
The is designed to setup/configure node installation as a service that runs on a virtual machine. This is the recommended setup for most scenarios when running as a validator. A validator node is expected to run 24/7 for network stability and security, and therefore cannot be autoscaled up/down across multiple instances.
If you're not running a validator node, or if you want more advanced control on your setup, is also supported. This method is also useful for running a localnet or when running a node on non-Linux systems for development purposes.
Tendermint documentation has .
; however in our testing so far this method has not been reliable and is therefore currently not recommended.