# Google Cloud 101

WARNING

This guide is in the process of being updated to cover cosmovisor. In the interim, for parts 4.3 up to and including part 6, you can follow the Install und, Cosmovisor and optionally Sync using statesync guide.

# Contents

# Introduction to installing und on Google Cloud VMs

TIP

If you intend to become a MainNet Validator, it is recommended that you practice on TestNet first in order to familiarise yourself with the process.

This guide introduces a very simple "quick start" single Google Cloud VM, using simple network infrastructure to connect to a Mainchain Public network. Validator node operators are highly encouraged to explore more sophisticated architecture configurations to increase the security, reliability and availability of their Validator node - for example, multi layered network with both private/public subnets, one or more "sentry" full (non-validator) nodes placed in front of your main (hidden in a private subnet) Validator node to handle and relay communication from the outside world, and reverse proxy for any RPC access via the sentries etc. in addition to implementing hardware KMS solutions to protect validator private keys.

Important

This guide should not be considered the default, full, out of the box solution for a Validator node, but more an "Google Cloud 101" guide to familiarise the reader with the core concepts involved in setting up the minimum GC VM and associated service requirements in order to operate a Validator node. It should be considered a starting point giving you the initial building blocks from which to build a more sophisticated network/node architecture to support and protect your Validator node.

TIP

any public IPs generated by Google Cloud during this guide are not static - they will change if the VM instance is restarted. It is recommended that the reader also investigates GC static IPs for their public-facing node(s).

Where the guide prompts users to open a terminal, Windows 10 users should use PowerShell.

This guide assumes the reader already has a Google Cloud account.

# Part 0: Create a new Project & Enable APIs

If you do not have an existing project for the node, you’ll need to create a new GC project. Click on the menu icon in the top left of the GC console, and select "Home" followed by "Create new project". Give the project a suitable name, check it is in the correct organisation and click "Create". Once created, in the organisation/project drop-down (top-left of the console in the header), select your new project name.

Next, go to "Menu" and click on "APIs & Services". Click the "Enable APIs and Services" button. From the filter menu on the left, select "Compute", then enable billing for "Compute Engine API".

# Part 1: Create an SSH key pair

An SSH key is required to log in to your GC VM - this can be created on your local PC, using the ssh-keygen command.

Open a terminal on your local PC, and check if you have a $HOME/.ssh directory:

ls -la $HOME/.ssh

If you do not have a $HOME/.ssh directory, create it:

$ mkdir $HOME/.ssh
$ chmod 700 $HOME/.ssh

Run the following commands, replacing vmusername with something easily identifiable such as the admin username ( only letters, no spaces) you will choose later in the guide for the VM, and enter a password to encrypt the key when prompted to do so:

$ ssh-keygen -t rsa -b 4096 -f $HOME/.ssh/gc_vmusername_id_rsa
$ chmod 400 $HOME/.ssh/gc_vmusername_id_rsa

Finally, the public key will be required later in the guide, so open it up in a text editor. The public key counterpart has the .pub file extension, e.g. $HOME/.ssh/gc_vmusername_id_rsa.pub

# Part 2: VPC Network & Firewall rules

We first need to create a VPC and define some firewall rules that will allow your node to communicate via P2P, and allow you to broadcast transactions to your node. Validator operators are encouraged to explore more sophisticated configurations for their production node, and not just rely on the defaults.

# 2.1: Create a VPC

From the Google Cloud console menu, scroll down to "VPC Network" and click "VPC Networks". Click the "Create VPC Network" button.

  1. Enter a suitable name for the VPC, such as "und-vpc", and a description. For "Subnets", select "Automatic".
  2. Don’t select any of the predefined firewall rules.
  3. Leave the rest as defaults, and click the "Create" button.

# 2.2: Firewall Rules

First, we need a firewall rule that allows only your local PC’s IP address to connect via SSH. You can find your IP address by running ifconfig in a terminal, or visiting https://www.whatismyip.com (opens new window).

Note

