
SUI Network - complete guide to run a Node & Validator
SUI is a layer 1 blockchain designed by Mysten Labs from the ground up in smart contract specific language called MOVE This guide will go over installing a Full Node and Validator from scratch in order to run a Sui network node, assumes a fresh install of Ubuntu 20.04LTS. Hardware Requirements: Node Requirements: Full node requirements are lower, but storage can be expected to increase over time CPUs: 2 RAM: 8GB Storage: 50GB Validator Requirements: Validators perform work and deal with chain...

Easy Guide to Gnosischain Validator - with Lighthouse
This guide is help you set up a Gnosischain Validator, this will cover the full set up on a local device installed with Ubuntu 20.04 LTS. We will be using Lighthouse for consensus layer client and Nethermind for our Execution layer client. Gnosischain merge is on the horizon, this guide is intended to be merge ready the set up will cover steps and configuration needed to run post merge, and today. Gnosischain is using Ethereum Proof of Stake consensus with the Beacon chain to select validator...

Cosmos Full Node
Deploy a full node for cosmos chain Cosmos hub is the economic centre of the Interchain cosmos ecosystem. Full node is a node that does not build blocks (non-validating) but stores the chain state and allows direct access to the network. NOTE: full node refers to a non-archival implementation of the node.Cosmos: The Internet of BlockchainsCosmos is an ever-expanding ecosystem of interoperable and sovereign blockchain apps and services, built for a decentralized future.https://cosmos.networkHa...
$ETH Solo Staker #stakefromhome

SUI Network - complete guide to run a Node & Validator
SUI is a layer 1 blockchain designed by Mysten Labs from the ground up in smart contract specific language called MOVE This guide will go over installing a Full Node and Validator from scratch in order to run a Sui network node, assumes a fresh install of Ubuntu 20.04LTS. Hardware Requirements: Node Requirements: Full node requirements are lower, but storage can be expected to increase over time CPUs: 2 RAM: 8GB Storage: 50GB Validator Requirements: Validators perform work and deal with chain...

Easy Guide to Gnosischain Validator - with Lighthouse
This guide is help you set up a Gnosischain Validator, this will cover the full set up on a local device installed with Ubuntu 20.04 LTS. We will be using Lighthouse for consensus layer client and Nethermind for our Execution layer client. Gnosischain merge is on the horizon, this guide is intended to be merge ready the set up will cover steps and configuration needed to run post merge, and today. Gnosischain is using Ethereum Proof of Stake consensus with the Beacon chain to select validator...

Cosmos Full Node
Deploy a full node for cosmos chain Cosmos hub is the economic centre of the Interchain cosmos ecosystem. Full node is a node that does not build blocks (non-validating) but stores the chain state and allows direct access to the network. NOTE: full node refers to a non-archival implementation of the node.Cosmos: The Internet of BlockchainsCosmos is an ever-expanding ecosystem of interoperable and sovereign blockchain apps and services, built for a decentralized future.https://cosmos.networkHa...
$ETH Solo Staker #stakefromhome

Subscribe to GLCstaked

Subscribe to GLCstaked
Share Dialog
Share Dialog


<100 subscribers
<100 subscribers
This is intended to be a user-friendly guide for anyone with little experience, I will be updating this as the Phases open up throughout the Testnet, and include later Testnet’s with Obol here as well.
THIS GUIDE IS NOW DEPRECATED AS IS THE ATHENA TESTNET, PLEASE SEE THE FOLLOWING FOR THE CURRENT BIA TESTNET
Obol Network is building technology for distributed validators (DVT) this essentially turns Ethereum Validators into a multi-sig, where a validator operates across a cluster of nodes in order to improve resilience (safety, liveness, or both) as compared to running a validator on a single node.
This opens the path to institutional staking as a validator can be secured to higher standards required by institutions.
This also democratises ETH staking, allowing users with much less than 32 $ETH required to run a single validator.


Obols distributed validators can connect to various consensus layer and execution layer clients forming a truly credible neutral layer.
If you want to dive deeper on Obol’s technology this is a great introduction by @solardefi. and the Docs can be found here.
The First public Testnet Athena is now live (8th July 2022), Charon-Obol’s distributed validator client will be tested by a larger community of Node Operators.
You will need to run the Charon client briefly to generate an ENR private key for use in a scheduled Distributed Key Generation ceremony.
see the article on Athena Testnet, to find the form to fill if you wish to apply to join this Testnet
Hardware Requirements: Wired connection to a local device with at least 8GB memory (I am using 16GB with no issues) 4 core CPU, would recommend starting with 500GB at minimum, as a node operator you're providing a service, so best to start with good hardware that will last and perform up to standard.
This guide is assuming you have a fresh install of Ubuntu 20.04 LTS, I am running locally. Navigate to the terminal.
Update the device
sudo apt update && sudo apt upgrade -y
Install pre-requisite software
we need to install curl and git
sudo apt install curl git -y
Install docker
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh
change permissions and check you have installed correctly
sudo usermod -aG docker $USER
docker --version
Download Charon
git clone https://github.com/ObolNetwork/charon-distributed-validator-node.git

