How to run a validator node on E Money Network
Run a Validator
E Money Network is based on CometBFT, which relies on a set of validators that are responsible for committing new blocks in the blockchain. These validators participate in the consensus protocol by broadcasting votes which contain cryptographic signatures signed by each validator's private key.
Validator candidates can bond their own staking tokens and have the tokens "delegated", or staked, to them by token holders. EMYC is the E Money Network's native token. Validators and their delegators will earn EMYC as block provisions and tokens as transaction fees through execution of the Tendermint consensus protocol.
Follow the documents within this section to run a validator node and a validator fullnode in the E Money Network. Here is a summary of the process:
Start by reading the node requirements to get to know the compute, memory and storage resources you need. Note also the internet bandwidth requirements.
Select a method to deploy your nodes, i.e., use a cloud managed Kubernetes, Docker, or source code.
Generate identity for the nodes. This is the first step in progressively making your nodes secure and ready to be integrated into the E Money Network.
Using YAML files, configure your nodes with user and network identity. This step enables the nodes to be recognized by other nodes in the E Money Network. Handshaking is possible after this step.
With the node identity established for the E Money Network, next you install the necessary binaries and locally generate the genesis blob and waypoint files. These will allow the node to be connected to the E Money Network.
Bootstrap the nodes. The nodes now have the E Money Network node binary running on them with the identity set. This fulfills the requirement for the E Money Network to become aware of your nodes. However, your nodes cannot connect to the E Money Network yet because these nodes are not yet in the validator set. On the E Money Network a validator can only accept another validator for connections. Until your nodes are in the validator set, they will be rejected by other validator nodes on the network.
Perform the required actions before joining the validator set. For this, you must perform a few tasks such as initialising a staking pool, delegating to operators and voters, downloading the latest versions of the genesis blob and waypoint text files and restarting your nodes.
Join the validator set. Other nodes will see your nodes and will establish connection to your nodes. Now you can stay in sync with the E Money Network blockchain by building up your database of the history of the ledger. It takes some time for your nodes to build the database. Whenever your nodes reach the latest version of the blockchain, your validator node will be able to start participating in the consensus process.
Node Requirements
To make your validator node and validator fullnode deployment hassle-free, make sure you have the resources specified in this document.
Validator and validator fullnode
Both a validator node and a validator fullnode required: For the E Money Network, we require that you run a validator node and a validator fullnode. We strongly recommend that you run the validator node and the validator fullnode on two separate and independent machines. Make sure that these machines are well-provisioned and isolated from each other. Guaranteeing the resource isolation between the validator and the validator fullnode will help ensure smooth deployment of these nodes.
Public fullnode is optional: We recommend that optionally you run a public fullnode also. However, a public fullnode is not required. If you run public fullnode also, then we strongly recommend that you run the public fullnode on a third machine that is separate and independent from either the validator or the validator fullnode machines.
Open the network ports: Make sure that you open the network ports prior to connecting to the network.
Close the network ports: Make sure that you close these ports after either being accepted or rejected for the network.
Hardware
Validators should set up a physical operation secured with restricted access. A good starting place, for example, would be co-locating in secure data centers.
Validators should expect to equip their datacenter location with redundant power, connectivity, and storage backups. Expect to have several redundant networking boxes for fibre, firewall and switching and then small servers with redundant hard drive and failover. Hardware can be on the low end of datacenter gear to start out with.
We anticipate that network requirements will be low initially. Bandwidth, CPU and memory requirements will rise as the network grows. Large hard drives are recommended for storing years of blockchain history.
Supported OS
We officially support macOS and Linux only in the following architectures:
darwin/arm64
darwin/x86_64
linux/arm64
linux/amd64
Minimum Requirements
To run mainnet or testnet validator nodes, you will need a machine with the following minimum hardware requirements:
4 or more physical CPU cores
At least 500GB of NVME SSD disk storage. Hard drive I/O speed is crucial!
At least 32GB of memory (RAM)
At least 100mbps network bandwidth
As the usage of the blockchain grows, the server requirements may increase as well, so you should have a plan for updating your server as well.
Example machine types on various clouds
AWS
c6id.8xlarge (if use local SSD)
c6i.8xlarge + io1/io2 EBS volume with 40K IOPS.
GCP
n2-standard-16 (if use local SSD)
n2-standard-32 + pd-ssd with 40K IOPS.
Motivations for hardware requirements
Hardware requirements depend on the transaction rate and storage demands. The amount of data stored by the E-Money blockchain depends on the ledger history (the number of transactions) of the blockchain and the number of on-chain states (e.g., accounts and resources). Ledger history and the number of on-chain states depend on several factors: the age of the blockchain, the average transaction rate, and the configuration of the ledger pruner.
The current hardware requirements are set considering the estimated growth over the period ending in Q1-2023. Note that we cannot provide a recommendation for archival node storage size as that is an ever-growing number.
Local SSD vs. network storage
Cloud deployments require choosing between using local or network storage such as AWS EBS, GCP PD. Local SSD provides lower latency and cost, especially relative to IOPS.
On the one hand, network storage requires additional CPU support to scale IOPS, but on the other hand, the network storage provides better support for backup snapshots and provides resilience for the nodes in scenarios where the instance is stopped. Network storage makes it easier to support storage needs for high availability.
Ports
When you are running a validator node, you are required to open network ports on your node to allow other nodes to connect to you. For fullnodes this is optional.
Last updated