The following guide will take you through all manual steps to be taken to have a fully running Sentry Node ready to be attached to your later installed Validator.

This guide assumes you have already followed steps to set up a new user named wmt to run the Sentry Node software, and that you have taken proper steps to secure this username from being logged into from external machines.

Note: DO NOT follow this guide while logged in as the root user on your machine. This is bad practice. Make a sudo group user named wmt FIRST, and configure secure login to it using SSH keys.

Now, with that warning out of the way, we shall proceed with the guide!

Step-By-Step Installation Guide

Logged in as user wmt we first start by making the base directory structure for World Mobile’s ayad and Cosmovisor binaries that are to be installed on our Node.
We do this by entering the following group of commands
Note: There is no need to replace "${USER}:${USER}" below with your own username, as ${USER} is a system variable that will always be the currently logged on user. Which, in this case, should be user wmt.
1 2 3 4 5 6
sudo mkdir -p /opt/aya sudo chown "${USER}:${USER}" /opt/aya mkdir -p /opt/aya/cosmovisor/genesis/bin mkdir -p /opt/aya/backup mkdir -p /opt/aya/logs mkdir -p /opt/aya/config
Next we set up our Node’s Aya Network Chain ID (depending on which Chain ID this Node will be running on)
We do this by entering the one of the following commands
Note: For the moment there is only one Chain ID for World Mobile Aya Chain Networks available publicly, but this will be changing soon and, as a result, there will be more than the single Chain ID option below to choose from. For now though, the single Chain ID option available is listed below.
For Aya Network Public Testnet:
1
CHAIN_ID="aya_preview_501"
Now we set up our Node’s Moniker (a friendly name for our Node to help identify it)
We do this by entering the following command
1
moniker='node'
Note: 'node' is an optional default Moniker we can use to create some ‘security by obscurity’ on the Aya Blockchain Network, by NOT having our publicly listed Sentry Node be named in any way that can be linked back to the name of our ENO. If a custom public Moniker is preferred, however, We can replace 'node' with our own chosen name at this point, keeping the ''s in place.
Now we install a required prerequisite package (jq) for the successful completion of installation steps.
We do this by entering the following command
1 2
sudo apt update sudo apt-get -q install jq -y

Now we create an installation directory for the EarthNode installation files, navigate to it, download the installer zip file, install the unzip command (if not already installed to our OS), and extract the earthnode_installer archive.

We do this by entering the following group of commands

1
2
3
4
5
6
mkdir ~/earthnode_installer
cd ~/earthnode_installer
wget https://github.com/max-hontar/aya-preview-binaries/releases/download/v0.4.1/aya_preview_501_installer_2023_09_04.zip
sudo apt-get -q install unzip -y
unzip aya_preview_501_installer_2023_09_04.zip
rm aya_preview_501_installer_2023_09_04.zip

Now we confirm that the included binaries for ayad and cosmovisor match their release_checksums values as provided by World Mobile. Check that the output of both commands match one another.
We do this by entering the following group of commands
1 2
sha256sum ayad cosmovisor cat release_checksums
Following this confirmation step, we copy the ayad and cosmovisor binary files to their home locations for use in future operations.
We do this by entering the following group of commands
1 2
cp ~/earthnode_installer/ayad /opt/aya/cosmovisor/genesis/bin/ayad cp ~/earthnode_installer/cosmovisor /opt/aya/cosmovisor/cosmovisor
Now we initialise ayad to create all of the required configuration and set up files needed for running the cosmovisor and ayad binaries.
We do this by entering the following command
1
./ayad init "${moniker}" --chain-id $CHAIN_ID --home /opt/aya
We have now populated the /opt/aya directory and its subdirectories with the necessary files to configure our Node.
Next we copy across the genesis.json file used to kickstart the aya_preview_501 Blockchain Connection.
We do this by entering the following command
1
cp ~/earthnode_installer/genesis.json /opt/aya/config/genesis.json

Before running our Sentry Node for the first time there are some initial configuration changes that need to be made to allow for smooth operation and connection the to aya_preview_501 Blockchain, and to ensure that connections between our own ENO Infrastructure’s Nodes remain robust.

So now we navigate to the aya config folder and open the config.toml file for our Sentry Node to make these changes.

We do this by entering the following group of commands

1
2
cd /opt/aya/config
nano config.toml 

We are now in the nano text editor, looking at the config.toml file contents for our Sentry Node.

Note: It is possible to search for the fields we need to edit more quickly by copying them from the below steps, pressing ctrl+w inside of nano in our terminal window, right clicking on the window, pasting the names of the values we need to edit, and pressing enter to jump to them.
We can also remove text blocks from a document that we wish to replace with new text blocks by holding down shift, selecting the existing rows we wish to remove, and then pressing ctrl+k to remove them.
We can then select and copy the replacement text from the steps shown in this guide below, and right click and paste the new settings into the terminal window.
We can undo any mistakes we’ve made while working inside nano by pressing alt+u

We now make the necessary changes to this file as follows

Change the statesync option to be enable = true instead of false

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
#######################################################
###         State Sync Configuration Options        ###
#######################################################
[statesync]
# State sync rapidly bootstraps a new node by discovering, fetching, and restoring a state machine
# snapshot from peers instead of fetching and replaying historical blocks. Requires some peers in
# the network to take and serve state machine snapshots. State sync is not attempted if the node
# has any local state (LastBlockHeight > 0). The node will have a truncated block history,
# starting from the height of the snapshot.
enable = true 

Change the addr_book_strict option to be addr_book_strict = false instead of true

1
2
3
# Set true for strict address routability rules
# Set false for private or local networks
addr_book_strict = false

Set the log_level to “error” instead of “info”
1
log_level = "error"

Set the public nodes supplied by World Mobile, that provide a statesync of historical Blockchain Data to our new Sentry Node, as persistent_peers

1
2
# Comma separated list of nodes to keep persistent connections to
persistent_peers = "692f6bb765ed3170db4fb5f5dfd27c54503d52d3@peer1-501.worldmobilelabs.com:26656,d1da4b1ad17ea35cf8c1713959b430a95743afcd@peer2-501.worldmobilelabs.com:26656"

Set the public seed node supplied by World Mobile, that helps keep your Sentry Node’s P2P address book file up to date, as a seed in seeds

1
2
# Comma separated list of seed nodes to connect to
seeds = "7836955a4d42ed85a6adb13ae4f96806ab2fd9b2@peer3-501.worldmobilelabs.com:26656"    

Set the external_address = “” field to have our own Node’s Public IP address followed by our Node’s local connection Port (default 26656), so that it can broadcast this information to other nodes over P2P (replace x.x.x.x with our Node’s Public IP).

1
2
3
4
5
6
# Address to advertise to peers for them to dial
# If empty, will use the same port as the laddr,
# and will introspect on the listener or use UPnP
# to figure out the address. ip and port are required
# example: 159.89.10.97:26656
external_address = "x.x.x.x:26656"

At this point the initial editing work to our config.toml file is done, and it can now be saved with these changes.

To save the config.toml file within nano editor we press ctrl+x and then press y, followed by enter. This will save the file with the same filename as before.

Next we need to make some initial changes to the app.toml file contents for our Sentry Node.

Luckily, the app.toml file we need to edit is in the same directory as config.toml.

So we do this by entering the following command

1
nano app.toml

We now make the necessary changes to this file as follows

Replace GRPC port to not overlap with standard Prometheus port, replacing 9090 with 29090

1
2
# Address defines the gRPC server address to bind to.
address = "localhost:29090"

make sure the gas price units for our network to be 0uswmt

1
2
3
4
# 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 = "0uswmt"

Change the API Configuration section enable option to be enable = true instead of false

1
2
3
4
[api]

# Enable defines if the API server should be enabled.
enable = true

At this point the initial editing work to our app.toml file is done, and it can now be saved with these changes.

To save the app.toml file within nano editor we press ctrl+x and then press y, followed by enter. This will save the file with the same filename as before.

Now we need to export some environment variables to get our system ready to run our Sentry Node for the first time.

We do this by entering the following group of commands

1
2
3
4
5
6
export DAEMON_NAME=ayad
export DAEMON_HOME=/opt/aya
export DAEMON_DATA_BACKUP_DIR=/opt/aya/backup
export DAEMON_RESTART_AFTER_UPGRADE=true
export DAEMON_ALLOW_DOWNLOAD_BINARIES=true
ulimit -Sn 4096