if your PC’s IP changes, you will need to update this rule in order to connect to your VM.

  1. Click the Menu button in the top left of the GC console, scroll down to "VPC Network" and click "Firewall Rules". Click the "Create Firewall Rule" button.
  2. Enter a name for the rule, such as "und-node-ssh", and suitable description. Change the value for "Network" from "default" to "und-vpc" (or whatever you called your VPC Network).
  3. For "direction of traffic", select "Ingres" and for "Action on Match", select "Allow"
  4. For "Targets", select "Specified Target Tag", and enter "und-node" under "Target Tags" (this will be used as the " network tag" when creating the VM instance later).
  5. For "Source IP Ranges", enter YOUR_IP/32, for example 22.33.44.55/32 Under "Protocols and Ports", select "specified protocols and ports", tick "tcp" and enter 22 as the port
  6. Click "Create"

Next, we need a firewall rule that allows the node to communicate via P2P.

  1. Click the "Create Firewall Rule" button.
  2. Enter a name for the rule, such as "und-node-p2p", and suitable description.
  3. Leave logs "off".
  4. Change the value for "Network" from "default" to "und-vpc" (or whatever you called your VPC Network)
  5. For "direction of traffic", select "Ingres" and for "Action on Match", select "Allow"
  6. For "Targets", select "Specified Target Tag", and enter "und-node" under "Target Tags" (this will be used as the " network tag" when creating the VM instance later).
  7. For "Source IP Ranges", enter 0.0.0.0/0
  8. Under "Protocols and Ports", select "specified protocols and ports", tick "tcp" and enter 26656 as the port
  9. Click "Create".

Next, we need to open the RPC port, so that we can broadcast Txs to the node. As with the SSH rule, we should restrict access to our own IP.

Repeat the steps above. Use "und-node-rpc" as the name, and YOUR_IP/32 (e.g. 22.33.44.55/32) as the IP range. Finally, tick "tcp" and enter 26657 as the port. As before, enter "und-node" under "Target Tags", ensure you select "und-vpc" as the network, and click "Create".

Note

port 26657 can be closed on your Validator node once you have registered your validator.

# Part 3: Create a VM Instance

To begin, ensure that billing for Compute Engine API is enabled for the current project. You will also need the public key for the SSH key created earlier. We’ll now create a VM for the node.

Click the Navigation Menu icon in the top left of the GC console, and go to Compute -> Compute Engine -> VM Instances. Click the "Create" button. Give your VM instance a suitable name.

  1. Under "Machine Configuration", leave "General purpose" selected, along with "N1" for Series.
  2. For "Machine Type", we recommend at least e2-medium
  3. In the "Boot Disk" section click the "Change" button
  4. Select "CentOS" as the operating system, and "CentOS 7" as the version Leave the disk size as default. Click the "Select" button.
  5. Click the "Management, security, disks, networking, sole-tenancy" link (under "Firewall").
  6. Click the "Security" tab.
  7. Copy your SSH public key into the input "Enter public SSH key".

Note

your public key will be in the format: ssh-rsa PUBLIC_KEY [email protected]. The "[email protected]" part will be used to define the admin username for the VM, e.g. ssh-rsa PUBLIC_KEY [email protected]

  1. Click the "Networking" tab.
  2. Enter "und-node" in the "Network tags" input (this is the tag we selected to apply our firewall rules to earlier).
  3. Click the "Network Interface" option, and change the Network from "default" to "und-vpc" (or whatever you named your VPC earlier).
  4. Click in the "Disks" tab. Choose a suitable name, change the "Type" to "SSD Persistant", and set the size to 100Gb
  5. Leave the rest of the options as their defaults, and click the "Create" button.

# Part 4: Log in to VM and configure via SSH

Once back on the Instances dashboard, you should see your new VM Instance listed. Find your instance, and make a note of the public IP address.

Note

any text in [square_brackets] (including the square brackets) in the following commands should be replaced with your own values. For example, vmusername should be replaced with the administrator username entered when creating the VM in Part 3.

Note for Windows users: Windows 10 should have an SSH client available in the PowerShell terminal. Older Windows versions will require PuTTY (opens new window).

Open a terminal on your PC, and run:

ssh -i $HOME/.ssh/[gc_vmusername_id_rsa] [vmusername]@[vm_ip]

# Part 4.1: Create and Mount the data drive

The following commands will create a new partition and format it ready for the state db

sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard /dev/sdb
sudo mkdir -p /mnt/disks/data
sudo mount -o discard,defaults /dev/sdb /mnt/disks/data
sudo chmod a+w /mnt/disks/data
sudo cp /etc/fstab /etc/fstab.backup
echo UUID=`sudo blkid -s UUID -o value /dev/sdb` /mnt/disks/data ext4 discard,defaults,nofail 0 2 | sudo tee -a /etc/fstab

# Part 4.2: Install the prerequisites

Update the installed packages:

sudo yum update -y

Install the following additional software:

sudo yum install nano jq wget -y

# Part 4.3: Install the und binary

The latest pre-compiled binaries are available for download from https://github.com/unification-com/mainchain/releases (opens new window).

  • The und binary has been compiled for Linux, OSX and Windows.

Download the latest version:

    Once downloaded, you can verify the SHA256 checksum against those listed in the release's checksums.txt, for example:

      Extract them and copy the binaries to a suitable location - preferably a location in your $PATH environment variable, for example /usr/local/bin.

        Once installed, verify:

        which und
        

        should output:

        /usr/local/bin/und
        

        and:

        und version --log_level=""
        

        The output should match the latest release version tag.

        # Part 5: Initialising your full node

        We’ll now initialise and configure the und node itself. As previously, any text in [square_brackets] (including the square brackets) in the following commands should be replaced with your own values accordingly. If you are not currently logged in to the VM instance via SSH, do so.

        Once logged in, run:

        und init [your_node_tag] --home=/mnt/disks/data/.und_mainchain
        

        [your_node_tag] can be any ID you like but is restricted to ASCII characters.

        # Download the latest Genesis file.

        IMPORTANT

        Please ensure you download the correct genesis for the network you would like to join! Remember to change the output directory in the command below if you are using something other than the default $HOME/.und_mainchain directory!

        To spin up your new node, download the latest genesis.json for the network you would like to join:

          Get the current chain ID from genesis. Make a note of the output, it'll be required in commands later in the guide. Command is all on one line:

          $ jq --raw-output '.chain_id' /mnt/disks/data/.und_mainchain/.und_mainchain/config/genesis.json
          

          # Get seed nodes

          IMPORTANT

          Please ensure you get the correct seed node information for the network you would like to join! Remember to change the directory if you are using something other than the default $HOME/.und_mainchain directory! For this guide, we are using /mnt/disks/data/.und_mainchain for the node's home directory.

          Your node will need to know at least one seed node in order to join the network and begin P2P communication with other nodes in the network. The latest seed information will always be available at each network's respective Github repo:

          Go to the repo for the network you are connecting to and copy one or more of the seed nodes (you only need the [email protected]:port)

          Edit your node configuration file using nano:

          nano /path/to/.und_mainchain/config/config.toml
          

          Hit Ctrl+W, type [p2p] (including the square brackets) and hit return - this will take you to the [p2p] section of the config file, which begins with:

          ##### peer to peer configuration options #####
          [p2p]
          

          Find the seeds = "" variable about 12 lines below, and add the seed node information between the double quotes (comma separated, no spaces if more than one). For example:

          seeds = "[email protected]:port"
          

          Next, hit Ctrl+W, type [rpc] (including the square brackets) and hit return - this will take you to the [rpc] section of the config file, which begins with:

          ##### rpc server configuration options #####
          [rpc]
          

          About 3 lines under this, find:

          laddr = "tcp://127.0.0.1:26657"
          

          Change the value to:

          laddr = "tcp://0.0.0.0:26657"
          

          Hit Ctrl+X followed by y and then return to save the file and exit nano.

          Note

          you can revert the [rpc] configuration for port 26657 to:

          laddr = "tcp://127.0.0.1:26657"
          

          once you have run thecreate-validator command. Broadcasting transactions can instead be done via a public RPC node, or, more securely, via a full node running on your local PC. See Part 8: Final cleanup for further details.

          # Gas Prices

          It is good practice to set the minimum-gas-prices value in $HOME/.und_mainchain/config/app.toml, in order to protect your full node from spam transactions. This should be set as a decimal value in nund, and the recommended value is currently 25.0nund. This means your node will ignore any Txs with a gas price below this value. To do so, open up $HOME/.und_mainchain/config/app.toml in a text editor, and set minimum-gas-prices

          nano $HOME/.und_mainchain/config/app.toml
          

          Change:

          minimum-gas-prices = ""
          

          To, for example:

          minimum-gas-prices = "25.0nund"
          

          Hit Ctrl+X followed by y and then return to save the file and exit nano.

          # Syncing the node with statesync

          Cosmos SDK >= 0.42, which is used by the latest und software, can use State Syncing from Snapshots to quickly sync your node from a safe checkpoint. This potentially reduces the sync time to no more than an hour or so, and in most cases mere minutes.

          Setting this up requires a few more steps

          1. Run the following command to get the latest block hash and height:

            Example output:

            [
              "820275B5EE63EDA2923886A01C0B1196A7CE1D96A89FA0D774942999C6698AAC",
              "1052423"
            ]
            
            1. Using the output from the above command, configure [statesync] section in .und_mainchain/config.toml:
            enable = true
            rpc_servers = "TWO_RPC_NODES"
            trust_height = 1052423
            trust_hash = "820275B5EE63EDA2923886A01C0B1196A7CE1D96A89FA0D774942999C6698AAC"
            trust_period = "168h0m0s"
            discovery_time = "30s"
            temp_dir = ""
            chunk_request_timeout = "60s"
            chunk_fetchers = "4"
            

            The rpc_servers requires two RPC nodes for verification. Replace TWO_RPC_NODES with:

              e.g.:

              rpc_servers = "sync1.unification.io:26657,sync2.unification.io:26657"
              

              Or any RPC servers of your choice for the target network.

              1. Start your node
              und start --home=/path/to/.und_mainchain
              

              you should start seeing the following:

              11:53AM INF Discovered new snapshot format=1 hash="V0���&�U1�J0�yP4A%�/���GŽ@\x05�<�j" height=1051600 module=statesync
              

              After a few seconds (or at most, minutes), you should see your node start downloading the blocks:

              11:56AM INF received proposal module=consensus proposal={"Type":32,"block_id":{"hash":"632E122ADDF385954FB8598FEE7D89EB09D7E93746FB36D2F12DECFEB7F07D9E","parts":{"hash":"E8246C504B9BC14275874A90C95E6AA035678302AD3BF9269B6F253B04C038BE","total":1}},"height":1052494,"pol_round":-1,"round":0,"signature":"HYJz0rV7o6bNm7za82sj1Az1rV25qVkLh9Y4s0K95nf86uVq+YmuDIf3LtIP7pDfFEYErxNVyeSplPGh7IVHDQ==","timestamp":"2022-05-19T10:56:03.273030584Z"}
              11:56AM INF received complete proposal block hash=632E122ADDF385954FB8598FEE7D89EB09D7E93746FB36D2F12DECFEB7F07D9E height=1052494 module=consensus
              11:56AM INF finalizing commit of block hash=632E122ADDF385954FB8598FEE7D89EB09D7E93746FB36D2F12DECFEB7F07D9E height=1052494 module=consensus num_txs=0 root=7EC77102840743503BD71FD89F60FD0B912DD0DE27575408B6AD67990CE4A6B8
              11:56AM INF executed block height=1052494 module=state num_invalid_txs=0 num_valid_txs=0
              11:56AM INF commit synced commit=436F6D6D697449447B5B3234312031333020323235203834203837203234372031303220323820323435203234382032372032303920313432203133372031303620353920343520323220323020313737203135342032303320323338203136352030203231322034392031383620313638203433203839203233395D3A3130304634457D
              11:56AM INF committed state app_hash=F182E15457F7661CF5F81BD18E896A3B2D1614B19ACBEEA500D431BAA82B59EF height=1052494 module=state num_txs=0
              11:56AM INF indexed block height=1052494 module=txindex
              

              Hit Ctrl+C to stop the node - it will be configured as a background service next.

              IMPORTANT

              keep your /mnt/disks/data/.und_mainchain/config/node_key.json and /mnt/disks/data/.und_mainchain/config/priv_validator_key.json files safe! These are required for your node to propose and sign blocks. If you ever migrate your node to a different host/VM instance, you will need these.

              # Part 6: Running und as a daemon

              Once you have initialised and tested the und node, it can be set up as a background daemon on the server using systemctl. This means that you can easily start/stop/restart the service, and do not need to leave the SSH session open while und is running.

              If you’re not logged in to your VM instance via SSH, log in. If you are still logged in, and have not stopped the und node, hit Ctrl+C to stop the node.

              We need to use the nano text editor to create the service configuration. Run:

              sudo nano /etc/systemd/system/und.service
              

              At a minimum, the service configuration should contain the following, replacing USERNAME and FULL_PATH_TO with your own values:

              [Unit]
              Description=Unification Mainchain Validator Node
              
              [Service]
              User=USERNAME
              Group=USERNAME
              WorkingDirectory=/home/USERNAME
              ExecStart=/usr/local/bin/und start --home /FULL_PATH_TO/.und_mainchain
              Restart=on-failure
              RestartSec=10s
              LimitNOFILE=4096
              
              [Install]
              WantedBy=default.target
              

              It is entirely possible to create a more sophisticated service definition should you desire.

              Note

              Also see: Using Cosmovisor with und: Quick Start for details on running und with cosmovisor.

              Next, inform systemctl of the new service:

              sudo systemctl daemon-reload
              sudo systemctl enable und
              

              The service can now be started:

              sudo systemctl start und
              

              and stopped:

              sudo systemctl stop und
              

              in the background.

              Finally, you can monitor the log output for the service by running:

              $ sudo journalctl -u und --follow
              

              and use Ctrl+C to exit the journalctl command. You can now log out of your SSH session and und will continue running in the background.

              # Part 7: Become a Validator

              Important

              ensure your node has fully synced with the network before continuing.

              If not already logged in, log in to your VM instance via SSH, and run:

              sudo journalctl -u und --follow
              

              Once fully synced (check the downloaded height against the current clock in the block explorer), hit Ctrl +C to quit the journalctl command.

              You will need your Validator node’s Tendermint public key in order to register it on the Mainchain network as a validator. Whilst still in the SSH session connected to your VM, run:

              und tendermint show-validator --home=/mnt/disks/data/.und_mainchain
              

              Make a note of the output, as you will need this in later commands, where it will be referred to as [your_validator_public_key].

              You can now exit the SSH session - the rest of the commands will be run in a terminal on your local PC.

              Go to https://github.com/unification-com/mainchain/releases/latest (opens new window) and download the latest und archive for your OS - for example, und_v1.5.1_windows_x86_64.tar.gz.

              Open a terminal/PowerShell, and cd into the directory where you extracted the und executable:

              cd path/to/extracted/und_directory
              

              As previously, any text in [square_brackets] (including the square brackets) in the following commands should be replaced with your own values accordingly.

              If you do not already have a wallet/account, you can create one (on your local PC, not in the SSH session) by running:

              ./und keys add account_name
              

              If you already have a wallet, you can import the account using:

              ./und keys add account_name --recover
              

              in which case, you will be prompted for the mnemonic and a password to secure the wallet.

              From here, it is assumed the reader has an account with sufficient FUND from which to self-delegate and create their Validator node. The account you use to self-delegate will become the "owner" account of the Validator node.

              On your local PC, run the following command, replacing any text in [square_brackets] accordingly with your own values:

              ./und tx staking create-validator \
              --amount=[stake_in_nund] \
              --pubkey=[your_validator_public_key] \
              --moniker="[your_ev_moniker]" \
              --website="[your_website]" \
              --details="[description]" \
              --security-contact="[security_email]" \
              --chain-id=[chain_id] \
              --commission-rate="[0.10]" \
              --commission-max-rate="[0.20]" \
              --commission-max-change-rate="[0.01]" \
              --min-self-delegation="1" \
              --gas="auto" \
              --gas-prices="25.0nund" \
              --gas-adjustment=1.5 \
              --from=account_name \
              --node=tcp://[vm_ip]:26657
              

              [stake_in_nund] = (required) the amount of FUND in nund you are self-delegating. You can use the und convert 1000 fund nund command to convert FUND to nund. E.g. 1000000000000nund.

              Note

              do not enter more nund than you have in your wallet!

              [your_validator_public_key] = (required) the public key output from the previous und tendermint show-validator command.

              [your_ev_moniker] = (required) a publicly visible ID/tag for your Validator node.

              [your_website] = (optional) website promoting your node

              [description] = (optional) short description of your node

              [security_email] = (optional) security contact for your organisation

              [chain_id] = the network (e.g. FUND-TestNet-2, or FUND-MainNet-2) you are creating a validator on - this was obtained earlier in the guide via the jq command

              [account_name] = the account self-delegating the FUND, previously created/imported with the und keys add command

              [vm_ip] = the IP address of your EC2 instance running the full node - you can get this from your AWS EC2 Instances console.

              # Commission Rates

              Your commission rates can be set using the --commission-rate , --commission-max-change-rate and --commission-max-rate flags.

              --commission-rate: The % commission you will earn from delegators' rewards. Keeping this low can attract more delegators to your node.

              --commission-max-rate: The maximum you will ever increase your commission rate to - you cannot raise commission above this value. Again, keeping this low can attract more delegators.

              --commission-max-change-rate: The maximum you can increase the commission-rate by per day. For example, if your maximum change rate is 0.01, you can only make changes in 0.01 increments, so from 0.10 (10%) to 0.11 (11%).

              WARNING

              The values for --commission-max-change-rate and --commission-max-rate flags cannot be changed after the create-validator command has been run.

              Finally, the --min-self-delegation flag is the minimum amount of nund you are required to keep self-delegated to your validtor, meaning you must always have at least this amount self-delegated to your node.

              For example:

              ./und tx staking create-validator \
              --amount=1000000000000nund \
              --pubkey=undvalconspub1zcjduepq6yq7drzefkavsrxhxk69cy63tj3r... \
              --moniker="MyAwesomeNode" \
              --website="https://my-node-site.com" \
              --details="My node is awesome" \
              --security-contact="[email protected]" \
              --chain-id=FUND-TestNet-2 \
              --commission-rate="0.05" \
              --commission-max-rate="0.10" \
              --commission-max-change-rate="0.01" \
              --min-self-delegation="1" \
              --gas="auto" \
              --gas-prices="25.0nund" \
              --gas-adjustment=1.5 \
              --from=my_new_wallet \
              --node=tcp://33.44.55.66:26657
              

              Your validator node should now be registered and contributing to the network. To verify, on you local PC, run the following:

              ./und query staking validator \
              $(und keys show [account_name] --bech=val -a) \
              --chain-id=[chain_id] \
              --node=tcp://[vm_ip]:26657
              

              Replacing [account_name], [chain_id] and [vm_ip] accordingly. Assuming you are going through this guide on TestNet, you should also see your node listed in https://explorer-testnet.unification.io/validators (opens new window)

              # Part 8: Final cleanup

              Finally, it’s a good idea to close the RPC port (26657) on your validator node, leaving only the P2P port (26656) open so that it can communicate with other nodes. This can be done by deleting the firewall rule for the RPC port, and by reverting the RPC laddr configuration value in config.toml to the 127.0.0.1 IP address (which will restrict the node’s RPC access to localhost). Further interaction with the network can be done by spinning up a separate non-validator full node (on your local PC for example), and broadcasting transactions via that node instead.

              Important

              Do not alter the P2P port (26656) configuration and firewall rules. If you do, your validator node will not be able to communicate with its peers.

              That’s it - you should now have a full Validator node up and running on a very basic Google Cloud Linux VM instance. Once again - Validator node operators are highly encouraged to explore more sophisticated architecture configurations to increase the security, reliability and availability of their Validator node.