Generate your Charon ENR private key
change directory
cd charon-distributed-validator-node
run the following to generate your ENR private key
sudo docker run --rm -v "$(pwd):/opt/charon" ghcr.io/obolnetwork/charon:v0.8.1 create enr

Copy your ENR private key and back this up
you need this ENR key for your Testnet application. its a good idea to keep a backup copy locally and elsewhere. You can simply copy and save this to a text file.
Backup your Private key
make a backup of your private key, (do not submit this in your application)
The private key is stored in .charon within charon-distributed-validator-node folder, The file we are locking for is called charon-enr-private-key i’ve chosen to save a copy in Documents/backups.
Make the folder
mkdir /home/<user>/Documents/backups
Note: change to your username on your device. sudo cp /home/<user>/charon-distributed-validator-node/.charon/charon-enr-private-key /home/<user>/Documents/backups
In order to freely move this (if you want to save to another device) we need to change permissions. sudo chown <user>:<user> /home/<user>/Documents/backups/charon-enr-private-key
Step 2. Leader creates the DKG configuration file and distributes it to everyone else Assigned cluster captain will do this stage Cluster Captain- Create an .env file cd charon-distributed-validator-cluster
cp .env.sample .env
Here we can cloned the example .env file which we can now see in our working directory, we will populate with our clusters unique details. Cluster Captain- Open .env for editing our cluster details We need to first get the ENR keys from each member in our cluster (IMPORTANT: these must match with the Private Keys created in Step 1, so make sure that the cluster members have double checked the correct file is in use) Now open the env for editing in the terminal, to fill in our members unique ENR keys nano .env
Place ENR keys for each member (Cluster Captain first) separated by comma no space, include the ENR:- prefix like so Cluster Captain- runs DKG configuration Replace the following $NAME = name of your cluster $FEE_RECIPIENT_ADDRESS = Eth address of our Deposit address $WITHDRAWAL_ADDRESS = Eth address of our Deposit address These can be set as variables, but I simply replaced into the command, Recommended to create a new ETH wallet to use as our deposit and fee address. sudo docker run --rm -v "$(pwd):/opt/charon" --env-file .env obolnetwork/charon:v0.9.0 create dkg --name=$NAME --fee-recipient-address=$FEE_RECIPIENT_ADDRESS --withdrawal-address=$WITHDRAWAL_ADDRESS
Cluster Captain- Shares Configuration file with Cluster Members Find the file in the directory cd charon-distributed-validator-node/.charon
ls -la
Copy to our backups directory so we can extract and share with the other team members sudo cp /home/<user>/charon-distributed-validator-node/.charon/cluster-definition.json /home/<user>/Documents/backups
Change permissions sudo chown <user>:<user> /home/<user>/Documents/backups/cluster-definition.json
You should now be able to extract this file from your device and share with other Cluster members Other Cluster members- Receive cluster-definition.json Other cluster members should now receive the cluster-definition.json
This is intended to be a user-friendly guide for anyone with little experience, I will be updating this as the Phases open up throughout the Testnet, and include later Testnet’s with Obol here as well.
THIS GUIDE IS NOW DEPRECATED AS IS THE ATHENA TESTNET, PLEASE SEE THE FOLLOWING FOR THE CURRENT BIA TESTNET
Obol Network is building technology for distributed validators (DVT) this essentially turns Ethereum Validators into a multi-sig, where a validator operates across a cluster of nodes in order to improve resilience (safety, liveness, or both) as compared to running a validator on a single node.
This opens the path to institutional staking as a validator can be secured to higher standards required by institutions.
This also democratises ETH staking, allowing users with much less than 32 $ETH required to run a single validator.