Before proceeding to start up our Sentry Node for the first time we will need to install some live monitoring software to see what it is doing once active.
We do this by entering the following group of commands
1 2 3 4 5 6
cd ~/ mkdir nodebase-tools cd nodebase-tools wget -O ayaview.zip https://github.com/nodebasewm/download/blob/main/ayaview.zip?raw=true unzip ayaview.zip rm ayaview.zip
We will also quickly add a new Firewall Rule to our Server to allow Incoming connections to come into our Node once it has started.
What command we need to enter to do this will depend on how our Server is set up to handle Firewall Rules.
If our Server is using ufw to handle Firewall Rules (most likely for most installs) we need to enter the following command to accept Incoming connections over Port 26656 (a Sentry Node’s default Port)
1
sudo ufw allow from any to any port 26656 proto tcp
If our Server is using iptables to handle Firewall Rules we need to enter the following group of commands to accept Incoming connections over Port 26656 (a Sentry Node’s default Port)
1 2
sudo iptables -I INPUT -p tcp -m tcp --dport 26656 -j ACCEPT sudo service iptables save
If we haven’t yet set up our Firewall Rules at all, we can follow the steps laid out over at Firewall Settings to do this.

With the Firewall Rule added we are now going to start up our Sentry Node for the first time, manually.

Note: Later we will be setting up a service file to have our Node automatically restart on Server reboot, or following a crash. For now though we will proceed manually.

We do this by entering the following group of commands

Note: There is a lot of automated scripting shown below that has to be run before first boot of Node to ensure that it will start to sync the chain. It will not be needed again for future start ups.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
INTERVAL=15000
LATEST_HEIGHT=$(curl -s "http://peer1-501.worldmobilelabs.com:26657/block" | jq -r .result.block.header.height)
BLOCK_HEIGHT=$((($((LATEST_HEIGHT / INTERVAL)) - 1) * INTERVAL + $((INTERVAL / 2))))
TRUST_HASH=$(curl -s "http://peer1-501.worldmobilelabs.com:26657/block?height=${BLOCK_HEIGHT}" | jq -r .result.block_id.hash)

# Set available RPC servers (at least two) required for light client snapshot verification
sed -i -E "s|^(rpc_servers[[:space:]]+=[[:space:]]+).*$|\1\"http://peer1-501.worldmobilelabs.com:26657,http://peer2-501.worldmobilelabs.com:26657\"|" /opt/aya/config/config.toml
# Set "safe" trusted block height
sed -i -E "s|^(trust_height[[:space:]]+=[[:space:]]+).*$|\1$BLOCK_HEIGHT|" /opt/aya/config/config.toml
# Set "qsafe" trusted block hash
sed -i -E "s|^(trust_hash[[:space:]]+=[[:space:]]+).*$|\1\"$TRUST_HASH\"|" /opt/aya/config/config.toml
# Set trust period, should be ~2/3 unbonding time (3 weeks for preview network)
sed -i -E "s|^(trust_period[[:space:]]+=[[:space:]]+).*$|\1\"302h0m0s\"|" /opt/aya/config/config.toml

cd ~/earthnode_installer
/opt/aya/cosmovisor/cosmovisor run start --home /opt/aya &>>/opt/aya/logs/cosmovisor.log &

We have now started our Node software for the first time!

Now we shall proceed to monitoring it.

We do this by entering the following group of commands

1
2
cd ~/nodebase-tools 
./ayaview

The ayaview software will start up and visually show us the Blockchain data being downloaded to bring us up to date with the current tip of the chain.

We will know it has caught up to the current state of the Chain once the Block Height column stops counting up so quickly, and starts adding just 1 new Block Height to left hand table only around every 5-6 seconds.

Once we are up to date with the current tip of the Chain we need to do some tidy up work on both the config.toml and app.toml files that we edited before the first run of our Node.

We can do this by first pressing q on the ayaview console to quit out of it and then by entering the following group of commands

1
2
cd /opt/aya/config/
nano config.toml

We are now back in the nano text editor, looking at the config.toml file contents for our Sentry Node.

We now make the necessary changes to this file as follows

change the statesync option to be enable = false instead of true

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
#######################################################
###         State Sync Configuration Options        ###
#######################################################
[statesync]
# State sync rapidly bootstraps a new node by discovering, fetching, and restoring a state machine
# snapshot from peers instead of fetching and replaying historical blocks. Requires some peers in
# the network to take and serve state machine snapshots. State sync is not attempted if the node
# has any local state (LastBlockHeight > 0). The node will have a truncated block history,
# starting from the height of the snapshot.
enable = false

At this point the tidy up editing work to our config.toml file is done, and it can now be saved with these changes.

To save the config.toml file within nano editor we press ctrl+x and then press y, followed by enter. This will save the file with the same filename as before.

Next we need to make a change to the app.toml file contents for our Sentry Node.
We do this by entering the following command
1
nano app.toml
And we edit the following section of the file to the below setting, changing it from being 0 to being 100.
Note: Setting the snapshot-interval to 100 will ensure that we can use our Sentry Node to kickstart our Validator later on. Which will allow us to set up our Validator without ever exposing its external IP to the rest of the Network.
1 2 3
# snapshot-interval specifies the block interval at which local state sync snapshots are # taken (0 to disable). snapshot-interval = 100
At this point the tidy up editing work to our app.toml file is done, and it can now be saved with these changes.
To save the app.toml file within nano editor we press ctrl+x and then press y, followed by enter. This will save the file with the same filename as before.
Note: These config.toml and app.toml file edits above should only be completed once we are SURE that our Node is up to date with the current state of the Chain. We DO NOT make this edit before our Node has fully synced to the current Block Height ayaview, and is adding a new Block around every 5-6 seconds.

At present, our Node should be running along nicely in the background and keeping up to date with the current state of the Chain, but we still have to complete some more steps before we have fully completed our Sentry Node’s initial set up.

First we need to ensure that we have saved all of our Node’s important data, needed for future reference both by tools and by us.

We do this by entering the following group of commands

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
cd ~/earthnode_installer
# Get the address of the validator
validator_address=$(./ayad tendermint show-address --home /opt/aya)
# Use 'jq' to create a JSON object with the 'moniker', 'operator_address' and 'validator_address' fields
jq --arg key0 'moniker' \
--arg value0 "$moniker" \
--arg key1 'validator_address' \
--arg value1 "$validator_address" \
'. | .[$key0]=$value0 | .[$key1]=$value1'  \
<<<'{}' | tee /opt/aya/sentry.json

This will save our Sentry Node’s data to the filename sentry.json in the /opt/aya directory.

Next we want to set up some symbolic links for the ‘ayad’ and ‘cosmovisor’ binaries so that their specific commands can be called from anywhere on our Node’s filesystem.
We do this by entering the following group of commands
1 2
sudo ln -s /opt/aya/cosmovisor/current/bin/ayad /usr/local/bin/ayad >/dev/null 2>&1 sudo ln -s /opt/aya/cosmovisor/cosmovisor /usr/local/bin/cosmovisor >/dev/null 2>&1

And finally, we want to create a systemd service file that will allow our Node to automatically start on a reboot of our Server and to automatically attempt to restart itself on any crashes.

We do this by entering the following group of commands

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
sudo tee /etc/systemd/system/cosmovisor.service > /dev/null <<EOF
# Start the 'cosmovisor' daemon
# Create a Systemd service file for the 'cosmovisor' daemon
[Unit]
Description=Aya Node
After=network-online.target

[Service]
User=$USER
# Start the 'cosmovisor' daemon with the 'run start' command and write output to journalctl
ExecStart=$(which cosmovisor) run start --home /opt/aya
# Restart the service if it fails
Restart=always
# Restart the service after 3 seconds if it fails
RestartSec=3
# Set the maximum number of file descriptors
LimitNOFILE=4096

# Set environment variables for data backups, automatic downloading of binaries, and automatic restarts after upgrades
Environment="DAEMON_NAME=ayad"
Environment="DAEMON_HOME=/opt/aya"
Environment="DAEMON_DATA_BACKUP_DIR=/opt/aya/backup"
Environment="DAEMON_ALLOW_DOWNLOAD_BINARIES=true"
Environment="DAEMON_RESTART_AFTER_UPGRADE=true"

[Install]
# Start the service on system boot
WantedBy=multi-user.target
EOF

