Gravity Bridge Setup
A Linux server with any modern Linux distribution, I use Ubuntu 20.0.4.
Intel Cascade Lake or better CPU with 4-cores, 8gb of RAM and at least 20 - 100gb of SSD storage.
Use a KeyPass password manager to keep track of my keys. Place them under the "Advanced" tab and be sure to click Protect value in process memory.
Review our Linux installation before continuing with our installation
Not ensuring the following caused my validator and sentry to fail during mainnet 1. This was generally an unknown issue at the time but I was the unlucky one to run into it. Thanks to "Simo | AC" the issue was correctly identified. I recommend Intel Cascade Lake (2019) generation of processor or newer.
I am using Google Cloud N2 Compute Instance.
Check Instruction Set:
cat /proc/cpuinfo | grep flags
Should have rdseed cpu instruction set listed
The following is configuration is based on Cosmos best practice of 3 Sentry nodes in front of your Validator. The Validator only talks to your Sentry nodes.
Outbound:
Any
Inbound (Sentry):
SSH (22 or custom port) from your personal IP only
P2P (26656) from Anywhere
RPC (26657) from Anywhere
Inbound (Validator):
SSH (22 or custom port) from your personal IP only
P2P (26656) from Sentry01
P2P (26656) from Sentry02
P2P (26656) from Sentry03
RPC (26657) from <MONITORING_NODE_IP>
Note that .profile/.bash_profile should be called when you logon to a Linux session. .bashrc will be called from .profile/.bash_profile This include when your start Akash as a service.
Insert the following lines at the bottom of your .bashrc file:
To open/create the file:
nano ~/.bashrc
# Increasing the default open files limit to prevent our node from crash in production. We also specify the ulimit in our systemctl Althea/Gravity-Bridge daemon.
ulimit -n 65530
# Ensure our path is correct and we will be able to start our nodes properly
export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin:~/bin:/home/<LOGON_USER_NAME>/.local/bin"
To save the file:
CTRL+o and ENTER
CTRL+x
The following is optional but will give you a colorful terminal window. Note for my Google Cloud instance, this was already there so just add the above two lines to the bottom of the .bashrc file:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
# don't put duplicate lines in the history. See bash(1) for more options
# ... or force ignoredups and ignorespace
HISTCONTROL=ignoredups:ignorespace
# append to the history file, don't overwrite it
shopt -s histappend
# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000
# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize
# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"
# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
xterm-color) color_prompt=yes;;
esac
# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
force_color_prompt=yes
if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi
if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt
# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
;;
*)
;;
esac
# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'
alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'
fi
# some more ls aliases
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'
# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
#if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
# . /etc/bash_completion
#fi
Now lets configure our .profile/.bash_profile file. Good news, for my Google Could and Ubuntu 20.04 installation the file was already configured to call .bashrc. If not, just create the file and paste the following into it. You should create it in your $HOME directory:
To open/create the file
nano ~/.profile
# ~/.profile: executed by Bourne-compatible login shells.
if [ "$BASH" ]; then
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
fi
mesg n 2> /dev/null || true
To save the file:
CTRL+o and ENTER
CTRL+x
These include ARM binaries for those of you on ARM platforms. Note that you will need to be running a 64bit ARM machine with a 64 bit operating system to use these binaries. In order to download ARM binaries change the names in the wget links from ‘client’ to ‘client-arm’. Repeat for all binaries. For the althea binary itself use -arm64 rather than amd.
cd ~/
mkdir althea-bin
cd althea-bin
# the althea chain binary itself
wget https://github.com/althea-net/althea-chain/releases/download/v0.0.5/althea-0.0.4-16-g6812f87-linux-amd64
mv althea-0.0.4-16-g6812f87-linux-amd64 althea
# Tools for the gravity bridge from the gravity repo
wget https://github.com/althea-net/althea-chain/releases/download/v0.0.5/client
wget https://github.com/althea-net/althea-chain/releases/download/v0.0.5/orchestrator
wget https://github.com/althea-net/althea-chain/releases/download/v0.0.5/register-delegate-keys
wget https://github.com/althea-net/althea-chain/releases/download/v0.0.5/relayer
chmod +x *
sudo mv * /usr/bin/
At specific points during the testnet you may be told to 'update your orchestrator' or 'update your althea binary'. In order to do that you can simply repeat the above instructions and then restart the affected software.
Be sure to back up the mnemonic/phrase you get! You’ll need it in below. If for some reason you lose or forget this mnemonic, simple repeat this step to create another.
Note is just the name of your key here, you can pick anything you like, just remember it later.
You'll be prompted to create a password, I suggest you pick a strong password that you can remember. You will be typing it a lot.
cd ~/
althea init <MONIKER> --chain-id althea-testnet1v5
althea keys add <MONIKER>
wget https://github.com/althea-net/althea-chain/releases/download/v0.0.5/althea-testnet1-v5-genesis.json
cp althea-testnet1-v5-genesis.json $HOME/.althea/config/genesis.json
# Change the p2p.persistent_peers field in ~/.althea/config/config.toml to contain the following:
nano ~/.althea/config/config.toml
persistent_peers = "[email protected]:26656"
# Change the api|enable = true field in ~/.althea/config/app.toml to contain the following:
nano ~/.althea/config/app.toml
###############################################################################
### API Configuration ###
###############################################################################
[api]
# Enable defines if the API server should be enabled.
enable = true
Save the file:
CTRL+O
press ENTER
CTRL+X
We are going to start and stop our node using a systemctl service
sudo nano /lib/systemd/system/gravity-bridge.service
Paste the following into the window that opens. If there is a problem with 'User=$USER' replace it with the current user's username.
[Unit]
Description=Gravity Bridge Daemon
After=network-online.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
User=$USER
TimeoutStopSec=90s
LimitNOFILE= 65530
WorkingDirectory=/usr/bin
ExecStart=/usr/bin/althea start
[Install]
WantedBy=multi-user.target
# Save and exit the file
CTRL+O
Press the ENTER key
CTRL+X
# Enable and start the system service using:
sudo systemctl enable gravity-bridge.service
sudo systemctl start gravity-bridge.service
Run the following command and look for "catching_up":false If this says 'true' you are still syncing.
althea status
Find your address. Copy it from above when you created it or type the following:
althea keys list
Enter your keyring password and press ENTER
Copy your address from the 'address:' field and paste it into the command below
Looks like this: cosmos1xxxxxxxxxxxx.....xxxx
curl -vv -XPOST http://testnet1.althea.net/get_altg/cosmos1xxxxxxxxxxxx.....xxxx
This will provide you 10 ALTG from the faucet storage.
althea tx staking create-validator \
--amount=9000000ualtg \
--pubkey=$(althea tendermint show-validator) \
--moniker="<GIVE_YOUR_VALIDATOR_A_NAME>" \
--chain-id=althea-testnet1v5 \
--commission-rate="0.10" \
--commission-max-rate="0.20" \
--commission-max-change-rate="0.01" \
--min-self-delegation="1" \
--gas="auto" \
--gas-adjustment=1.5 \
--gas-prices="0.025ualtg" \
--from=<MONIKER(YOUR_KEY_NAME_FROM_ABOVE>
If you have problems with above failing after a couple of tries, add the following to the command:
--fees 5000ualtg
Lets get your validator address. If it does not return an address you are not a validator:
althea keys show skynet --bech val --address
You will be prompted for your keyring passphrase. Enter it and your should get your validator address:
cosmosvaloper1xxxxxxxxxxxx.....xxxx
If you did not get your validator address above you have not created a validator. If you did get an address go to the next step to see if you are signing blocks:
Now that we have our validator address we can see if we are validating.
althea query staking validator cosmosvaloper1xxxxxxxxxxxx.....xxxx
In the output from the above command and look for the line status: It should say BOND_STATUS_BONDED If it does you are a validator and signing blocks. If it says BOND_STATUS_UNBONDED your are jailed and not signing blocks.
If you do not get Orchestrator going in a timely manner your will also get jailed
Delegate keys allow the for the validator private keys to be kept in secure storage while the Orchestrator can use it's own delegated keys for Gravity functions. The delegate keys registration tool will generate Ethereum and Cosmos keys for you if you don't provide any. Please save them as you will need them later.
This call will be added to the Gravity Bridge cli before production to provide Ledger signing support.
Once you save the phrase generated by this command you will have two phrases to keep track of. The one generated here is your 'delegate address' and the one you generated before is your 'validator address'.
RUST_LOG=INFO register-delegate-keys --validator-phrase="<THE_MNEMONIC_YOU_SAVED_ABOVE>" --cosmos-rpc="http://localhost:1317" --fees=footoken
Both your Ethereum delegate key and your Cosmos delegate key will need some tokens to pay gas. On the Althea chain side you where sent some 'footoken' along with your ALTG. We're essentially using footoken as a gas token for this testnet.
You should have received 100 Althea Governance Token in uALTG and the same amount of footoken. We're going to send half to the delegate address
To get the address for your validator key you can run the below, where <KEY_NAME> is whatever you named your key in the 'generate your key' step.
althea keys show <KEY_NAME>
althea tx bank send <KEY_NAME> <YOUR_COSMOS_DELEGATE_ADDRESS_FROM_ABOVE(cosmos1xxxxxxxxxxxx.....xxxx)> 5000000footoken --chain-id=althea-testnet1v5
The above Cosmos Delegate address is different than your self-delegation address your created with the althea keys add <KEY_NAME>
With the Althea side funded, now we need some Goerli Eth. [This is your Ethereum Delegate Address from above]
curl -vv -XPOST http://testnet1.althea.net/get_eth/<YOUR_ETHEREUM_DELEGATE_ADDRESS_FROM_ABOVE(0xxx.....xxxx)>
To see your balances type the following. This is your address from althea keys add
althea query bank balances cosmos1xxxxxxxxxxxx.....xxxx
We will be using Geth Ethereum light clients for this task. For production Gravity we suggest that you point your Orchestrator at a Geth light client and then configure your light client to peer with full nodes that you control. This provides higher reliability as light clients are very quick to start/stop and resync. Allowing you to for example rebuild an Ethereum full node without having days of Orchestrator downtime.
Please note that only Geth full nodes can serve Geth light clients, no other node type will do. Also you must configure a Geth full node to serve light client requests as they do not do so by default.
For the purposes of this testnet just follow the instructions below, even on the slowest node you should be synced inside of a few minutes.
cd ~/
wget https://gethstore.blob.core.windows.net/builds/geth-linux-amd64-1.10.1-c2d2f4ed.tar.gz
tar -xvf geth-linux-amd64-1.10.1-c2d2f4ed.tar.gz
cd geth-linux-amd64-1.10.1-c2d2f4ed
./geth --syncmode "light" --goerli --http --cache 16
Once 66% of the validator set has registered their delegate Ethereum key it is possible to deploy the Gravity Ethereum contract. Once deployed the Gravity contract address on Görli will be posted here
Here is the contract address! Move forward!
0xB48095a68501bC157654d338ce86fdaEF4071B24
Now that the setup is complete you can start your Orchestrator. Use the Cosmos mnemonic generated in the 'register delegate keys' step and the Ethereum private key also generated in that step. You should setup your Orchestrator in systemd or elsewhere to keep it running and restart it when it crashes.
If your Orchestrator goes down for more than 16 hours during the testnet you will be slashed and booted from the active validator set.
Since you'll be running this a lot I suggest putting the command into a script, like so
We are going to start and stop Orchestrator as a service. This way it will be restarted if stops or when the system is started
sudo nano /lib/systemd/system/orchestratord.service
Paste the following into the window that opens. If there is a problem with 'User=$USER' replace it with the current user's username.
[Unit]
Description=Althea Orchestrator Daemon
After=network-online.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=3
User=lightiv
TimeoutStopSec=90s
LimitNOFILE=4096
WorkingDirectory=/usr/bin
ExecStart=/usr/bin/orchestrator \
--cosmos-phrase="<YOUR_MNEMONIC_FROM_ABOVE(Generate your key (address) step)" \
--ethereum-key="0x68a4aff5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
--cosmos-legacy-rpc="http://localhost:1317" \
--cosmos-grpc="http://localhost:9090" \
--ethereum-rpc="http://localhost:8545" \
--fees=footoken \
--contract-address="0xB48095a68501bC157654d338ce86fdaEF4071B24"
[Install]
WantedBy=multi-user.target
Save and exit the file
CTRL+O
Press the ENTER key
CTRL+X
# Enable and start the system service using:
sudo systemctl enable orchestratord.service
sudo systemctl start orchestratord.service