Obols distributed validators can connect to various consensus layer and execution layer clients forming a truly credible neutral layer.
If you want to dive deeper on Obol’s technology this is a great introduction by @solardefi. and the Docs can be found here.
The First public Testnet Athena is now live (8th July 2022), Charon-Obol’s distributed validator client will be tested by a larger community of Node Operators.
You will need to run the Charon client briefly to generate an ENR private key for use in a scheduled Distributed Key Generation ceremony.
see the article on Athena Testnet, to find the form to fill if you wish to apply to join this Testnet
Hardware Requirements: Wired connection to a local device with at least 8GB memory (I am using 16GB with no issues) 4 core CPU, would recommend starting with 500GB at minimum, as a node operator you're providing a service, so best to start with good hardware that will last and perform up to standard.
This guide is assuming you have a fresh install of Ubuntu 20.04 LTS, I am running locally. Navigate to the terminal.
Update the device
sudo apt update && sudo apt upgrade -y
Install pre-requisite software
we need to install curl and git
sudo apt install curl git -y
Install docker
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh
change permissions and check you have installed correctly
sudo usermod -aG docker $USER
docker --version
Download Charon
git clone https://github.com/ObolNetwork/charon-distributed-validator-node.git

Generate your Charon ENR private key
change directory
cd charon-distributed-validator-node
run the following to generate your ENR private key
sudo docker run --rm -v "$(pwd):/opt/charon" ghcr.io/obolnetwork/charon:v0.8.1 create enr

Copy your ENR private key and back this up
you need this ENR key for your Testnet application. its a good idea to keep a backup copy locally and elsewhere. You can simply copy and save this to a text file.
Backup your Private key
make a backup of your private key, (do not submit this in your application)
The private key is stored in .charon within charon-distributed-validator-node folder, The file we are locking for is called charon-enr-private-key i’ve chosen to save a copy in Documents/backups.
Make the folder
mkdir /home/<user>/Documents/backups
Note: change to your username on your device. sudo cp /home/<user>/charon-distributed-validator-node/.charon/charon-enr-private-key /home/<user>/Documents/backups
In order to freely move this (if you want to save to another device) we need to change permissions. sudo chown <user>:<user> /home/<user>/Documents/backups/charon-enr-private-key
Step 2. Leader creates the DKG configuration file and distributes it to everyone else Assigned cluster captain will do this stage Cluster Captain- Create an .env file cd charon-distributed-validator-cluster
cp .env.sample .env
Here we can cloned the example .env file which we can now see in our working directory, we will populate with our clusters unique details. Cluster Captain- Open .env for editing our cluster details We need to first get the ENR keys from each member in our cluster (IMPORTANT: these must match with the Private Keys created in Step 1, so make sure that the cluster members have double checked the correct file is in use) Now open the env for editing in the terminal, to fill in our members unique ENR keys nano .env
Place ENR keys for each member (Cluster Captain first) separated by comma no space, include the ENR:- prefix like so Cluster Captain- runs DKG configuration Replace the following $NAME = name of your cluster $FEE_RECIPIENT_ADDRESS = Eth address of our Deposit address $WITHDRAWAL_ADDRESS = Eth address of our Deposit address These can be set as variables, but I simply replaced into the command, Recommended to create a new ETH wallet to use as our deposit and fee address. sudo docker run --rm -v "$(pwd):/opt/charon" --env-file .env obolnetwork/charon:v0.9.0 create dkg --name=$NAME --fee-recipient-address=$FEE_RECIPIENT_ADDRESS --withdrawal-address=$WITHDRAWAL_ADDRESS
Cluster Captain- Shares Configuration file with Cluster Members Find the file in the directory cd charon-distributed-validator-node/.charon
ls -la
Copy to our backups directory so we can extract and share with the other team members sudo cp /home/<user>/charon-distributed-validator-node/.charon/cluster-definition.json /home/<user>/Documents/backups
Change permissions sudo chown <user>:<user> /home/<user>/Documents/backups/cluster-definition.json
You should now be able to extract this file from your device and share with other Cluster members Other Cluster members- Receive cluster-definition.json Other cluster members should now receive the cluster-definition.json
backupsls -lacluster-definition.json.charon.charonvalidator_keys/deposit-data.jsoncluster-lock.json192.168.0.1docker-compose.ymldistributed-charon-validator-nodeversion:3.3version: “3.3”deposit-data.jsondeposit-data.jsondocker-compose.yml,Teku keystore file /path/to/keystore-*.json.lock already in use--validators-keystore-locking-enabled=falsebackupsls -lacluster-definition.json.charon.charonvalidator_keys/deposit-data.jsoncluster-lock.json192.168.0.1docker-compose.ymldistributed-charon-validator-nodeversion:3.3version: “3.3”deposit-data.jsondeposit-data.jsondocker-compose.yml,Teku keystore file /path/to/keystore-*.json.lock already in use--validators-keystore-locking-enabled=false
No activity yet