This will have added a new service file to our Server under the path /etc/systemd/system named cosmovisor.service. This service file is what will be called when the Server reboots, or if our Node crashes.

With the service now created, we now need to enable it for future use.

We do this by entering the following group of commands

1
2
3
4
# Reload the Systemd daemon
sudo systemctl daemon-reload
# Enable the 'cosmovisor' service to start on system boot
sudo systemctl enable cosmovisor

We can now confirm that our service is ready to be started by entering the following command.

1
sudo systemctl status cosmovisor.service

This should show us the following

1
2
3
○ cosmovisor.service - Aya Node
    Loaded: loaded (/etc/systemd/system/cosmovisor.service; enabled; vendor preset: enabled)
    Active: inactive (dead)

If we see this, we know we have successfully installed our Aya Node Service.

All that remains now, is to close down our first run of our Node and to restart it using this newly installed Service instead of manually launching our Node as before.

To do this, we need to identify what the current process number of our still running first run Node is.

We do this by entering the following command

1
ps -ef | grep cosmovisor

The output of this command should something like this

1
2
3
wmt   33619   33486  0 03:11 pts/0    00:00:02 /opt/aya/cosmovisor/cosmovisor run start --home /opt/aya
wmt   33625   33619 33 03:11 pts/0    00:16:16 /opt/aya/cosmovisor/genesis/bin/ayad start --home /opt/aya
wmt   34703   33486  0 03:59 pts/0    00:00:00 grep --color=auto cosmovisor

What we are looking for is the leftmost number appearing for the line that contains “/opt/aya/cosmovisor/cosmovisor run start –home /opt/aya” on its right hand side

In the above example, this number is 33619.

Our number will be different, and we need to take a note of it for the next step.

Once we have this number we can now use it to turn off our first run Node that has served us so well to get our Blockchain sync up to date with the current tip of the Chain.

We do this by entering the following command

Note: We replace <number> with our noted number from above at this point, removing the surrounding <>

1
sudo kill <number>

We have now killed our running Node, but don’t worry, we are going to bring it right back to life. Except this time, as a Service!

To do this we enter the following command

1
sudo systemctl start cosmovisor.service

Now we need to check that cosmovisor.service has started properly.

We do this by entering the following command

1
sudo systemctl status cosmovisor.service

When we ran this command previously it said our Aya Node Service was inactive (dead), this time it should say something like the following

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
cosmovisor.service - Aya Node
    Loaded: loaded (/etc/systemd/system/cosmovisor.service; enabled; vendor preset: enabled)
    Active: active (running) since Wed 2023-03-01 04:06:05 UTC; 4s ago
Main PID: 34791 (cosmovisor)
    Tasks: 15 (limit: 4573)
    Memory: 382.3M
        CPU: 5.063s
    CGroup: /system.slice/cosmovisor.service
            ├─34791 /usr/local/bin/cosmovisor run start --home /opt/aya
            └─34796 /opt/aya/cosmovisor/genesis/bin/ayad start --home /opt/aya

Mar 01 04:06:05 localhost systemd[1]: Started Aya Node.
Mar 01 04:06:05 localhost cosmovisor[34791]: 4:06AM INF running app args=["start","--home","/opt/aya"] module=cosmovisor path=/opt/aya/cosmovisor/genesis/bin/ayad

Some details will be different to the above example, but this should be the general layout. The important point is that it should say ‘active (running)’ in green.

We can now confirm everything is continuing to sync from the Blockchain by going back to our ayaview console and watching to see if the Block Height is still slowly ticking upwards as before.
We do this by entering the following group of commands
1 2
cd ~/nodebase-tools ./ayaview
If everything is working as it should our ayaview console should now be showing us the Aya Blockchain ticking on by once more, around every 5-6 seconds.

And that’s it!!!

Congratulations! We have now successfully completed setting up a Sentry Node!

Note: At the moment though, our Sentry Node does not yet have a Validator that it connects to for protecting it, and passing on its Block Votes.
Which means it hasn’t yet got to fulfil its true purpose in life just yet (much like many of us).
So, to fix this, we will tackle connecting our newly set up Sentry Node to our EarthNode Validator, as well as any other running Sentry Nodes in our Infrastructure, in a separate guide.
For now though, we can simply bask in the glory of setting up a well running Sentry Node!

2.2 - 2. Validator Node Manual Installation

Full Installation Guide for installing a Validator Node

Written by Nodebase Team member intertree (Johnny Kelly)

Introduction

The following guide will take you through all manual steps to be taken to have a fully running Validator Node. Taking you through how attach it to your prevously installed Sentry Nodes, and how to register your EarthNode Stake Pool via both an On-Chain ENNFT Registration Transaction on the Cardano Network as well as an On-Chain Validator Registration Transaction on the Aya Network.

A number of elements of the set up process are very similiar to that of setting up a Sentry Node.

However additional steps will be required to ensure that the Validator only ever connects to other Nodes under your own control, so that your Validator Node’s ID and IP adddress are never publicised to the rest of the Blockchain Network.

This will require changing settings on both your existing Sentry Nodes and your newly set up Validator, to ensure proper cross connections are in place.

Details of what changes need to be made, on both sides, will appear in this guide.

This guide assumes you have already set up the Sentry Nodes that will be used to connect to this Validator using the steps laid out over at Sentry Node Manual Installation.

Note: In order for full Validator set-up to work without ever connecting to a World Mobile supplied Node, you will need to have two working Sentry Nodes in your Infrastructure.
As they will be acting as the two required RPC Servers to help kickstart your Validator syncing to the tip of the Chain.

This guide also assumes that all IP addresses being used to established cross connections between your Sentry Nodes and your Validator will be Private IP addresses, and that each will be visable to one another.

Note: In order for this to be the case all of your Nodes will need to appear under the same IP subnet. To achieve this within an Infrastructure in which you have Nodes running across either multiple Cloud Providers or a hybrid mix of Cloud and Baremetal Servers you will need to install and run a VPN Service that will make each of your Nodes appear to eachother as being on the same local network.
Setting up of such a VPN Service is outside the scope of this guide, but it is highly recommended that a VPN Service be used in any set up where Nodes do not already have Private IPs, on the same local subnet, that can be utilised for the task.
If all of your Nodes are running on the same Cloud Provider it is highly likely that they will already be running on the same Private IP subnet, and that that your Cloud Provider will make thse Private IPs available to you, but it must be highlighted that relying on a single Cloud Provider for all of your Node Infrastructure also creates a single point of failure for your EarthNode Stake Pool.
The level of acceptance you have for this single point of failure risk, is up to you.

And finally, this guide assumes you have already followed steps to set up a new user named wmt to run the Sentry Node software, and that you have taken proper steps to secure this username from being logged into from external machines.

Note: DO NOT follow this guide while logged in as the root user on your machine. This is bad practice. Make a sudo group user named wmt FIRST, and configure secure login to it using SSH keys.

Now, with this introduction, and its various warnings, out of the way, we shall proceed with the guide!

Step-By-Step Installation Guide

Logged in as user wmt we first start by making the base directory structure for World Mobile’s ayad and Cosmovisor binaries that are to be installed on our Node.
We do this by entering the following group of commands
Note: There is no need to replace "${USER}:${USER}" below with your own username, as ${USER} is a system variable that will always be the currently logged on user. Which, in this case, should be user wmt.
1 2 3 4 5 6
sudo mkdir -p /opt/aya sudo chown "${USER}:${USER}" /opt/aya mkdir -p /opt/aya/cosmovisor/genesis/bin mkdir -p /opt/aya/backup mkdir -p /opt/aya/logs mkdir -p /opt/aya/config
Next we set up our Node’s Aya Network Chain ID (depending on which Chain ID this Node will be running on)
We do this by entering the one of the following commands
Note: For the moment there is only one Chain ID for World Mobile Aya Chain Networks available publicly, but this will be changing soon and, as a result, there will be more than the single Chain ID option below to choose from. For now though, the single Chain ID option available is listed below.
For Aya Network Public Testnet:
1
CHAIN_ID="aya_preview_501"
Now we set up our Node’s Account name (a friendly name for Our Operator Wallet Address that will be used to run our EarthNode Stake Pool) and Moniker (a friendly name for our Validator Node that will appear On-Chain for people to Delegate to). We will also save our Account name to a file for future reference.
We do this by entering the following group of commands
1 2 3
account='<account>' moniker='<moniker>' echo "$account" > /opt/aya/account
Note: We replace <account> and <moniker> with our own chosen names at this point, removing the surrounding <> They can be the same name.
Now we install a required prerequisite package (jq) for the successful completion of installation steps.
We do this by entering the following command
1 2
sudo apt-get update sudo apt-get -q install jq -y

We do this by entering the following group of commands

1
2
3
4
5
6
mkdir ~/earthnode_installer
cd ~/earthnode_installer
wget https://github.com/max-hontar/aya-preview-binaries/releases/download/v0.4.1/aya_preview_501_installer_2023_09_04.zip
sudo apt-get -q install unzip -y
unzip aya_preview_501_installer_2023_09_04.zip
rm aya_preview_501_installer_2023_09_04.zip

Now we confirm that the included binaries for ayad and cosmovisor match their release_checksums values as provided by World Mobile. Check that the output of both commands match one another.
We do this by entering the following group of commands
1 2
sha256sum ayad cosmovisor cat release_checksums
Following this confirmation step, we copy the ayad and cosmovisor binary files to their home locations for use in future operations.
We do this by entering the following group of commands
1 2
cp ~/earthnode_installer/ayad /opt/aya/cosmovisor/genesis/bin/ayad cp ~/earthnode_installer/cosmovisor /opt/aya/cosmovisor/cosmovisor
Now we initialise ayad to create all of the required configuration and set up files needed for running the cosmovisor and ayad binaries.
We do this by entering the following command
1
./ayad init "${moniker}" --chain-id $CHAIN_ID --home /opt/aya
We have now populated the /opt/aya directory and its subdirectories with the necessary files to configure our Node.
Next we copy across the genesis.json file used to kickstart the aya_preview_501 Blockchain Connection.
We do this by entering the following command
1
cp ~/earthnode_installer/genesis.json /opt/aya/config/genesis.json

Now we are going to create a new Operator Account, and display its Seed Phrase.

We do this by entering the following group of commands

Note: During this step you will be asked to set up a spending password for your Account, this password will be needed when sending your On-Chain Validator Registration Transaction in a later step. Enter in a secure password to be used for this.

1
2
3
4
5
6
7
8
9
# Create a new operator account and store the JSON output in the 'operator_json' variable
operator_json=$(./ayad keys add "${account}" --output json --home /opt/aya)

# Extract the address from the 'operator_json' variable and store it in the 'operator_address' variable
operator_address=$(echo "$operator_json" | jq '.address' | sed 's/\"//g')

# Display the mnemonic and address of the operator account
echo -e "\n-- [ONLY FOR YOUR EYES] Store this information safely, the mnemonic is the only way to recover your account. \n"
echo "$operator_json" | jq -M

Note: This Operator Account is similar to a Cardano Wallet, and as such it will have along with it a Seed Phrase to allow for its future recovery. It is vitally important that we keep this Seed Phrase in a safe and secure location in case we ever need to recover our Account on a different machine in the future. The Operator Account is what controls our EarthNode Stake Pool’s Registration and Pool settings, so if we lose access to this Account we will lose access to our EarthNode Stake Pool altogether.

Next we are going to need the obtain our Validator Node’s Node ID in order to complete some work over on our already configured Sentry Nodes in the next section of the guide.
We do this by entering the following command
1
./ayad tendermint show-node-id --home /opt/aya
Note: At this point we want to copy and paste the output of this command to a separate, temporary, text file on our machine for use in the Sentry Node section of this guide. Which is starting now.

Now we need to prepare our Sentry Nodes for connection from our Validator.

Note: During the following section of the guide work will be being done on both of our Sentry Nodes to make them ready for Validator first contact. However, to simplify the instructions, the steps to take on our Sentry Nodes will only be run through once.
We need to Make sure to complete the steps below on both of our Sentry Nodes. To do this, we will need to connect to each of them in separate terminal windows. Remember, these edits are not to be done on our Validator Node.
We also need to make sure to not close our existing Validator Node terminal window while working on the separate terminal windows of our already ocnfigured Sentry Nodes. As doing so will break future steps in Valdiator set up.

After connecting in a separate terminal window to our already configured Sentry Node we are now going to obtain its Node ID.
We do this by entering the following command
1
ayad tendermint show-node-id --home /opt/aya
Note: At this point we want to copy and paste the output of this command to a separate temporary text file on our machine for use later in this guide.
Continuing on our already configured Sentry Node we are now going to make an edit to its config.toml file to allow for remote RPC connections.
We do this by entering the following group of commands
1 2
cd /opt/aya/config nano config.toml
We are now in the nano text editor, looking at the config.toml file contents for our already configured Sentry Node.
Note: It is possible to search for the fields we need to edit more quickly by copying them from the below steps, pressing ctrl+w inside of nano in our terminal window, right clicking on the window, pasting the names of the values we need to edit, and pressing enter to jump to them.
We can also remove text blocks from a document that we wish to replace with new text blocks by holding down shift, selecting the existing rows we wish to remove, and then pressing ctrl+k to remove them.
We can then select and copy the replacement text from the steps shown in this guide below, and right click and paste the new settings into the terminal window.
We can undo any mistakes we’ve made while working inside nano by pressing alt+u
We now make the necessary changes to this file as follows
- Add our Validator’s Node ID to unconditional_peer_ids
  1 2
  # List of node IDs, to which a connection will be (re)established ignoring any existing limits unconditional_peer_ids = "<Validator Node ID>"
Note: We replace <Validator Node ID> with our separately copied Validator Node ID from above at this point, removing the surrounding <>
- Add our Validator’s Node ID to private_peer_ids
  1 2
  # Comma separated list of peer IDs to keep private (will not be gossiped to other peers) private_peer_ids = "<Validator Node ID>"
Note: We replace <Validator Node ID> with our separately copied Validator Node ID from above at this point, removing the surrounding <>
- Set the laddr = “tcp://127.0.0.1:26657” field to be laddr = “tcp://0.0.0.0:26657” in the RPC Server Configuration Options section of the file.
  1 2
  # TCP or UNIX socket address for the RPC server to listen on laddr = "tcp://0.0.0.0:26657"
At this point the editing work to our already configured Sentry Node’s config.toml file is done, and it can now be saved with these changes.
To save the config.toml file within nano editor we press ctrl+x and then press y, followed by enter. This will save the file with the same filename as before.
Next we may need to make a change to the app.toml file contents for our already configured Sentry Node.
Luckily, the app.toml file we need to edit is in the same directory as config.toml.
So we do this by entering the following command
1
nano app.toml
We now make the necessary change to this file as follows
- Set snapshot interval to 100 instead of 0 to activate the snapshot manager
Note: It is quite possible that our already configured Sentry Node’s snapshot-interval is already set to be 100. If this is the case, no further changes are neccessary.
1 2 3
# snapshot-interval specifies the block interval at which local state sync snapshots are # taken (0 to disable). snapshot-interval = 100
At this point the editing work to our app.toml file is done, and it can now be saved with these changes.
To save the app.toml file within nano editor we press ctrl+x and then press y, followed by enter. This will save the file with the same filename as before.
Now we are going to add a new Firewall Rule on our already configured Sentry Node to Allow traffic from our Validator Node’s Private IP address to come in over Port 26657.
What command we need to enter to do this will depend on how our Server is set up to handle Firewall Rules.
If our Server is using ufw to handle Firewall Rules (most likely for most installs) we need to enter the following command
1
sudo ufw allow from <Validator.Private.IP.address> to any port 26657 proto tcp
If our Server is using iptables to handle Firewall Rules we need to enter the following group of commands
1 2
sudo iptables -I INPUT -p tcp -s <Validator.Private.IP.address> --dport 26657 -j ACCEPT sudo service iptables save
Note: We replace <Validator.Node.Private.IP> with our Validator Node’s IP at this point, removing the surrounding <>

Now we need to check that our changes didn’t do anything to prevent our already configured Sentry Node from being able to start up its cosmovisor Service.

We do this by entering the following group of commands

1
2
sudo systemctl restart cosmovisor.service
sudo systemctl status cosmovisor.service

If all of our changes have not caused any issues with our already configured Sentry Node’s cosmovisor Service we should see something very similar to the following output.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
● cosmovisor.service - Aya Node
     Loaded: loaded (/etc/systemd/system/cosmovisor.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2023-03-15 16:27:02 UTC; 6s ago
   Main PID: 122758 (cosmovisor)
      Tasks: 15 (limit: 4660)
     Memory: 568.5M
        CPU: 9.121s
     CGroup: /system.slice/cosmovisor.service
             ├─122758 /usr/local/bin/cosmovisor run start --home /opt/aya 
             └─122764 /opt/aya/cosmovisor/genesis/bin/ayad start --home /opt/aya

Mar 15 16:27:02 wmt-sentry1 systemd[1]: Started Aya Node.
Mar 15 16:27:02 wmt-sentry1 cosmovisor[122758]: 4:27PM INF running app args=["start","--home","/opt/aya"] module=cosmovisor path=/opt/aya/cosmovisor/genesis/bin/ayad
Mar 15 16:27:08 wmt-sentry1 cosmovisor[122764]: 4:27PM ERR Error dialing peer err="dial tcp <Validator.Node.Private.IP>:26656: connect: connection refused" module=p2p

Note: Even though we see a connect: connection refused error at this point this is only due to the fact that we haven’t yet started up our Validator for the first time. Seeing this error simply means our configuration has been laoded into our already configured Sentry Node successfully. Because we entered our Validator Node’s ID into the unconditional_peers section of the config.toml file, this should not pose an issue.

We have now concluded our required edits to our already configured Sentry Node’s set up. We need to make sure that we have completed the above steps to both of our Sentry Nodes.

We can now to return to our Valdiator Node to complete the rest of its set up.

Before running our Validator Node for the first time there are some initial configuration changes that need to be made to allow for smooth operation and connection the to aya_preview_501 Blockchain, and to ensure that connections between our own ENO Infrastructure’s Nodes remain robust.

So now we navigate to the aya config folder and open the config.toml file for our Validator Node to make these changes.

We do this by entering the following group of commands

1
2
cd /opt/aya/config
nano config.toml 

We are now in the nano text editor, looking at the config.toml file contents for our Validator Node.

We now make the necessary changes to this file as follows

Change the statesync option to be enable = true instead of false

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
#######################################################
###         State Sync Configuration Options        ###
#######################################################
[statesync]
# State sync rapidly bootstraps a new node by discovering, fetching, and restoring a state machine
# snapshot from peers instead of fetching and replaying historical blocks. Requires some peers in
# the network to take and serve state machine snapshots. State sync is not attempted if the node
# has any local state (LastBlockHeight > 0). The node will have a truncated block history,
# starting from the height of the snapshot.
enable = true 

Change the pex option to be pex = false instead of true

1
2
# Set true to enable the peer-exchange reactor
pex = false

Change the addr_book_strict option to be addr_book_strict = false instead of true

1
2
3
# Set true for strict address routability rules
# Set false for private or local networks
addr_book_strict = false

Change the persistent_peers_max_dial_period option to be persistent_peers_max_dial_period = “10s” instead of “0s”

1
2
# Maximum pause when redialing a persistent peer (if zero, exponential backoff is used)
persistent_peers_max_dial_period = "10s"

Set the log_level to “error” instead of “info”
1
log_level = "error"

Set our already configured Sentry Nodes, that will seed Blockchain Data to our new Sentry Node, as persistent_peers

1
2
# Comma separated list of nodes to keep persistent connections to
persistent_peers = "<Sentry Node 1 Node ID>@<Sentry.Node1.Private.IP>:26656,<Sentry Node2 Node ID>@<Sentry.Node2.Private.IP>:26656"

Note: We replace <Sentry Node 1 ID> and <Sentry Node 2 ID> with our separately copied Sentry Node IDs from above, as well as <Sentry.Node1.Private.IP> and <Sentry.Node2.Private.IP> with each of our already configured Sentry Node’s IPs, at this point, removing the surrounding <>

Add our alreay configured Sentry Node IDs to unconditional_peer_ids

1
2
# List of node IDs, to which a connection will be (re)established ignoring any existing limits
unconditional_peer_ids = "<Sentry Node 1 ID>,<Sentry Node 2 ID>"

Note: We replace <Sentry Node 1 ID> and <Sentry Node 2 ID> with our separately copied Sentry Node IDs from above at this point, removing the surrounding <>

At this point the initial editing work to our config.toml file is done, and it can now be saved with these changes.

To save the config.toml file within nano editor we press ctrl+x and then press y, followed by enter. This will save the file with the same filename as before.

Next we need to make some initial changes to the app.toml file contents for our Validator Node.

Luckily, the app.toml file we need to edit is in the same directory as config.toml.

So we do this by entering the following command

1
nano app.toml

We now make the necessary changes to this file as follows

Replace GRPC port to not overlap with standard Prometheus port, replacing 9090 with 29090

1
2
# Address defines the gRPC server address to bind to.
address = "localhost:29090"

Make sure that the gas price units for our network are set to be 0uswmt

1
2
3
4
# 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 = "0uswmt"

Change the API Configuration section enable option to be enable = true instead of false

1
2
3
4
[api]

# Enable defines if the API server should be enabled.
enable = true

At this point the editing work to our app.toml file is done, and it can now be saved with these changes.

To save the app.toml file within nano editor we press ctrl+x and then press y, followed by enter. This will save the file with the same filename as before.

Now we need to export some environment variables to get our system ready to run our Validator Node for the first time.

We do this by entering the following group of commands

1
2
3
4
5
6
export DAEMON_NAME=ayad
export DAEMON_HOME=/opt/aya
export DAEMON_DATA_BACKUP_DIR=/opt/aya/backup
export DAEMON_RESTART_AFTER_UPGRADE=true
export DAEMON_ALLOW_DOWNLOAD_BINARIES=true
ulimit -Sn 4096

Before proceeding to start up our Valdiator Node for the first time we will need to install some live monitoring software to see what it is doing once active.
We do this by entering the following group of commands
1 2 3 4 5 6
cd ~/ mkdir nodebase-tools cd nodebase-tools wget -O ayaview.zip https://github.com/nodebasewm/download/blob/main/ayaview.zip?raw=true unzip ayaview.zip rm ayaview.zip
Now we shall set up some variables that will be used in the next step to allow us to quickly manually start up our Validator, and let it begin its statesync process.
We do this by entering the following group of commands
Note: We need to make sure we have replaced <Sentry.Node1.Private.IP> and <Sentry.Node2.Private.IP> below with the Private IP addresses that come from each of our Sentry Nodes, removing the surrounding <>s, before entering this group of commands.
We can do this by copying the above group of commands below into a separate, temporary, text file and making any required edits before finally copying and pasting them into our Validator Node’s terminal window.
1 2
RPC_PEER_1="<Sentry.Node1.Private.IP>" RPC_PEER_2="<Sentry.Node2.Private.IP>"
At this point, before running our Node Software for the first time, we are going to check that our Firewall Rules are set up to match the recommended settings laid out over at Firewall Settings
We can check our Node’s current settings match by entering the following command
1
sudo ufw status numbered
If they match we can carry on with the guide. If not, we will follow the Validator Firewall setup steps on the Firewall settings page and then continue with the guide.

With the Firewall Rules now verified or added, and our Sentry Nodes’ Private IP addresses set, we are now going to start up our Valdiator Node for the first time, manually.

Note: Later we will be setting up a service file to have our Node automatically restart on Server reboot, or following a crash. For now though we will proceed manually.

We do this by entering the following group of commands

Note: There is a lot of automated scripting shown below that has to be run before first boot of Node to ensure that it will start to sync the chain. It will not be needed again for future start ups.
We need to make sure that this whole set of commands below is copied and pasted into our Terminal window as a single, whole, blob, and is not entered piecemeal, in order for the blob to work properly.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
INTERVAL=100
LATEST_HEIGHT=$(curl -s ""${RPC_PEER_1}":26657/block" | jq -r .result.block.header.height)
BLOCK_HEIGHT=$((($((LATEST_HEIGHT / INTERVAL)) - 1) * INTERVAL + $((INTERVAL / 2))))
TRUST_HASH=$(curl -s ""${RPC_PEER_1}":26657/block?height=${BLOCK_HEIGHT}" | jq -r .result.block_id.hash)

# Set available RPC servers (at least two) required for light client snapshot verification
sed -i -E "s|^(rpc_servers[[:space:]]+=[[:space:]]+).*$|\1\""${RPC_PEER_1}":26657,"${RPC_PEER_2}":26657\"|" /opt/aya/config/config.toml
# Set "safe" trusted block height
sed -i -E "s|^(trust_height[[:space:]]+=[[:space:]]+).*$|\1$BLOCK_HEIGHT|" /opt/aya/config/config.toml
# Set "qsafe" trusted block hash
sed -i -E "s|^(trust_hash[[:space:]]+=[[:space:]]+).*$|\1\"$TRUST_HASH\"|" /opt/aya/config/config.toml
# Set trust period, should be ~2/3 unbonding time (3 weeks for preview network)
sed -i -E "s|^(trust_period[[:space:]]+=[[:space:]]+).*$|\1\"302h0m0s\"|" /opt/aya/config/config.toml

cd ~/earthnode_installer
/opt/aya/cosmovisor/cosmovisor run start --home /opt/aya &>>/opt/aya/logs/cosmovisor.log &

We have now started our Node software for the first time!

Now we shall proceed to monitoring it.

We do this by entering the following group of commands

1
2
cd ~/nodebase-tools 
./ayaview

The ayaview software will start up and visually show us the Blockchain data being downloaded to bring us up to date with the current tip of the chain.

Once we are up to date with the current tip of the Chain we need to do some tidy up work on both the config.toml and app.toml files that we edited before the first run of our Node.

We can do this by first pressing q on the ayaview console to quit out of it and then by entering the following group of commands

1
2
cd /opt/aya/config/
nano config.toml

We are now back in the nano text editor, looking at the config.toml file contents for our Validator Node.

We now make the necessary changes to this file as follows

change the statesync option to be enable = false instead of true

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
#######################################################
###         State Sync Configuration Options        ###
#######################################################
[statesync]
# State sync rapidly bootstraps a new node by discovering, fetching, and restoring a state machine
# snapshot from peers instead of fetching and replaying historical blocks. Requires some peers in
# the network to take and serve state machine snapshots. State sync is not attempted if the node
# has any local state (LastBlockHeight > 0). The node will have a truncated block history,
# starting from the height of the snapshot.
enable = false

At this point the tidy up editing work to our config.toml file is done, and it can now be saved with these changes.

To save the config.toml file within nano editor we press ctrl+x and then press y, followed by enter. This will save the file with the same filename as before.

Note: This config.toml file edit above should only be completed once we are SURE that our Node is up to date with the current state of the Chain. We DO NOT make this edit before our Node has fully synced to the current Block Height ayaview, and is adding a new Block around every 5-6 seconds.

First we to ensure that we have saved all of our Node’s important data, needed for future reference both by tools and by us.

We do this by entering the following group of commands

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
cd ~/earthnode_installer
# Get the address of the validator
validator_address=$(./ayad tendermint show-address --home /opt/aya)

# Use 'jq' to create a JSON object with the 'moniker', 'operator_address' and 'validator_address' fields
jq --arg key0 'moniker' \
   --arg value0 "$moniker" \
   --arg key1 'operator_address' \
   --arg value1 "$operator_address" \
   --arg key2 'validator_address' \
   --arg value2 "$validator_address" \
   '. | .[$key0]=$value0 | .[$key1]=$value1 | .[$key2]=$value2' \
 <<<'{}' | tee /opt/aya/registration.json  
 

This will save our Validator Node’s data to the filename registration.json in the /opt/aya directory.

Next we want to set up some symbolic links for the ‘ayad’ and ‘cosmovisor’ binaries so that their specific commands can be called from anywhere on our Node’s filesystem.
We do this by entering the following group of commands
1 2
sudo ln -s /opt/aya/cosmovisor/current/bin/ayad /usr/local/bin/ayad >/dev/null 2>&1 sudo ln -s /opt/aya/cosmovisor/cosmovisor /usr/local/bin/cosmovisor >/dev/null 2>&1

And finally, we want to create a systemd service file that will allow our Node to automatically start on a reboot of our Server and to automatically attempt to restart itself on any crashes.

We do this by entering the following group of commands

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
sudo tee /etc/systemd/system/cosmovisor.service > /dev/null <<EOF
# Start the 'cosmovisor' daemon 
# Create a Systemd service file for the 'cosmovisor' daemon
[Unit]
Description=Aya Node
After=network-online.target

[Service]
User=$USER
# Start the 'cosmovisor' daemon with the 'run start' command and write output to journalctl
ExecStart=$(which cosmovisor) run start --home /opt/aya
# Restart the service if it fails
Restart=always
# Restart the service after 3 seconds if it fails
RestartSec=3
# Set the maximum number of file descriptors
LimitNOFILE=4096

# Set environment variables for data backups, automatic downloading of binaries, and automatic restarts after upgrades
Environment="DAEMON_NAME=ayad"
Environment="DAEMON_HOME=/opt/aya"
Environment="DAEMON_DATA_BACKUP_DIR=/opt/aya/backup"
Environment="DAEMON_ALLOW_DOWNLOAD_BINARIES=true"
Environment="DAEMON_RESTART_AFTER_UPGRADE=true"

[Install]
# Start the service on system boot
WantedBy=multi-user.target
EOF

With the service now created, we now need to enable it for future use.

We do this by entering the following group of commands

1
2
3
4
# Reload the Systemd daemon
sudo systemctl daemon-reload
# Enable the 'cosmovisor' service to start on system boot
sudo systemctl enable cosmovisor

We can now confirm that our service is ready to be started by entering the following command.

1
sudo systemctl status cosmovisor.service

This should show us the following

1
2
3
○ cosmovisor.service - Aya Node
    Loaded: loaded (/etc/systemd/system/cosmovisor.service; enabled; vendor preset: enabled)
    Active: inactive (dead)

If we see this, we know we have successfully installed our Aya Node Service.

All that remains now, is to close down our first run of our Node and to restart it using this newly installed Service instead of manually launching our Node as before.

To do this, we need to identify what the current process number of our still running first run Node is.

We do this by entering the following command

1
ps -ef | grep cosmovisor

The output of this command should something like this

1
2
3
wmt       147797  146916  0 16:44 pts/0    00:00:00 /opt/aya/cosmovisor/cosmovisor run start --home /opt/aya
wmt       147803  147797 11 16:44 pts/0    00:01:05 /opt/aya/cosmovisor/genesis/bin/ayad start --home /opt/aya
wmt       148235  146916  0 16:54 pts/0    00:00:00 grep --color=auto cosmovisor

What we are looking for is the leftmost number appearing for the line that contains “/opt/aya/cosmovisor/cosmovisor run start –home /opt/aya” on its right hand side

In the above example, this number is 147797.

Our number will be different, and we need to take a note of it for the next step.

Once we have this number we can now use it to turn off our first run Node that has served us so well to get our Blockchain sync up to date with the current tip of the Chain.

We do this by entering the following command Note: We replace <number> with our noted number from above at this point, removing the surrounding <>

1
sudo kill <number>

We have now killed our running Node, but don’t worry, we are going to bring it right back to life. Except this time, as a Service!

To do this we enter the following command

1
sudo systemctl start cosmovisor.service

Now we need to check that cosmovisor.service has started properly.

We do this by entering the following command

1
sudo systemctl status cosmovisor.service

When we ran this command previously it said our Aya Node Service was inactive (dead), this time it should say something like the following

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
cosmovisor.service - Aya Node
    Loaded: loaded (/etc/systemd/system/cosmovisor.service; enabled; vendor preset: enabled)
    Active: active (running) since Wed 2023-03-01 04:06:05 UTC; 4s ago
Main PID: 34791 (cosmovisor)
    Tasks: 15 (limit: 4573)
    Memory: 382.3M
        CPU: 5.063s
    CGroup: /system.slice/cosmovisor.service
            ├─34791 /usr/local/bin/cosmovisor run start --home /opt/aya
            └─34796 /opt/aya/cosmovisor/genesis/bin/ayad start --home /opt/aya 

Mar 01 04:06:05 localhost systemd[1]: Started Aya Node.
Mar 01 04:06:05 localhost cosmovisor[34791]: 4:06AM INF running app args=["start","--home","/opt/aya"] module=cosmovisor path=/opt/aya/cosmovisor/genesis/bin/ayad

Some details will be different to the above example, but this should be the general layout. The important point is that it should say ‘active (running)’ in green.

We can now confirm everything is continuing to sync from the Blockchain by going back to our ayaview console and watching to see if the Block Height is still slowly ticking upwards as before.
We do this by entering the following group of commands
1 2
cd ~/nodebase-tools ./ayaview
If everything is working as it should our ayaview console should now be showing us the Aya Blockchain ticking on by once more, around every 5-6 seconds.

At this stage in the guide, we have successfully completed setting up a Validator Node that is able to privately sync with the Aya Blockchain, through only our already configured Sentry Nodes, but we have not yet used it to Register our EarthNode Stake Pool to both the Cardano and Aya Network Blockchains.

So, we shall now proceed to doing this.

Note: Before proceeding, we press q to leave ayaview.

First we need to obtain the details needed for our ENNFT Registration on the Cardano Blockchain side of the equation. We have actually already been shown them earlier, but let’s just get them again.

We do this by entering the following command

1
cat /opt/aya/registration.json

The output of this command should look something like this

1
2
3
4
5
{
  "moniker": "<our Validator Node Moniker>",
  "operator_address": "<our Operator Address beginning aya1, followed by a random string of letters and numbers>",
  "validator_address": "<our Validator Address beginning ayavalcons1, followed by a random string of letters and numbers>"
}

Note: At this point we want to copy and paste the output of this command, including its surrounding {}s, to a separate, temporary, text file on our machine.

Now we need to open a web browser and navigate to https://tinyurl.com/wmeno and click on the EarthNode Registration tab at the top of the page.
Next we need to connect our Cardano Preview Testnet Wallet that contains our Testnet EarthNode NFT to be Registered to this EarthNode Registration site.
We do this by
a) Ensuring the Wallet containing our Testnet EarthNode NFT is the one currently selected for dApp connections in our Cardano Wallet Browser Extension b) Esnuring that it has enough collateral set to enable sumbission of Smart Contract Transactions (5 ADA should be enough) and then c) By clicking on the Connect Wallet Button on the site EarthNode Registration site
Note: Once our Preview Testnet Wallet is connected the EarthNode NFTs in your Wallet: section of the EarthNode Registration site should populate with the EarthNodeNFT# numbers that you hold in your Preview Testnet Wallet.
Now we need to click on the EarthNodeNFT# number we wish to associate with our newly set up Validator Node.
Next we make sure we have RegisterEarthNode selected under the Select Transaction Type: Dropdown Menu.
And now we need to paste in the previously copied information, obtained during step 30 above, into the Paste Installation Script Output: Box and press the Build Transaction Button.
Note: We will now be asked for our Preview Testnet Wallet’s Spending Password at this point in order to Authorise the Registration Transaction to be Posted On-Chain on the Cardano Preview Testnet Newtork.
We need to enter our Spending Password and click Sign.
This should then show us a Transaction Successful! message on the EarthNode Registration Page along with a Transaction Hash that corresponds to the Transaction ID that will appear on the Cardano Blockchain.
Note: Whilst the Transaction itself has now been successfully submitted, it may still take a little bit of time for it to appear On the Cardano Blockchain. There will be a link at the bottom of the EarthNode Registration site that will take us to an external page to reload until we see the Transcation finally go through. Once we see this Transaction appear on that page. We can proceed to the next step.
Now we return to our Validator Node’s Terminal Window as before, and complete the final steps to get our EarthNode Stake Pool online. The first thing we will do is make sure that our Operator Address received 5 uswmt Tokens to be able to complete the Aya Network side of our Stake Pool Registration.
We do this by entering the following command
1
ayad query bank balances <our Operator Address> --home /opt/aya
Note: We replace <our Operator Address> with the full operator_address detail that begins with aya1 from the information we obtained for EarthNode Registration in step 30, removing the surrounding <>
If Registration on the Cardano Blockchain side has been successful, this command should give us the following output
1 2 3 4 5 6
balances: - amount: "5" denom: uswmt pagination: next_key: null total: "0"
Note: A balance amount of “5” appearing in this output means that The Cardano Transaction triggered our Operator Address being topped up with 5 uswmt to be used to set up our EarthNode Stake Pool on the Aya Blockchain side. The side we are now working with.

Now we need to Register our EarthNode Stake Pool to the Aya Blockchain Network.

We do this by entering the following group of commands

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
ayad tx staking create-validator \
  --amount=1uswmt \
  --pubkey="$(ayad tendermint show-validator --home /opt/aya)" \
  --moniker="$moniker" \
  --chain-id="$CHAIN_ID" \
  --commission-rate="0.10" \
  --commission-max-rate="0.20" \
  --commission-max-change-rate="0.01" \
  --min-self-delegation="1" \
  --from="$account" \
  --home /opt/aya \
  --output json \
  --yes 

Note: After entering this group of commands we will be asked to enter the Spending Password we set up earlier in the guide specifically for our Validator Account. We must enter it now.

If the Transcation has been successful we should see an output that contains a txhash value that consists of a string of capital letters and numbers, along with a lot of other information in JSON format, that looks something like this

1
{"height":"0","txhash":"<Transaction Hash containing capital letters and numbers>","codespace":"","code":0,"data":"","raw_log":"[]","logs":[],"info":"","gas_wanted":"0","gas_used":"0","tx":null,"timestamp":"","events":[]}

Now we now need to go and see if our Validator has been successfully Registered on the Aya Blockchain Network by opening our browser and going to https://wmt-explorer.com/AyaChain
Once there we need to look at the ‘New joined EarthNode Validators’ section and check to see if the Monkier we gave our EarthNode Stake Pool has appeared in the list.
Finally, we need to go back to ayaview and make sure the status of our Node has been updated to say that the Validator reports Status: BONDED and Signing: Active. Which should be visable in the upper left box of the ayaview console.
We do this by entering the following group of commands
1 2
cd ~/nodebase-tools ./ayaview

If the Moniker appears om the wmt-exploer website, and ayaview reports what we are expecting to see above, Congratulations! We have now successfully completed setting up both our Validator Node AND our EarthNode Stake Pool!

2.3 - 3. Cardano Chain Follower Manual Installation and root-list Registration

Full Installation Guide for installing a Cardano Chain Follower Service and registering it to the Cardano Chain Follower root-list.

Written by Nodebase Team member intertree (Johnny Kelly)

Introduction

The following guide will take you through all manual steps to be taken to have a fully running Cardano Chain Follower. Taking you through how attach it to an existing public Cardano API Server, as well as how to register your EarthNode to the Cardano Chain Follower root-list via 2 On-Chain Registration Transactions on the Aya Network.

At the moment, this installation only requires set up through an existing On-Chain Registered Validator Node. In the future proxy connection methods may be introduced, but, for now, connections are directly made from your EarthNode Validator to a pre-configured Cardano API Server Endpoint.

This guide assumes you have already set up both of your Sentry Nodes and your EarthNode Validator, and have Registered your Validator to the Chain, using the steps laid out over at Sentry Node Manual Installation and Validator Node Manual Installation, respectively.

Now, with this introduction out of the way, we shall proceed with the guide!

Step-By-Step Installation Guide

Logged in as user wmt we first start by making the base directory for the Cardano Chain Follower files that are to be installed on our Node.
We do this by entering the following group of commands
1 2
sudo mkdir -p /opt/aya/ccf sudo chown "${USER}:${USER}" /opt/aya/ccf
Next we set the aya_home environment variable so that further installation steps can be simplified.
We do this by entering the following group of commands
1
aya_home=/opt/aya
Now we install a required prerequisite package (libpq-dev) for the successful completion of installation steps.
We do this by entering the following group of commands
1 2
sudo apt-get update sudo apt install libpq-dev -y

Now we create an installation directory for the Cardano Chain Follower installation files, navigate to it, download the installer zip file, install the unzip command (if not already installed to our OS), and extract the Cardano Chain Follower archive.

We do this by entering the following group of commands

1
2
3
4
5
6
7
mkdir ~/earthnode_installer/
mkdir ~/earthnode_installer/ccf
cd ~/earthnode_installer/ccf
wget https://cdn.discordapp.com/attachments/1072502970027081749/1144181313583186002/wm_230824_ccf_rev2.zip
sudo apt-get -q install unzip -y
unzip wm_230824_ccf_rev2.zip 
rm wm_230824_ccf_rev2.zip

Now we copy the aya_chain_follower binary and daemon_wm.toml configuration files to their home locations for use in future operations.
We do this by entering the following group of commands
1 2
cp ~/earthnode_installer/ccf/aya_chain_follower "${aya_home}"/ccf cp ~/earthnode_installer/ccf/daemon_wm.toml "${aya_home}"/ccf

Next we want to create a systemd service file that will allow our Cardano Chain Follower to automatically start on a reboot of our Server and to automatically attempt to restart itself on any crashes.

We do this by entering the following group of commands

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
sudo tee /etc/systemd/system/chain_follower.service > /dev/null <<EOF
# Create systemd service file that describes the background service running the 'aya_chain_follower' daemon.
[Unit]
Description=Cardano Chain Follower
After=network-online.target

[Service]
# Execute daemon from user account
User=$USER
# Set working directory
WorkingDirectory=${aya_home}/ccf/
# Start the 'aya_chain_follower' daemon with providing configuration file path
ExecStart=${aya_home}/ccf/aya_chain_follower daemon --config ${aya_home}/ccf/daemon_wm.toml
# Restart the service if it fails
Restart=always
# Restart the service after 3 seconds if it fails
RestartSec=3
 
[Install]
# Start the service on system boot
WantedBy=multi-user.target
EOF

This will have added a new service file to our Server under the path /etc/systemd/system named chain_follower.service. This service file is what will be called when the Server reboots, or if our Service crashes.

With the service now created, we now need to enable it for future use.

We do this by entering the following group of commands

1
2
3
4
# Reload the Systemd daemon
sudo systemctl daemon-reload
# Enable the 'chain_follower' service to start on system boot
sudo systemctl enable chain_follower

We can now confirm that our service is ready to be started.

We do this by entering the following command

1
sudo systemctl status chain_follower

This should show us the following

1
2
3
○ chain_follower.service - Cardano Chain Follower
     Loaded: loaded (/etc/systemd/system/chain_follower.service; enabled; vendor preset: enabled)
     Active: inactive (dead) 

If we see this, we know we have successfully installed our Cardano Chain Follower Service.

Now we start the Cardano Chain Follower Service.
We do this by entering the following command
1
sudo systemctl start chain_follower.service

Now we need to check that chain_follower.service has started properly.

We do this by entering the following command

1
sudo systemctl status chain_follower.service

When we ran this command previously it said our Cardano Chain Follower Service was inactive (dead), this time it should say something like the following

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
● chain_follower.service - Cardano Chain Follower
     Loaded: loaded (/etc/systemd/system/chain_follower.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2023-09-08 14:52:46 UTC; 3s ago
   Main PID: 105986 (aya_chain_follo)
      Tasks: 15 (limit: 38243)
     Memory: 4.7M
        CPU: 96ms
     CGroup: /system.slice/chain_follower.service
             └─105986 /opt/aya/ccf/aya_chain_follower daemon --config /opt/aya/ccf/daemon_wm.toml

Sep 08 14:52:46 eno318-validator aya_chain_follower[105986]: /api/info/asset/metadata/{fingerprint}
Sep 08 14:52:46 eno318-validator aya_chain_follower[105986]: /api/info/history/discover/{hash}
Sep 08 14:52:46 eno318-validator aya_chain_follower[105986]: /api/info/history/address/
Sep 08 14:52:46 eno318-validator aya_chain_follower[105986]: /api/info/address/stake/assets/
Sep 08 14:52:46 eno318-validator aya_chain_follower[105986]: /api/info/addresses/assets/
Sep 08 14:52:46 eno318-validator aya_chain_follower[105986]: /api/info/pools/{page}
Sep 08 14:52:46 eno318-validator aya_chain_follower[105986]: /api/info/tokens/isNft/
Sep 08 14:52:46 eno318-validator aya_chain_follower[105986]: /api/aya/epoch/change/from/{epoch1}/{epoch2}
Sep 08 14:52:46 eno318-validator aya_chain_follower[105986]: /api/aya/epoch/change/latest
Sep 08 14:52:46 eno318-validator aya_chain_follower[105986]: /api/aya/epoch/current/

Some details will be different to the above example, but this should be the general layout. The important point is that it should say ‘active (running)’ in green and there should be a list of ‘/api/’ items.

At this stage in the guide, we have successfully completed setting up a Cardano Chain Follower Service that is able to publically call the IOG Provided Cardano Testnet API Server (a potential privacy concern which may be addressed later by World Mobile in their guidance on how to set up these Services), but we have not yet used it to Register our EarthNode to the Cardano Chain Follower root-list.

So, we shall now proceed to doing this.

Note: Before proceeding, we press ctrl+c to leave the Service status view.

First we need to obtain our account name that was previously saved during out Validator’s set up process.
We do this by entering the following command
1
cat /opt/aya/account
Note: The output of this command will be the name to replace the word <account> with in the next step.

Now we need submit our 1st of 2 Transactions to complete formal Registration to be a part of the Cardano Chain Follower Root list.

Note: The Root list is a list of all viable Registered Cardano Chain Follwer Validators that can be selected from to become a part of the Leader set in any given Epoch.
The Leader set are the smaller, rotating, sub-group of Validators from the overall root-list of Registered Validators that have the job of monitoring for specific Transaction information on the Cardano Blockchain, interpreting that information, and carrying out any actions that need to be taken on the Aya Network Blockchain as a result of that information.
Which Registered Cardano Chain Folllower Validators get to become a part of the current Leader set is determined by the Aya Chain itself, on a rotational basis.

We do this by entering the following command

1
ayad tx cce set-val-acc --home /opt/aya --from <account> --chain-id aya_preview_501 -y

Note: After entering this command we will be asked to enter the Spending Password we set up earlierin the previous guide used specifically to set up our Validator Account. We must enter it now.
Also, remember to replace with the output of the previously completed cat command used to get this information. Also ensure to remove the <>s from the placeholder text above.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
code: 0
codespace: ""
data: ""
events: []
gas_used: "0"
gas_wanted: "0"
height: "0"
info: ""
logs: []
raw_log: '[]'
timestamp: ""
tx: null
txhash: <Transaction Hash containing capital letters and numbers>

Before proceeding to the next step, we need to wait long enough so that the 1st Registration step fully completed as expected. We are waiting for the Transaction that was just posted to the Aya Blockchain to make its way to a fully Minted Block, and to form a part of that Block’s list of Transactions.
We can look to see if and when this Transaction has made it to the Aya Blockchain by going to https://wmt-explorer.com/AyaChain.
Once there we need to look at the ‘Latest Transactions’ section and check to see if the ‘MsgSetValAcc’ Transaction we just sent has appeared on the Blockchain History.
When we see it appear, we can then move on to the next step.

Now we need submit our 2nd of 2 Transactions to complete formal Registration to be a part of the Cardano Chain Follower root-list.

We do this by entering the following command

1
ayad tx chainfollower send-root --home /opt/aya --from <account> --chain-id aya_preview_501 -y

Note: After entering this command we will once again be asked to enter the Spending Password we set up earlier in the previous guide used specifically to set up our Validator Account. We must enter it now.
Also, remember to replace with the output of the previously completed cat command used to get this information. Also ensure to remove the <>s from the placeholder text above.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
code: 0
codespace: ""
data: ""
events: []
gas_used: "0"
gas_wanted: "0"
height: "0"
info: ""
logs: []
raw_log: '[]'
timestamp: ""
tx: null
txhash: <Transaction Hash containing capital letters and numbers>

Before proceeding to the next step, we need to wait long enough so that the 2nd Registration step fully completed as expected. We are waiting for the Transaction that was just posted to the Aya Blockchain to make its way to a fully Minted Block, and to form a part of that Block’s list of Transactions.
We can look to see if and when this Transaction has made it to the Aya Blockchain by going to https://wmt-explorer.com/AyaChain.
Once there we need to look at the ‘Latest Transactions’ section and check to see if the ‘MsgSendRoot’ Transaction we just sent has appeared on the Blockchain History.
Now we are going to complete the neccesary steps to ensure that our Validator is now actually a part of the Registered list of Cardano Chain Followers.
We will start by setting up our Validator’s operator address as a variable for future steps.
We do this by entering the following command
1
operator_address=$(ayad tendermint show-address --home /opt/aya)
Next we use that created variable to check to see if our newly Registered Chain Follower is in the list of Chain Follower roots.
We do this by entering the following command
1
ayad query chainfollower list-root | grep $operator_address
We are now checking to see if entering this command returns back a result that looks like the following, with the ayavalcons1 part of the response appearing fully in red.
1
val_addr: ayavalcons1<various lowercase letters and numbers>

If it does, Congratulations! We have now successfully completed setting up our Validator to be a full Chain Follwer root-list!